Hi Paul, 2010/6/21 Paul Poulain <[email protected]>: > The technical fact : > - we (BibLibre) have 450+ patches on git.biblibre.com, master branch, > that are not in git.koha-community.org (new features & bugfixes) > - koha-community has 100 patches that are not on biblibre/master
Ouch! > > So : if we do nothing, in a few *weeks*, we will have a fork that we > want to avoid ! Great! > > 1-Release 3.2 : > ============= > hdl will take care this next two weeks of the 2 BLO related to > updatedatabase & affected to him > > 2 - rebase biblibre/master on koha/master > ============== > We (BibLibre) take care of rebasing our master at a date we define > altogether. As that will be a HUGE work, you (chris) don't apply any other > patches while we rebase to avoid breaking our work. We think we would need > one week (maybe two) to rebase & test properly. I think, this would be the place to implement the first of Chris' suggestions: Have hdl (or whoever) do this merging in such a way as to produce smaller feature-centric branches. (Think "bite sized" pieces.) However, I think this must be done concurrent to development on 3.4. We must also consider that if we are ever to have schedule based releases, we *must* take this opportunity to hold on to a stable master and use branching along with merging to facilitate ongoing development while maintaining that stable master. So here is a good place to begin. As BibLibre finishes up merging on a particular feature branch, QA can immediately pickup with testing and then the RM take care of merging the tested branch into master, thus keeping master stable. I think if everyone pitches in that this could all happen in a month time frame. As you say, these new features are in production on several of your large clients, so they should not be too buggy. > > 3/4 - push biblibre patches on koha/master > ============== > You (chris) push our 450+ patches on koha/master. Since the new rules were > not defined when we wrote all this code, those patches don't abide by those > rules and can't. As Chris and Nicole have pointed out, I don't think a direct push into a stable master of this large of a patch set will prove beneficial to anyone. > > 5 - define rules > ============== > Once 3.2 is released, we (community) set all rules (Including coding style, > test cases, choosing OO pattern, standard commit notes,...) and everybody > use them - including us (BibLibre) we don't request to be favored - > > 6 - work on 3.4 > ============== > All RFCs we wrote on the wiki are now implemented for our Nimes & Lyon 3 > customers. If something new comes, we will respect fully the new rules. > There may be some patches fixing Lyon3/Nimes features that won't respect > them, but, hopefully, there will be only a few of them (Lyon3 is live, Nimes > go live next week, so it's really stable) The rest of this naturally follows along of course. We need some enforcement of rules especially as the project gets bigger and larger support companies are pushing the development at a greater pace. It will be especially imperative that those who have the resources to push development faster adhere more strictly to good coding/testing/etc practices as messy code in large quantities will quickly produce chaos and be of little use in the long haul. Kudos to BbLibre for being open and transparent in all of this and for requesting community input as they undergo growing pains. Kind Regards, Chris _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
