Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: commit early, commit often (was: Submit patch again?)
Home

[Freeciv-Dev] Re: commit early, commit often (was: Submit patch again?)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Reinier Post <rp@xxxxxxxxxx>
Cc: Freeciv developers <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: commit early, commit often (was: Submit patch again?)
From: Daniel Sjölie <deepone@xxxxxxxxxx>
Date: Thu, 16 Aug 2001 10:37:22 +0200

On 2001-08-16 10:11:56, Reinier Post wrote:
> On Wed, Aug 15, 2001 at 11:33:32PM -0700, Kevin Brown wrote:
> > > Another problem is that patches get lost or outdated too easily.
> > 
> > This is because they're not being committed to CVS!
> 
> Not sure.  If they were in CVS (on separate branches?)
> their status might be even harder to follow.

But if a patch gets into CVS there's no need to track it really... It
will be improved and bugfixed with new patches to CVS, not patches to
patches to patches...

> > In my little time here on the list, there's one impression I get that
> > seems to come through loud and clear: there is a great reluctance to
> > commit patches to the CVS tree, sometimes for the most trivial of
> > reasons (coding style, for instance).
> 
> Yes, the policy has been to keep the source tree stable and clean.
> (Note: I'm just echoing what others have said here, I'm not a
> core developer.)
> 
> > I can't stress this enough: commits of patches to CVS are the *only*
> > way to make forward progress in the development of Freeciv.  So it
> > follows that it should be as easy as possible to get a patch into CVS.
> > If the concern is the integrity of the code, then remember that in CVS
> > you can create a fork and merge it back into the main tree later.  So
> > for particularly hairy patches we could, for instance, create a CVS
> > fork, apply the patch, create a binary distribution from the fork, let
> > dudes test it out and give feedback, and eventually merge it back into
> > the main line...or discard it if it's too difficult to fix.
> 
> Seems like a good thing to try ... some change is definitely required.

I don't think that one branch for each patch is a good idea - but I
certainly think that an UNSTABLE CVS branch would be a really good
idea... That would be a branch created after every release where patches
get submitted pretty much as soon as they're compiling... Or something
like that... :) It should be a lot easier to get in there than to
current CVS anyway...

Is it possible to grant write access to one branch but not another?
Perhaps not... If so, perhaps there should be an unstable cvs repositry
instead - so there could be more people with write access to that one...
Eg, everyone who gets a patch into stable gets direct write acces to
unstable... Write access isn't that dangerous... CVS can be reverted to
an older version You know... :)

/Daniel

-- 
Now take a deep breath, smile and don't take life so seriously... :)


[Prev in Thread] Current Thread [Next in Thread]