On Mon, Aug 25, 2008 at 2:59 PM, Giel van Schijndel <[EMAIL PROTECTED]> wrote:
>> 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.

That is fine by me.

>> 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.

It won't be flooded if people close tickets when they are done with them.

> 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.

Shall we try this system for a little while before spelling doom and
gloom over it?

> 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.

Well, it works for the linux kernel, so I suppose it cannot be all that bad.

  - Per

Warzone-dev mailing list

Reply via email to