RFC: Changing the way we handle sarge in the SVN

[Benjamin Seidenberg]

Sven Mueller wrote:
> Henrique de Moraes Holschuh wrote on 24/04/2006 04:46:
>   
>> On Sun, 23 Apr 2006, Benjamin Seidenberg wrote:
>>
>>     
>>> I think maintaining a sarge backport branch is silly, since it's only
>>> released once, and only differs from the main release by the changelog
>>> file. I suggest an alternate approach.
>>>       
>> That's incorrect.  Sarge backports often require a lot more than just
>> changelog changes. *Currently* they are that simple, but that will not
>> necessarily hold for the future.
>>     
>
> I have to second that: Normally, Sarge backports need a lot more than
> just changing debian/changelog, so I would want to keep the current
> sarge branch. It just happens that the sarge branch can currently be
> recreated easily from /trunk, so I do that from time to time, to make
> sure it includes all the fixes.
>
>   
>>> Once a release is prepared and finalized, do an svn copy of trunk to
>>> tags/<sarge-version>. Change the changelog there, and commit that
>>> revision, uploading from the tag. It saves time and effort, and saves
>>> the work of keeping the branch in sync.
>>>       
>> I have actually come to the conclusion that not being able to really track
>> what is inside a branch is too severe a hindrance, now that I got used to it
>> on arch-like systems :(  But the solution to that one is to switch away from
>> SVN, which is *not* something I am proposing.
>>     
>
> Actually, now that I used an arch-like system in the company, I feel SVN
> is much easier to handle. True, it is harder to keep track of which
> patch is in which branch, but the plus side is that you have one
> definite authority which has all the fixes (/trunk in one repository).
> In the company, the trip to an arch-like system was a short one, we
> reverted to SVN resp. CVS (depending on what was used for the project
> before baz) after just three weeks.
>
>   
>> I don't know which way is worse, now:  Keeping branches in sync with the
>> trunk, or reaplying all changes needed for a "function branch" (i.e. sarge
>> backport) to the trunk [a copy of it, actually] every time.  But we *really*
>> should pick whichever is less prone for disaster, and not whichever is
>> easier.
>>     
>
> Currently, keeping the branches in sync with trunk works relatively well
> and as long as the changelog entries of the branch always includes the
> patchsets applied, it is also relatively easy to make sure all necessary
> patches are applied. However, since the changes between sarge branch and
> /trunk are currently really small (changelog only), I do a recreation of
> the sarge branch when I'm not sure wether all patches had been applied.
>
> Same is true for the idled branch and the current (temporary)
> sarge-2.2.13 branch.
>
> cu,
> sven

Based on what both of you said, I have come to see the light and
withdraw my suggestion. Now lets work on getting .13 released.  It's
been working just fine on my server. I think the 12->13 delta is
somewhat minimal, do we want to skip experimental and go right to unstable?

Benjamin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-imapd-debian-devel/attachments/20060424/67e8ae51/signature.pgp