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

[Dave Airlie]

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

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

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.

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

Dave.