Per Inge Mathisen schreef: > On Mon, Aug 25, 2008 at 5:03 AM, bugs buggy <[EMAIL PROTECTED]> wrote: >> About these guidelines, take this: >> >> " Patches as a rule go into the patch tracker. Give a quick run down of what >> it does and what it changes." >> >> Does it matter which tracker? > > No. But if the tracker doesn't email the list, please do so manually.
NOTE: Setting up Trac to send a mail to the mailinglist for every *change* to a ticket (includes ticket creation) is trivial. Just adding an address to the smtp_always_cc will do. Only automatically notifying the mailing list when tickets are created is significantly less trivial. See Trac ticket #6613 [1] for the hack approach I took to implement it (Trac 0.10). >> " Patches that only fix bugs (no rewrites which fix bugs...) or build errors >> can go in at once." >> >> What do you mean by that? Most of the time you have to rewrite some stuff >> to fix the bug, unless you mean really simple errors that involve less than >> a few lines? > > If the fix is a few lines, fine. If you have to rewrite a lot of code > (ie has a high chance of introducing new bugs), then post the patch > for review first. I'm afraid that this approach translates to "every non-bugfix & non-documentation change has to go through the patch tracker". This approach would result in flooding the patch tracker, effectively demotivating almost anyone (it would demotivate me) from even looking at it. Also this would make incremental development (i.e. where change B depends on change A) nearly impossible (due to the minimum of 48 hrs wait time before committing if no one commented by then), thus it would actually promote "mega patches" which no one understands anymore (this due to the fact that Subversion is only capable of tracking a single change from "public" HEAD). git-svn could alleviate this somewhat, but only for changes that require no other changes than file modifications. Then regarding: > If a subsystem of the code has its own maintainer, that person is > free to make commits to this code without posting to the list first. I hope you don't mean this to translate to "subsystems are owned by their maintainers" ? As I think that code ownership is a *very*, *very* bad thing. This because it will demotivate people that are not the "owner" to touch that code, which would result in only the "owner" having real knowledge about how that code works. Thus for the purpose of maintaining that code we would come to depend on whomever "owns" that code. What I'm talking about now is, in part, the "bus-factor" [2], which we should keep as high as possible. The linked video in that wikipedia page, [3], also addresses this in a rather interesting way. I'd recommend to see the whole video if you have the time (1 hour), the "bus-factor" is dealt with in the time frame from 16:30ish to 20:30ish. [1] http://trac.edgewall.org/ticket/6613 [2] http://en.wikipedia.org/wiki/Bus_factor [3] http://video.google.com/videoplay?docid=-4216011961522818645 -- Giel
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
