[Cosmo-dev] Cosmo 0.6 task bugs created

[Ted Leung]

On Nov 13, 2006, at 5:01 PM, Brian Moseley wrote:

> On 11/13/06, Ted Leung <twl at osafoundation.org> wrote:
>
>> - we don't really have an obvious component for RPC work - am I must
>> missing it?
>
> no. it's not an obvious component to the user, which was the criteria
> that guided my choice of components in the past. now that we're using
> bugzilla for task tracking it makes sense to have that component.

Ok, I'll create it.  Who should own it?

>
>> - we don't really have a component for general UI work like
>> subscription dialogs etc
>
> well, subscription dialogs in general i'd put into calendar ui.
> actually we should probably rename "calendar ui" to "pim ui" or some
> such.

ok, after cosmo 0.6 I'll rename it to PIM UI

>
>> - we have an admin UI component, but not a component for general
>> admin functionality
>
> what would you put into a "general admin" bucket? to me, you've got
> cmp, admin ui, services, and storage. not seeing a need for anything
> else.

Actually, I am not seeing components for services and storage.   
Should I create those also?

>
>> - I wonder if it makes sense to have Travis own the admin UI  
>> component?
>
> +1

Done.

>
>> Lastly, when you add up the additional time, it looks like we are
>> looking at 31 days of work in order to finish all the feature work in
>> 0.6.  That takes us slightly beyond the boundaries of a 6 week
>> release cycle, and there are only 7 weeks left in 2006 (not
>> accounting for vacations).    We have been talking about trying to
>> stick to a 4-6 (more likely 6) week release cycle, so I'd be
>> interested in people's opinions on what we ought to do given that
>> things are looking tight.
>
> let's assign priorities to all the feature bugs and make sure the
> defect bugs are all p3-p5 except for the most egregious stuff, which
> should all be p1 or p2. as we progress through nov and dec we can
> re-evaluate based on priority and how we're doing vs our estimates.
>
> i propose that any bug (feature or defect) that is prioritized p3-p5
> is a candidate for deferring to the next release, and that any one
> that is p1 or p2 is a release blocker.

Seems reasonable to me, we can look at this in the bug council.