possible scm change for busybox dev

[Erik Hovland]

On Mon, Jun 12, 2006 at 09:55:19PM +0200, Bernhard Fischer wrote:
> >> If developers are specifically being sloppy about checking in, then
> >> there is not going to be a fix for this problem if you allow the same
> >> people to push to your public git repo.
> >
> >There's no coordination between developers at all.  (Erik's way of working and 
> >my way of working are different.)

Yes, this is what I was eluding to. The problem is not the scm, but the
way the scm is used.

> >> That may be easy seeing as Bernhard seems to behave a lot like Andrew
> >> Morton.
> 
> Not really.

To be clear. Andrew is the guy who triags patches and bugs. Bernhard
does way more of that then anyone else.

> >Preparing a bunch of patches to feed into my tree?  Not really, no.
> 
> The kernel is maintained in a monolitical manner. One person can write,
> everybody else can not.
> 
> The repository as it is now is setup so that several people can write.

I don't think that is a bad model. But it means that the committers have
to be trusted with the person actually responsible for releasing. It
certainly isn't fair for Rob to have to accept Erik A's web o' trust.
And it seems that Rob is chafing from this very problem.

Look, everyone knows what opinions are like. So take what you want from
this.

But from what Rob has been talking about, I think busybox scm should
have a trunk which only Rob and Bernhard have write access to.

Everyone else who currently has write access on trunk loses it. If
someone is developing interesting work, give them their own branch to
write to. This is helpful if Rob or Bernhard ever want to easily pull
that dev work. It skips the 'apply patch' step. It puts the problem of
merging with trunk on the dev occasionally merging from trunk to their
branch. And gets rid of Rob's headache. If people can't stand the
branching hassles then encourage use of svk (its a dirty kludge, but it
works).

Continue to provide stable branches once releases are cut. And just go
from there. Once commiters build trust again, they can have trunk access
back.

Obviously, there might be other people then Bernhard who could have
trunk that I have mentioned. That is merely my ignorance of the
community at large.

I think if you like the scm features of subversion, it shouldn't be
dropped. Unless there is some feature it lacks or it doesn't fit with the
scm model chosen.

E

-- 
Erik Hovland
mail: erik AT hovland DOT org
web: http://hovland.org/
PGP/GPG public key available on request