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

[Jose Fonseca]

> Lets have a development model discussion. Can anyone who has an
> interest in the development model please answer the two questions
> below in their view/opinion.
> 
> a) what are the goals of the mesa project and development model?
> 
> to produce drivers for graphics hardware.
>
> to produce something that Linux distributions can consume in a useful
> manner.

I think we want to cater for as much goals the community (devel, users, distros) has as possible, but I agree these are the probably the main ones.

> b) how does the current development model impact those goals.

> The current development model seems to be designed around the VMware
> working model, not the distro working model. I'm not sure what to call
> the VMware working model other than that. I call it that because we
> used to have the TG working model and its not the same as that, and
> its not the same as any other Linux shipped projects working model.
>
> So whats wrong with the current model. It basically seems to suggest
> that everyone working on mesa should be working on the stable branches
> and not mainline. Why? because if I add a new feature to my mainline
> branch then happen to notice a bug fix along the way, then I have to
> stop what I'm doing, check out stable, run a test suite, fix the bug
> in stable, run another test suite, merge stable to master, run a test
> suite on master before my fix, run a test suite on master after the
> merge, hope I didn't break 5 other drivers doing the merge. Then I can
> keep going working on my feature, the other key problem is I as a
> developer have to understand what is suitable for stable and what
> isn't. I don't think every developer needs to be responsible for this
> decision. It also makes the merge history hella ugly but we can get
> over that.
> 
> It means we lose the ability to have stable driver maintainers, as
> cherry picking isn't allowed. So for instance I have 2-3 developers
> who are stabilising master as hard as they can for the next release,
> I'd like to out-of-line pull some of those fixes into stable and not
> have the world end. If every developer has to maintain development and
> stable trees its a major duplication of resources vs one developer
> once every couple of weeks just pulling back a big load of fixes to
> stable, and doing a regression run across them, and bisecting out any
> regressions before pushing the whole lot to stable. Now I can
> cherry-pick a bunch of fixes to 7.8 now off-line, but I still end up
> having to merge that back to master and retest master for breakages,
> instead of concentrating on making the stable backport work properly,
> so it makes me waste a lot of the limited resource which is developer
> time.
> 
> So here is the thing I can totally see how the current driver model
> would be advantageous to the subset that is (a) drivers that don't
> ship in the distro channels, and (b) drivers that have a lot of
> development resources where developers can live on the stable branch
> for long periods of time. However I question whether this is
> optimising for the right set of people, considering the number of
> units of mesa shipping in the distro channel and the overheads to
> community driver developers.

First let me elucidate you on how vmware releases drivers from mesa (perhaps what you call working model): 
- we develop features on master until they are complete
- then we jump to a stable branch, whichever happens to be active then
- soon after we fork it internally for strict control of what goes in
It doesn't matter whether fixes are merged or cherry-picked in the public stable branch. Everything has to be to a fine tooth comb before it gets applied into the private branch: not only the requirement of not breaking stuff, but for each commit the risk/benefit tradeoff is considered, and as as release comes near the risk factor prevails.

So the current mesa development model is *not* the result of VMware internal requirements. (And when you paint things like that, you end up alienating supporters inside VMware -- there is no mind control, we don't think all alike, although we do have all great respect for each others.)

It's clear from Brian's reply that the current mesa development is model is the natural outcome of Brian trying to maximize the number of bugfixes in the stable releases almost just by himself. Commiting in the oldest branch and successively merging into newer branches allows to quickly deliver commits to several branches, without forgetting commits in between, at the risk of occasionally breaking something. It is not even an unique method -- I perfectly recall people giving examples of one other project doing the same in other times this subject came up, although I don't recall which (kernel or mozilla?)

But if the mesa stable branch development model is still a burden to Brian, is inadequate for the distros, is mostly irrelevant for vmware internal needs, and assuming most users get the drivers through the distros, then my suggestion would be to decouple the development maintenance from the stable release maintenance, ie., have a separate release manager (or better team), that is responsible for:
- the release schedule
- what commits gets in or not
- testing it (and this is why a team is better, to ensure all hardware and software is covered, and not just a particular distro)
This would also free Brian from the ungrateful task of maintaining so many stable branches on a schedule he didn't choose.

Jose