[RFC] gnucash-patches mailing list

[Derek Atkins]

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.
Or they can CC both lists and wait for the list admin to clear the
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.

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

This is an okay short-term solution.  The problem of course is that
people don't always start a new email thread when sending in a patch,
so sometimes the [PATCH] keyword gets instantiated somewhere in the
middle of a thread.  Another issue is that replies to the patch get
put into the thread and also have a [PATCH] keyword in the subject.

This is why I say it's an "okay" solution.  It's not great.

[snip]
> Anyway, I'd like to roll the ball on this proposal by describing an
> exact implementation that I think has all the important features.
>
[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.

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

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available