-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Feb 15, 2007, at 16:24, Bucky Katz wrote:

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

Ah, that explains it ( sorry, was just curious )

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

Ah yes, not many people were happy with the first branch.

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

There was a lot of work in the vfs area, mainly about locking issues I 
think but I could be wrong - not my work area or anything I feel 
competent enough to comment on.

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

I'm pretty sure it will.

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

They'd go first into -current.

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

That would certainly be easier for us.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRdTppcpnzkX8Yg2nAQIY1Qf8DfbRbcVlOsjYYVdmvZ0wn2fqhPBkl1He
jmjg52QaeZAP6J4DefMnI193lWptmS01eeTuqHQ+OzpAHu0diDLIK7+RSJ85p8v3
CIMaaBhzKlB/vOtzdCAJKxWWrMxAqGt0jPHMGx7JhzWMHy0kSqBAz3KXQ6Fouz1o
U2aQVnOA4u5K4hPRXq+IxyqEqN1125L6FtW77zeNd7W2bLkFEk6WL4DAae7TfLwx
RR8BuvF1xI4IovaIN4O6dJgGwWyz2LhQ3zeRK5SH8Uhyq3boxM3TtsR1pOWtf3ba
/zY/Kz38t5KWT6H4bsbcKCzFDL80CFsN7SGcLxhZVvIvt0Km7aoKCA==
=GbYS
-----END PGP SIGNATURE-----