Thing is also that we have not too many bugs filed against the implementation, but many bugs against the components, where the bugs against the implementation are more important, probably.
regards,
Martin
On 8/2/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
I was thinking we might be able to address this issue through JIRA's
voting procedure. Perhaps a rule of "If an issue has two votes, it
must be dealt with before the release." Then we could add those
issues to the release plan as a reminder (and requirement) for the
release.
Two votes (plus the original reporter who can't vote for his own
issue) seems to me to be a good standard for whether or not something
is urgent. Of course there could be an urgent bug that nobody votes
for, but its a start.
I agree with Craig that we should be definitive about what is going to
be deferred and what is not. Perhaps we could add a "TBD" version
(for "To Be Determined") and mark bugs that we are intentionally
deferring as such. The JIRA voting system could help us sort them
out.
Thoughts?
sean
On 8/2/05, Craig McClanahan < [EMAIL PROTECTED]> wrote:
> On 8/2/05, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Count me in!
> >
> > +1 for a release plan, but not as detailed, I would say - listing a 100
> > bugs is not so informative, I'd say.
> >
>
> The purpose of listing the outstanding bugs isn't really to be
> informative (you can do your own queries just as easily). The purpose
> is to motivate the developers to dispense with them -- either get them
> fixed (and therefore off the list), or deliberately decide to defer
> them (and list them as outstanding issues on the release notes).
>
> Either outcome is OK -- what's not OK is uncertainty about whether a
> particular issue is going to get addressed or not. And, if it's on a
> list like this, there's no excuse for a developer to say "but I didn't
> *know* about that problem" ... :-)
>
> > regards,
> >
> > Martin
> >
>
> Craig
>
