[Prism54] CVS -> bk tree update

[Prism54] CVS -> bk tree update

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 275 bytes --]


Hey Jeff,

was wondering what the status of the latest prism54 patches is. Did all
go through cleanly, are we in-sync now? Are there patches you're still
reviewing?

Thanks,

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

Re: [Prism54] CVS -> bk tree update

[Jeff Garzik]

Luis R. Rodriguez wrote:
> Hey Jeff,
> 
> was wondering what the status of the latest prism54 patches is. Did all
> go through cleanly, are we in-sync now? Are there patches you're still
> reviewing?


Check Andrew's -mm tree and see if there's anything missing.

	Jeff

Re: [Prism54] CVS -> bk tree update

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 1119 bytes --]

On Mon, Jun 14, 2004 at 06:31:48PM -0400, Jeff Garzik wrote:
> Luis R. Rodriguez wrote:
> >Hey Jeff,
> >
> >was wondering what the status of the latest prism54 patches is. Did all
> >go through cleanly, are we in-sync now? Are there patches you're still
> >reviewing?
> 
> 
> Check Andrew's -mm tree and see if there's anything missing.
> 
> 	Jeff

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.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

Re: [Prism54] CVS -> bk tree update

[Jeff Garzik]

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

This is one of the big downsides to developing in CVS, and it bites 
people again and again.

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.

	Jeff

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

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 3690 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

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

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 188 bytes --]


Jeff,

Ok 2.6.7 is out, we missed it. Now what, send a group of patches against that then?

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

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

[Francois Romieu]

Luis R. Rodriguez <mcgrof@studorgs.rutgers.edu> :
[...]
> 
> Ok 2.6.7 is out, we missed it. Now what, send a group of patches against
> that then?

Imho it would make sense to feed patch against -mm.

Do you have something like a tarball of the cvs repository up to the
point from which you have elaborated the 1898 lines diff against -mm ?

--
Ueimor

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

[Jeff Garzik]

Luis R. Rodriguez wrote:
> Jeff,
> 
> Ok 2.6.7 is out, we missed it. Now what, send a group of patches against that then?

Don't feel too bad, it was in release candidate status so any patches 
submitted would not have gone into 2.6.7 anyway (unless they were 
critical bug fixes).

I'll reply to your other email after a yummy bowl of Ramen noodles...

	Jeff

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

[Jeff Garzik]

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