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

[Corbin Simpson]

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?

Of course, feel free to disregard me. I maintain drivers that nobody
appears to care about besides Phoronix, and my next Mesa code bits are
drivers for the Wii and Pollux, and another Python state tracker that
I'm writing on purely silly reasons.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>