thoughts about branches

[Henning Sprang]

On Tue, 2005-10-18 at 00:33 +0200, Thomas Lange wrote:
> >>>>> On Sun, 16 Oct 2005 13:44:42 +0200, Henning Sprang <henning_sprang at gmx.de> said:
> 
>     > - if we need multiple small patches like that, they still get made that
> I think small patches are not worth to create a new branch in
> svn. Just add the diffs to the BTS for this bug. IMO this make thinks
> much easier, because I do not have to look at the BTS and into all
> peoples branches.

I don't agree. In my opinion, subversion should serve also to make
testing patches from other people easier. Remember how we all dislike
manual interaction? Pulling a patch from svn is much easier than from
BTS, and that raises the probability that more people test some patches,
because testing is easy.

And because it should be possible to easily test only a single patch,
even a one line change is useful to live in an extra branch. If you
inherently need two patches together, because they somehow depend on
each other (like now two different fai-cd bugs - you need both to create
a working cd), you would merge them together in a release branch for the
next release. So, as it's described in the svn book, and as you proposed
yesterday, we should already now have a release branch for FAI 2.8.5,
and mix there together bugfixes from 320024 and 334333, which should be
both independently in subversion. 


> We should think about a bugs branch in svn. Why do we create bugs
> subdir under people/<name>/ directories?

Simple: Michael and me wanted to work on those bugs, we are not allowed
to do stuff in /trunk /branches and /tags, so we needed a place where we
could put our code that fixes bugs.

>  If I'm looking for a certain
> patch for a bug, this patch is (or should not be) not related to a
> certain person.

When somebody fixes a specific bug in his people branch successfully, he
should document that in the BTS. So, its easy to find, and, through svn
easy to apply and test for others.

>  Currently I have to checkout all peoples branches and
> search in these directories. 
> With a new bugs branch I can find a patch
> for this bug very quickly.

But do you want to do only _one_ single bugfix branch, and fix _all_
bugs in there? How will you then extract single patches?

Or do you propose to have something like /branches/bug/<BUGNUMBER> for
each bug? That I think is an idea we could consider. Still, it could
only be a problem if two people want to implement and propose completely
conflicting fixes for a bug. A decision which of those fixes is "better"
can only be made, when the different fixes are easily available in svn,
and can therefore independently and easily tested by others. 

This, though, should not happen too fast, normally a developer should
first communicate with others if he thinks somebody else's bugfix is
inapropriate. Only if there can't a decision be made, for example becaue
multiple people need to test the different "flavors" of a fix, somebody
should create it's own, additional bugfix branch. But maybe that's a too
specific case.

How would we regulate who is allowed to commit in
which /branches/bugfix/<BUGNUMBER> branch? As For now, "normal"
developers are not allowed to commit anywhere but /people/, but we need
to commit in svn to share our bugfix proposals.

With that considered, having all in /people is still easier. It's then
up to you to merge the best bugfix for a bug into a release branch, or
delegate that work to a single developer by private mail, in case you
have no time. That gives all of us freedom to do work when we have
sparetime, and that is important to make our work efficient. It's
blocking developmentand therefore frustrating if I want to deliver a
solution, but have to wait for allowance to commit
in /branches/bugs/<BUGNUMBER>.

But maybe we'll need some strategy on where people work together, even
on feature branches:

Example:
When Florent and me will work on fai-multi-distribution, where will we
do that?
in /people/lazyboy/fai-multi-distribution or
in /people/florent/fai-multi-distribution ? or both, and the results
will be merged in /braches/fai-multi-distribution? 

Probably that's far too complicated, in that case it would be good to
have /branches/fai-multi-distribution, and Florent and me (and anybody
else interested) are allowed to commit there.


> 
>     > - we need to keep book about which patch (say, changes in which branch)
>     > we already merged into which other branch, when.
> 
>     > - we need to think about what we do to get those patches into the trunk,
>     > also, because we most often will want and need them there, also.
> Should I delete a certain bug branch if it is included into the trunk?

I am not sure if it's enough when it's in the trunk. It must probably
also be in the release branches from which future release are possible
because they do not ultimately get changes from the trunk. This can vary
from time to time, not sure if there can be set up a simple rule in one
sentences when what has to ber merged where before a branch can be
deleted. So a bit of care has to be taken before a branch gets deleted.

> 
> I was very supprised when I say the first people branch only for a
> single bug. I thought people branches are made mainly for new features
> or maybe also for bigger bug fixes. But maybe I'm wrong. Should we
> really want to create a branch for every single small bug?

That's the things we didn't talk about explicitly until now, but here we
are :) It's good to talk about it now, and I think we should, as soon as
we have some consense here, add some sentences to the svn howto, and I
will make a proposal (keeping in mind that the howto, which also serves
as our svn policy, should be as clear, easy and short as it can be, but
it should not sacrifice importan information just for the sake of
shortness) for that these days.

BTW: the svn book says: "branches are cheap, so use them liberally" ...

Henning