thoughts about branches

[Michael Tautschnig]

[...]
> 
> We should think about a bugs branch in svn. Why do we create bugs
> subdir under people/<name>/ directories? If I'm looking for a certain
> patch for a bug, this patch is (or should not be) not related to a
> certain person. 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.
Basically, I'd appreciate this - at the moment each of the people-users has
created a bugfixes-branch; but we need to find some way to coordinate this -
either by explicitly stating the editors in some file within the
bugfix-number-sub-branch or via this list.

> 
> 
>     > - 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?
Maybe you should do that, maybe the bugfix-author should do it - in any case,
some coordination between you and the author is required (might be personal
mail).

> 
> 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?
Maybe my "bugfix" was the one suprising you most, as it is really small. But I
thought the svn is an ideal place to collect all those patches from the BTS to
make it a lot easier to apply them to trunk.

Furthermore, although I have quite some new code (which I have partially already
posted to the BTS), I think fixing bugs is currently a lot more urgent than many
new features. Once we have closed many of those mostly small bugs, we can start
implementing new features... However, this is an entirely different discussion.

Best regards,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.uni-koeln.de/pipermail/linux-fai-devel/attachments/20051018/21dacbce/attachment.bin