On Tue, 2008-08-26 at 14:17 -0700, Jesse Barnes wrote:
> On Tuesday, August 26, 2008 1:27 pm Stephane Marchesin wrote:
> > On Tue, Aug 26, 2008 at 10:21 PM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > On Tuesday, August 26, 2008 1:03 pm Stephane Marchesin wrote:
> > >> > As for the "new development model"... Things are actually worse than I
> > >> > thought. There are some fairly large differences between linux-core
> > >> > and upstream, some of which have been in linux-core for a long time.
> > >> > It's one thing to have an out-of-tree development process but another
> > >> > entirely to let stuff rot for months & years there. It just adds to
> > >> > the already huge set of driver combinations we have to worry about and
> > >> > support...
> > >>
> > >> How is doing merges preventing us from working on a single tree ? It's
> > >> two completely separate problems.
> > >
> > > There are several problems, see the earlier thread "Adapt on_each_cpu"
> > > where we talked about the current dev process problems.
> >
> > I am outlining the fact that you confuse a problem and its solution.
> >
> > Problem: merging stuff upstream takes time to Dave
> > Your solution: have lots of in-development trees and everyone
> > upstreams its stuff which breaks other drivers and platforms
> > A possible solution: everyone upstreams its stuff from a common tree
> > which keeps other drivers and platforms working
>
> Figured I should reply to this too (still trying to cool off after our heated
> discussion on IRC).
>
> I'm definitely *not* proposing a bunch of in-development trees to break other
> drivers and platforms. I don't want to break other drivers and platforms.
> Let me state again my issues:
> 1) drm master is way out of date wrt upstream Linux (and yes this is my
> fault too). This sucks and I'm trying to fix it by sending Dave easily
> digestible and tested patches against the tree he'll send to Linus for
> 2.6.28.
> 2) our current development process makes it fairly easy to get into
> situation (1). It's far too easy to push something into drm master and
> assume Dave will take care of it. It's also easy to push something in
> that the BSD guys miss, causing them to do extra work next time they
> merge ("hmm wtf is this new code supposed to do?")
> 3) dealing with ongoing Linux changes in the drm tree is harder than it has
> to be (we just continually add more compat code all the time, and things
> often break with new kernel updates)
>
> So really I'm just looking for solutions to (2) and (3). For me, that means
> developing & testing against a Linux tree first, since that's what goes
> upstream and that's what I have to support. It doesn't mean I can't push the
> resulting patches into drm master or work with people to make sure things get
> ported to BSD, etc. I don't think there are any silver bullets here. No
> matter what we do I think it's a lot of work.I'm certainly not saying that, you particularly have always been good about working with and helping me to get stuff going on bsd. I am also really appreciative of the work and resources that you guys puts toward development. I still see the biggest part of your frustration being that stuff hasn't been merged and I just don't see that as a problem with where we develop code. That just seems like a failure to get it (merging upstream) done... Like I said on irc, I am all for trying to make drm.git a happier, friendlier place for everyone. I think Dave had some good ideas for how to try and ease everyones pain... In the end, all I really want is to be able to support the features that userland apps want to use. I realize that I'm a second class citizen here, so I'm willing to accept some compromises as long as it doesn't make things overly difficult for me to continue trying to improve things for FreeBSD. You guys certainly have the right to spend your time and effort in whatever way you choose. As I said before, I think that it's great that you guys do the work that you do. I don't see how that makes it fair to strong-arm everyone else into doing it your way, when it seems that we are far from concensus that it is the right way forward. You guys don't even have concensus among the linux crowd. I know that you would have good intentions of merging changes back into drm.git, but I don't think that would last very long. It doesn't really matter which direction your merging changes into, it's going to involve some quantity of pain... and if you already have it in a linux tree, I just don't see anyone willing to put in the effort to merge it to master. Your problem is that feature X is under development, it isn't stable and ready to go into a released linux kernel, so it sits and starts to bitrot... I can't see how it matters if it sits in linux kernel tree or drm.git, it still has to get stabilized and tested before it can get pushed upstream. Would TTM really have made it upstream faster if the code was developed in a linux? I think your going to have the same problem no matter which development model you take. Features have to get tested and someone has to put in the effort to get them upstream. As far as testing goes... I think a bit of publicity would go a long way. As far as I can see, it's difficult for people to see what is being developed and how it might effect them. If it was clear what features were being worked on and in what branches. I think more people would be willing and capable of testing in development code. In my experience a fair number of people are willing and capable of running the git master branch. I don't think the other branches get a lot of excercise except by the git savvy. I think if someone took the time to properly document the development efforts and tell people how they can test the relevant branches, we would see more testing. That said, I'm probably the worlds worst for doing it... robert. > On a more personal note, statements like the below really suck: > ... > <marcheu> jbarnes: it was working fine before you were here, dude > ... > <MrCooper> yeah, it was fine before people stopped caring for anything but > their little niche > ... > > I've worked hard to make sure changes I make update all drivers in the DRM > master tree, and worked with the other OS guys to keep things up to date, > making things better for everyone in the process. If I've made anyone's life > harder, I'm sorry, that's definitely not my intention. When I said, "So > drm-next is all I care about anymore", it was more out of frustration than > anything else. It's certainly all I care about *at the moment* since I'm > trying to get most of the stuff from linux-core into upstream Linux, but that > doesn't mean I'll stop working on drm master on other drivers or OSes. > > Jesse > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > -- > _______________________________________________ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel -- Robert Noland <[EMAIL PROTECTED]> 2Hip Networks
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
