On 23/11/13 11:55 +0100, Sergi Almacellas Abellana wrote: > El 17/11/13 19:49, Cédric Krier ha escrit: > >Hi, > > > > From the discussion about the development workflow, some complaints > >were the missing of branches (called in mercurial named branch). > >I still don't know if we should switch to named branch or not but to see > >what it could be I created a testing repository [1] with all named > >branches by merging all the clone branches of trytond. > Goood news! For me is the way to go as you will have all versions' > history on the same repo and you can easly switch between branches > (no need to clone another repo).
That's a minor point because doing an hg nup 3.0 will take some times any way. > I can't see any point to don't move to named branches. > > >I made the choice to not rewrite the history (rewrite history is bad) > >and so keep old clone branch are in the default named branch and I just > >created named branch for the future. (So it will be possible to pull > >from any clone branch from this new repository.) > > > >Once we have such repository, there are two workflows to maintain the > >series: > > > > - by cherry picking, it is the already used workflow (with > > transplant). The advantage will be to use “graft” which could use > > the internal of mercurial to make better conflict merge than > > “transplant”. > > So with this way, there will be no change in the development and > > we could still push fixes in trunk/default and backport one week > > later to old affected series > IMHO i think this will be the easiet way to maintain the series. Also > if some user has a bugfix on al older series it can also be fixed on > the named branch and upported to superior series if needed. But it is not the common way to manage named branches except when there is a too big grap between branches. For example Python, use graft only for 2.7 branches, the 3.x branches follow the merging way. > > - by merging branch, this workflow is about fixing the bug in the > > oldest branch affected and then merging the fixed branch to the > > upper one and so on. In this workflow, we will no longer have the > > one staging week before commiting fixes in series and we will need > > to ask to contributor to provide such complex patches or the > > developpers will have to commit them instead of contributor. But > > it will have the advantage to make the decision about which > > branches must be fixed on early stage and also share the > > responsability of maintaince of series to all developpers. > I think this workflow will make bug fixing workflow harder, so I will > be against it. Yes, we will need to educate the few developpers. The contributor will be taken away of this because we could not request non developper to manage the merging (and provide patches of it) But if it is to follow the graft way, I don't really see a big benefit that will deserve to migration. -- Cédric Krier - B2CK SPRL Email/Jabber: [email protected] Tel: +32 472 54 46 59 Website: http://www.b2ck.com/
pgpqfWpoDVSwn.pgp
Description: PGP signature
