forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: planning the 0.8 release
Date Wed, 12 Apr 2006 02:21:41 GMT
Keeping this topic at the top of the list.
http://issues.apache.org/jira/browse/FOR-853

-David

David Crossley wrote:
> Ross Gardler wrote:
> > David Crossley wrote:
> > >Ross Gardler wrote:
> > >>David Crossley wrote:
> > >>>Ross Gardler wrote:
> > >>>>David Crossley wrote:
> > >>>>
> > >>>>>The "roadmap" mixes in all of the plugins issues.
> > >>>>>The so-called "Priority" is a reporter-based priority.
> > >>>>
> > >>>>Does it? I can't check it right now (I'm replying offline) but I'm

> > >>>>pretty sure I moved all of the plugin stuff out of the roadmap for
0.8. 
> > >>>>The only references to plugins in there (that I intentionally left)
is 
> > >>>>to how core handles plugins.
> > >>>
> > >>>Ah, i did not realise that you were doing that.
> > >>>
> > >>>However, as we move more stuff into plugins,
> > >>>what would happen when we have plugins issues
> > >>>that need to be fixed?
> > >>
> > >>That's where you urgency field comes in (which wasn't available when I 
> > >>did the 0.8 roadmap).
> > >
> > >That sounds like it would work. So to assess the
> > >state of the upcoming release, we look at the filters
> > >to see Urgency=blocker and Urgency=urgent
> > >(whether they are marked on the roadmap or not).
> > >The remaining issues on the roadmap are "hope-to-fix".
> > >Is that how you see it too?
> 
> I didn't, but i was trying to put the current
> discussion into words.
> 
> > Pretty similar to how I see it:
> > 
> > I have a slight problem with the sentence "whether they are marked on 
> > the roadmap or not".
> 
> I added that because i was previously under
> the impression that the plugin issues are on
> the roadmap too.
> 
> > My understanding of the urgency field was to allow 
> > plugins to have blockers that are not blockers to a core release. We 
> > therefore need to be able to keep such issues out of the roadmap, but 
> > keep them visible. Hence the introduction of urgency.
> 
> I had seen it as applying to all issues.
> After lots of thought in the last few days
> i tend to like your suggested method.
> 
> So i suppose that Urgency only applies to plugin issues.
> It is a duplication of information and effort to apply
> it to the general issues, since we would not use it there.
> 
> Actually i wonder if your techinique of leaving
> plugin issues out of the roadmap removes the need
> for the Urgency field. Could filters [D] and [E]
> use the Priority field instead?
> 
> > I see it working like this:
> > 
> > Priority indicates priority to that part of the project (core or plugin).
> 
> Currently we say that Priority is the "severity" from
> the reporter/user point-of-view, i.e. how it affects them. [A]
> I will change the docs and Jira prompts
> 
> > Urgency indicates the likelihood of the community fixing it (as opposed 
> > to the reporter).
> 
> Yes, community. I don't think that the reporter
> matters in this case.
> 
> > So, a blocker for the OOo plugin may only have a low urgency if it is 
> > unique to a specific use case for a specific user. On the other hand, a 
> > low priority issue may be an indicate of a problem with the design of 
> > the plugin system in the core, in which case we are likely to give it a 
> > high urgency.
> 
> I had trouble coming up with good examples.
> Your second example would probably result in
> creating a new core Issue about fixing the
> plugin system.
> 
> Again i am wondering if the Urgency field is
> worth the effort with the new way of managing the
> roadmap.
> 
> > So, to establish the state of a core release, look at the 0.8-dev roadmap.
> 
> Made a filter for that: [B] FOR-roadmap-dev
> 
> While we are here, lets figure out how to progress
> to a release. How is this:
> 
> * Each of us visit [C] and add any more core issues
> that we would realistically like to have fixed onto
> the roadmap [B].
> 
> * The roadmap is going to be too big (already 40).
> So we review it and move some issues over to Fix-for=0.9
> i.e. put them on the next roadmap rather than send
> them back to the unscheduled basket. Also jiggle some
> Priority values. Need some discussion on each issue.
> 
> * Focus on the remaining issues.
> 
> * Repeat that process or carefully watch new issues.
> Only put them on 0.8 roadmap if really necessary.
> 
> > To establish the state of a plugin release look at the urgency/priority 
> > of issues against that plugin.
> 
> Yes. Also made two filters to show such issues
> for all plugins:
> [D] FOR-plugins-blocker
> [E] FOR-plugins-urgent
> 
> > To find issues that are unscheduled, but should be in the roadmap look 
> > at all non-plugin issues sorted by priority/urgency.
> 
> Made a filter for that: [C] FOR-unscheduled-not-plugin
> 
> > >There were many issues in the "unscheduled" before
> > >you started. Speaking for myself, i don't look
> > >often enough at that filter.
> > 
> > I reviewed all issues when creating the roadmap (after discussion). That 
> > doesn't mean I didn't miss any, but I did my best ;-)
> 
> [A] Forrest issue tracker description
> http://forrest.apache.org/issues.html
> [B] FOR-roadmap-dev
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310820
> [C] FOR-unscheduled-not-plugin
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310822
> [D] FOR-plugins-blocker
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310825
> [E] FOR-plugins-urgent 
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12310824
> 
> Note that some filters don't work well yet because
> we still need to classify the issues.
> 
> -David

Mime
View raw message