15 Oct
2014
15 Oct
'14
4:09 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
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!
Tim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iFYEARELAAYFAlQ983MACgkQLaxZSoRZrGEx5ADeNYtJaoJmUaRXV3HYDtrsXQu8
PvsdRiOpkr340gDghJzNpVIIylDuByl8o8lBdOMHQq279JCb/wbgcA==
=wm7b
-----END PGP SIGNATURE-----