gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] distringuished branches, Re: distinguished branch n


From: Robert Collins
Subject: Re: [Gnu-arch-users] distringuished branches, Re: distinguished branch name, "clone"
Date: Sun, 09 Nov 2003 19:24:56 +1100

On Mon, 2003-11-10 at 18:19, Colin Walters wrote:
> On Sun, 2003-11-09 at 01:43, Robert Collins wrote:
> > As for more complicated, switching between versions like
> > you suggest is more complicated in terms of side effect.
> 
> Not really any more complicated than the fact that upgrading sometimes
> changes the version in configure.ac, for example.

Yes it is more complex. What if the user wants to track the version they
checked out? I.e. if someone wants to track rhythmbox 0.6, they have to
put extra effort in to stay on that version. And what if you have
several versions open in parallel ? For instance: in squid we have squid
2.5 - stable, and 3.0 - unstable. No one in their right mind would want
to accidentally end up on 3.0. The vast majority of our users track
stable, because this is core infrastructure. Likewise for cygwin - the
bulk of users track stable released code. And I suspect that for gcc the
same applies - the bulk of users want the released code, the bleeding
edge are in the minority. Following your scheme, I strongly suspect the
bulk of users will need to put in extra effort to follow the 'common
case' - that is to avoid being automatically 'upgraded' to the next
version up of whatever branch they are tracking.

> > So you're improving our lot? I don't buy that. I'd buy "my users are
> > giving me grief".
> 
> Is that what you want to hear?  Because let me tell you, I've certainly
> gotten it.  Not overwhelmingly so; but the certainly majority of people
> I've helped learn arch have been frustrated by the requisite verbosity.

I don't want to hear any specific thing. But I do want something that
rings true, and altruism didn't.

> >  Or "Bug 5XXX on savannah is an end user needing hand
> > holding". Or "I'm getting RSI typing in rhythmbox ad infinitum and I
> > don't want to maintain a fork".  (Well, if you do that much RCS relative
> > to actual coding, I'd be amazed. But the point is made I hope).
> 
> One issue is that I have to help a lot of people out with arch, and that
> involves typing these commands a lot more than I ordinarily would.  So
> the effect of the verbosity on me personally is magnified
> proportionally.

I'm surprised you haven't got a boilerplate howto for your project. The
projects I'm involved in do for CVS, and for arch (as appropriate, per
project).

> > I really think that for both the use cases you have proposed, an
> > external implementation is the right proving ground for them.
> 
> Why in the world would this go in an external implementation?  We're
> talking about probably at most 50-100 lines of code.  This isn't a
> complex problem, it's mostly an issue of sane defaults.

It's not code size thats the issue. I don't recall saying it was. If the
design is questionable, it should not go in the core until it's been
thrashed out. 

Rob
-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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