!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
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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

Reply via email to