[Techteam] Adding a "Next release" milestone in trac
kim at laptop.org
Fri Jun 20 23:54:44 EDT 2008
If we can all agree on tagging and on using exactly the same tags
(which is very difficult); then we still have to deal with the
milestone issue as the entire roadmap and all the past expectations
have been that the milestone DO mean something.
It is difficult to give up on milestones (at least for me) and I'm
really concerned if tags are not a 'pull down' that we will NOT
successfully search on tags and get all the trac items.
Can we use a combination of milestones and tagging?
If you want something to get into milestone 9.1.0; you put it there
AND you tag it with rel-8.2.0:- rel-9.1.0:?
Maybe the milestone represents the desired location of the feature,
and the tags represent current expectations as to whether it can make
one release or another.
So if someone puts 'Groups' into Milestone 9.1.0; you might also tag
it with rel-9.1.0:? because it is undefined and therefore not clear
that can make that milestone without a lot more attention. As it gets
broken down into smaller parts, some of those features might get
rel-9.1.0:+ and some get -.
We might put 'Grab key scrolling' into 8.2.0 as the desired milestone;
with rel-8.2.0:? rel-8.2.1:+ (not sure it can make 8.2.0, but really
think it can make 8.2.1).
I think all the trac items still open once we hit a milestone should
get automatically pushed into the next milestone.
On Fri, Jun 20, 2008 at 9:01 PM, Michael Stone <michael at laptop.org> wrote:
> On Fri, Jun 20, 2008 at 09:35:33PM +0200, Marco Pesenti Gritti wrote:
>> On Fri, Jun 20, 2008 at 9:06 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
>> > I began wishing that I could meaningfully differentiate between the
>> > "Future release" and non-existent "Next release" components.
> Because we are unlikely to make a new major stable release within four
> months of shipping 8.2.0, our next major stable release will, in all
> probability, be named 9.1.0 -- the first major stable release of 2009.
> Looking out from today, I would expect it to land sometime in the first
> quarter of 2009. I could also easily imagine the creation of an 8.2.1
> bugfix release to pick up minor improvements to 8.2.0 which are required
> after ship or which we lacked the resources to release on the first
> As for how to represent these possibilities: I don't like the Milestone
> field because it fails to two important qualities of tickets: that they
> may have been considered for multiple releases and that they must be
> proposed, then accepted or rejected for release.
> Unfortunately, the Milestone field does not permit us to describe
> tickets which are in danger of slipping from a release, which are
> _proposed_ for a release but not yet accepted, or which have slipped
> through several releases. In reaction to these flaws, I am using a
> tagging scheme like:
> rel-8.2.0:- rel-9.1.0:?
> to describe tickets which are definitely not going into 8.2.0 and which
> have been proposed for 9.1.0.
> Does this scheme suit your needs?
> Devel mailing list
> Devel at lists.laptop.org
More information about the Devel