launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

Thanks Rob.  I agree with your general observations.  We have wondered 
if a larger rethinking of our modeling would lead to a better design, 
eventually.  We've even tried to do some of that rethinking in our 
discussions about this topic.

That said, the discussions led to this proposal.  I am optimistic that 
this proposal seems to strike an acceptable balance between pragmatism 
and good feature design.  I'm encouraged by the approval of the domain 
expert, Curtis, who started the idea; Matthew; and Danilo, who said that 
it could address multiple needs for his team.

Brad asked me if we should still proceed, after reading your concerns.  
I understood your last paragraph, plus the approval of the other people 
I mentioned, as sufficient blessing to do so.  We won't be able to roll 
it out until January anyway because of the DB schedule, so that should 
work out fine as long as the end result of our conversation does not 
discard much of the work we will have done by then.

Thanks,

Gary

On 12/18/2011 02:05 AM, Robert Collins wrote:
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp