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

[Jakob Bornecrantz]

On Sun, May 2, 2010 at 6:37 AM, Dave Airlie <airlied at gmail.com> wrote:
>>
>> My thought about this is that this idea adds more work for all
>> developers, not only does the developer have to consider if a patch is
>> suitable for stable but they also need to update a wiki and a such get
>> bookkeeping overhead. If they knew that the patch was suitable for
>> stable couldn't they just cherry-pick them selfs. But that of course
>> would mean they have to at least compile the change and testing would
>> be good. So guess both add more work.
>>
>> I think that its that what it all boils down to. How to get the most
>> out of a stable branch with the least amount of work.
>
> Pretty much, which is why I think tagging fixes in master for possible
> inclusion into master is the nicest way with a person who cares for
> stable going forward picking stuff back in and enlisting help on
> getting some regression tests done on the major drivers before
> releasing a stable tarball.
>

I'm actually okay with commits appearing twice in the history and all
that as long as it doesn't give me more problems doing merges from
stable to master. That is the guy doing the picking also does the
merge.

>> When working on the svga driver for linux I had a set amount of
>> developer and QA time that I had at my disposal. We choice to build
>> the driver from the 7.7 branch, mostly because this was the branch
>> that the windows driver was based off so we knew that all general 3D
>> testing and bug fixing would apply to our release as well, but also
>> this happen to be the branch that happen to be around that time we
>> started doing stabilization work. Given these parameters for me the
>> logical thing was to have QA test 7.7 and report bug, then fix the
>> bugs in 7.7 and then "waste" as little time as possible getting these
>> fixes into master (that is merge and fixup any build breakage if
>> somebody complains).
>>
>> Now maybe this is where our mindsets differ, maybe we care more about
>> what goes into a release/stable branch then what happens to go into a
>> future release/master branches. Maybe the "VMware" way is shortsighted
>> in that it only care about the stable branch, but for me it gives me
>> the most found and fixed bugs affecting the stable branch. Or maybe
>> the problem is that we have to long cycles (pretty much skipping every
>> other mesa release)?
>>
>> If anybody have a better way to get more bugs found and fixed into a
>> stable branch then directing all available resources on that branch
>> then please let me know.
>
>
> The thing is for that sort of project, where only you are working on
> it or only you + other closely coordinated teams, it makes more send
> to just make a branch that isn't stable or master, but is for your
> project. i.e. 7.8-svga-stable. You can then choose to pull or rebase
> anything in there to master. The thing is developing on a stable
> branch must always be considered wrong, its a *stable* branch. If you
> are fixing one or two bugs, but the minute you are doing something in
> any way different you need to rethink your strategy. Also with
> something like svga, you don't have any community involvement or
> crossover, or from what I can any interest in doing things the Linux
> way (i.e. using distros to ship drivers not doing it yourself).

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.

>
> 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.

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 problem I have with going full multi-branch is that the history in
stable will become a utter mess with all the merges.

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.

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)?

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.

Cheers Jakob.