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

[Luis R. Rodriguez]

On Tue, Jun 15, 2004 at 11:10:28PM -0400, Jeff Garzik wrote:
> Luis R. Rodriguez wrote:
> >Thanks Jeff. I did, and a diff of Andrew's -mm tree Vs our cvs tree
> >2.6.7-prism54 gives a 1898 line diff. This is excluding spaces,
> >newlines, and tabbing and all of Andew's .orig, .rej's. 
> >
> >This time it's going to be a *real* pain to provide a changelog and split 
> >the
> >diffs.. so can I just send you that 1898 line diff and then another for
> >space changes? Everything has already been reviewed on the lists here...
> >
> >I promise this will be our last big patch too. I'll ask our team
> >to send patches from now on to netdev after each ChangeLog entry, for
> >more public review and to not loose sync of our trees. Let us know if
> >you think we should do otherwise.
> 
> 
> 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 one of the big downsides to developing in CVS, 

<edit> for the kernel since what's mainly used by mantainers is
bitkeeper </edit> 

> 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.

> 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.

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'll just send patches for *every* CVS changelog entry from now on.

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?

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://prism54.org/pipermail/prism54-devel/attachments/20040616/4fbaf929/attachment.pgp