Hi, On Tue, Jul 1, 2008 at 2:17 AM, Paul POULAIN <paul.poulain@free.fr> wrote:

With 3.0RC1 done, git should now have only bugfixes. So I think it's time for a 3.2 branch.

I have no idea of how it can be done with git. Should be have 2 separate repos ? only one with a git checkout -b rel_3_2 origin/rel_3_2 locally to point on branch rel_3_2 ? That's probably the way to go. Git experts will have more ideas...

We definitely should have just one repository. I suggest keeping current development in HEAD, and establishing the 3.0 maintenance line as a branch the instant 3.0 enters general release. For now, if you or anybody else has 3.2 patches that they want to submit immediately, we can stick them into topical branches and merge them into HEAD after 3.0-maint branches off.

I think we should have a patches30@koha.org and a patches32@koha.org mailbox to send patches.

Unless having just one patches address becomes unmanageable, I would prefer not to fragment it. An author can signal if something is meant for 3.0. Since, with the possible exception of things like backporting mod_perl support, 3.0 should only accept bugfixes, there will be a period of time where many 3.0 patches will be immediately cherry-picked for 3.2.

What about a patch for 3.0 that must be ported to 3.2 ? Should the author of the 3.0 patch or the RM of 3.2 be responsible of the "cherry picking" ? someone specifically dedicated to this task ?

Cherry-picking should be the responsibility of the 3.2 RM - this is one of the reasons I'd prefer that the patches list stay unified. A patch author can give hints, of course.

Last question : who will be Release Maintainer for 3.0 ?

For the immediate future, I suggest that Joshua be Release Maintainer for 3.0, following (as I understand it) the tradition that the release manager becomes the maintainer. If somebody else wants to volunteer, though, that can be revisited.

To continue with the memcached thread : maybe the memcached, once done on 3.2, can be backported (for the core part only ?) to 3.0 to get speed improvement before 3.2 is released. That will be 3.0RM decision, but if asked, I would probably vote yes (once memcached stuff has been well tested on 3.2 branch)

mod_perl support would be a candidate for such treatment as well. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel