Michael Lorenz <macallan@netbsd.org> writes:

> Hello,
>
> On Feb 15, 2007, at 13:56, Bucky Katz wrote:
>
>> The whole point of our trying to get the patches into the CVS tree
>> is to reduce the workload of having to continually reapply patches
>> every time we pull a new CVS tree into our work environment.
>
> Hmm, usually cvs update does a pretty good job merging changes. 
> Certainly works for me ( with occasional conflict solving of course )
>

We use perforce internally and have a *lot* of changes to the kernel
that we haven't submitted.  They include proprietary filesystems that
I can't submit, power management for embedded systems, MI drivers that
conflict with drivers that were submitted after we finished ours but
before we could submit ours, a MI layer for NAND support that we
haven't decided if there's any value in submitting, and
NetBSD-as-USB-Device USB kernel subsystem that's not ready to submit
yet, and bug fixes that I simply haven't had time to turn into
sendprs.

Once a month, I put the tarball snapshots from CVS, make sure they
build, run a regression of them on an omap target, import them into
our "NetBSD vendor tree" in perforce and then integrate from there
into our NetBSD development tree. (My "most of a day" starts at the
import)

>> The problem with a pullup is that we'd have to rebase all of our other
>> stuff back onto 4.0 I believe that rebase would be more work than
>> coping with the 1:1 change will be.
>
> Really? 4.0 was rebranched pretty recently, it can't be that far from 
> HEAD-before-newlock2. I'd almost bet the OMAP stuff hasn't been touched 
> since.
>

I could be wrong. I was thinking of how much change happened since the
original 4.0 branch and not the rebranch.

But as you can see from the above it's not just OMAP stuff. We've
tracked changes to the filesystem interfaces for example that I
believe aren't in 4.0 but are in -current.

>> We've adapted libpthread to support userlevel thread priorities, which 
>> our application needs, and we'll have to redo that adaptation. (That's 
>> the patch I sent Andrew to review.)
>
> Seriously - did you even look at the 4.0 branch? Or am I missing 
> something here?

We've been working in -current for over a year. If I recall correctly,
the original 4.0 branch was in November. Maybe the rebranch would make
it easier.  Not removing m:n uniprocessor support would make it moot.

But the other aspect of our staying in -current was my (possiblly
incorrect) understanding that if we submitted new bits, such as the
USB device subsystem, they'd go in current and not a stable branch.

Given that you now know that we intend to submit some large chunks of
functionality should we be working in -current?