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 > > > > > > > <vehem...@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
