[RFC] gnucash-patches mailing list

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] gnucash-patches mailing list

Chris Shoemaker
[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.]

A couple observations:
  - gnucash-patches is being use for two very different purposes; 1)
user patch submission, 2) syndication of commit messages.
  - responses to messages of either type often belong on -devel.
  - ReplyTo munging moves the discussion to -devel but does have the
traditional downsides of mail header munging.
  - any involved developer doesn't want to miss any conversation that
starts up in response to a commit message on -patches.
  - nor any of the dozen or so per year user-submitted patches.
  - any such developer basically has to subscribe to (at minimum)
-devel, -patches, and -changes.
  - any so subscribed developer gets most gnucash-related email in
duplicate: a -changes/-patches pair, with and without the diff.

Goals:
  - I want the user-submitted patches and follow-up discussion to get
a lot of visibility.
  - I'd love to unsubscribe from the commit message syndication and cut
my gnucash-related email in half.

I propose that we make gnucash-patches read-only, i.e.
  - document that user-submitted code should be sent to -devel
  - allow posts to -patches only from svn commit hook
  - set ReplyTo as gnucash-devel, so any response to a commit-message
goes to -devel
  - gnucash-patches becomes essentially only a syndication of commit
messages, which some people seem to want.

Disclaimer: I have diminishing sympathy for any self-proclaimed
non-developers who might say that they want to remain subscribed to
-devel but don't want user-sumbitted patches crowding their inbox.
  1) It's a really small volume compared to the rest of -devel traffic.
  2) "-devel" stands for development, which for software includes "code".
  3) Reviewing code is *important* and a part of "development" and
appropriate on -devel.
  4) Did I say "tough cookies?"  :)

Comments?

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Neil Williams-2
On Thursday 08 December 2005 9:29 pm, Chris Shoemaker wrote:
>   - gnucash-patches is being use for two very different purposes; 1)
> user patch submission, 2) syndication of commit messages.

When I subscribed, I expected gnucash-changes to be the automated logs and
gnucash-patches for submissions. To me, that is more intuitive.

> Goals:
>   - I want the user-submitted patches and follow-up discussion to get
> a lot of visibility.
>   - I'd love to unsubscribe from the commit message syndication and cut
> my gnucash-related email in half.

As long as the diffs still come through so that each of us is aware if someone
commits a change that maybe conflicts with local development code or contains
a flaw that would be obvious to someone else.

SVN diffs -> gnucash-changes because the code has changed.
patches -> gnucash-patches because the patch needs to be applied.

Cease all current svn direction to gnucash-patches.

Overall, that's is the most intuitive IMHO plus it means the fewest changes to
existing arrangements. All we need to do is declare how it's done and stop
the hook from svn to gnucash-patches.

> I propose that we make gnucash-patches read-only, i.e.

I'd go for the opposite - leave gnucash-patches as is - read-write.

Make gnucash-changes the ONLY output for SVN messages, almost as is. That
could be read-only.

>   - document that user-submitted code should be sent to -devel

-patches.

>   - allow posts to -patches only from svn commit hook

allow posts to -changes only from svn commit hook (because the code has been
changed)

>   - set ReplyTo as gnucash-devel, so any response to a commit-message
> goes to -devel

Agreed.

>   - gnucash-patches becomes essentially only a syndication of commit
(gnucash-changes)

> messages, which some people seem to want.

The naming seems obtuse - patches are what come in, changes are what we make.

When a developer with svn access makes a commit, that is a change to the
codebase - gnucash-changes.

When a developer/user without svn access creates a patch, it would seem
natural to send that to gnucash-patches.

Once applied, it goes onto gnucash-changes.

> Disclaimer: I have diminishing sympathy for any self-proclaimed
> non-developers who might say that they want to remain subscribed to
> -devel but don't want user-sumbitted patches crowding their inbox.

Agreed. I see no reason for the current messages from SVN to gnucash-patches
(never have really). I think they should stop and leave gnucash-patches only
for contributed code and gnucash-changes only for commit messages *with*
diffs.

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
On Thu, Dec 08, 2005 at 10:44:36PM +0000, Neil Williams wrote:

> On Thursday 08 December 2005 9:29 pm, Chris Shoemaker wrote:
> >   - gnucash-patches is being use for two very different purposes; 1)
> > user patch submission, 2) syndication of commit messages.
>
> When I subscribed, I expected gnucash-changes to be the automated logs and
> gnucash-patches for submissions. To me, that is more intuitive.
>
> > Goals:
> >   - I want the user-submitted patches and follow-up discussion to get
> > a lot of visibility.
> >   - I'd love to unsubscribe from the commit message syndication and cut
> > my gnucash-related email in half.
>
> As long as the diffs still come through so that each of us is aware if someone
> commits a change that maybe conflicts with local development code or contains
> a flaw that would be obvious to someone else.
>
> SVN diffs -> gnucash-changes because the code has changed.
> patches -> gnucash-patches because the patch needs to be applied.
>
> Cease all current svn direction to gnucash-patches.

I proposed this before and it was not received too favorably.  I
pretty much agree with you about the uselessness of sending commit
messages to -patches, but some people seem to want this.

OTOH, I still don't like the idea of segmenting out a list just for
submission and discussion of a few patches.  So, combining what I
agree with about your proposal with what I want to retain from my
proposal would mean the complete elimination of -patches.  I can't say
I'd mind.

> >   - gnucash-patches becomes essentially only a syndication of commit
> (gnucash-changes)
>
> > messages, which some people seem to want.
>
> The naming seems obtuse - patches are what come in, changes are what we make.

I agree that the naming is totally backward for what I'm proposing.
If renaming the list was easy I'd call it "gnucash-commit-log".

>
> When a developer with svn access makes a commit, that is a change to the
> codebase - gnucash-changes.
>
> When a developer/user without svn access creates a patch, it would seem
> natural to send that to gnucash-patches.
>
> Once applied, it goes onto gnucash-changes.
>
> > Disclaimer: I have diminishing sympathy for any self-proclaimed
> > non-developers who might say that they want to remain subscribed to
> > -devel but don't want user-sumbitted patches crowding their inbox.
>
> Agreed. I see no reason for the current messages from SVN to gnucash-patches
> (never have really). I think they should stop and leave gnucash-patches only
> for contributed code and gnucash-changes only for commit messages *with*
> diffs.

Well, we agree about reducing the dual use of -patches.  And if
there's no uproar, I'd agree with you about dropping the commit-log,
too.  But I still think it's better to concentrate eyeballs onto one
list instead of -devel and -patches.

Part of my motivation is that I think developers are grown by example.
Segregating patch submission means that lots of "aspiring" developers
won't actually see any user submitting code, because they'd subscribe
to -devel but not -patches.  OTOH, when all of the aspiring developers
on -devel see the occasional fellow-user submitting patches, it
fosters thoughts like "Oh, so that's how people submit patches" and
"Hmm, maybe I can do that, too."

IOW, reducing my mail flow is really only the fringe benefit.  My real
motivation is community development.

-chris

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Neil Williams-2
On Thursday 08 December 2005 11:10 pm, Chris Shoemaker wrote:

> On Thu, Dec 08, 2005 at 10:44:36PM +0000, Neil Williams wrote:
> > On Thursday 08 December 2005 9:29 pm, Chris Shoemaker wrote:
> > SVN diffs -> gnucash-changes because the code has changed.
> > patches -> gnucash-patches because the patch needs to be applied.
> >
> > Cease all current svn direction to gnucash-patches.
>
> I proposed this before and it was not received too favorably.  I
> pretty much agree with you about the uselessness of sending commit
> messages to -patches, but some people seem to want this.
I guess -patches would become really, really quiet so I can see your point
about then merging -patches into -devel.

The problem then would be things like the translations that can be truly
MASSIVE patches and if there's nowhere else to send them, it adds an
unwelcome burden to a -devel subscription, especially at the critical
pre-release time.

Contributors of small patches can still CC: -devel. I'd rather not have twenty
12Mb translation patches arriving in my -devel folder!

> OTOH, I still don't like the idea of segmenting out a list just for
> submission and discussion of a few patches.  So, combining what I
> agree with about your proposal with what I want to retain from my
> proposal would mean the complete elimination of -patches.  I can't say
> I'd mind.

I think translation patches could be a deal-breaker for some -devel
subscribers.

> Part of my motivation is that I think developers are grown by example.
> Segregating patch submission means that lots of "aspiring" developers
> won't actually see any user submitting code, because they'd subscribe
> to -devel but not -patches.  OTOH, when all of the aspiring developers
> on -devel see the occasional fellow-user submitting patches, it
> fosters thoughts like "Oh, so that's how people submit patches" and
> "Hmm, maybe I can do that, too."
>
> IOW, reducing my mail flow is really only the fringe benefit.  My real
> motivation is community development.
As is mine, but I'm also conscious that we could end up mail-bombing -devel
subscribers close to release time!
:-)

I suspect there are a whole lot more -devel subscribers than -patches
subscribers!

--

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Andrew Sackville-West
In reply to this post by Chris Shoemaker
!uproar

I've said it before, as a serious -devel lurker, I have zero (! ((char
*)NULL || (void *)0)) problem with code on -devel and would like to see
more of it frankly. I am hoping to learn by osmosis. So your reasons
(Chris) for seeing more code on -devel suit me just fine.

A

Chris Shoemaker wrote:

> On Thu, Dec 08, 2005 at 10:44:36PM +0000, Neil Williams wrote:
>
>>On Thursday 08 December 2005 9:29 pm, Chris Shoemaker wrote:
>>
>>>  - gnucash-patches is being use for two very different purposes; 1)
>>>user patch submission, 2) syndication of commit messages.
>>
>>When I subscribed, I expected gnucash-changes to be the automated logs and
>>gnucash-patches for submissions. To me, that is more intuitive.
>>
>>
>>>Goals:
>>>  - I want the user-submitted patches and follow-up discussion to get
>>>a lot of visibility.
>>>  - I'd love to unsubscribe from the commit message syndication and cut
>>>my gnucash-related email in half.
>>
>>As long as the diffs still come through so that each of us is aware if someone
>>commits a change that maybe conflicts with local development code or contains
>>a flaw that would be obvious to someone else.
>>
>>SVN diffs -> gnucash-changes because the code has changed.
>>patches -> gnucash-patches because the patch needs to be applied.
>>
>>Cease all current svn direction to gnucash-patches.
>
>
> I proposed this before and it was not received too favorably.  I
> pretty much agree with you about the uselessness of sending commit
> messages to -patches, but some people seem to want this.
>
> OTOH, I still don't like the idea of segmenting out a list just for
> submission and discussion of a few patches.  So, combining what I
> agree with about your proposal with what I want to retain from my
> proposal would mean the complete elimination of -patches.  I can't say
> I'd mind.
>
>
>>>  - gnucash-patches becomes essentially only a syndication of commit
>>
>>(gnucash-changes)
>>
>>
>>>messages, which some people seem to want.
>>
>>The naming seems obtuse - patches are what come in, changes are what we make.
>
>
> I agree that the naming is totally backward for what I'm proposing.
> If renaming the list was easy I'd call it "gnucash-commit-log".
>
>
>>When a developer with svn access makes a commit, that is a change to the
>>codebase - gnucash-changes.
>>
>>When a developer/user without svn access creates a patch, it would seem
>>natural to send that to gnucash-patches.
>>
>>Once applied, it goes onto gnucash-changes.
>>
>>
>>>Disclaimer: I have diminishing sympathy for any self-proclaimed
>>>non-developers who might say that they want to remain subscribed to
>>>-devel but don't want user-sumbitted patches crowding their inbox.
>>
>>Agreed. I see no reason for the current messages from SVN to gnucash-patches
>>(never have really). I think they should stop and leave gnucash-patches only
>>for contributed code and gnucash-changes only for commit messages *with*
>>diffs.
>
>
> Well, we agree about reducing the dual use of -patches.  And if
> there's no uproar, I'd agree with you about dropping the commit-log,
> too.  But I still think it's better to concentrate eyeballs onto one
> list instead of -devel and -patches.
>
> Part of my motivation is that I think developers are grown by example.
> Segregating patch submission means that lots of "aspiring" developers
> won't actually see any user submitting code, because they'd subscribe
> to -devel but not -patches.  OTOH, when all of the aspiring developers
> on -devel see the occasional fellow-user submitting patches, it
> fosters thoughts like "Oh, so that's how people submit patches" and
> "Hmm, maybe I can do that, too."
>
> IOW, reducing my mail flow is really only the fringe benefit.  My real
> motivation is community development.
>
> -chris
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Derek Atkins
In reply to this post by Chris Shoemaker
Chris Shoemaker <[hidden email]> 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 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.

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

  suggest people to send "code-to-test" to -devel, and "code-to-apply"
    to -patches

  consider better tracker integration so we don't lose patches.

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Josh Sled
On Fri, 2005-12-09 at 11:40 -0500, Derek Atkins wrote:

> 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
>
>   suggest people to send "code-to-test" to -devel, and "code-to-apply"
>     to -patches
>
>   consider better tracker integration so we don't lose patches.

I can support this.  I'm in favor of killing -patches and just having
people submit patches to -devel, but if you don't want patches to go to
-devel then that's fine ... I don't really care too much.

+1 for the counter-proposal.

...jsled
--
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
In reply to this post by Derek Atkins
On Fri, Dec 09, 2005 at 11:40:00AM -0500, Derek Atkins wrote:

> Chris Shoemaker <[hidden email]> 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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Derek Atkins
Chris Shoemaker <[hidden email]> 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?

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

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

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

-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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
On Fri, Dec 09, 2005 at 04:09:10PM -0500, Derek Atkins wrote:

> Chris Shoemaker <[hidden email]> 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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Derek Atkins
Chris Shoemaker <[hidden email]> 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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
On Tue, Dec 27, 2005 at 11:15:44AM -0500, Derek Atkins wrote:

> Chris Shoemaker <[hidden email]> 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
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

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

They should get an email from mailman telling them their message was
entered into the moderation queue because they weren't subbed.  So,
they shouldn't assume their mail was dropped.  Or at least I don't
know why they would assume that....

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

:-P

Probably not until Mid January...  I dont get home until the 7th or 8th
so probably the weekend after that I can devote to upgrading the gnucash
hardware and software.  Note that it means about 24-48 hours of downtime
for SVN, Email, Wiki, etc.

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

Agreed.  In the long run we should have a -commits list that is read-only
(and only commiters, and perhaps 'trac' post to it).

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

I'm not sure if there's a good way to compare list membership.  I suppose
I could do it by pulling out the membership lists into files and then
comparing the files...  *ponders and easy way to do this*

> -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
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
On Tue, Dec 27, 2005 at 12:11:10PM -0500, Derek Atkins wrote:

> Quoting Chris Shoemaker <[hidden email]>:
>
> >>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.
>
> They should get an email from mailman telling them their message was
> entered into the moderation queue because they weren't subbed.  So,
> they shouldn't assume their mail was dropped.  Or at least I don't
> know why they would assume that....

Oh, I see.

> >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.
>
> I'm not sure if there's a good way to compare list membership.  I suppose
> I could do it by pulling out the membership lists into files and then
> comparing the files...  *ponders and easy way to do this*

perhaps something along these lines? :

$ list_members gnucash-{patches,devel | sort > patches
$ list_members gnucash-devel | sort > devel
$ diff -u devel patches | grep ^+ | wc -l

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Derek Atkins
In reply to this post by Chris Shoemaker
We've got 26 email addresses subscribed to -patches but not subscribed
to -devel.  Of those 26 addresses, 9 of them are linas.org/gnucash.org
addresses of developers.  So that means there are 17 people subscribed
to -patches that are not subscribed to -devel.

-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
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
On Tue, Dec 27, 2005 at 12:59:00PM -0500, Derek Atkins wrote:
> We've got 26 email addresses subscribed to -patches but not subscribed
> to -devel.  Of those 26 addresses, 9 of them are linas.org/gnucash.org
> addresses of developers.  So that means there are 17 people subscribed
> to -patches that are not subscribed to -devel.

Oops. I forgot about people subscribed for the commit messages.  We
should post the new policy then.  Something as simple as:

This list will soon be read-only.  Please submit future patches to
[hidden email] with `[PATCH]' prefixed to the Subject line.

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

> On Tue, Dec 27, 2005 at 12:59:00PM -0500, Derek Atkins wrote:
>> We've got 26 email addresses subscribed to -patches but not subscribed
>> to -devel.  Of those 26 addresses, 9 of them are linas.org/gnucash.org
>> addresses of developers.  So that means there are 17 people subscribed
>> to -patches that are not subscribed to -devel.
>
> Oops. I forgot about people subscribed for the commit messages.  We
> should post the new policy then.  Something as simple as:
>
> This list will soon be read-only.  Please submit future patches to
> [hidden email] with `[PATCH]' prefixed to the Subject line.

Feel free to send that out now.  I'll cope with my personal methods
to keep track of patches between now and when we get something like
the trac tracker up and running.  I presume you don't object to requiring
developers (read: committers) to have trac accounts to handle and close out
patches?

> -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
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Chris Shoemaker
On Tue, Dec 27, 2005 at 01:19:29PM -0500, Derek Atkins wrote:

> Quoting Chris Shoemaker <[hidden email]>:
>
> >On Tue, Dec 27, 2005 at 12:59:00PM -0500, Derek Atkins wrote:
> >>We've got 26 email addresses subscribed to -patches but not subscribed
> >>to -devel.  Of those 26 addresses, 9 of them are linas.org/gnucash.org
> >>addresses of developers.  So that means there are 17 people subscribed
> >>to -patches that are not subscribed to -devel.
> >
> >Oops. I forgot about people subscribed for the commit messages.  We
> >should post the new policy then.  Something as simple as:
> >
> >This list will soon be read-only.  Please submit future patches to
> >[hidden email] with `[PATCH]' prefixed to the Subject line.
>
> Feel free to send that out now.  

Will do.

> I'll cope with my personal methods
> to keep track of patches between now and when we get something like
> the trac tracker up and running.  I presume you don't object to requiring
> developers (read: committers) to have trac accounts to handle and close out
> patches?

Except for marking a patch as applied, I'm not sure what that entails.
For patch discussion I hope trac has at least as good integration with
email as bugzilla does.  But it sounds reasonable to require trac accounts
and, no, I can't object until I've at least tried it.  :)

-chris
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] gnucash-patches mailing list

Derek Atkins
Quoting Chris Shoemaker <[hidden email]>:

>> I'll cope with my personal methods
>> to keep track of patches between now and when we get something like
>> the trac tracker up and running.  I presume you don't object to requiring
>> developers (read: committers) to have trac accounts to handle and close out
>> patches?
>
> Except for marking a patch as applied, I'm not sure what that entails.
> For patch discussion I hope trac has at least as good integration with
> email as bugzilla does.  But it sounds reasonable to require trac accounts
> and, no, I can't object until I've at least tried it.  :)

I guess it depends on what process we use.   I was thinking that
discussion of patches would happen on -devel -- trac would just
keep track of which patches are applied.  So devs would have to
go into trac to close out applied patches, but other than that
I doubt we'd not need trac accounts..    But I guess it depends on
what we do for process, and whether we want the discussion thread
stored in trac as well as the email archive.

> -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
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel