On Fri, Dec 09, 2005 at 04:09:10PM -0500, Derek Atkins wrote: > Chris Shoemaker <[EMAIL PROTECTED]> 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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
