> > 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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
