Subject: Re: Wine release 960131
From: torvalds@cc.helsinki.fi (Linus Torvalds)
Date: Feb 10 1996
Newsgroups: comp.emulators.ms-Windows.wine

In article <JULLIARD.96Feb8140221@lrcsuns.epfl.ch>,
Alexandre Julliard <julliard@lrcsuns.epfl.ch> wrote:

>I'm perfectly willing to change the schedule if people think it's a
>good idea. The fixed two-weeks schedule was instituted on many
>people's request that they needed to know when to submit their
>patches.

I can only speak for the kernel, but I have to say that the less fixed
scheme with releases very often (or as often as I deem necessary) has
been very nice.  Not only for development speed, but for me personally. 

>	 It would probably be easier for me to make a release whenever
>I got enough changes, instead of receiving a bunch of patches on the
>day before making the release (I got 36 different patches for last
>release, not to mention my own changes, so it's no wonder a few things
>are broken).

I'd definitely discourage that sort of development: not only does it put
an unnecessary strain on you personally, but it also makes it harder for
the other developers to synchronize. 

>	    Of course this would mean that all people who didn't
>submit their patches before the release would have to re-synchronise
>their changes with the new release.

This hasn't been a problem at least for me and the kernel, exactly
_because_ it forces the other developers to re-synchronize. 

Essentially, the way I work, if I get patches that I consider dubious,
or that do not patch in cleanly into my current sources any more, I make
sure I have a recent release available and then ask the person who sent
me the patches to re-submit a synchronized patch (in fact, in most cases
I don't even need to ask: the person notices that the patch wasn't in
the latest release, and re-submits automatically). 

Note that this actually means _less_ work for the main developer, while
at the same time improving quality control (because instead of having
one person trying desperately to make the patches fit, you have the
authors of the patches themselves to do it - they know better what the
intention of the patch was in the first place anyway). 

Also, because you make releases often, it's easier to synchronize to the
latest kernel. 

(It makes it a bit harder to synchronize for people who do patches only
once and don't have the stamina to keep synchronizing them, but that
kind of developer isn't likely to do good work in the long run anyway). 

So I can wholeheartedly recommend the "linux kernel development
approach".  It has certainly worked for me (somebody claimed that wine
and linux aren't comparable, because wine is in early beta testing, but
linux was like that too for a long time and it worked fine for me back
then too). 

		Linus