/branches/0.11-stable write permission access
Christian Boos
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
Jonas Borgström
>
> 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
Christian Boos
> 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.
>> 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.
Thanks! The browser quickjump list looks better now ;-)
-- Christian
osimons
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.
>
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
policy only be a few handfuls of the current 177 open tickets for 0.11-
stable should actually go in the branch, the rest should be targeted
for 0.12 in trunk.
An 0.12 release that should not be in the far too distant future,
btw... :-)
:::simon
https://www.coderesort.com
Christian Boos
(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.
>
> 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.
> 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.
Yeah, I think those are good guidelines, except for the "major"
qualifier: I see no reason that fixes for regressions, for minor bugs or
even trivial fixes shouldn't go in as well. Anything non-obvious could
of course benefit from some review, either here on Trac-dev or on tickets.
This is for 0.11.1 of course, the more the minor version number
increases, the more serious the bug should be. For example, 0.10.5dev
had very few "minor fixes".
> Based on this
> policy only be a few handfuls of the current 177 open tickets for 0.11-
> stable should actually go in the branch, the rest should be targeted
> for 0.12 in trunk.
>
A handful for 0.11, yes, but I think that for 0.11.1, a good deal of the
116 opened defects are worth addressing (e.g. I would consider fixing
something like 40 tickets fixed for 0.11.1 to be a good achievement).
There's a lot of triaging work that has to be done though (*), as:
- all 0.10.5 tickets should be moved forward (0.11.1 or later)
- some 0.11.1 defects and untriaged tickets are likely "worksforme"
- some 0.11.1 defects are actually enhancement requests and should be
moved to 0.12 or beyond
> 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 see two main directions for improving our development process for 0.12:
- don't be hesitant to make pre-release versions, clearly labeled as
such (0.12pre1 or 0.12alpha1), as soon as we feel we're having an
interesting enough new feature set to propose to our users
- instead of having only vague 0.12, 0.13 ... 1.0 milestones, also use
topic milestones (e.g. a wikidom milestone, for all tickets related to
the wiki refactoring) and use them to track progress on topic branches.
Once the branch is going to trunk, the topic milestone can be deleted
and the tickets retargeted to the corresponding milestone (0.12, 0.13,
whatever is current at the time the branch is merged). This is clearly
more telling than assigning something to 0.13 or 1.0: when it makes
sense, a bug or enhancement is assigned to a topic and when that topic
is ready it goes to a given version
Of course the two ideas are complementary: once we close one or two
topic branches, we can decide whether it would be adequate to create a
new pre-release.
I see only advantages in making pre-releases, let me discuss some of
them in more details.
1) Reference points during the 0.Xdev period
We already created a 0.12dev version on t.e.o instead of the too broad
"devel" that was used in the past. Nevertheless, we're still going to
have to ask about the actual trunk revision people used.
Also, we have a track record of having a very stable trunk. I see no
reason to change that, we should strive at making non-disrupting changes
on trunk, so that people who want to stay on the edge can continue to do
so. Or they could reduce the risks of accidentally updating to a bad
changeset by only updating from one pre-releases to the next. Such
pre-releases could be preceded by a mini-freeze period of a few days
where everyone test the current status in order to make sure we have a
reasonably stable intermediate version.
2) Better visibility for the API changes
During 0.11dev, the API was unstable and people were reluctant to adapt
their plugins because they had to follow a constantly moving target.
But having the freedom to introduce new APIs and make them evolve during
some time is precisely the purpose of a development period!
If we have intermediate versions, it gives the plugin developer an
reference point against which she can develop her plugin (as by
definition of a released version the API won't change). Moreover, it
gives us the possibility to document all the API changes between those
intermediate releases. That will help us to create the "final" API
change document, the one detailing the changes between major versions.
The plugin developer has everything to gain from this approach as well:
instead of wasting time adapting his "trunk" compatible plugin against
an API which has not yet stabilized, he can wait for the next
intermediate release, and get a summary of the changes he has to take
into account.
Not to mention we increase the chances to get feedback on the new or
modified APIs before they are actually frozen, which is what will happen
if plugin developers only start to adapt or create their plugin once the
major version is released.
To sum up, I'd like to propose the following API changes guidelines,
taking 0.12dev, 0.11-stable as examples.
a. APIs from 0.11 should not change in 0.11-stable
b. non-deprecated APIs from 0.11 have to be supported throughout
0.12dev (and beyond in 0.12-stable due to a.)
c. APIs deprecated in 0.11 can be dropped in 0.12dev (preferably not
at the very beginning of the development cycle, to ease transition)
d. new APIs can be introduced anytime in 0.12dev, preferably after
some review. However a note about the change should be added in a
CHANGES file. The status of the CHANGES will be frozen after each
intermediate release, so that one can quickly see what has changed since
the last intermediate release
Let me take an example to illustrate point d.
- r7290 introduces a "IFooBarListener", CHANGES looks like this:
----
Trac 0.12dev - interim release 'FooBar' (--, 2008)
* introduce IFooBarListener so that components can listen to various noises
----
- r7321 changes the spelling to IFoobarListener
----
Trac 0.12dev - interim release 'foobar' (--, 2008)
* introduce IFoobarListener so that components can listen to various noises
----
(no need to talk about the former transient spelling, we're "in flux")
- r7333 - time to release foobar,
----
Trac 0.12pre1 - interim release 'foobar' (May 30, 2008)
* introduce IFoobarListener so that components can listen to various noises
----
Then we realize we forgot to add methods into this interface! Damn...
- r7334 adds some methods to this interface
----
Trac 0.12dev - interim release '???' (--, 2008)
* added method foo_bar_triggered to IFooBarListener
Trac 0.12pre1 - interim release 'foobar' (May 30, 2008)
* introduce IFoobarListener so that components can listen to various noises
----
See? Now if a plugin developer implemented IFoobarListener, he can
quickly find what he needs to do in order to adapt its plugin once the
next interim version is out.
When we write the final TracDev/ApiChange/0.12 document (mirrored in
CHANGES-0.12 ?), we will have all the information we need at hand. Of
course, there we sum up all the changes, so that the line about
IFoobarListener will read something like: IFoobarListener interface
added (contains one method for being notified about xyz) - or more
likely in this specific case, will contain nothing at all as we
discovered we didn't need that interface...
I believe that if we're adopting this new practices, we will have a much
better chance to have faster release cycles: after a while, we will just
have to decide that, ok, that last 0.12preN release was actually pretty
good, so let's stop here and make that 0.12, going forward on 0.13 (or
1.0 or whatever).
Now, if we can keep the current development pace, it's not impossible
that the first 0.12pre1 with i18n support will be out even before 0.11
proper :-)
-- Christian
(*) I noticed that sid is back, so there's some hope about the triaging
;-) Thanks a lot for your work sid, it's highly appreciated!
osimons
> > 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.
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...
>
figure out where to commit my bugfixes...
:::simon
https://www.coderesort.com