launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

Hi Rob, all,

Sorry for not responding on this earlier.

У нед, 18. 12 2011. у 20:05 +1300, Robert Collins пише:
> I've got mixed feelings about this proposal.
> 
>  - tagging things in general allows a lot of user defined flexibility
>  - adding new concepts adds complexity
>  - Are we actually solving the problem (of our core being unable to do
> what the user wants)
>  - The long established bug with milestones in bugs being unbound vs
> the series the task is on seems particularly relevant here. We have
> explicitly modelled release processes and folk can have a bug that
> says 'due for 3.3beta1' when the task is on a series called '4', and
> similarly 'released in release 3.3beta1' (after the milestone is
> released) - this is internally inconsistent.
> 
> We have for a project group the following:
>  - series
>  - milestones
>  - releases
> 
> and now tags. I think we should strive to keep the number of concepts
> under control. Adding tags to these objects could be very good, but I
> wonder if we can drop some of the other objects as we do it, to keep
> the number of interactions, and the redundancy, down.
> 
> I guess my worry is that folk will have:
> series 4, milestone 4.4beta1, milestone tag beta1
> series 3, milestone 3.3beta1, milestone tag beta1
> 
> or
> series 4, milestone 4.4-11.10, milestone tag 11.10
> series 3, milestone 3.3-11.10, milestone tag 11.10
> 
> Where we are making them put in the same data, because the rest of our
> model is broken.
> 
> Presumably the single milestone view that is desired is 'what work are
> we about to release', or some such. That might be more directly
> addressed by allowing a query for 'what work are we about to release',
> independent of milestone names: just take all the open milestones with
> a release date with the next N weeks. (Think 'todo list for
> dashboards').
> 
> I'm not vetoing this approach, but I would like a call with Yellow
> about it early in the new year before it goes live: building on shaky
> foundations adds to our tech debt and maintenance costs, and I want to
> avoid that.

To help put things in perspective, let me add a few more things here.

Linaro basically wants to have two main things in Launchpad to serve as
our work overview/planning tool:
 - Linaro monthly release page which lists all things coming in a
certain release for a certain project group
 - Per team/person views of upcoming work items (bugs/blueprints)

What was escalated as a bug 480123 is mostly the former part.  If
thinking about both at the same time makes Launchpad have a stronger
foundation for what Linaro really needs, then by all means go for it.

In general, Linaro will not be strongly opposed to changing their
current release management model to some extent, though we'd need to
have clear benefits in doing that or there might be discontent with
Launchpad, and I'd hate to see that.

I'd very much like us to get a clear path forward, since for at least
some of these things, we'd love to spend some time hacking on them
directly on Launchpad (to spare ourselves from hacking on things like
launchpad-work-items-tracker).

Another part of all the above is making blueprint workitems first class
Launchpad objects, but that's a different discussion that we can have at
a separate point in time.

It was my earlier estimation that bug 480123 is feature work and that
seems to always get reconfirmed when someone starts looking at it
afresh: nobody with the Launchpad hat can in their right mind easily
agree to just removing the DB restriction and thus break the model for a
few other things.  Perhaps it's time to confirm that what we need out of
480123 is not a simple escalated bug and we need to move on to thinking
about proper solutions instead.

Happy Christmas all and talk to you soon :)

Cheers,
Danilo