[IAEP] Announce: OLPC software strategy.

[James Cameron]

You're asking me to rejustify decisions made in November 2009 when the
environment was somewhat different.

We had informal unpublished plans to release but we had no release name
chosen.

The change I made months ago was to facilitate testers and bug reporters
... to increase the data quality by removing the version numbers from a
popup list, and encouraging use of the keywords field.

The naming scheme was chosen because people had been logging tickets
using the milestone as a version field.  So I wanted to deprive them of
that option in the long run.  This also gave us the flexibility to use
any version number we like for a release.

On Sun, Jul 11, 2010 at 09:05:45PM -0400, Martin Langhoff wrote:
> On Sun, Jul 11, 2010 at 8:45 PM, James Cameron <quozl at laptop.org> wrote:
> > Use 1.x-software-update for tickets you plan to have fixed for the next
> > release. ?(Choose these tickets based on the intent of the release).
> 
> That's not how Trac is designed to work, however. And not how most
> (all minus olpc? ;-) ) use it.
> 
> You are using the milestones as a "sliding window", so
> 'sofrware-update' means "whatever the next release is".

Trac allows any use of the milestone field; in software project
management one does not always map a milestone to a release name.
Conflating the two was causing confusion.

I wanted to be rid of the old milestone values too, but the argument
against that was that the old data was harmless and occasionally useful.

> > Use 1.x-software-later for tickets you intend to delay until after the
> > next release. ?(Choose these tickets where the effort required exceeds
> > the available time and there are more important tickets).
> 
> So everytime we have a release you reset all the 1.x-software-later
> tickets to 1.x-software-update?

Certainly not.  Instead you should cherry pick those tickets that you
plan to fix.  This is how we've been doing it.

> That is literally backwards from the normal usage.
> 
> By using it this way we completely miss the ability to query trac thus:
>  - show me the changelog for 10.1.1 (status=closed and
>  milestone=10.1.1)
>  - what release was bug X fixed in? (all tasks are fixed in
>  'software-update'!)

I'm not missing either of those abilities.  I make sure that I enter the
build number when I've tested a problem to confirm it is solved.

I really really dislike the idea of building a changelog by capturing a
list of tickets closed that had a milestone of a particular value:

- tickets are often closed during the window leading up to a release
  without their milestone reflecting anything useful.  I don't want to
  have to add procedures to check for this.

- the actual changes made by developers should be captured instead.

> Why don't we use it in the way it was designed to be used...? Might
> even work ;-)

Your arguments are not sufficiently compelling.

The changed environment does suggest some changes to bug tracking ...

1.  we need to track tickets that are cross platform (XO-1 and XO-1.5),
and currently we only have "milestone is either 1.0-software-update or
1.5-software-update" [2]

2.  we need new milestones for the as yet unnamed Fedora 13 for XO-1.75
work.

Ideally we would migrate to a more flexible bug tracking solution, such
as Launchpad.  It better supports multiple teams and multiple goals.
But I don't think the situation warrants that level of investment yet.

[1]  http://lists.laptop.org/pipermail/devel/2009-November/026444.html

[2]  http://dev.laptop.org/query?status=assigned&status=new&status=reopened&max=1000&order=priority&col=id&col=summary&col=milestone&col=priority&col=component&milestone=1.0-software-update&milestone=1.5-software-update&report=43#no1

-- 
James Cameron
http://quozl.linux.org.au/