Messages in this thread | | | Date | Fri, 27 Aug 2004 00:57:56 +0100 (IST) | From | Dave Airlie <> | Subject | maintaining DRM and using bitkeeper.. |
| |
Okay I want to ask other groups of developers how they are maintaining subsystems away from linux-kernel list and how they get things merged?
The biggest problem we are facing with the DRM is getting things tested before submitting them to Linus as the last thing we want to happen is to destabilise the DRM code in the kernel, the two testing paths are a) DRM CVS, this gets picked up in DRI snapshots and tested quite heavily - this is by far the most successful testing path for the DRM b) the -mm tree is more useful for picking out non-x86 (sparc usually) users,
At the moment I put patches into the BK CVS first, we stabilise them, I take the CVS changes and patch them into bitkeeper, Andrew picks them up, we find more bugs I fix em in bitkeeper and put em back in CVS, now however the bk tree hasn't got a unique patch for a fix, it has a bunch of changesets that are the initial patch plus the fixes for it,
Now if I submit to Linus via the -bk tree I'm screwed when he either a) rejects an idea in the tree or b) doesn't respond at all, as I can't just have him pull up the changesets that matter as a lot of them have been crossed over by core kernel cleanup patches and bk is getting very shirty with me about undo and excluding things...if I submit patches to Linus and he puts them into his tree then I'll be continually dumping my bk trees and starting again - it takes most of an evening to clone a tree to my machine at home and I have time to work on this 2 or 3 evenings.. so should I abandon bk and go it the old way, this means I submit every patch to Linus and the DRM doesn't stay stable, (if we had 2.7 I would be happy with this but we don't so .. :-(
So I'm asking is there a better way, considering at this stage I'm not *trusted*, the DRM is an unholy mess and I'm the only one stupid enough to step up and do anything about it ... (you should see the DRM in CVS at the moment it is so much easier to work with without a lot of macros, unfortunately it won't go into the kernel anytime soon....)
Dave.
-- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |