Message: previous - next
Month: October 2014

Re: [trinity-devel] R14 hard freeze for RC1

From: "Timothy Pearson" <kb9vqf@...>
Date: Tue, 14 Oct 2014 23:09:23 -0500
Hash: SHA224

> My two cents about bug and development through the freeze period.
> 1) About the remaining 3 bugs.
> - bug 1850: I don't see it as fully blocking. WE could release v14.0.0
> even if not control module tabs have been updated to open the correct
> handbook. Of course it would be nice to fully close the bug, but if not
> we can leave the remaining things for the first subsequent maintenance
> release v14.0.1

Considering the amount of time required for the archive rebuild I would
think we can close this report out for RC2/R14 final, especially with more
than one developer working on it as it is mostly grunt work.

> - bug 1859: documentation is almost fully updated (I still have a few
> list to do, which I should be able (or at least I hope) to do within
> this week. I can push all the doc updates in one cumulative push when
> ready. After that there are two more things to do. One is sorting the
> top level list (not critical, but should not be too long) and one is to
> add a button for manually updating the top level list (this is more
> important)

Sounds good!

> - bug 2152: I haven't look at the details, but based on the two commits
> already made by Slavek it should not take long to fix.

Yeah, I was already looking at it.  I'm tentatively working on digikam if
you or Slavek want to tackle koffice.

> 2) about freezing, development and v14.0.x
> Tim, is it possible to create a GIT branch for v14.0.0 so that we can
> keep pushing patches *not to be in v14.0.0* to the main trunk? The main
> question here is actually "how are we going to maintain the v14.0.x
> branch when v14.0.0 has been release and the main trunk will be for
> v14.1.0"?

Ah yes, the branch issue.  Slavek posted some good ideas in his reply to
this message; conceptually branching is a good idea but the devil is in
the details.  We use several automated systems to not only provide
services (the build farm and patchset generator) but also to work around
GIT misfeatures such as the lack of automatically-tracking submodules.  I
need to carefully consider the technical end of this (including
scalability and load on the already overtaxed servers) before jumping in
and committing to a particular scheme.

Short answer: If I can technically make branching work in a somewhat
intuitive manner without overloading the servers Slavek's option 2 sounds
best.  This means we won't branch at this point anyway, so I have a bit of
breathing room to work on the site and such before RC1 release.

> Cheers
>    Michele
Thanks for starting the discussion Michele!

Version: GnuPG v1.4.9 (GNU/Linux)