About this list Date view Thread view Subject view Author view Attachment view

From: Sam Vilain (sam_at_vilain.net)
Date: Wed 04 May 2005 - 02:53:47 BST

Michal Ludvig wrote:
> Don't take it personally as I just wonder - is your effort blessed by
> current project maintainers? (Herbert, Enrico, ...) Or is it a fork attempt?

No-one's trying to fork anything. If anything, we're trying to help
people pull their forks into the one repository. "We" so far including
Herbert, Björn, Ola and me. Enrico and Jacques have also been invited.

> I'm not sure if you have an experience with development management, but
> allowing wiki style development seems contraproductive for me.

You need a certain critical mass of eyeballs watching the changes go in
before it works. Another important thing is automated smoke testing to
track down where one fixed bug causes four new ones. Which of course we
don't have yet, but the theory is good! :)

> I have participated in many opensource projects and I know how "naive"
> patches people (incl. me) try to commit at the beginning. They could fix
> a particular problem they address but without knowing the broader
> context they'd often break something else.

Yes, that is fine. If you change something and break the tests, or
someone else sees the change and realises that there are conditions that
it would break, then it raises an issue that must be solved. Ideally by
first adding a failing test to demonstrate the problem and then fixing

If the change is decided to be a larger piece of work, then a branch can
be made easily.

The worst case is to reverse an individual change, in which case it is
still not a complete loss - the person who made the change finds out why
what they were doing was wrong. If they don't learn they lose their
commit bit.

The important point is to encourage exchange of ideas through code, and
to connect eager hands with yearning code.

> The amount of crap getting in this way would be a real pain in the ass
> to clean once you're about to make a release.

Changes to parts considered "production" will generally be reviewed as
they are made.

> Eh, and one more "proven" thing - set up a mailing list whete all diffs
> from commits would be automatically posted by svn. If you really allow
> everyone commit everything you should at least post-examine the changes.

I'm working on this now!

Thanks for your input,
Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 04 May 2005 - 02:54:30 BST by hypermail 2.1.3