-----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-----