[Mesa-dev] so the development model is working?

[Keith Whitwell]

On Fri, 2010-04-30 at 09:42 -0700, Corbin Simpson wrote:
> On Fri, Apr 30, 2010 at 6:54 AM, Keith Whitwell
> <keith.whitwell at googlemail.com> wrote:
> >> I happen to do mesa development work on about 10 different machines,
> >> so yes I generally keep one mesa tree on each as close to master as I
> >> can get. Again you are developing for swrast or for vmware. Try
> >> developing for something like radeon and intel on different days, I
> >> have to keep a number of test boxes with r100->r600 cards in them,
> >> along with laptops at home where I idly do gallium work and also a
> >> pile of laptops in the office. I don't do any mesa development on my
> >> main workstation because I try to use it to read emails and stuff.  I
> >> know you guys have worked on hw drivers in the past, but its always
> >> been quite focused on one platform at a time. I don't get that luxury
> >> working on a distro, the open bug list for 3D drivers on Fedora is
> >> quite large and involves hopping machines and swapping hw
> >> configurations quite a lot.
> >
> > Actually, I'm sure I've done as much diverse development on different
> > target machines as anybody here.  10 machines was hardly atypical.  My
> > approach is straightforward, and scaled well to the situations you're
> > describing.
> >
> > Basically I never touch the target machines except to reboot them.
> > All interaction is with my main machine (at home or office), usually a
> > laptop.  On that machine I have a lot of trees, as Brian described,
> > and scripts which:
> >  - recognize the tree surrounding the PWD
> >  - sync it to the remote machine
> >  - invoke make on the remote machine with the remainder of the command
> > line arguments.
> >  - perform any manipulation on the compiler output to get emacs to
> > understand it locally.
> >
> > That way I can do things like:
> >
> >   rmake test-i965 foo
> >
> > from inside emacs, have the remote machine kick off a local build, and
> > have emacs treat it as if it were local.
> >
> > The remote machines have basic OS install plus relevant dev tools.
> > It's possible to develop & test on several target machines
> > simultaneously in this way.
> 
> Maybe it's because I don't get paid (enough), but I don't really put
> any magic effort into a "development model."
> 
> ~ Always work on master
> ~ Focus on extremely bisectable patches
> ~ Don't ask permission for things I maintain (r300g, r300c, radeong),
> everything else goes to list or feature branches
> ~ Ignore stable branches unless people ask for cherry-picks or intend
> to make bugfix releases that affect my work
> 
> Feature branches aren't too much of a problem, except they all are
> usually along these lines:
> 
> ~ Touches Gallium API
> ~ Lacks corresponding changes to API docs
> ~ Incompatible with at least one other feature branch
> ~ Require changes to all drivers or all winsys (because of the API change)
> 
> So merging any two to master at a time is a pain. I will agree that
> it's kind of nice to see the emails on the list for API changes that
> we actually care about.
> 
> Here's the actual problem with not actually doing this kind of work on
> master: Nobody has enough hardware to regress-test a significant part
> of Mesa by themselves. (Not even ajax, I think.) This wouldn't be a
> problem, except it implies that branches can break master when merged
> in. And they do! Even just within Gallium, the nouveau and r300
> drivers have been broken a fair amount by these merges. IIRC cell was
> broken for a couple months before a random drive-by noticed it.
> 
> I think the big problem is the disconnect between VMWare and the rest
> of the developers in terms of communication. We all are on IRC
> extensively but at least Brian, Keith, Jose, and Vinson are not.
> Coincidentally, these are the people I need to talk to when I need to
> talk about Gallium API, and so I have to go send off an email. This is
> kinda frustrating because everybody else that I can think of is on
> IRC, even if only sporadically. A lot of times, I feel like I'm
> working with patchsets tossed over a firewall. :C
> 
> At the end of the day, though, I'm not sure what could be changed. VMW
> has good reasons for doing it they way they do. I suppose the only
> thing I'd really care about is whether we could try to lump together
> interface change discussions, so that we could have a discussion about
> multiple changes at once and not have as many difficulties
> coordinating. I'm pretty certain that Gallium's gonna need to absorb
> plenty more changes before it's ever included in a (non-Gentoo)
> distro, right? So why can't we talk about them all at once?

Here's my current working plan:
- extend gallium to support DX10.1 and equivalent GL functionality

- move surface functions stuff out of the screen, and address any other
performance glitches we find.

- build a mid-layer to bridge the gap between driver & state tracker
capabilities

- build a mid-layer which performs strict checking on gallium interface
usage - ie a debug layer.

- make a pass over the interfaces and clean up inconsistent naming,
usages, etc.

Keith