[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dri-devel
Subject:    Re: RFC: libdrm repo
From:       Robert Noland <rnoland () 2hip ! net>
Date:       2009-11-29 15:07:41
Message-ID: 1259507261.2315.141.camel () balrog ! 2hip ! net
[Download RAW message or body]

On Sat, 2009-11-28 at 20:40 -0800, vehemens wrote:
> On Saturday 28 November 2009 16:21:58 Robert Noland wrote:
> > On Sat, 2009-11-28 at 13:38 -0800, vehemens wrote:
> > > On Saturday 28 November 2009 10:41:39 Robert Noland wrote:
> > > > On Fri, 2009-11-27 at 17:23 -0800, vehemens wrote:
> > > > > On Sunday 22 November 2009 01:01:10 Dave Airlie wrote:
> > > > > > On Sun, Nov 22, 2009 at 7:10 PM, vehemens <vehemens@verizon.net> 
> wrote:
> > > > > > > On Saturday 21 November 2009 20:09:53 Dave Airlie wrote:
> > > > > > >> > I see that you deleted bsd-core dispite the requests of a
> > > > > > >> > number of people that you do not.
> > > > > > >>
> > > > > > >> Its git, nobody has touched any of it in ages, and none of the
> > > > > > >> BSD maintainers used it, you can just get it back by branching
> > > > > > >> from the commit before its removal, if you think revival is
> > > > > > >> needed, don't bring back linux-core when you do please.
> > > > > > >
> > > > > > > I already told the both of you that I was planning to use it on
> > > > > > > IRC, I just haven't had time to put anything in.
> > > > > > >
> > > > > > > In addition, he's asking for a repro to libdrm.  The way I see
> > > > > > > it, is there were two choices:
> > > > > > > 1) repro to libdrm, add the changes, not piss people off
> > > > > > > 2) add the changes, repro to libdrm, piss people off
> > > > > >
> > > > > > I think we pissed one person off, not people, as I said, there are
> > > > > > two people registered as BSD maintainers for drm code, oga and
> > > > > > rnoland, neither of them cared. I'm not sure what value the
> > > > > > codebase has if neither Free or OpenBSD are going to use it.
> > > > >
> > > > > You pissed a number of people off, but the difference with me is that
> > > > > I'm not letting either of you get away with it.
> > > > >
> > > > > There are more then two BSD maintainers, and your statement that
> > > > > neither of them cared is not correct.
> > > >
> > > > Don't get me wrong here, I don't like the current state of things, but
> > > > given current drm development practices, this change was irrelevant.  I
> > > > was a bit frustrated at the build breakage for libdrm, but krh and I
> > > > worked through that and it is now resolved.
> > > >
> > > > While you have provided me with patches in the past, (which are much
> > > > appreciated) I have not seen consistent or relevant work lately, so it
> > > > really isn't clear to me how this is a big deal.  Given the nature of
> > > > git, you could just branch your local repo before that commit, though
> > > > patches based on the old repo are becoming increasingly difficult to
> > > > merge into real code.
> > >
> > > I haven't published any of my work recently, but that doesn't mean I
> > > haven't done anything that I would like to share.  Not sure why you feel
> > > this is important however.
> >
> > Because unpublished work doesn't exist.... That goes for the work that
> > I've done that isn't yet published as well.  Until it is in the hands of
> > someone besides yourself it is irrelevant.
> 
> Thats the whole point of having a public respository.  How else can one 
> publish?

Again, there is nothing that prevents you from publishing your version
of the drm repo, though I don't see the point.

> > > I gave you a number of suggestions in private emails on how to fix
> > > problems such as the merging issue and you were unwilling to take them.
> >
> > I'm not sure which issue you are referring to right now.  But if you
> > mean trying to backport the work of Intel, ATI/AMD and nouveau into a
> > repository that all of the above have now abandoned, none who currently
> > have commit to the drm repo are willing or able to take on that task.
> >
> > Did you miss my plea's, rants and attempts to make valid arguments not
> > to reorganize/abandon drm in the first place?  Unfortunately, we lost
> > that battle.  It only served to increase the complexity and workload
> > that I am faced with.  However, since every major vendor has now pulled
> > out and maintains a private linux repo for their code, the code that
> > lived in drm git was stale, and not terribly useful for anything other
> > than historical purposes.
> 
> First you say abandoning the respository increased your workload, then you say 
> it wasn't useful.  Which is it?

What increased my workload was having to go and try and pull changes
from several different linux trees and try to incorporate that into some
usable code base.  Now, that the repo has been abandoned it is no longer
useful.  If vendors were still committing to the repo, we wouldn't be
having this debate.

> > If you are referring to the patches/diffs that you have sent me, then I
> > have always appreciated the work that you have done.  The last batch of
> > stuff that you sent me, however was quite a mess.  While there was some
> > nice cleanup in it, it also contained at least some reversions of code
> > specifically changed for FreeBSD.  Even more of a problem than that was
> > that what you sent me at the time was one big jumble and in no way
> > represented a coherent set of patches that I could apply and commit to
> > any repo.  You did state at the time, that it was WIP, so perhaps you
> > have a more coherent patch set now.  I should have provided you with
> > direct feedback when you sent me that work and for that I do appologize.
> 
> The WIP was sent to you because you had stalled on DRM development and didn't 
> seem to moving forward.

If you mean that I stopped committing to drm git, then yes... If I
already have to go and collect and merge changes from all the linux
repos, then it is just easier to commit it directly to FreeBSD, rather
than do all the work to try and put that into drm git first.

> I'm surprized that you didn't understand the changes as they were fairly 
> stright forward.

I understood it fine... There was some good cleanup in it, as well as
some regressions, but it wasn't in a form that I could easily separate
the good from the bad.  It did not contain anything that impacted drm
functionality as I recall.

> > > The whole point of having a public repository for code is collaboration
> > > that it allows.  You seem to of lost sight of this goal.
> >
> > This is IMHO, the good and bad of git.  There is nothing that prevents
> > you from taking your existing drm git and branching it prior to the
> > removal of the code and publishing that on some other server.  I would
> > truly hope that it isn't your intent to try to provide an alternate
> > FreeBSD drm build, though there is nothing to prevent it.
> 
> The point is that you have been unable to move development forward.  I never 
> intended to provide an alternate FreeBSD drm build.

The only stall is on GEM/TTM, which I am working on, but I am only one
person and this won't be solved by just incorporating white-space
changes and renaming defines.  It requires a fairly in depth knowlege of
the FreeBSD vm system and so it is slow work.  If you are prepared to
offer actual code, then please send me diffs...

> > > If you are unwilling or unable to do the work your self, you shouldn't
> > > prevent others from doing so.
> >
> > Who would be contributing to this repo besides yourself?  And who would
> > be the consumer?
> 
> Don't be stupid.  You know that the FreeeBSD would be the consumer.

The code that we are shipping in FreeBSD has moved well beyond what was
in drm git.  I don't get why you insist on continuing to beat a dead
horse and won't just send me patches to the FreeBSD src tree.  It is
easy enough to manage with either svn or git.  I personally find a git
copy of the repo easier to manage for my development since it allows me
to batch up several commits before committing those to the src tree,
however, if you care to discuss that, we should probably move to a
private thread.

> > For good or bad, the responsibility for drm in FreeBSD lands entirely on
> > my head.  I'm happy to review and accept patches based on the FreeBSD
> > source tree, or at least in the form of something that I can apply with
> > patch.  As long as they are discrete patches that I can work with, I'll
> > be more than happy to accept them if they make sense.  If it is as much
> > work for me to turn the patch into something that I can commit as it
> > would have been for me to do the work from scratch, it will likely fall
> > on the pile of stuff that will never see the light of day.
> 
> Thanks for the feedback, I now have a better understanding where the problem 
> lies with BSD development.

If you want to contribute, then it is really pretty simple.  Just
provide me with coherent patches based on the src repo.  I fail to see
the difficulty here.  The benefit of drm git was that it was a shared
repo between multiple OS and so all benefited from the work that went on
there.  Using drm git as an intermediate dumping ground for changes to
FreeBSD, only makes more work.

robert.

-- 
Robert Noland <rnoland@2hip.net>
2Hip Networks


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[prev in list] [next in list] [prev in thread] [next in thread]