From: Larry McVoy <lm@bitmover.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Larry McVoy <lm@bitmover.com>, linux-kernel@vger.kernel.org
Subject: Re: The direction linux is taking
Date: Thu, 27 Dec 2001 12:33:44 -0800 [thread overview]
Message-ID: <20011227123344.H25698@work.bitmover.com> (raw)
In-Reply-To: <20011227121033.F25698@work.bitmover.com> <Pine.LNX.4.33.0112271213210.1167-100000@penguin.transmeta.com>
In-Reply-To: <Pine.LNX.4.33.0112271213210.1167-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Thu, Dec 27, 2001 at 12:21:02PM -0800
On Thu, Dec 27, 2001 at 12:21:02PM -0800, Linus Torvalds wrote:
>
> On Thu, 27 Dec 2001, Larry McVoy wrote:
> > On Thu, Dec 27, 2001 at 06:05:40PM +0000, Linus Torvalds wrote:
> > > Note that things like CVS do not help the fundamental problem at all.
> > > They allow automatic acceptance of patches, and positively _encourage_
> > > people to "dump" their patches on other people, and not act as real
> > > maintainers.
> >
> > Huh. I'm not sure I understand this. Once you accept a patch into the
> > mainline source, are these people still supposed to maintain that patch?
>
> [Linus stuff]
But this didn't answer my question at all. My question was why is this a
problem related to a source management system? I can see how to exactly
mimic what described Al doing in BK so if that is the definition of goodness,
the addition (or absence) of a SCM doesn't seem to change the answer.
I _think_ what you are saying is that an SCM where your repository is a
wide open black hole with no quality control is a problem, but that's
not the SCM's fault. You are the filter, the SCM is simply an accounting/
filing system.
> > > I know that source control advocates say that using source control makes
> > > it easy to revert bad stuff, but that's simply not TRUE. It's _not_
> > > easy to revert bad stuff.
> >
> > It's trivial to revert bad stuff if other stuff hasn't come to depend
> > on that bad stuff, assuming a reasonable SCM system.
>
> Well, there's the other part to it - most bad stuff is just "random crap",
> and may not have any physical bad tendencies except to make the code
> uglier. Then, people don't even realize that they are doing things the
> wrong way, because they do cut-and-paste, or they just can't do things the
> sane way because the badness assumes a certain layout.
>
> And THAT is where badness is actively hurtful, while not being buggy.
> Which is why I'd much rather have people work on maintenance, and not rely
> on the bogus argument of "we can always undo it".
No argument. In fact, wild agreement. I absolutely *hate* bad crap
being checked into the tree because when it is fixed later it obscures
the original reason for the addition of the code in the first place.
While we rarely reach it, I think we can agree it would be great if code
were checked in once and never modified again because it is perfect.
Obviously a pipe dream, but I think it is the sentiment you are expressing
- don't check in garbage, check in good stuff, and anything that makes
checking in garbage easier is a Bad Thing (tm).
Switching topics just slightly, isn't one of the main problems with SCM
systems that the end user does the merges rather than the maintainer?
Look at how you do it:
a) release tree
b) wait for patches
c) weed through patches looking for good ones
d) apply patches, which means merging in some cases
e) repeat
but your typical SCM has the end user doing the merges, not the maintainer.
If you had an SCM system which allowed the maintainer to do all or some of
the merging, would that help?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
next prev parent reply other threads:[~2001-12-27 20:34 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-27 15:46 The direction linux is taking Dana Lacoste
2001-12-27 16:01 ` Rik van Riel
2001-12-27 16:33 ` Alan Cox
2001-12-27 16:30 ` Rik van Riel
2001-12-27 16:53 ` Alan Cox
2001-12-27 17:03 ` Thomas Capricelli
2001-12-27 17:54 ` Alan Cox
2001-12-27 16:57 ` Russell King
2001-12-27 17:11 ` Rik van Riel
2001-12-27 17:25 ` Erik Mouw
2001-12-27 18:05 ` Linus Torvalds
2001-12-27 18:24 ` Rik van Riel
2001-12-27 18:58 ` Linus Torvalds
2001-12-27 19:16 ` Rik van Riel
2001-12-27 19:29 ` Linus Torvalds
2001-12-27 19:46 ` Rik van Riel
2001-12-27 19:57 ` Richard Gooch
2001-12-27 20:07 ` Rik van Riel
2001-12-27 20:12 ` Linus Torvalds
2001-12-27 21:13 ` Troy Benjegerdes
2001-12-27 21:18 ` Rik van Riel
2001-12-27 21:28 ` Richard Gooch
2001-12-27 18:37 ` Dave Jones
2001-12-27 19:25 ` Linus Torvalds
2001-12-27 20:16 ` Dave Jones
2001-12-27 19:33 ` Arnaldo Carvalho de Melo
2001-12-27 21:20 ` Legacy Fishtank
2001-12-27 20:10 ` Larry McVoy
2001-12-27 20:21 ` Linus Torvalds
2001-12-27 20:33 ` Larry McVoy [this message]
2001-12-27 20:41 ` Linus Torvalds
2001-12-27 20:50 ` Larry McVoy
2001-12-27 21:43 ` Troy Benjegerdes
2001-12-27 21:53 ` Larry McVoy
2001-12-29 17:14 ` Oliver Xymoron
2001-12-29 17:27 ` Larry McVoy
2001-12-28 2:27 ` Alexander Viro
2001-12-27 20:43 ` Alan Cox
2001-12-27 17:38 ` Richard Gooch
2001-12-27 17:55 ` Dave Jones
2001-12-27 18:04 ` Richard Gooch
2001-12-27 18:06 ` Dave Jones
2001-12-27 18:17 ` Richard Gooch
2001-12-27 18:02 ` Alan Cox
2001-12-27 17:59 ` Richard Gooch
2001-12-27 18:38 ` Russell King
2001-12-28 4:03 ` Daniel Phillips
2001-12-29 18:02 ` Oliver Xymoron
2001-12-29 19:06 ` Christer Weinigel
2001-12-29 19:18 ` Oliver Xymoron
2001-12-29 19:37 ` Larry McVoy
2001-12-29 19:58 ` Oliver Xymoron
2001-12-29 20:04 ` Larry McVoy
2001-12-29 20:30 ` Oliver Xymoron
2001-12-29 22:09 ` Larry McVoy
2001-12-29 22:24 ` Oliver Xymoron
2001-12-29 23:01 ` Alan Cox
2001-12-29 22:59 ` Oliver Xymoron
2001-12-29 23:09 ` Alexander Viro
2001-12-29 23:07 ` Dave Jones
2001-12-29 23:19 ` Alan Cox
2001-12-29 23:24 ` Dave Jones
2001-12-29 23:33 ` Oliver Xymoron
2001-12-29 23:41 ` Arnaldo Carvalho de Melo
2001-12-31 8:51 ` Daniel Phillips
2001-12-29 23:04 ` Larry McVoy
2001-12-29 23:29 ` Oliver Xymoron
2001-12-29 23:35 ` Larry McVoy
2001-12-29 23:59 ` Oliver Xymoron
2001-12-30 0:04 ` Larry McVoy
2001-12-30 0:25 ` Oliver Xymoron
2001-12-29 22:26 ` Dave Jones
2001-12-29 23:02 ` Alan Cox
2001-12-29 20:01 ` Olivier Galibert
2001-12-29 20:04 ` Dave Jones
2002-01-02 15:06 ` Geert Uytterhoeven
2001-12-29 21:03 ` Benjamin LaHaise
2001-12-29 22:04 ` Larry McVoy
2001-12-29 22:58 ` Alan Cox
2001-12-29 23:14 ` Larry McVoy
2001-12-29 23:33 ` Dave Jones
2001-12-29 23:38 ` Larry McVoy
2001-12-29 23:47 ` Dave Jones
2001-12-29 23:50 ` Atomic Killer Attack Fish
2001-12-30 2:36 ` Alan Cox
2001-12-30 2:49 ` Larry McVoy
2001-12-30 3:54 ` Dave Jones
2001-12-30 10:07 ` Alan Cox
2002-01-01 1:32 ` Horst von Brand
2001-12-31 21:24 ` Rob Landley
2002-01-01 1:46 ` Dave Jones
2002-01-02 14:59 ` Geert Uytterhoeven
2001-12-31 8:45 ` Daniel Phillips
2001-12-31 21:33 ` Rob Landley
2002-01-02 10:14 ` Daniel Phillips
2002-01-02 10:50 ` Neil Brown
2002-01-02 11:07 ` Daniel Phillips
2001-12-27 18:41 ` John Alvord
2001-12-27 18:49 ` Russell King
2001-12-27 17:52 ` Alan Cox
2001-12-27 17:59 ` Andre Hedrick
-- strict thread matches above, loose matches on Subject: below --
2002-01-07 5:26 Eyal Sohya
2001-12-27 21:24 Dana Lacoste
2001-12-27 20:45 Dana Lacoste
2001-12-27 20:55 ` Larry McVoy
2001-12-23 14:18 Eyal Sohya
2001-12-23 14:13 Eyal Sohya
2001-12-23 14:11 Eyal Sohya
2001-12-18 15:18 Dana Lacoste
2001-12-18 18:08 ` John Alvord
2001-12-18 18:42 ` rsweet
2001-12-18 19:50 ` Alan Cox
2001-12-18 14:32 Dana Lacoste
2001-12-18 15:04 ` Alan Cox
2001-12-18 15:09 ` Dead2
2001-12-18 18:37 ` Ken Brownfield
[not found] ` <01121909274103.01840@manta>
2001-12-19 9:56 ` Dead2
2001-12-19 18:06 ` Ken Brownfield
2001-12-19 18:11 ` Ken Brownfield
2001-12-18 5:20 Eyal Sohya
2001-12-18 6:11 ` Craig Christophel
2001-12-18 12:19 ` Rik van Riel
2001-12-18 14:38 ` M. Edward (Ed) Borasky
2001-12-18 15:18 ` David Weinehall
2001-12-18 15:27 ` Momchil Velikov
2001-12-20 6:49 ` Kai Henningsen
2001-12-20 9:30 ` Momchil Velikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011227123344.H25698@work.bitmover.com \
--to=lm@bitmover.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox