launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

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.

-Rob