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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
