Freezes and Git Migration

[Hugo Parente Lima]

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.

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.

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.

Anyway it's just my opinion, given my experience working with git every day, 
I'm not a kdevelop developer, just a user and enthusiast. The perfect git 
work-flow is a developer choice and there aren't one work-flow suitable for 
every project, I'm sure that you will pick up the best one for kdevelop.
 
> Just my 2 cents.
> Nitin

-- 
Hugo Parente Lima
"Precisamos de mais gênios humildes no mundo, hoje somos poucos!"
JID: hugo at jabber.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100426/9f0dc820/attachment.sig>