!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