[rfc] Fix committed/released distinction

[Robert Collins]

On Fri, Apr 8, 2011 at 5:06 PM, Martin Pool <mbp at canonical.com> wrote:

> We do use series tasks for updates to stable series (like 2.2, 2.3)
> and we use the main-project task for fixing something in trunk, which
> is where eg 2.4beta releases come from.  We could modify things to say
> that just being landed to trunk counts as fix released, whereas for a
> stable series it is only fixcommitted when it's on the branch, and
> then fixreleased when it's out.  Is that what you mean?
>
> That would mean we only change the process for things that go into a
> stable branch, and only in the case where the reminder to release is
> really useful, which is nice.  On the other hand it makes the meaning
> of the statuses more complex.
>
> Or do you mean that as well as the trunk, we would create a series
> task for things going into the current beta series?  I don't think
> that would fit well; it would mean practically every bug gets +1 more
> task, without really carrying more information.

Either of those interpretations would make sense to me.

This isn't well advertised, but Launchpad special cases tasks for the
'default series' (aka trunk): they are called 'conjoined masters', and
status changes in the default series task are reflected as changes in
the project scope task. And vice versa. (sidebar: I am thinking about
recommending a change in LP where we /get rid/ of non-series bugtasks.
That is, by default target the default series, and have no non-series
tasks.)

So adding a default series task for things going into the current beta
would be a noop, unless you also create a distinct series separate
from trunk for that - which doesn't really make sense to me.

Lets see, couple of notes as well:
 - I think for trunk/current beta, having stuff fix committed for 6
months would be unpleasant.
 - having stuff visible where there is a special process for getting
it to users is good.

-Rob