[IAEP] Announce: OLPC software strategy.
martin.langhoff at gmail.com
Mon Jul 12 19:48:20 EDT 2010
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
[ 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?
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
More information about the Devel