[RFC] gnucash-patches mailing list

[Chris Shoemaker]

On Fri, Dec 09, 2005 at 04:09:10PM -0500, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at cox.net> writes:
> 
> >> I agree with everyone so far that discussion of patches should go to
> >> -devel.  Indeed, I've already fixed the Reply-To on -patches to send
> >> there, which should solve the immediate problem.
> >
> > Agreed, but it doesn't look like your proposal addresses the problem that
> > Christian raised.  I think the Reply-To hack is useful, but it does
> > have the hackish side-effects.
> 
> Hmm, I don't think I've seen that email.  At least I can't seem to
> find it in my personal archives.  What was the problem that he raised?

Hidden in Dec. 8 email "Updated Greek translation": evils of Reply-To.

> 
> >>   suggest people to send "code-to-test" to -devel, and "code-to-apply"
> >>     to -patches
> >
> > I don't think this is a useful or practical distinction.  It's not
> > _practical_ because the submitter probably has no idea whether or not
> > the patch will generate discussion.  It's not _useful_ because not
> > matter which category the submitter chooses, the patch needs the
> > *same* amount of review.
> 
> Well, what would be BETTER would be to have all patches submitted
> through some tracking system (bugzilla? Trac?) and then we can
> forward the "new tracked item" message to -devel.

Agreed, but I think we can make an incremental improvement soon-ish,
while a full-blown patch management system will take slightly
longer. :) IMO, the usability of the bugzilla interface still has a
long way to go.  A certain patch volume could justify its use anyway
but right now the pain factor is still pretty high.  I've never seen
Trac's patch management functionality.

> 
> >>   consider better tracker integration so we don't lose patches.
> >
> > If your reason for wanting to segregate -patches is to keep track of
> > applied vs. pending, maybe there's some way to do that while still
> > getting more eyes on submitted code.  Hmmm... Idea: leave -patches for
> > submission of user code, but deliver mail sent to -patches to both
> > -patches *and* -devel.  That way:
> 
> I don't know if there's a good way to get mailman to do that.  I mean,
> I can probably subscribe gnucash-devel to gnucash-patches, but that
> just feels... wrong.

Seems... elegant.  :)

> 
> >  * responses can still go to -devel without any header munging
> > (Christian's concern addressed)
> >  * everybody on devel still sees user-submitted code (my concern
> > addressed)
> >  * there's still a place to look when you want to see *just*
> > user-submitted code (your concern addresses)
> >
> > Any down-sides?
> 
> The difficulty of getting messages to both lists?  This also feels
> somewhat clunky.  Also, honestly, I don't think we want or need
> translation updates to go to -devel.

Well, translation updates don't bother me, because I just delete mail
in any language I don't read, BUT...

If this is really a show-stopper, I'm also fine with creating a
gnucash-translators list.  Reasoning:

 * Technical issues related to translation are often of no concern to
non-translators.
 * "lurkers" have little to gain from seeing translation patches.
 * translation patches don't need the same level of review as code patches.
 * posters know before posting whether a patch is "code" or "translation"
 * translation patches are probably 10% of patches but 90% of byte-volume.

IOW, none of my reasons for wanting patches on -devel really apply to
translation patches, so I'm willing to take 'em or leave 'em.

-chris