[Cosmo-dev] Cosmo 0.6 task bugs created
twl at osafoundation.org
Tue Nov 28 15:52:36 PST 2006
I created components for RPC (br), Service (bcm), and Storage (randy).
On Nov 15, 2006, at 5:36 PM, Ted Leung wrote:
> 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
> 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
> 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
>>> 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.
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
More information about the cosmo-dev