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

[Dave Airlie]

>
> How is trying to make the best possible release with a given amount of
> resources and trying to get as much of this into any future release as
> well not the Linux way? Tho I can see how our long stabilization
> periods would conflict with other peoples view on how to do releases.
> See below about 7.8-svga-stable.

Its all a matter of scale and possibly perspective. You guys want to
make life as easy as possible for your development model, others want
to make life as easy as possible for theirs. The question is should we
be optimising for the drivers distros ship or the drivers vmware ship.
I'm still waiting for someone to address the scaling issue, which no
proponent of the pulling stable into master seems willing to do.

>> The thing is with other drivers where we have a looser developer group
>> and less of a product + deadline focus, it makes not sense for people
>> to work on stable as a primary focus. People want to fix problems on
>> master for the next release to make the total better, not just one
>> piece. Also stable development even bugfixing requires a different
>> mentality,. Say I run piglit on stable and it fails a few tests on my
>> driver, now I to fix one of those tests I have to add say point sprite
>> support, is this really stable material? or am I just developing in
>> the wrong place.
>>
>
> So people who want to get a better release then that are now tough out
> of luck? Then again you have a good point about feature vs bugfix. See
> more below
>
>>> If I where to do bug-fixing on the master branch I run the risk of
>>> having to fix the bug twice. Sure its good that the bug got fixed in
>>> master as well but its time that gets taken out of other bug-fixing
>>> for stable. Add to that I also have to spend time verifying it myself
>>> on both branches and then direct QA to verify on their setup.
>>
>> You work on master, you get it to the level you want, you pull the
>> fixes back to stable once QA is satisfied. If master moves too much
>> you should probably just branch off master or stable at the project
>> start. The question is whats the point of a driver you've developed
>> and shipped on stable to the rest of the development group? You are
>> just going to spend an obscene amount of time forward porting all the
>> fixes across 6 gallium feature merges that screw you. git pulling
>> stable into master can't fix that, and probably means someone else
>> will get screwed with the job of merge conflict fixing. So if you
>> aren't interested in working on master I'd argue you shouldn't be
>> working on stable at all either, as you need to confirm your merges
>> don't break stuff on master.
>>
>>> I guess what it does boil down to is where you do your main
>>> development. For me, I did all the work on the stable branch and every
>>> once in a while when I got time over I did work on master. Once we
>>> stopped merging back 7.7 to master/7.8 keeping track of what has gone
>>> from 7.7 to master/7.8 became pretty damn hard, well the first time
>>> wasn't that hard just "git log --pretty=format:%(hash) master..7.7 --
>>> touching/path | xargs -n1 git cherry-pick" tho following runs did not
>>> go well since doing two git cherry-pick of the same commit would
>>> explode. And any conflict would cause me to do the whole thing
>>> manually anyways. The bottom line is that keeping track of what I have
>>> ported over from stable to master because hard after a while since
>>> cherry-picking makes it impossible for git (is there a way?) to tell
>>> if a commit has already been picked.
>>
>> I generally use git diff, but really I don't think stable pulling
>> helps here either, as you are going to get lost in the merge
>> conflicts, and I find if someone else does the merge resolution there
>> is a good chance they'll either pick the previous or the new behaviour
>> or whatever compiles and probably not what actually you want in the
>> code. Again you guys need to think of this and scaling, it works fine
>> for one driver, if there is 5-10 drivers all working on stable, you
>> are going to have a hell of a time doing merge resolutions, at which
>> point I suspect you'd be better off with one stable branch per
>> side-project and someone pulling those into a super-stable branch, and
>> also each separate developer pulling them into master on their own,
>> and never pulling the super stable branch into master.
>
> Has doing merges now been bad with 7.8? You know our counter argument
> that if everybody does a merge after dangerous changes it wont be
> hard.

Thats not a counter argmuent, I already asked for someone to address
that in the previous emails. It doesn't scale at all well. If everyone
has to  merge after every change and I contend they have to because if
you aren't working in master you won't know what the state of master
is, then you've pretty much gone from cherry-pick each commit to merge
each commit, with merging clearing being inferior when you have
divergent development streams between stable and master, as one person
not merging to master after their commit can completely screw some
other developers workflow, as they have to resolve merges.

> Anyways you mentioned that I could create a 7.8-svga-stable branch and
> that I could do what ever I wanted with that. It does sound fine in
> theory but the problem is this: it just just the svga driver that
> makes up the stack. So the problem is that I would have to cherry-pick
> any changes from 7.8 stable that touched core-mesa st/mesa or st/dri.
> And since I want to keep on doing stable to master merges since this
> is what this whole thing is about wont that still be bad for you guys?
> Tho you seem sort of okay with that if I read your last comment about
> multiple branches correctly.

The thing is you could in theory do a svga-stable->master for your
svga branch a lot easier as you won't have changes to all the other
drivers. cherry-picking the core mesa/gallium stuff into your branch
will also be a pain but less so, as we hope master is where actual
development of these fixes happen. Once master diverges from stable
more than 2-3 features its pointless trying to ever merge it anyways.
So far as Eric noted a fair few of the stable->master merges have
broken drivers, this isn't going to get better if everyone follows it.

> The problem I have with going full multi-branch is that the history in
> stable will become a utter mess with all the merges.

And it won't now if everyone follows the model we have now?

> A half backed idea would be to have to run a opt in slightly unstable
> branch, instead of going full multi-branch development model. Where
> bug-fixes can go in freely, small features can go in after a review of
> the changes by the module maintainer. What that means in practice is
> that driver developers can develop new features in their drivers but
> any new feature touching shared parts needs to get reviewed. The idea
> behind the branch is to be flexible if the situation change. So the
> branch might be restarted if the parties who are investing time in it
> agree to it. There could also be discussion if we want to base stable
> releases of it or master directly. Tho given the feel of the rest of
> the community stable will be based of master and slightly unstable
> will restart after that.

We call this master though, does master really move so much that one
person can't follow it? So far with all the gallium churn two unpaid
developers have fixed up r300g normally within a day or two of the
breakage being merged. This leads me to think people who get paid to
work on this stuff for 8 hrs a day are sort of crying poor/lazy when
they claim they can't keep up. They *don't* want to keep up, but lifes
tough. If you want to stabilise your driver on a different time frame
to a mesa release cycle, a separate branch with cherrypicks from
master for core mesa + driver developement should be started but it
shouldn't be allowed to diverge from master that far, like really if
your driver is that buggy when you diverge perhaps its not really in a
good place for release.

> Basically I will be running this branch either way, I'm just wondering
> if this is something that community has interest in it (given that the
> community are okay with me picking parts I like from stable branches
> into it and merging that back to master, with parts I'm interested in
> is core-mesa, st/mesa, st/dri, st/xorg and svga, also given that the
> change make sense)?

Again this sounds better than working in stable, fixing things in
outside the svga driver in that branch should be sent to the list or
just fixed in master. The other thing that happens in long-lived
"stable" development branches is people start making questionable
design decisions without review to fix their issues. So I'd pretty
much state again you should never do anything in these branches that
isn't trivial fixes. If you find a feature you need to add you need to
backport it from master, not add it into stable first, and I'd be
really tight about the definition of feature.

>
> Some more thoughts on slightly unstable, I will also when it becomes
> to obvious that doing mergers isn't going to work anymore stop doing
> that, and probably make the branch a (not the) stable branch.
>

Dave.