[IAEP] Announce: OLPC software strategy.

[Martin Langhoff]

On Mon, Jul 12, 2010 at 5:37 PM, James Cameron <quozl at laptop.org> wrote:
> Question back at you; why would you want to know what tickets were closed
> as part of work toward a particular release?

I regularly 'datamine' the SCM repos and bug/task-trackers of the
components I use. This is enormously important when making decisions
downstream.

[ As a result of this, and some other factors, I was one of the
earliest adopters and hackers of git. ]

This kind of datamining is key when you are downstream, and your cost
of updating to the new release is high -- because you have
customisations, you want to perform your own QA, or because you have a
large number of machines in the field (say, 360K) -- and you know each
update will break (in real and/or subjective ways) for some users.

Imagine you are a downstream on 10.1.x wondering whether 10.1.z is
worth the (high) cost. If/when we release something like a 10.2.x /
11.1.0 (say, based on F-13, a big delta with more potential for
grief); when you are downstream your questions are:

 - Does it fix problems / add enhancements I care about? [ This breaks
down into "are we monitoring any of those tasks?" and "can I spot
anything there that I am interested in?".

 - What areas are affected / have been worked on? ("Where should I focus my QA?)

 - What patches will I have to rebase / features to rework?

It is a very hard, multi-dimensional cost-benefit analysis.

Yes, you can diff the rpm changelogs, but that is shipping lots of
trees to someone who wants a postcard of a forest.

This is an important use of trac. Of course the data in trac is not
perfect, but it can give us (with current practices -- plus the change
I suggest) a very-close-to-correct picture of what's been worked on,
and considered 'done' for a given release.

And I don't see any downside to the change I suggest. Maybe I am a bit
shortsighted here, but I've seen similar practice in various projects
with no ill effects.

Some projects do have a fuzzy "future release" milestone, as well as
the next one, and initially tag all tasks (except urgent bugfixes) for
the FR milestone. Then when it's clear that a particular task will get
done in the next release (because it is a blocker/high pri, or is
close to completion), they change the milestone to the actual
release/milestone it will land on. So they get the benefit of both our
'fuzzy future, no specific promise' and the 'task/bug accounting'.

It would be a mix of explicitly using 'Future release', most of the
time, and explicit release names ("10.1.2") as we are nearing the
release and stuff lands.

Would something like that work?

cheers,


m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff