Re: There is no cabal (was: the BK flamewar)

[Jeff Garzik <garzik@havoc.gtf.org>]

On Mon, Apr 22, 2002 at 04:22:29PM -0700, Davide Libenzi wrote:
> On Mon, 22 Apr 2002, Jeff Garzik wrote:
> 
> > 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.
> 
> Jeff, did you really mean this ?
> 
> "If we attempt to pretend that BK is not widely usage ..."
> 
> It did not seem to me that Linus required BK to interact with him. So to
> be or not to be inside the above group does not depend at all from BK
> usage. BK can make life a lot easier for guys handling huge number of
> patches with complex hierarchies, but forcing the one working with 1-5
> patches to use it, it reflects the "trend followup" i was talking about.

If you read that from what I wrote, you are mistaken...

I'm saying that removing the BK doc from the kernel sources removes
description of one, _optional_ avenue to Linus.  That is denying
people information.

Which is completely contrary to one of my goals, spreading knowledge
about working with Linus to decrease the barrier of entry.

BK is not a requirement, even for regular submittors.  Optional.

	Jeff