KernelFreeze, 2.6.14, UBZ agenda, and other bits

[Fabio Massimo Di Nitto]

Ben Collins wrote:

> On to 2.6.14, for dapper. I've already got a tree in baz for 2.6.14, but
> before we go head strong into it, I think we need to re-evaluate the whole
> kernel development proces for Ubuntu. UBZ is probably going to be a good
> time for us to finalize some ideas for this. I wasn't here for most of
> breezy, so I don't know all the problems or things learned from the last
> cycle. This is where most of you step in.

Yes we are definetely going to talk a lot about it.

> 
> I want to get an agenda setup for discussion at UBZ, mainly to outline our
> development cycle for post-breezy and 2.6.14. The main thing on the top of
> my list right now is RCS. If anyone has anything to add to it, let me
> know.

We will also need to reevaluate the leftovers from UDU. I think we already
have plenty to discuss about without adding new stuff.

> 
> We've some conflicts about some of our objectives for the kernel. First
> off, Matt wanted me to get the kernel onto kernel.org as a more open and
> public development line. However, with all of our internal work, I feel
> like baz/bzr is the required revision control system.
> 
> If we want to be more apart of the kernel development, then we need to
> move to git. My thinking was that we would host the git tree on our
> system, and push a copy of it to kernel.org on a regular basis (few times
> a day if needed) for people to pull from.
> 
> Personally, I'm all for moving to git. However, I understand that Ubuntu
> as a whole also need to be concerned with consistency, and git isn't
> consistent with some of the future goals.
> 
> So what I may propose is a dual RCS. Use git for our kernel tree, in which
> we will integrate the mainline kernel with external drivers and
> siginificant patchsets. Then use baz for our debian/ directory like we do
> now, which will also hold patches, but will be the ones that are ubuntu
> specific (hacks and workarounds, and such).
> 

I don't like the idea of dual RCS. it is overkilling. We might want instead
consider to use git and that's it. This will also require us to change our
kernel build system to a more appropriate one given that we don't want
to apply patches realtime if we switch to git.

While i do understand the consistency point, that's up to the baz team to
provide us with such consistency. Right now baz is simply useless on such
a big tree and it is not recognized by upstream as preferred RCS.

i don't want to turn this into a yet another RCS flame, but we need to be
realistic with the goal we want to achieve and personally i prefer
kernel.org target as way more important for the entire community.

Fabio

-- 
I'm going to make him an offer he can't refuse.