You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2006/03/18 02:10:03 UTC
Signal to noise on derby-dev
I don't know if any of you have noticed, but it's getting a bit thick
out there on this list.
I have heard that the Apache Way is to maintain a single list for a
project regardless of how big it is. But has anybody talked to the
veterans over at other big projects like httpd or Tomcat to get some
tips about how they manage the signal-to-noise ratio on their lists?
How do individual contributors keep up with everything and not miss
things that might be important or relevant to them and their work?
Thanks,
David
Re: Signal to noise on derby-dev
Posted by Rick Hillegas <Ri...@Sun.COM>.
I think that, for a maintenance release, the old model is a fine way to
generate Release Notes: there JIRAs pretty much correspond to fixed
bugs. But for a major development effort, a big shower of granular
subtasks will probably confuse customers. Alas, this complicates the
10.2 release manager's job!
Regards,
-Rick
Daniel John Debrunner wrote:
>Rick Hillegas wrote:
>
>
>
>>I would be surprised if the subject lines of these granular JIRAs made
>>their way into the Release Notes. We subdivide tasks into bite-sized
>>JIRAs to help developers and reviewers digest large features. I think
>>we'll just confuse our customers if we expose this detail of our
>>development process. For the sample JIRA below, I don't think the
>>customer will appreciate either the existing subject line or the
>>proposed replacement. Instead, I would recommend that the Release Notes
>>provide some composite summary, describing which high level JDBC4
>>features we support and which we don't.
>>
>>
>
>That's what has been done for the past Derby releases, create the
>release notes using Jira's facility to do that. Of course additional
>text can be added into the release notes.
>
>Dan.
>
>
>
>
Re: Signal to noise on derby-dev
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> I would be surprised if the subject lines of these granular JIRAs made
> their way into the Release Notes. We subdivide tasks into bite-sized
> JIRAs to help developers and reviewers digest large features. I think
> we'll just confuse our customers if we expose this detail of our
> development process. For the sample JIRA below, I don't think the
> customer will appreciate either the existing subject line or the
> proposed replacement. Instead, I would recommend that the Release Notes
> provide some composite summary, describing which high level JDBC4
> features we support and which we don't.
That's what has been done for the past Derby releases, create the
release notes using Jira's facility to do that. Of course additional
text can be added into the release notes.
Dan.
Re: Signal to noise on derby-dev
Posted by Rick Hillegas <Ri...@Sun.COM>.
I would be surprised if the subject lines of these granular JIRAs made
their way into the Release Notes. We subdivide tasks into bite-sized
JIRAs to help developers and reviewers digest large features. I think
we'll just confuse our customers if we expose this detail of our
development process. For the sample JIRA below, I don't think the
customer will appreciate either the existing subject line or the
proposed replacement. Instead, I would recommend that the Release Notes
provide some composite summary, describing which high level JDBC4
features we support and which we don't.
Regards,
-Rick
Daniel John Debrunner wrote:
>Dyre.Tjeldvoll@Sun.COM wrote:
>
>
>
>>If you are going to add a method to a class, what should the title be,
>>exactly? Can you please give an example of a more descriptve title?
>>
>>
>
>Take DERBY-953
>
>Subject is "Add miscellaneous Statement methods introduced by JDBC 4",
>that's the subject that jira uses for the e-mails for comments on this
>bug. Not very descriptive of what the issue is addressing.
>
>Something like would be more useful:
>
>Implement JDBC4's Statement.isClosed() and
>Statement.getResultSetHoldability().
>
>Also the subject of a bug gets put into the release notes, it's helpful
>if the subject provides a clear consise description issue or enhancement.
>
>Dan.
>
>
>
Re: Signal to noise on derby-dev
Posted by Dy...@Sun.COM.
Daniel John Debrunner <dj...@apache.org> writes:
> Dyre.Tjeldvoll@Sun.COM wrote:
>
>> If you are going to add a method to a class, what should the title be,
>> exactly? Can you please give an example of a more descriptve title?
>
> Take DERBY-953
[Valid comments about DERBY-953 snipped]
I'm sorry but I don't see the connection. As far as I can tell,
DERBY-953 does not have any discussion about "metadata queries and
backwards/forwards comptability"?
--
dt
Re: Signal to noise on derby-dev
Posted by Daniel John Debrunner <dj...@apache.org>.
Dyre.Tjeldvoll@Sun.COM wrote:
> If you are going to add a method to a class, what should the title be,
> exactly? Can you please give an example of a more descriptve title?
Take DERBY-953
Subject is "Add miscellaneous Statement methods introduced by JDBC 4",
that's the subject that jira uses for the e-mails for comments on this
bug. Not very descriptive of what the issue is addressing.
Something like would be more useful:
Implement JDBC4's Statement.isClosed() and
Statement.getResultSetHoldability().
Also the subject of a bug gets put into the release notes, it's helpful
if the subject provides a clear consise description issue or enhancement.
Dan.
Re: Signal to noise on derby-dev
Posted by Dy...@Sun.COM.
Daniel John Debrunner <dj...@apache.org> writes:
> David W. Van Couvering wrote:
>
>> I don't know if any of you have noticed, but it's getting a bit thick
>> out there on this list.
>>
>> I have heard that the Apache Way is to maintain a single list for a
>> project regardless of how big it is. But has anybody talked to the
>> veterans over at other big projects like httpd or Tomcat to get some
>> tips about how they manage the signal-to-noise ratio on their lists?
>>
>> How do individual contributors keep up with everything and not miss
>> things that might be important or relevant to them and their work?
>
> I think as Jean said keeping and changing subject lines to reflect the
> true discussion is vital. I don't think we do a good job here. I think
> sometimes we continue a discussion as Jira comments when really it has
> expanded to be a wider topic than that specific Jira entry.
Who decides when the discussion should move? When you ask about how to
solve a particular issue, should that not be done as a JIRA comment?
> For example
> there is some discussion about metadata queries and backwards/forwards
> comptability (I think) but it's hidden in one of the non-descript JBDC
> 4.0 Jira entries "add blah blah methods to blah blah class".
I'm sorry, can you be more specific? Which JIRAs are you talking about?
If you are going to add a method to a class, what should the title be,
exactly? Can you please give an example of a more descriptve title?
Thanks.
--
dt
Re: Signal to noise on derby-dev
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>I think as Jean said keeping and changing subject lines to reflect the
>true discussion is vital. I don't think we do a good job here. I think
>sometimes we continue a discussion as Jira comments when really it has
>expanded to be a wider topic than that specific Jira entry. For example
>there is some discussion about metadata queries and backwards/forwards
>comptability (I think) but it's hidden in one of the non-descript JBDC
>4.0 Jira entries "add blah blah methods to blah blah class".
>
>
>
I can see your point at one level. The issue of metadata maintenance
came up first last December in the context of DERBY-573 and perhaps
that was masked to the folks interested in the topic.
http://www.nabble.com/-PATCH-%28DERBY-573%29-Provide-support-for-optimizer-overrides-in-Derby-t517576.html#a1867453
On the other hand, in the context of many Jira issues, long term
maintainability issues have come up. Often the patch may not introduce
a regression today but might create a state where it is impossible to
fix a bug in the future, extremely difficult to maintain, impact rarely
tested jvm/derby combinations, or require some sort of general
infrastructure that is missing . Examples are, maintenance of
metadata, maintenance of client/server compatibility, maintenance
issues associated with sharing a class, handling of partially
implemented features at release time etc.
In the scratch your own itch world I have found that usually the person
working on a single Jira entry doesn't want to address these global
issues, but I think that it is their responsibility to make sure that
the long term maintenance impact of their specific change is addressed
and to that extent the conversation belongs in the bug.
Kathey
Re: Signal to noise on derby-dev
Posted by Daniel John Debrunner <dj...@apache.org>.
David W. Van Couvering wrote:
> I don't know if any of you have noticed, but it's getting a bit thick
> out there on this list.
>
> I have heard that the Apache Way is to maintain a single list for a
> project regardless of how big it is. But has anybody talked to the
> veterans over at other big projects like httpd or Tomcat to get some
> tips about how they manage the signal-to-noise ratio on their lists?
>
> How do individual contributors keep up with everything and not miss
> things that might be important or relevant to them and their work?
I think as Jean said keeping and changing subject lines to reflect the
true discussion is vital. I don't think we do a good job here. I think
sometimes we continue a discussion as Jira comments when really it has
expanded to be a wider topic than that specific Jira entry. For example
there is some discussion about metadata queries and backwards/forwards
comptability (I think) but it's hidden in one of the non-descript JBDC
4.0 Jira entries "add blah blah methods to blah blah class".
Dan.
Re: Signal to noise on derby-dev
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
David W. Van Couvering wrote:
> I don't know if any of you have noticed, but it's getting a bit thick
> out there on this list.
>
> I have heard that the Apache Way is to maintain a single list for a
> project regardless of how big it is. But has anybody talked to the
> veterans over at other big projects like httpd or Tomcat to get some
> tips about how they manage the signal-to-noise ratio on their lists?
>
> How do individual contributors keep up with everything and not miss
> things that might be important or relevant to them and their work?
you can actually look at mail list metrics here:
http://people.apache.org/~coar/mlists.html
mean posts per day (as of just now when I checked) are ...
derby-dev 31.49
derby-user 7.32
The highest hitters seem to be ...
commons-dev@jakarta.a.o 50.07
tapestry-user@jakarta.a.o 41.52
dev@maven.a.o 68.34
users@maven.a.o 45.58
users@myfaces.a.o 46.59
users@spamassassin.a.o 40.87
user@struts.a.o 54.57
user@tomcat.a.o 52.39
Great tips are here:
http://www.apache.org/dev/contrib-email-tips.html
Helpful tips include:
> Take the time to clearly explain your issue and write a concise
email message. Less confusion facilitates fast and complete resolution.
Everyone will benefit from the extra time on your part. The less
unnecessary discusion, the better.
However, balanced by the next line:
> Every contribution is worthwhile. Even if the ensuing discussion proves it to be off-beam, then it may jog ideas for other people.
And my favorite:
> Use sensible and concise email subject headings. Search engines, and humans trying to browse a voluminous list, will respond favourably to a descriptive title.
Also, I see management on several lists for managing new topics with new
subject headings to avoid one subject from getting overly cluttered
(doesn't always work, but it's a good goal):
> Keep each topic focussed. If some new topic arises then start a new discussion. This leaves the original topic to continue un-cluttered.
-jean