maintaining DRM and using bitkeeper..

From: Dave Airlie (airlied_at_linux.ie)
Date: 08/27/04

  • Next message: Hiroyuki KAMEZAWA: "Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap [3/4]" 
    Date:	Fri, 27 Aug 2004 00:57:56 +0100 (IST)
To: linux-kernel@vger.kernel.org

    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/
  • Next message: Hiroyuki KAMEZAWA: "Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap [3/4]"

    Relevant Pages

    • Re: [PATCH] orinoco rfmon
      ... > Could anyone elaborate on the status of this patch? ... > in order to get this into the official tree. ... access to the driver CVS. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: maintaining DRM and using bitkeeper..
      ... > 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, ... > Now if I submit to Linus via the -bk tree I'm screwed when he either a) ...
      (Linux-Kernel)
    • Re: MM kernels - how to keep on the bleeding edge?
      ... >which fixes things up for the -mm tree. ... >your patch if Pavel's stuff gets merged. ... I'm just saying it would be handy for the cvs to be able to compile ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [OT] Q: what would you choose for a VCS today
      ... CVS repository before they let you start doing any work in the newly ... You can keep 'importing' snapshots of the src tree from any ... This is how we 'resync' with the official doc/ tree changes in the Greek ... The whole process of importing clean snapshots is automated in a shell ...
      (freebsd-hackers)
    • Re: [git pull] drm fixes
      ... (I thought it would be wise to include any core drm ... the reason the tree got rebased is that i did a pull from Ben and I ... And why did the drm tree rebase a tree that had obviously been public ...
      (Linux-Kernel)