[RFC] gnucash-patches mailing list

Chris Shoemaker c.shoemaker at cox.net
Fri Dec 23 15:29:59 EST 2005


On Fri, Dec 09, 2005 at 04:35:24PM -0500, Chris Shoemaker wrote:
> On Fri, Dec 09, 2005 at 04:09:10PM -0500, Derek Atkins wrote:
> > >>   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.  :)

Hmm... I thought of an obvious downside to this idea: a user who wants
to submit code has to subscribe to both -devel and -patches, and so
received all of -patches mail in duplicate.  Yuk.

I agree that we should consider the use of some kind of patch
management tool, but tucking the patches away to -patches (instead of
broadcasting them to -devel) seems kind of like shooting ourselves in
the foot.  It's not clear to me that patches are less likely to get
lost in a lower-volume, less-subscribed list vs. a higher-volume,
more-subscribed list.  Since I can't think of a way to get the best of
both worlds, I think we should just consolidate patch submission onto
-devel.  That's easier and has other clear benefits.

I think telling people to prefix Subject: with [PATCH] is probably the
most reasonable way to mitigate lost patches, short of some integrated
patch management system.

> > >  * 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.

Looking back at historic and recent "translation" patches, I'm
starting to change my mind about this a bit.  There's always been some
number of "translation" patches that contained information or
questions that actually are informative to non-translators.
Therefore, I'm developing a preference for a
"cross-that-bridge-when-we-get-there" approach.  I.e. consolidate
*all* patches into one list, and wait and see if people really do
complain about too many bytes.  Considering that GC is one of the
heftiest FOSS around I doubt we're putting off any developers with
multi-kilobyte emails, maybe just the lurkers.


Anyway, I'd like to roll the ball on this proposal by describing an
exact implementation that I think has all the important features.

To reiterate motivation:
  1) To increase visibility into the development process, especially
the "user contribution" parts.
  2) To avoid getting commit messages in duplicate
  3) To mitigate the loss of user submitted patches
  4) To be able to reply to submitter without fishing for their email address
  5) To satisfy users who want syndication of commit messages

Proposed Policy:
  1) Send user contributed code to -devel with [PATCH] prefix in Subject:
  2) Syndication of commit messages will now happen on -commits, not -patches.
  3) To participate in development, simply subscribe to -devel (and
hopefully, -changes, too.)

Implications:
  1) No need for clunky sending messages to multiple lists.
  2) No need for submitter to choose which list to send a patch to.
  3) No need for header munging, so submissions are From: the submitter.
  4) No need to subscribe to multiple lists getting duplicate info.
  5) People who want to see commit messages but not patches will be
happy with -commits.
  6) All "development" activities are seen on -devel.

Implemention:

1) Announce policy on -patches
2) Disable posting to -patches.
 3,Simplest?) "Alias" -commits to -patches
 3,Alternate?) "Rename" -patches to -commits
 3,Fullblown?) Create read-only -commits with same membership as -patches; disolve -patches.
4) Update svn hook to point to -commits.


What's the best way to accomplish step 3?

-chris


More information about the gnucash-devel mailing list