[RFC] gnucash-patches mailing list

[Chris Shoemaker]

On Tue, Dec 27, 2005 at 11:15:44AM -0500, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at cox.net> writes:
> 
> >> > 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.
> 
> Nah, they can subscribe to -patches and then turn /off/ email sending.
> Sure, it's an extra two web-clicks to do it, but it's a one-time deal.

I didn't know about that option.  That seems reasonable.

> Or they can CC both lists and wait for the list admin to clear the
> moderation queue.

Oh, if they're only subscribed to -devel, right?  That's not so good.
They're just as likely to assume their mail was dropped rather than
entered into a moderation queue.

> 
> > 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 was looking into this..  Trac has a patch tracker, and even has an
> email submission program to let you submit tracker items via email.
> Unfortunately it requires a newer version of trac than we have, and I
> can't build the new version of trac because it requires python 2.3
> (the server only has 2.2)..  So, upgrading trac is going to require
> upgrading the server, which isn't going to happen until next year.

Next year?  So Sunday?  I can't wait.  :-P

> [snip]
> > 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.)
> 
> I see little reason to change #2 at this time if we're implementing
> #1.

The only reason I was thinking of was that "patches" becomes somewhat
of a misnomer.  But, that would only bother me if it were the
long-term solution.  I certainly don't mind leaving it as -patches,
until something better comes along.

> > 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?
> 
> I....  Don't think we should implement step 3 or step 4 right now.  I
> do think we should/could implement steps 1 and 2 right now.  Then next
> month, once I update the server, we can implement the longer-term
> solution of having an email patch-submission address that inserts the
> patch into trac and then forwards the email to -devel (and perhaps
> -patches)..  And at that time we can look into renaming -patches to
> -commits.

Ok.  Sounds good.  As list-admin, you can tell how many people are
subscribed to -patches that are not subscribed to -devel.  I suspect
it's very few.  If it's sufficiently few, maybe we can count this
thread as accomplishing step 1.

-chris