Re: [Prism54-devel] Re: [Prism54] CVS -> bk tree update

[Jeff Garzik <jgarzik@xxxxxxxxx>]

Luis R. Rodriguez wrote:
> On Tue, Jun 15, 2004 at 11:10:28PM -0400, Jeff Garzik wrote:
> > Sorry, no.  You knew that split-up patches would be needed, once the 
> > initial driver merge is complete (which was complete before the most 
> > recent series of 17 patches).
>
>
> Actually no. I wasn't aware of how netdev patches went upstream until
> the driver got in and our first set of patches got rejected. After the
> driver got in the kernel the first set of patches was just to get the
> kernel tree up to speed with what *really* was current in our cvs tree
> (remember Jean was the one who submitted the original patch).
>
> What occurred afterwards was more of a misunderstanding of what is
> acceptable and what is not for patches for network driver projects. I
> thought, since you had suggested to continue with the prism54 project,
> and submit a patch for our next release. No one on our dev team or 
> lists knew any better or didn't say much to make us think otherwise.

This is general Linux kernel development, nothing netdev specific about 
it (besides who the email goes to).

The details are in Documentation/SubmittingPatches.

Large "megapatches" are _always_ discouraged.  The only normal case 
where large patches are accepted is when adding new drivers.


> > This is one of the big downsides to developing in CVS, 
>
>
> <edit> for the kernel since what's mainly used by mantainers is
> bitkeeper </edit> 

Nope.  CVS specifically sucks above all other SCMs, including 
no-SCM-at-all :)

"subversion" and "arch" are up-and-coming open source competitors to 
BitKeeper, that are already 1000 times better than cvs.

I kept my kernel hacking in cvs for years 
(http://sf.net/projects/gkernel/) but I abandoned that before BitKeeper 
arrived, because CVS was simply the _wrong_ SCM for kernel development.

CVS does not have a good idea of what a "changeset" is, it only knows 
about individual file revisions.  CVS is a big fat hack :)  But nothing 
else was free and remotely usable at the time, so it caught on.


> > and it bites 
> > people again and again.
>
>
> CVS is used as a project repository, not *the linux kernel repository*. It would
> seem to me reasonable though that if a project is doing a good job in
> making sure code gets tested, keeping a tight bugzilla, cvs daily
> updates, a detailed changelog, and viewcvs, that a big patch sent out to
> kernel mantainers for a new driver project release version would just be
> accepted. Apparantly not and *this* is what sucks about using CVS -- the
> fact these rules for small patches exist, and that the kernel uses a
> different versioning system. And that's it.

Versioning system is irrelevant, it's the lack of changeset support in 
CVS that hurts the most.


> > Linux kernel development relies on split-up patches for review, testing, 
> > and narrowing down which patch in a series introduced a bug.  There 
> > are real, engineering-related reasons we do things this way.
>
>
> Don't get me wrong... I love this. I think that because of this is why
> we have such a great kernel. The problem here was that there was
> miscommunication between you, Jean, and us. The patch shouldn't have
> been accepted to include the driver into the kernel until 
> our main project goals were completed. We then did not know the details 
> on followup procedures to update netdev drivers, nor were we told.

Agreed, this was largely a problem of miscommunication.

For my part, I simply assumed that you guys knew the standard kernel 
procedure (Documentation/SubmittingPatches), since the first two steps 
were successful:
1) submit driver, and
2) submit follow-up changes as small, broken-up patches


> We've learned our lesson the hard way. Oh well. Just please warn others
> submitting new drivers too -- submit until you think you only have small
> changes left, and also integrate the driver by verifying first with the 
> mantainers (warn about patch policy, etc).

We mainly need to make sure people read Documentation/SubmittingDrivers 
and Documentation/SubmittingPatches...


> This also just makes me want to just consider using bitkeeper. What benefits are
> there for our project, would we be able to get write access, and how
> else would procedures change for us?

Bitkeeper is de-centralized, designed for massively distributed 
development.  The best way to answer your questions is to read 
Documentation/BK-usage/bk-kernel-howto.txt -- I wrote it, and it 
presents BitKeeper from a CVS point of view, for kernel hackers.

Food for thought:  There is no client/server in BitKeeper, each 
repository on disk it essentially its own branch.

As to submitting changes via BitKeeper, here is an example of me sending 
changes to Linus: 
http://seclists.org/lists/linux-kernel/2003/Dec/1166.html (that email is 
almost completely auto-generated)

        Jeff