[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: feature branch during freeze
From:       Cyrille Berger <cberger () cberger ! net>
Date:       2010-09-08 6:20:30
Message-ID: 201009080820.30578.cberger () cberger ! net
[Download RAW message or body]

First all, no one can prevent anyone to make his own branch, or a group to 
make his own branch for any purpose, or to work on anything. We have to 
acknowledge that some people have different agendas, different goal.

At the end of the day, people who work on bug fixing will get the credits to 
have made KOffice ready.

On Tuesday 07 September 2010, Thomas Zander wrote:
> On Tuesday 7. September 2010 20.29.20 Jaroslaw Staniek wrote:
> > Again, it's a matter of trust and attitude.
> 
> And of experience; the last time it was clear that a large part of our
> regular contributor did not fix any bugs on the main branch.

I guess, it varies from applications to applications... In Krita bugs were 
fixed in trunk, otherwise you would get a spanking from its maintainer. I 
suggest other maintainers do the same with their slav^D euhm contributors. In 
other word, this branch is a *new-feature-only* branch, people should not 
commit bug fixes there, they should commit it to trunk. Hopefully, the game 
rule is clear.

> > While I understand the risks, I am also a bit lost since I remember
> > you as a relatively strong supporter of git/gitorious; a tool that
> > largely encourages branching at any time of the development process.
> 
> This redirecting the thread to Git is thus not really relevant; when we get
> git.kde.org in use, we can reopen the topic for sure.
Different tool, different workflow. With git, features are developed in branches, 
and are merge in the release branch when sufficiently ready. In svn, features 
are developed in the release branch and might not be sufficiently ready.

To take as example the text-on-shape feature.

With svn, Thomas start working on it, he publish a single patch on review-
board, then Boudewijn applies that patch locally and start refactoring it to 
get loading and saving, then a discussion happen on the two approach. Thomas 
solution is chosen, he applies it to trunk, despite several problems that are 
not solved at that point, because it is the most convenient way to work on a 
feature. And they might still not be solved now that the release branch is 
frozen.

With git, Thomas starts a new branch, he publish the branch, then Boudewijn 
forks the branch and refactor it to get loading and saving, then a discussion 
happen on the two approach. Thomas solution is chosen. From that point, it 
gets really different from svn, Thomas keep working in his branch on fixing the 
issues, until all major problem are solved, and then he merge the branch in 
the release branch, which might have already branched for the 2.3 release, in 
such case the feature will only appear in 2.4.

I hope it clarifies why git branches are less likely to trigger problem.

-- 
Cyrille Berger
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]