public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Momchil Velikov <velco@fadata.bg>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: zack@codesourcery.com, <gcc@gcc.gnu.org>
Subject: Re: source mgt. requirements solicitation
Date: Sat, 14 Dec 2002 15:33:00 -0000	[thread overview]
Message-ID: <87znr8kw4w.fsf@merlin.maxx.bg> (raw)
In-Reply-To: <200212142107.gBEL78R23083@deepthought.transmeta.com>

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
    Linus> My tree is often called the "official" tree, but what it
    Linus> really is is just a base tree that many people maintain
    Linus> their own forks from.  This is fundamentally _more_

Err, haven't you noticed that this is the tree that many (all) people
want to merge their forks into ? I think this is "what it really is".

When evaluating a SCM tool, IMHO, the most important is the ease of
merges - remove the need for later merges and any sophisticated "fork"
tool boils down to a "cp -R".

    Linus> scalable than the CVS mess that is gcc, since it much more
    Linus> easily allows for very radical branches that do not need
    Linus> any centralized permission from me.

I surely have a "fork" of GCC and I ain't got nobody's permission.
Permission is needed not when forking, but when merging.

    Linus> Think of it this way: in gcc, the egcs split was a very
    Linus> painful thing.  In Linux, those kinds of splits (people
    Linus> doing what they think is right, _without_ support from the
    Linus> official maintainers) is how _everything_ gets done.  Linux
    Linus> is a "constantly forking" project, and that's how
    Linus> development very fundamentally happens.

    Linus> And a fork is a lot more scalable than a branch.  It's also

There's no difference, unless by "branch" and "fork" you mean the
corresponding implementations in CVS and BK of one and the same
development model.

    Linus> I would like to point out that Linux development has scaled
    Linus> a lot better than gcc, to a larger source base (it's 5+ M
    Linus> lines) with much more fundamental programming issues
    Linus> (concurrency etc).  I will bet you that the Linux kernel
    Linus> merges are a lot bigger than the gcc ones, that development
    Linus> happens faster, and that there are more independent
    Linus> developers working on their own versions of Linux than
    Linus> there are of gcc.

How about a different view on the subject ?

IMHO a good metric of the complexity of a particular problem/domain is
the overall ability of the mankind to cope with it.

Thus, what you describe, may be due to the fact that people capable of
kernel programming are a lot more than people capable of compiler
programming, IOW, that most kernel programming requires rather basic
programming knowledge, compared to most compilers programming.

No ?

    Linus> Any source control system that has "write access" issues is
    Linus> fundamentally broken in my opinion.  Your repository should
    Linus> be _yours_, and nobody elses.  There is no "write access".
    Linus> There is only some way to expedite a merge between two
    Linus> repositories.  The source control management should make it
    Linus> easy for you to export your changes to other repositories.

A SCM should facilitate collaboration.  Any SCM that requires single
person's permission for modifications to the source base (e.g. by
having only private repositories) is broken beyond repair and scalable
exactly like a BitKeeper^WBKL.

~velco

  parent reply	other threads:[~2002-12-14 22:41 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-08  7:13 on reputation and lines and putting things places (Re: gcc branches?) Robert Dewar
2002-12-08 14:18 ` source mgt. requirements solicitation Tom Lord
2002-12-08 14:56   ` DJ Delorie
2002-12-08 15:02     ` David S. Miller
2002-12-08 15:45       ` Bruce Stephens
2002-12-08 16:52         ` David S. Miller
2002-12-08 15:11     ` Bruce Stephens
2002-12-08 16:24       ` Joseph S. Myers
2002-12-08 16:47         ` Tom Lord
2002-12-08 22:20           ` Craig Rodrigues
2002-12-08 16:09   ` Phil Edwards
2002-12-08 19:13     ` Zack Weinberg
2002-12-09 10:33       ` Phil Edwards
2002-12-09 11:06       ` Joseph S. Myers
2002-12-09  9:42         ` Zack Weinberg
2002-12-09 11:00           ` Jack Lloyd
2002-12-09 15:10     ` Walter Landry
2002-12-09 15:27       ` Joseph S. Myers
2002-12-09 17:05         ` Walter Landry
2002-12-09 17:10           ` Joseph S. Myers
2002-12-09 18:27             ` Walter Landry
2002-12-09 19:16               ` Joseph S. Myers
2002-12-10  0:27                 ` Zack Weinberg
2002-12-10  0:41                   ` Tom Lord
2002-12-10 12:05                   ` Phil Edwards
2002-12-10 19:44                   ` Mark Mielke
2002-12-10 19:57                     ` David S. Miller
2002-12-10 20:02                       ` Phil Edwards
2002-12-10 23:07                         ` David S. Miller
2002-12-11  6:31                           ` Phil Edwards
2002-12-14 13:43                   ` Linus Torvalds
2002-12-14 14:06                     ` Tom Lord
2002-12-14 17:44                       ` Linus Torvalds
2002-12-14 19:45                         ` Tom Lord
2002-12-14 14:41                     ` Neil Booth
2002-12-14 15:47                       ` Zack Weinberg
2002-12-14 15:33                     ` Momchil Velikov [this message]
2002-12-14 16:06                       ` Linus Torvalds
2002-12-15  3:59                         ` Momchil Velikov
2002-12-15  8:26                         ` Momchil Velikov
2002-12-15 12:02                           ` Linus Torvalds
2002-12-15 14:16                             ` Momchil Velikov
2002-12-15 15:20                               ` Pop Sébastian
2002-12-15 16:09                                 ` Linus Torvalds
2002-12-15 16:49                                   ` Bruce Stephens
2002-12-15 16:59                                     ` Linus Torvalds
2002-12-15 18:10                                       ` Bruce Stephens
2002-12-16  8:32                                       ` Diego Novillo
2002-12-17  3:36                                         ` Pop Sébastian
2002-12-17 13:14                                           ` Tom Lord
2002-12-17 15:28                                             ` Itching and scratching (Re: source mgt. requirements solicitation) Stan Shebs
2002-12-17 16:07                                               ` Tom Lord
2002-12-17 15:46                                                 ` Stan Shebs
2002-12-16 17:22                                   ` source mgt. requirements solicitation Mike Stump
2002-12-15 17:09                         ` Stan Shebs
2002-12-09 17:50           ` Zack Weinberg
2002-12-11  1:11         ` Branko Čibej
2002-12-08 18:32   ` Joseph S. Myers
2002-12-11  2:48     ` Branko Čibej
2002-12-12  6:43 Robert Dewar
2002-12-14 20:16 Nathanael Nerode
2002-12-14 21:34 ` Linus Torvalds
2002-12-15 18:29 Nathanael Nerode
2002-12-18  9:06 Robert Dewar
2002-12-18  9:07 Robert Dewar
2002-12-18  9:48 ` Linus Torvalds
2002-12-18 10:11   ` Phil Edwards
2002-12-18  9:22 Robert Dewar
2002-12-18  9:35 Robert Dewar
2002-12-18  9:58 Robert Dewar
2002-12-18 17:33 Robert Dewar

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=87znr8kw4w.fsf@merlin.maxx.bg \
    --to=velco@fadata.bg \
    --cc=gcc@gcc.gnu.org \
    --cc=torvalds@transmeta.com \
    --cc=zack@codesourcery.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).