[prev in list] [next in list] [prev in thread] [next in thread]
List: dri-devel
Subject: Re: RFC: libdrm repo
From: vehemens <vehemens () verizon ! net>
Date: 2009-11-29 18:15:42
Message-ID: 200911291116.13765.vehemens () verizon ! net
[Download RAW message or body]
On Sunday 29 November 2009 07:07:41 Robert Noland wrote:
> 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.
Your missing the point of using a development structure which supports
collobration.
> > > > 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.
The difference is that you are the only one doing the work now.
> > 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.
Again it sounds like you did not understand the changes.
> > > > 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...
Again, your missing the point of using a development structure which supports
collobration.
> > > > 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.
It hasn't moved "... well beyond what was in drm git." If you believe
otherwise, your only fooling yourself.
> > > 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.
See above comments.
------------------------------------------------------------------------------
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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic