Re: Subscribe maintainers list to the bug/patch tracker [was "Patch to make common octave_dock_widget class"]

[Daniel J Sebald]

On 02/07/2013 02:14 PM, Carnë Draug wrote:
> On 7 February 2013 19:30, c.<address@hidden>  wrote:
> > On 7 Feb 2013, at 19:40, Carnë Draug<address@hidden>  wrote:
> > > On 7 February 2013 13:56, c.<address@hidden>  wrote:
> > > > The trackers seem like a very good place to store contributions but not as good 
> > > > for carrying on the discussion about them.
> > >
> > > Why is it not a good place to carry a discussion about a bug? It's
> > > very self contained, no one can change the subject line and get the
> > > discussion split into multiple threads, keeps an history, and anyone
> > > not on the mailing list can easily be added to the notifications. It's
> > > the perfect place to carry the discussion about a specific bug. It was
> > > designed for that purpose.
> >
> > All true, but I somehow get the feeling that, in practice, patches posted on 
> > the tracker
> > only get the attention they deserve when the contributor also announces them on 
> > the mailing list.
> >
> > [...]
> >
> > which was not announced on the list AFAIK and has been waiting in vain in the 
> > tracker even though
> > it solves an issue that has been brought up already a few times on the list in 
> > the past.
> >
> > > [..] Instead, developers should be motivated to subscribe to the
> > > trackers, [...]
>
> Yes, but that's because there's people on the mailing list that will
> comment and work on the bug/patch that are not subscribed on the
> trackers. That's why I suggested that the solution should be to
> encourage those developers to subscribed to the trackers.
>
> The current method of opening a report on the trackers and then coming
> to the mailing list announcing it annoys me a tiny bit. It's a call of
> attention, as if the person thinks his reports are more important the
> others by bringing it to a larger audience.

I think most everyone has been pretty good on this.  There is always 
going to be a "competition for attention", whether it is a software 
project, a board room, whatever.  But some general rules are good:

1) If one submits a bug report that isn't of much urgency, wait a few 
days or even weeks to see if the bug is responded to.

2) If the user has submitted a bug report WITH an attached changeset, 
consider announcing it to the list if developers have not responded to 
the bug report and it seems as though it has sunk to the bottom in all 
the new reports arriving.

3) If the user has submitted a bug report with an attached changeset and 
it is has some urgency (i.e., others are searching for a fix at the 
time), or it has some broad implications, tell the list.

I don't think this would be too much of a concern one way or another if 
the number of bug reports can be reduced by good programming, less 
FIXMEs, so on.  Bottom line is that putting more effort into writing 
bug-free code will prevent excessive effort servicing the bug list.


>  If everyone starts doing
> it, then all reports get the same attention again so none will get the
> "advantage" (it feels like they are on race and it shouldn't). The
> solution should not to bring them all to the mailing list but to force
> them to stay on the tracker. I already get a notification when there's
> something new on the trackers, I don't need a duplicate.

Again, that wouldn't be such a hindrance if the number of bug reports 
were less.

Dan