[RFC] gnucash-patches mailing list

[Chris Shoemaker]

On Fri, Dec 09, 2005 at 11:40:00AM -0500, Derek Atkins wrote:
> Chris Shoemaker <c.shoemaker at cox.net> writes:
> 
> > [This proposal has been brewing for several weeks, but has been
> > expedited by Christian's recent complaint.  I think this will better
> > address both my concerns and Christian's.]
> [snip]
> 
> Here's my take on it:
> 
> 1) People want a list where they can see the commit log messages
>    without seeing diffs.  (I'll add that there's no requirement
>    that this list be -patches, but there is a requirement that it
>    NOT be -devel).  I see no reason not to provide this service.
> 
> 2) /I/ want a list (not -devel) where people send patches to be
>    applied, so I can keep track of which ones have been applied and
>    which ones are still pending.  Personally I'd prefer better
>    bugzilla integration and suggest that all patches go through
>    bugzilla, but I think that's more overhead than people are willing
>    to allow.
> 
> I'll note that I have no problem creating a new list, say
> "gnucash-commits", that takes over role #1 and leave -patches
> for role #2.  I agree that there is little reason to have these
> two roles on the same list, but I think there's certainly a
> demand for both.

I've got no problem with that.

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

> 
> I think that patches/code meant for DISCUSSION (as opposed to
> finished, tested, "please apply this" patches) can and should be sent
> to and discussed on -devel.  
> However patches ready to apply,
> translation updates, etc should go into something like -patches.
> Ideally -patches would feed directly into bugzilla, but I don't
> see that happening.
> 
> So I think my counter proposal:
> 
>   create gnucash-commits
>   - duplicate the subscription database from -patches to -commits
>   - move the svn log messages w/o diffs from -patches to -commits

That's fine with me, and it would at least separate the two
issues.

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

>   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:
 * 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?

-chris