From: Jeff Garzik <garzik@havoc.gtf.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Daniel Phillips <phillips@bonn-fries.net>,
dean gaudet <dean-list-linux-kernel@arctic.org>,
Larry McVoy <lm@bitmover.com>,
linux-kernel@vger.kernel.org
Subject: There is no cabal (was: the BK flamewar)
Date: Mon, 22 Apr 2002 18:17:42 -0400 [thread overview]
Message-ID: <20020422181742.A17575@havoc.gtf.org> (raw)
In-Reply-To: <20020422164728.H20999@havoc.gtf.org> <Pine.LNX.4.44.0204221446070.1578-100000@blue1.dev.mcafeelabs.com>
On Mon, Apr 22, 2002 at 03:04:19PM -0700, Davide Libenzi wrote:
> On Mon, 22 Apr 2002, Jeff Garzik wrote:
>
> > The real question, as I understand it, is whether or not the kernel doc
> > should be in the kernel source or not. If the answer is 'no', then I
> > fully support making it a URL, or printing it out the back of
> > phonebooks, or whatever means of distribution :)
>
> i really tried to remain out of this. in theory, like Linus said, we
> should not even know that he's using bk. it should be completely hidden.
> the only method described inside the kernel tarbal should be the
> old diff+patch one. main maintainers ( i mean the group of at most 10 that
> are handling huge number of patches and that are highly interacting with
> Linus ) will very likely get benefits from using bk instead of diff+patch,
> but for these one no doc is necessary. either they know or Larry can
> provide them with all the docs they need. for all the remaining crew, bk
> adoption is simply a trend followup.
Nope, the kernel doc was created precisely for the kernel maintainers,
cuz most of them (like me) had no clue about how to use BK nicely
for the kernel. Honestly, we were all lazy (except the PPC guys
and GregKH, I guess :)) and let Linus figure out kernel development
under BK.
If we attempt to pretend that BK is not widely usage, you do a
dissservice to other kernel developers, sysadmins, and power users --
and possibly _increase_ the barrier to entry of the "group of at most
10" you describe above.
That "10" does not need do, and should never be, an exclusive club...
it just sorta evolved over time as the people who work best with
Linus. I want to spread knowledge about working well with Linus
as far and as wide as possible -- that benefits all Linux users,
and open source overall.
I think I have proven that I am working towards that goal, of
publishing "Linus knowledge" -- I wrote not only the BK version of
Doc/SubmittingPatches, but also Doc/SubmittingPatches itself.
Let the knowledge out there, and let people make their own decisions...
Jeff
next prev parent reply other threads:[~2002-04-22 22:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020421101731.D10525@work.bitmover.com>
2002-04-21 17:22 ` [PATCH] Remove Bitkeeper documentation from Linux tree Jeff Garzik
2002-04-20 17:48 ` Daniel Phillips
2002-04-21 17:55 ` Jeff Garzik
2002-04-20 18:07 ` Daniel Phillips
2002-04-20 18:13 ` Daniel Phillips
2002-04-21 18:15 ` Jeff Garzik
2002-04-20 18:26 ` Daniel Phillips
2002-04-21 18:40 ` Jeff Garzik
2002-04-21 18:21 ` Larry McVoy
2002-04-20 18:29 ` Daniel Phillips
2002-04-21 18:36 ` Larry McVoy
2002-04-20 18:46 ` Daniel Phillips
2002-04-21 19:07 ` Larry McVoy
2002-04-21 14:39 ` Daniel Phillips
2002-04-21 18:38 ` yodaiken
2002-04-21 18:08 ` Larry McVoy
2002-04-20 18:15 ` Daniel Phillips
2002-04-21 19:06 ` dean gaudet
2002-04-21 14:53 ` Daniel Phillips
2002-04-22 17:03 ` Jeff Garzik
2002-04-21 17:27 ` Daniel Phillips
2002-04-22 17:30 ` Larry McVoy
2002-04-21 17:47 ` Daniel Phillips
2002-04-22 17:40 ` Jeff Garzik
2002-04-21 17:57 ` Daniel Phillips
2002-04-22 20:47 ` Jeff Garzik
2002-04-21 20:54 ` Daniel Phillips
2002-04-22 22:04 ` Davide Libenzi
2002-04-22 22:17 ` Jeff Garzik [this message]
2002-04-22 23:22 ` There is no cabal (was: the BK flamewar) Davide Libenzi
2002-04-22 23:27 ` Jeff Garzik
2002-04-22 20:37 ` double-standard? (Re: [PATCH] Remove Bitkeeper documentation from Linux tree) dean gaudet
2002-04-21 20:49 ` Daniel Phillips
2002-04-21 20:22 ` [PATCH] Remove Bitkeeper documentation from Linux tree Andrew Morton
2002-04-22 0:01 ` Larry McVoy
2002-04-22 20:32 ` Jeff Garzik
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=20020422181742.A17575@havoc.gtf.org \
--to=garzik@havoc.gtf.org \
--cc=davidel@xmailserver.org \
--cc=dean-list-linux-kernel@arctic.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
--cc=phillips@bonn-fries.net \
/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
all inboxes | Powered by JetHome®