Christian Boos | 2 May 10:17
Picon
Favicon

[Trac-dev] /branches/0.11-stable write permission access


Hi Jonas,

It seems I don't have the write permission there.
Please add it for me and others.

Also, you could take this opportunity to kill the old developer-specific 
branches (cboos-dev, cmlenz-dev, etc.). Christopher was OK with that.

-- Christian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Jonas Borgström | 2 May 10:42
Favicon

[Trac-dev] Re: /branches/0.11-stable write permission access


Christian Boos wrote:
> 
> Hi Jonas,
> 
> It seems I don't have the write permission there.
> Please add it for me and others.

It should work now. I also initialized merge tracking.

> Also, you could take this opportunity to kill the old developer-specific
> branches (cboos-dev, cmlenz-dev, etc.). Christopher was OK with that.

Yes, will do.

/ Jonas

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Christian Boos | 2 May 11:04
Picon
Favicon

[Trac-dev] Re: /branches/0.11-stable write permission access


Jonas Borgström wrote:
> Christian Boos wrote:
>   
>> Hi Jonas,
>>
>> It seems I don't have the write permission there.
>> Please add it for me and others.
>>     
>
> It should work now.

Yes it does, thanks!

>  I also initialized merge tracking.
>   

Well, from the lesson learnt during 0.10-stable maintenance, I can say 
that using svnmerge for tracking to merges from trunk to stable quickly 
becomes unusable, as there's too much manual maintenance to do for the 
"blocked" changes and the situation, while manageable at the beginning, 
only worsen over time, as more and more changes need to be blocked.

However, it could eventually work if the merges are done in the other 
direction (from stable to trunk), as bug fixes should usually also apply 
to trunk. For example, this is what the Mercurial project does, they 
have an hg-stable branch where they do the bug fixes, and that branch 
regularly gets merged into the default branch (the development branch 
for the next version). This minimizes the merge tracking maintenance.

(Continue reading)

osimons | 2 May 11:53
Picon

[Trac-dev] Re: /branches/0.11-stable write permission access


On May 2, 11:04 am, Christian Boos <cb...@neuf.fr> wrote:

> Well, from the lesson learnt during 0.10-stable maintenance, I can say
> that using svnmerge for tracking to merges from trunk to stable quickly
> becomes unusable, as there's too much manual maintenance to do for the
> "blocked" changes and the situation, while manageable at the beginning,
> only worsen over time, as more and more changes need to be blocked.
>
> However, it could eventually work if the merges are done in the other
> direction (from stable to trunk), as bug fixes should usually also apply
> to trunk. For example, this is what the Mercurial project does, they
> have an hg-stable branch where they do the bug fixes, and that branch
> regularly gets merged into the default branch (the development branch
> for the next version). This minimizes the merge tracking maintenance.
>

I like that idea. It would make for fewer changes to sync, and as the
differences between branch and trunk increases over time it becomes
more likely that a merge could break something unexpected. Better it
breaks in trunk than in the stable branch.

That then means we need to make the 'backport' decision at commit
time, and commit to branch or trunk as appropriate. A periodic sync
should then be OK.

Which again raises a new question of all the changes scheduled for
0.11.x, and the development policy that has so often been discussed:
Only major bug and security features for stable brances, and new
development happens in trunk for next major version. Based on this
(Continue reading)

Christian Boos | 2 May 15:14
Picon
Favicon

[Trac-dev] Re: /branches/0.11-stable write permission access


Hello Odd Simon,

(first let me make a note about the terminology I'll use below: I'll 
refer to 0.11, 0.12 as being "major" versions and "0.11.1", "0.12.1" as 
"minor" ones)

osimons wrote:
> On May 2, 11:04 am, Christian Boos <cb...@neuf.fr> wrote:
>   
>> Well, from the lesson learnt during 0.10-stable maintenance, I can say
>> that using svnmerge for tracking to merges from trunk to stable quickly
>> becomes unusable, as there's too much manual maintenance to do for the
>> "blocked" changes and the situation, while manageable at the beginning,
>> only worsen over time, as more and more changes need to be blocked.
>>
>> However, it could eventually work if the merges are done in the other
>> direction (from stable to trunk), as bug fixes should usually also apply
>> to trunk. For example, this is what the Mercurial project does, they
>> have an hg-stable branch where they do the bug fixes, and that branch
>> regularly gets merged into the default branch (the development branch
>> for the next version). This minimizes the merge tracking maintenance.
>>
>>     
>
> I like that idea. It would make for fewer changes to sync, and as the
> differences between branch and trunk increases over time it becomes
> more likely that a merge could break something unexpected. Better it
> breaks in trunk than in the stable branch.
>
(Continue reading)

osimons | 4 May 21:37
Picon

[Trac-dev] Re: /branches/0.11-stable write permission access


On May 2, 3:14 pm, Christian Boos <cb...@neuf.fr> wrote:
> > That then means we need to make the 'backport' decision at commit
> > time, and commit to branch or trunk as appropriate. A periodic sync
> > should then be OK.
>
> Yes, this is mostly deciding whether it's a bug fix as opposed to an
> enhancement.
> Also, a bug that needs an API or a behavior change in order to be fixed
> should not be targeted for 0.11-stable.

I wasn't committing at last major stable branching, so I'm hesitant to
be the judge of what the best practice actually would be. I'm fine
either way, I think.

What do others think? If we are to switch policy on this we really
should decide asap.

> > An 0.12 release that should not be in the far too distant future,
> > btw... :-)
>
> That would have been the topic of another mail (and there will certainly
> be more detailed ones to come), but now while we are at it...
>

I'll make that a topic of another reply - my immediate need is to
figure out where to commit my bugfixes...

:::simon

(Continue reading)


Gmane