Freezes and Git Migration

[Andreas Pakulat]

On 26.04.10 00:58:06, Hugo Parente Lima wrote:
> On Sunday 25 April 2010 22:28:44 Nitin Gupta wrote:
> > On 04/26/2010 01:37 AM, Andreas Pakulat wrote:
> > > One last thing: I'm not sure wether we talked about this yet, but once
> > > we do live in git I think we should go with the usual (at least for
> > > now): "Bugfixes should always be done in the oldest branch that you want
> > > it to be in, usually not in master" and then merge the current stable
> > > branch into master on a regular basis (I'm thinking about once a month).
> > > There are other development models (amarok uses one, another is
> > > explained here: http://www.nvie.com/git-model), so if anybody is of
> > > different opinion please open a new thread about that.
> > 
> > With this model, what is the way to get the bleeding edge code?
> > As I understand, new feature development will be based on master while
> > bugfixes will on "oldest branch you want it to be in" and sync to master
> > will happen once in a month. So, there will be no way to get all the latest
> > features with all the known fixes?
> > 
> > Maybe all fixes should be automerged to master as soon as something is
> > committed to other stable branch? Maybe the developer doing the fix should
> > make sure that the fix is ported properly to main?
> 
> I agree, if the last release was 4.3.1, the bug fix would be merged into 
> mainline and on 4.3.2 branch.
> 
> IMO, the bug fix should be merged just on the last version branch and on 
> master, if you released 4.3.1, doesn't make sense to apply the bugfix onto 
> 4.2.9 branch, even if the bug still there, because this branch won't never be 
> released.

We might not release it, but packagers can potentially still pick it up.
There are still people fixing ocassional grave bugs in KDE3.5 too ;)

> After all are just two merges, and merging early reduces the chances of 
> conflicts. Conflict resolution, manual or automatic is always a opportunity for 
> the rise of new evil bugs.

Yes, but I don't want to have a merge commit for every single bugfix,
that just pollutes the history in master/branches.

> Other problem, developers works on code in master branch, so you will develop 
> new features with a annoying bug that you known that it was fixed, but you need 
> to wait until the end of the month to see it fixed on your tree.

As I said to Niko, we could reduce to one week that should make it
a lot less painful for everybody.

Andreas

-- 
You will be called upon to help a friend in trouble.