commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <>
Subject Re: [all] Jira reporting
Date Fri, 05 Jan 2007 22:50:15 GMT
On 1/5/07, Joerg Heinicke <> wrote:
> Martin Cooper <martinc <at>> writes:
> > > > Any exact targetting for unresolved issues will lead to "this
> > > > issues hasn't made it into the latest release, we try to get it into the
> > > > next one" mails polluting the mailing lists without nearly any additional
> > > > value.
> > >
> > > I think that is a good thing as it means someone is looking at that
> > > issue each release and deciding that it won't go in that release. If
> > > it keeps getting punted all the time then someone can ask if it's ever
> > > going to happen.
> >
> > This is exactly why we moved to something like what Hen is proposing for
> > Struts. We had oodles of issues just sitting there with no indication of
> > when, if ever, they were likely to be fixed, and no indication of whether
> > anyone was committed to looking at them. Once you start versioning the
> > issues, you get the beginnings of a roadmap rather than just a bucket of
> > issues.
> Ok, that's a point. Cocoon does indeed suffer from this as well. But I guess in
> Cocoon changing this would just not work (or end in 300 "issue version
> re-addressed" mails per release). For the maintenance branch the development is
> much less targeted as it is more or less only project-driven, i.e. an issues
> that a committer needs on his current project gets handled rapidly. Other issues
> are mostly done on demand or on request. For littler projects or projects with
> less chaotic project management (which I like much though :)) the above might
> indeed be useful.

Yeah, for a larger project it'd be more painful. I think you'd want to
be thinking about more defined process - this one is an intentionally
lightweight hack that seems to work with little buy in.

The spam issue is a tricky decision. Sometimes I turn off the
notifications to then do a lot of changes, other times I let the spam
hit the list because moving an issue into a version is a decision. If
there were a lot of them, I'd be tempted to send an email to the list
saying "Moving these issues into XXX" and then do a bulk move with the
send-email option turned off.

That'd be a nice JIRA feature - bulk-email notification rather than
individual notification for each issue.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message