Re: [Mesa-dev] so the development model is working?
Jakob Bornecrantz wallbra...@gmail.com writes: 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)? We essentially bundle Mesa with the release of our software. This model sounds much more in line with the resources we have available for validation. It is definitely something we're interested in. We would need some type of tarball releases though. Ideally these would be official Mesa releases, but we could make do without that. -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Monday 03 May 2010 14:17:30 Alex Deucher wrote: On Mon, May 3, 2010 at 2:09 PM, Brian Paul bri...@vmware.com wrote: I think it's worth exploring a policy of somehow tagging commits as candidates for back-porting to the stable branch so they can be some level of accounting and tracking. I don't think we need to work that out immediately though. On this point, it might be useful to update a cherry-pick wiki when you do cherry-pick commits back to the stable branch. That way when it comes time for the next stable point release, we can refer to the list to update the release notes (or even link to the page from the release notes for finer grained details). Thoughts? Would that actually gain us anything? I mean what would be the difference between that list and git log last_stable_releast..current_stable_branch ? I think what Brian meant was adding a magic tag to the commit message, e.g. BACKPORT, or FIX which I could make the Mesa3D commit hook pick out from the commits and either create a bugzilla entry for that commit, email the author after some time, add that commit sha1 hash to some list or do some other random action. But as Brian mentioned this is something we don't have to figure out right away but see what would actually be useful as folks start cherry picking to the stable branch. z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Mon, May 3, 2010 at 2:26 PM, Zack Rusin za...@vmware.com wrote: On Monday 03 May 2010 14:17:30 Alex Deucher wrote: On Mon, May 3, 2010 at 2:09 PM, Brian Paul bri...@vmware.com wrote: I think it's worth exploring a policy of somehow tagging commits as candidates for back-porting to the stable branch so they can be some level of accounting and tracking. I don't think we need to work that out immediately though. On this point, it might be useful to update a cherry-pick wiki when you do cherry-pick commits back to the stable branch. That way when it comes time for the next stable point release, we can refer to the list to update the release notes (or even link to the page from the release notes for finer grained details). Thoughts? Would that actually gain us anything? I mean what would be the difference between that list and git log last_stable_releast..current_stable_branch ? I think what Brian meant was adding a magic tag to the commit message, e.g. BACKPORT, or FIX which I could make the Mesa3D commit hook pick out from the commits and either create a bugzilla entry for that commit, email the author after some time, add that commit sha1 hash to some list or do some other random action. But as Brian mentioned this is something we don't have to figure out right away but see what would actually be useful as folks start cherry picking to the stable branch. I guess it's just more of a manual variant of the same thing. Maybe we can add a mesa-stable address and you can add a cc in the commit like the kernel does. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
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
Re: [Mesa-dev] so the development model is working?
I develop on multiple machines too, FWIW. I do lots of ssh stuff like Keith described. BTW, your last sentence can go either way. From my point of view it's: Its a lot easier to just fix bugs on the 7.8 branch on those machines, and when you get around to it later merging the changes back into master, and dedicating a day to retesting master on as many configurations as you think require it for you to be happy with the work done. The thing is breaking master by accident or temporarily isn't near as bad as screwing up on the stable branch. I really want stable branch to be something I can pull a diff from at any point without worrying its broken stuff. I don't think we are good enough to stabilise a single driver or piece of mesa on the stable branch without causing collateral damage or unknown side effects in other drivers or parts of the codebase. Bugs are a natural side effect of any development, and if there are more people using master for development there is a chance of someone else tripping over the bugs, before hitting stable. I'm usually working on master. If I think I've found a bug (or someone reports a bug in 7.8, for example) I just change terminal tabs and start debugging in my 7.8 directory. I don't have to save my work on master or check out a different branch, etc. Just switch to a different terminal and fire up emacs. After I fix the bug, I commit it to the 7.8 branch and document it in the release notes file (I'm practically the _only_ person who bothers to do that, btw!). If I think it's important to get the fix into master quickly (or there's any doubt about applicability) I'll do a merge right away. Otherwise, I just resume whatever I was doing before, knowing that the fix will propogate into master whenever we do a merge. Again I don't think is what the majority of developers at least the part-time ones do or anything close. They restrict their limited time to making master at any point in time work well for them. If you are developing a feature, and you fix a bug in a separate commit while working on the feature, taking a divergent path into 7.8 land is quite a detour, it usually involved git rebasing the stable 7.8 you checked out a month ago up to whatever is latest version, rebuilding it, applying your patch, building, testing, pushing, pulling into master, rebasing your current development work which may also need the bug fixed to continue on top of it. I really don't see this as a small divergence. If you are focused on doing development, this is a complete task switch, which could reliably be done in a separate task later, with arguably a lower chance of regressions. I think this is a matter of opinion because I think it's easy to temporarily switch to my 7.8 tree when I find a bug while working on master. Also, if I'm working on file.c I don't have to temporarily back-out my new work there in order to fix/commit a bug elsewhere in the file. git stash is what usually works here, or git add -p, I generally just git add -p the fix, commit it to master, stash local changes, run test, push commit to master, unstash and keep going. I often queue up 2-3 fixes in my master before I finish the feature or bother testing all the fixes. I think you exagerate how many testing steps you have to do for each and every fix. Absolutely, there are times when thorough testing is needed. But lots of simple bug fixes/changes in 7.8 can be merged into master without worry. I can provide many concrete examples if you don't believe me. I can also provide quite a large long list of commits that aren't in 7.8 because nobody wants to deal with them. Also committing any fixes directly to a stable branch is something I've never really heard of as a standard. I would assume the expectation is that nobody willing introduces regressions, but lots of people accidentally do, and it would be better to find those in master first not in the stable branch when a distro has already shipped it. If you're concerned with causing regressions with a commit, you can do several things including posting the patch for review first and/or running a bunch of regression tests (which it sounds like you're already doing) before committing. Also, just because a bug fix works on master is not a guarantee that it won't cause regressions on the stable branch. It goes both ways. The problem with regression tests is they don't cover enough hw combos. Like I can regression test some radeon easily, however when I shove stuff onto master, I get the side benefits of Intel testing for regressions in their driver, the other radeon guys doing tests on different hw combos etc. But they are stabilizing master for the next release. For r300 for example accel CopyTexImage was added in master, while fixing that Maciej also fixed a few FBO bugs. His focus was just on making master pass piglit better. He wasn't thinking about how applicable these fixes were to
Re: [Mesa-dev] so the development model is working?
On Sat, May 1, 2010 at 2:32 AM, Dave Airlie airl...@gmail.com wrote: I develop on multiple machines too, FWIW. I do lots of ssh stuff like Keith described. BTW, your last sentence can go either way. From my point of view it's: Its a lot easier to just fix bugs on the 7.8 branch on those machines, and when you get around to it later merging the changes back into master, and dedicating a day to retesting master on as many configurations as you think require it for you to be happy with the work done. The thing is breaking master by accident or temporarily isn't near as bad as screwing up on the stable branch. I really want stable branch to be something I can pull a diff from at any point without worrying its broken stuff. I don't think we are good enough to stabilise a single driver or piece of mesa on the stable branch without causing collateral damage or unknown side effects in other drivers or parts of the codebase. Bugs are a natural side effect of any development, and if there are more people using master for development there is a chance of someone else tripping over the bugs, before hitting stable. I'm usually working on master. If I think I've found a bug (or someone reports a bug in 7.8, for example) I just change terminal tabs and start debugging in my 7.8 directory. I don't have to save my work on master or check out a different branch, etc. Just switch to a different terminal and fire up emacs. After I fix the bug, I commit it to the 7.8 branch and document it in the release notes file (I'm practically the _only_ person who bothers to do that, btw!). If I think it's important to get the fix into master quickly (or there's any doubt about applicability) I'll do a merge right away. Otherwise, I just resume whatever I was doing before, knowing that the fix will propogate into master whenever we do a merge. Again I don't think is what the majority of developers at least the part-time ones do or anything close. They restrict their limited time to making master at any point in time work well for them. If you are developing a feature, and you fix a bug in a separate commit while working on the feature, taking a divergent path into 7.8 land is quite a detour, it usually involved git rebasing the stable 7.8 you checked out a month ago up to whatever is latest version, rebuilding it, applying your patch, building, testing, pushing, pulling into master, rebasing your current development work which may also need the bug fixed to continue on top of it. I really don't see this as a small divergence. If you are focused on doing development, this is a complete task switch, which could reliably be done in a separate task later, with arguably a lower chance of regressions. I think this is a matter of opinion because I think it's easy to temporarily switch to my 7.8 tree when I find a bug while working on master. Also, if I'm working on file.c I don't have to temporarily back-out my new work there in order to fix/commit a bug elsewhere in the file. git stash is what usually works here, or git add -p, I generally just git add -p the fix, commit it to master, stash local changes, run test, push commit to master, unstash and keep going. I often queue up 2-3 fixes in my master before I finish the feature or bother testing all the fixes. I think you exagerate how many testing steps you have to do for each and every fix. Absolutely, there are times when thorough testing is needed. But lots of simple bug fixes/changes in 7.8 can be merged into master without worry. I can provide many concrete examples if you don't believe me. I can also provide quite a large long list of commits that aren't in 7.8 because nobody wants to deal with them. Also committing any fixes directly to a stable branch is something I've never really heard of as a standard. I would assume the expectation is that nobody willing introduces regressions, but lots of people accidentally do, and it would be better to find those in master first not in the stable branch when a distro has already shipped it. If you're concerned with causing regressions with a commit, you can do several things including posting the patch for review first and/or running a bunch of regression tests (which it sounds like you're already doing) before committing. Also, just because a bug fix works on master is not a guarantee that it won't cause regressions on the stable branch. It goes both ways. The problem with regression tests is they don't cover enough hw combos. Like I can regression test some radeon easily, however when I shove stuff onto master, I get the side benefits of Intel testing for regressions in their driver, the other radeon guys doing tests on different hw combos etc. But they are stabilizing master for the next release. For r300 for example accel CopyTexImage was added in master, while fixing that Maciej also fixed a few FBO bugs. His focus was just on making
Re: [Mesa-dev] so the development model is working?
On Sat, 2010-05-01 at 10:00 -0400, Alex Deucher wrote: On Sat, May 1, 2010 at 2:32 AM, Dave Airlie airl...@gmail.com wrote: I develop on multiple machines too, FWIW. I do lots of ssh stuff like Keith described. BTW, your last sentence can go either way. From my point of view it's: Its a lot easier to just fix bugs on the 7.8 branch on those machines, and when you get around to it later merging the changes back into master, and dedicating a day to retesting master on as many configurations as you think require it for you to be happy with the work done. The thing is breaking master by accident or temporarily isn't near as bad as screwing up on the stable branch. I really want stable branch to be something I can pull a diff from at any point without worrying its broken stuff. I don't think we are good enough to stabilise a single driver or piece of mesa on the stable branch without causing collateral damage or unknown side effects in other drivers or parts of the codebase. Bugs are a natural side effect of any development, and if there are more people using master for development there is a chance of someone else tripping over the bugs, before hitting stable. I'm usually working on master. If I think I've found a bug (or someone reports a bug in 7.8, for example) I just change terminal tabs and start debugging in my 7.8 directory. I don't have to save my work on master or check out a different branch, etc. Just switch to a different terminal and fire up emacs. After I fix the bug, I commit it to the 7.8 branch and document it in the release notes file (I'm practically the _only_ person who bothers to do that, btw!). If I think it's important to get the fix into master quickly (or there's any doubt about applicability) I'll do a merge right away. Otherwise, I just resume whatever I was doing before, knowing that the fix will propogate into master whenever we do a merge. Again I don't think is what the majority of developers at least the part-time ones do or anything close. They restrict their limited time to making master at any point in time work well for them. If you are developing a feature, and you fix a bug in a separate commit while working on the feature, taking a divergent path into 7.8 land is quite a detour, it usually involved git rebasing the stable 7.8 you checked out a month ago up to whatever is latest version, rebuilding it, applying your patch, building, testing, pushing, pulling into master, rebasing your current development work which may also need the bug fixed to continue on top of it. I really don't see this as a small divergence. If you are focused on doing development, this is a complete task switch, which could reliably be done in a separate task later, with arguably a lower chance of regressions. I think this is a matter of opinion because I think it's easy to temporarily switch to my 7.8 tree when I find a bug while working on master. Also, if I'm working on file.c I don't have to temporarily back-out my new work there in order to fix/commit a bug elsewhere in the file. git stash is what usually works here, or git add -p, I generally just git add -p the fix, commit it to master, stash local changes, run test, push commit to master, unstash and keep going. I often queue up 2-3 fixes in my master before I finish the feature or bother testing all the fixes. I think you exagerate how many testing steps you have to do for each and every fix. Absolutely, there are times when thorough testing is needed. But lots of simple bug fixes/changes in 7.8 can be merged into master without worry. I can provide many concrete examples if you don't believe me. I can also provide quite a large long list of commits that aren't in 7.8 because nobody wants to deal with them. Also committing any fixes directly to a stable branch is something I've never really heard of as a standard. I would assume the expectation is that nobody willing introduces regressions, but lots of people accidentally do, and it would be better to find those in master first not in the stable branch when a distro has already shipped it. If you're concerned with causing regressions with a commit, you can do several things including posting the patch for review first and/or running a bunch of regression tests (which it sounds like you're already doing) before committing. Also, just because a bug fix works on master is not a guarantee that it won't cause regressions on the stable branch. It goes both ways. The problem with regression tests is they don't cover enough hw combos. Like I can regression test some radeon easily, however when I shove stuff onto master, I get the side benefits of Intel testing for regressions in their driver, the other radeon guys doing tests on different hw combos etc. But they are stabilizing master for the next release.
Re: [Mesa-dev] so the development model is working?
On Sat, May 1, 2010 at 3:00 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Sat, May 1, 2010 at 2:32 AM, Dave Airlie airl...@gmail.com wrote: I develop on multiple machines too, FWIW. I do lots of ssh stuff like Keith described. BTW, your last sentence can go either way. From my point of view it's: Its a lot easier to just fix bugs on the 7.8 branch on those machines, and when you get around to it later merging the changes back into master, and dedicating a day to retesting master on as many configurations as you think require it for you to be happy with the work done. The thing is breaking master by accident or temporarily isn't near as bad as screwing up on the stable branch. I really want stable branch to be something I can pull a diff from at any point without worrying its broken stuff. I don't think we are good enough to stabilise a single driver or piece of mesa on the stable branch without causing collateral damage or unknown side effects in other drivers or parts of the codebase. Bugs are a natural side effect of any development, and if there are more people using master for development there is a chance of someone else tripping over the bugs, before hitting stable. I'm usually working on master. If I think I've found a bug (or someone reports a bug in 7.8, for example) I just change terminal tabs and start debugging in my 7.8 directory. I don't have to save my work on master or check out a different branch, etc. Just switch to a different terminal and fire up emacs. After I fix the bug, I commit it to the 7.8 branch and document it in the release notes file (I'm practically the _only_ person who bothers to do that, btw!). If I think it's important to get the fix into master quickly (or there's any doubt about applicability) I'll do a merge right away. Otherwise, I just resume whatever I was doing before, knowing that the fix will propogate into master whenever we do a merge. Again I don't think is what the majority of developers at least the part-time ones do or anything close. They restrict their limited time to making master at any point in time work well for them. If you are developing a feature, and you fix a bug in a separate commit while working on the feature, taking a divergent path into 7.8 land is quite a detour, it usually involved git rebasing the stable 7.8 you checked out a month ago up to whatever is latest version, rebuilding it, applying your patch, building, testing, pushing, pulling into master, rebasing your current development work which may also need the bug fixed to continue on top of it. I really don't see this as a small divergence. If you are focused on doing development, this is a complete task switch, which could reliably be done in a separate task later, with arguably a lower chance of regressions. I think this is a matter of opinion because I think it's easy to temporarily switch to my 7.8 tree when I find a bug while working on master. Also, if I'm working on file.c I don't have to temporarily back-out my new work there in order to fix/commit a bug elsewhere in the file. git stash is what usually works here, or git add -p, I generally just git add -p the fix, commit it to master, stash local changes, run test, push commit to master, unstash and keep going. I often queue up 2-3 fixes in my master before I finish the feature or bother testing all the fixes. I think you exagerate how many testing steps you have to do for each and every fix. Absolutely, there are times when thorough testing is needed. But lots of simple bug fixes/changes in 7.8 can be merged into master without worry. I can provide many concrete examples if you don't believe me. I can also provide quite a large long list of commits that aren't in 7.8 because nobody wants to deal with them. Also committing any fixes directly to a stable branch is something I've never really heard of as a standard. I would assume the expectation is that nobody willing introduces regressions, but lots of people accidentally do, and it would be better to find those in master first not in the stable branch when a distro has already shipped it. If you're concerned with causing regressions with a commit, you can do several things including posting the patch for review first and/or running a bunch of regression tests (which it sounds like you're already doing) before committing. Also, just because a bug fix works on master is not a guarantee that it won't cause regressions on the stable branch. It goes both ways. The problem with regression tests is they don't cover enough hw combos. Like I can regression test some radeon easily, however when I shove stuff onto master, I get the side benefits of Intel testing for regressions in their driver, the other radeon guys doing tests on different hw combos etc. But they are stabilizing master for the next release. For r300 for example accel CopyTexImage was added in master, while
Re: [Mesa-dev] so the development model is working?
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
Re: [Mesa-dev] so the development model is working?
On Fre, 2010-04-30 at 14:59 +1000, Dave Airlie wrote: I think you exagerate how many testing steps you have to do for each and every fix. Absolutely, there are times when thorough testing is needed. But lots of simple bug fixes/changes in 7.8 can be merged into master without worry. I can provide many concrete examples if you don't believe me. I can also provide quite a large long list of commits that aren't in 7.8 because nobody wants to deal with them. I'd be interested in seeing that FWIW. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
2010/4/30 Michel Dänzer mic...@daenzer.net: On Fre, 2010-04-30 at 14:59 +1000, Dave Airlie wrote: I think you exagerate how many testing steps you have to do for each and every fix. Absolutely, there are times when thorough testing is needed. But lots of simple bug fixes/changes in 7.8 can be merged into master without worry. I can provide many concrete examples if you don't believe me. I can also provide quite a large long list of commits that aren't in 7.8 because nobody wants to deal with them. I'd be interested in seeing that FWIW. From 15 mins just looking across the mesa 7.8 to master logs I've noticed over 30 commits that should be considered for stable http://fpaste.org/kZeg/ its just commitids because I'm on the couch and its the weekend already, and I'm not claiming this list is in any way complete or accurate. These are also only commits that meet my criteria of being useful to actual consumers of stable branch release tarballs, I've deliberately not picked at gallium or demos or anywhere outside the src/mesa or src/glx dirs. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
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
Re: [Mesa-dev] so the development model is working?
I happen to do mesa development work on about 10 different machines, so yes I generally keep one mesa tree on each as close to master as I can get. Again you are developing for swrast or for vmware. Try developing for something like radeon and intel on different days, I have to keep a number of test boxes with r100-r600 cards in them, along with laptops at home where I idly do gallium work and also a pile of laptops in the office. I don't do any mesa development on my main workstation because I try to use it to read emails and stuff. I know you guys have worked on hw drivers in the past, but its always been quite focused on one platform at a time. I don't get that luxury working on a distro, the open bug list for 3D drivers on Fedora is quite large and involves hopping machines and swapping hw configurations quite a lot. Actually, I'm sure I've done as much diverse development on different target machines as anybody here. 10 machines was hardly atypical. My approach is straightforward, and scaled well to the situations you're describing. Basically I never touch the target machines except to reboot them. All interaction is with my main machine (at home or office), usually a laptop. On that machine I have a lot of trees, as Brian described, and scripts which: - recognize the tree surrounding the PWD - sync it to the remote machine - invoke make on the remote machine with the remainder of the command line arguments. - perform any manipulation on the compiler output to get emacs to understand it locally. That way I can do things like: rmake test-i965 foo from inside emacs, have the remote machine kick off a local build, and have emacs treat it as if it were local. The remote machines have basic OS install plus relevant dev tools. It's possible to develop test on several target machines simultaneously in this way. Keith ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
From: ... Brian Paul Sent: Friday, April 30, 2010 12:17 AM To: Dave Airlie Cc: mesa-dev@lists.freedesktop.org ... If you're concerned about producing a stable driver, why aren't you making more fixes to the 7.8/stable branch, whether by cherry picking or whatever? That's the whole point of it. Master is not a stable branch. Look above and see if you can guess why I prefer doing merges to cherry-pick.? I'd rather do 3 merges vs. 20+ cherry-picks. Cherry picking quickly becomes a PITA once you get beyond a handful of patches or one commit per week or so. Quick question; Dave's comments implied that there is a policy against fixing bugs in master then cherry picking 'em to stable; your comments implied master-first plus cherry pick is OK but you feel that fixing in stable and merging back to master is a *better* way of working. Is it fair to say that if a developer is working in master and notices a potential bug fix then it's OK to fix in master and cherry-pick that fix to one or more stable branches afterwards, but if the primary task is fixing a bug (particularly a big discovered in stable) then fixing first in the stable branch is preferred ? re: the overall development model, my main question would be whether continuing work on a release branch after the initial release is really still required now that we have quarterly major releases for all the major components. JB ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
Bridgman, John john.bridg...@amd.com writes: re: the overall development model, my main question would be whether continuing work on a release branch after the initial release is really still require d now that we have quarterly major releases for all the major components. FWIW, the frequency of Mesa releases is daunting for our project. We could really go for branches which are maintained for longer periods of time. Our test suite is (almost) entirely based around saving images and comparing to baselines, all of which have been generated via swrast. We currently generate 2200+ images every run of our test suite. A Mesa upgrade means some poor jerk (read: me ;) needs to flip his eyeballs over every single image and either recreate the baseline or mark it 'bad'. It's so daunting that nobody in our group had touched Mesa since 5.0, before I showed up around here, perhaps a year ago now. We're now running 7.5, and I know of one Mesa bug and two bugs which appeared when we upgraded Mesa but I haven't categorized yet... but Mesa 7.5 is unsupported now. If we had stable branches that lasted longer, and probably skipped some major releases, that would be a real boon. I am not knowledgable enough, nor do I have the time available to be able to maintain such a branch. However if Dave and/or others are interested in such branches, I would gladly contribute. Just my $0.02. -tom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Fri, 30 Apr 2010 12:13:23 +1000, Dave Airlie airl...@gmail.com wrote: So in the spirit of being less of a dickhead, 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? The goal of the Mesa project I want to be working on is: To produce open-source OpenGL drivers for Linux (/open-source) platforms. 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. (The TG model didn't work so well either but it was part of TG's business model and we had a smaller community back then, it mainly consisted of driver code drops appearing at misc times and releases happening on a whenever we have time approach, this was fine then I'm not sure with it now, also CVS sort of drove a lot of the problems.). 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. This is what I actually have to do to participate in the stable branch according to Brian's rules. I really do want to be bringing patches to stable. I also have the work time to do so. But the current process has made me quit. When I'm producing fixes for Mesa, it's generally because I'm working on some other interesting thing on master, notice the bug, reproduce it, start hacking on a fix, come up with the minimal testcase, clean up the fix, and push it. If I am to follow Brian's rules, I need to go to my stable tree, run the testsuite, pull my hacks out of master and clean up the fix there, test it, push, go to the master tree, run testsuite, merge stable, run testsuite, and push. And in the meantime someone conflicted with me and I get to re-merge and test and despair. So Brian's rules make a simple fix not related to my primary task for the day go from 2 testsuite runs on 1 tree to 4 testsuite runs on 2 trees. I will not merge to master without testing. Every time I push changes without testing, they're broken. And that doesn't appear to be significantly different for other people that have merged stable changes into master in my drivers. So, I have realized that if I follow these rules, I will simply ignore small bugfixes I ought to do because it's too much of a distraction from what I need to be doing. Instead I just develop on master, ignore stable, and hey at least the next major release will be better. (For a while I was cherry-picking to stable and ignoring Brian's rules. I got yelled at enough about this by people who wanted me to put my foot down about this bad model instead of ignoring it that I just quit entirely). If the VMware guys will stop merging stable to master, I will start cherry-picking fixes to my driver back to stable again. pgp3e5ne7hKYa.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Airlie wrote: Also committing any fixes directly to a stable branch is something I've never really heard of as a standard. I would assume the expectation is that nobody willing introduces regressions, but lots of people accidentally do, and it would be better to find those in master first not in the stable branch when a distro has already shipped it. This has been the core of my argument against this model since the beginning. One person testing a patch on one configuration does not make it a suitable candidate for a stable branch. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvbOGQACgkQX1gOwKyEAw/A+ACfX4Gu/gwXGA3FM8TRvYOm0B+9 SwQAnA4GqUyYpGVwEJU5PJ1eP4U3kUF0 =8ivH -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
Corbin Simpson wrote: [...] I think the big problem is the disconnect between VMWare and the rest of the developers in terms of communication. We all are on IRC extensively but at least Brian, Keith, Jose, and Vinson are not. I tried IRC years ago but it was too much of a distraction. If it was on my desktop and I saw something happen out of the corner of my eye it distracted me from whatever I was working on and interupted my concentration. If I kept it out of view I soon forgot about it. I realize that I probably miss out on some good conversations on IRC, but I don't have time to loose to interuptions. Sorry, I guess I'm getting old and can't multitask as well as you young guys! :) -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
Dave Airlie wrote: Dave, I'm sorry you're frustrated, but let's see if we can at least come to a better understanding of where we're each coming from. Your message seems to boil down to cherry-pick fixes from master back to the stable branch vs. fix bugs in the stable branch and periodically merge to master. If you have issues with the timing of releases, take it up with Intel. They're the ones who suggested the quarterly release model. I've been OK with that so far, but I don't think it's ideal. Sometimes the quantity and collection of changes/fixes don't neatly fall into the calendar months. I'm quite happy that we have timed based releases at least, since we know when stuff needs to be stabilised and when we can get away with not having master as good as it should be. I'd like to respond to some of your arguments: 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. Of course not. Many of us are working on new features or redesigning things. That's what master (and feature branches) is for and is totally inappropriate for stable branches. 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. Hmmm, here's how I work: I have several separate git check-outs in different directories. At the moment I have four that I'm actively working on (plus ~30 inactive/older ones). My active directories contain different branches (master vs. 7.8 vs. 7.7 etc) with different builds (swrast vs. DRI vs. llvm, etc). I typically have a terminal/tab open on each of my active check-outs. This lets me quickly and easily compare the results of Mesa 7.7 vs. 7.8 vs. master when I find a bug or want to compare performance, etc. Do you really do all your work in one directory with just one check-out?? I happen to do mesa development work on about 10 different machines, so yes I generally keep one mesa tree on each as close to master as I can get. Again you are developing for swrast or for vmware. Try developing for something like radeon and intel on different days, I have to keep a number of test boxes with r100-r600 cards in them, along with laptops at home where I idly do gallium work and also a pile of laptops in the office. I don't do any mesa development on my main workstation because I try to use it to read emails and stuff. I know you guys have worked on hw drivers in the past, but its always been quite focused on one platform at a time. I don't get that luxury working on a distro, the open bug list for 3D drivers on Fedora is quite large and involves hopping machines and swapping hw configurations quite a lot. So when you are working on multiple hw drivers you don't really get the liberty of just keeping a bunch of trees in one place that you regularly up date and test. Its a lot easier to just work in master on those machines, and when you get around to it later pulling the changes back into stable, and dedicating a day to retesting stable on as many configurations as you think require it for you to be happy with the work done. I develop on multiple machines too, FWIW. I do lots of ssh stuff like Keith described. BTW, your last sentence can go either way. From my point of view it's: Its a lot easier to just fix bugs on the 7.8 branch on those machines, and when you get around to it later merging the changes back into master, and dedicating a day to retesting master on as many configurations as you think require it for you to be happy with the work done. I'm usually working on master. If I think I've found a bug (or someone reports a bug in 7.8, for example) I just change terminal tabs and start debugging in my 7.8 directory. I don't have to save my work on master or check out a different branch, etc. Just switch to a different terminal and fire up emacs. After I fix the bug, I commit it to the 7.8 branch and document it in the release notes file (I'm practically the _only_ person who bothers to do that, btw!). If I think it's important to get the fix into master quickly (or there's any doubt about applicability) I'll do a merge right away. Otherwise, I just resume whatever I was doing before, knowing that the fix will propogate into master whenever we do a merge. Again I don't think is what the majority of developers at least the part-time ones do or anything close. They restrict their limited time to making master at any point in time work well for them. If you are developing a feature, and you fix a bug in a separate commit while working on the feature, taking a divergent path
Re: [Mesa-dev] so the development model is working?
Bridgman, John wrote: From: ... Brian Paul Sent: Friday, April 30, 2010 12:17 AM To: Dave Airlie Cc: mesa-dev@lists.freedesktop.org ... If you're concerned about producing a stable driver, why aren't you making more fixes to the 7.8/stable branch, whether by cherry picking or whatever? That's the whole point of it. Master is not a stable branch. Look above and see if you can guess why I prefer doing merges to cherry-pick.? I'd rather do 3 merges vs. 20+ cherry-picks. Cherry picking quickly becomes a PITA once you get beyond a handful of patches or one commit per week or so. Quick question; Dave's comments implied that there is a policy against fixing bugs in master then cherry picking 'em to stable; your comments implied master-first plus cherry pick is OK but you feel that fixing in stable and merging back to master is a *better* way of working. I'd rather avoid cherry picks like that, but that's better than bugs not getting into the stable branch at all. A neat git history (w/out duplicate commits) isn't as important as getting fixes into the stable branch either, IMO. If fixes originate in the stable branch, they won't get lost or left behind from master thanks to periodic merges. As it now, when things are fixed on master they're not getting into the stable branch. Even if we had a cherry-pick policy, I'm sure some fixes would fall through the cracks. Is it fair to say that if a developer is working in master and notices a potential bug fix then it's OK to fix in master and cherry-pick that fix to one or more stable branches afterwards, but if the primary task is fixing a bug (particularly a big discovered in stable) then fixing first in the stable branch is preferred ? Well, if I said OK, that'd be an excuse for people to just work on master all the time (and again, I bet some of those fixes would get lost). re: the overall development model, my main question would be whether continuing work on a release branch after the initial release is really still required now that we have quarterly major releases for all the major components. I think that maintaing stable branches is important and master is not always a stable place. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Thu, 29 Apr 2010 22:16:51 -0600, Brian Paul bri...@vmware.com wrote: Dave Airlie wrote: 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. Hmmm, here's how I work: I have several separate git check-outs in different directories. At the moment I have four that I'm actively working on (plus ~30 inactive/older ones). My active directories contain different branches (master vs. 7.8 vs. 7.7 etc) with different builds (swrast vs. DRI vs. llvm, etc). I typically have a terminal/tab open on each of my active check-outs. This lets me quickly and easily compare the results of Mesa 7.7 vs. 7.8 vs. master when I find a bug or want to compare performance, etc. Do you really do all your work in one directory with just one check-out?? I don't, but that just eliminates the check-out step, not the actual expensive do testing steps. I'm usually working on master. If I think I've found a bug (or someone reports a bug in 7.8, for example) I just change terminal tabs and start debugging in my 7.8 directory. I don't have to save my work on master or check out a different branch, etc. Just switch to a different terminal and fire up emacs. After I fix the bug, I commit it to the 7.8 branch and document it in the release notes file (I'm practically the _only_ person who bothers to do that, btw!). If I think it's important to get the fix into master quickly (or there's any doubt about applicability) I'll do a merge right away. Otherwise, I just resume whatever I was doing before, knowing that the fix will propogate into master whenever we do a merge. I think you exagerate how many testing steps you have to do for each and every fix. Absolutely, there are times when thorough testing is needed. But lots of simple bug fixes/changes in 7.8 can be merged into master without worry. I can provide many concrete examples if you don't believe me. Grepping Mesa history for merge leads to either laughing or crying. Here's a sample of someone thought they didn't need to test a merge and were wrong this year, not even changes that went into stable when they shouldn't have. commit a098fd71d7b7347bb8f1841bad0e7ce24e0e6de9 Author: Eric Anholt e...@anholt.net Date: Mon Jan 25 22:27:46 2010 -0800 i965: Fix build after merge of mesa stable branch. commit f6a49ac21721353948b03cf3ca3b5aa5c87e59e6 Author: Brian Paul bri...@vmware.com Date: Fri Jan 22 18:35:36 2010 -0700 svga: fix up breakage from earlier 7.7 merge commit 1e4b81267c77567ec9dfb687ccd8f02086053777 Author: Brian Paul bri...@vmware.com Date: Fri Jan 22 12:27:25 2010 -0700 gallium/aux: re-add pb_buffer_fenced.[ch] accidentally remove during merge commit 5a7c2a99a65399a59f54c6a0756c106c1ae048ff Author: Eric Anholt e...@anholt.net Date: Tue Jan 5 11:07:54 2010 -0800 i965: Fix build after blind merge of mesa 7.7 by Brian. Of course, I get complained at for the breakage in my driver, not the people that did the bad merge. pgphY1QS7ONok.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
Brian Paul ... BTW, your last sentence can go either way. From my point of view it's: Its a lot easier to just fix bugs on the 7.8 branch on those machines, and when you get around to it later merging the changes back into master, and dedicating a day to retesting master on as many configurations as you think require it for you to be happy with the work done. Would a regular schedule for merging back to master help, say every Friday or something ? I guess the downside of this is that the fixes that go into a release branch probably wouldn't go in if they weren't important, which argues for merging back to master almost immediately. FWIW this was one of the problems we ran into with a branch-first model - rather than fix/fix/fix/fix/merge we ended up with fix/merge fix/merge fix/merge which was no less effort than a master-first flow. Also, just because a bug fix works on master is not a guarantee that it won't cause regressions on the stable branch. It goes both ways. Amen to that. I think the best way to get stable releases is to get people to work/test more on the stable branches in the first place. From an observer's point of view this is really the core issue in the sense that if there were more people working on the release branches then the conflicting views re: best model would go away. If you strip away the hey, I'm already working on master, all my stuff is there argument the remaining argument for master-first is that submitting changes there first gives them some test coverage that they simply won't get in a release branch today. The question is whether it is practical to get more people working on the release branches (or even if it's a good use of time, I guess). What I can say after 25 years of mucking around with development process in proprietary SW is that in the end most teams seem to converge on stabilizing in master, branching as late as possible, and making so few changes in the branch that everyone can live with branch-first *or* master-first, whichever is chosen. Getting everyone to do anything is hard. And I don't know who has the time to handle that role. My work days at VMware are pretty full and I don't have as much spare time for Mesa work as I did in the past. I didn't quote a lot of your comments about the challenges of leading the mesa project, but IMO the fact that there is such a civilized discussion about development model speaks volumes about how well the project has been managed so far. Debates about development process don't normally go this smoothly ;) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Fri, 30 Apr 2010 14:59:09 +1000 Dave Airlie airl...@gmail.com wrote: Jesse Barnes 4 0 - some good DRI2 fixes, I'll allow Jesse to reveal his own opinions on getting those in. Fixing in master and cherry picking is easier for my work flow; I don't have a setup as sophisticated as what Brian and Keith mention, even though I test/build on 6 or so machines regularly. Plus I think it makes more sense; I don't like to merge changes to the stable branch unless they've been tested a bit, since causing regressions is so easy. Committing to stable first increases the chance that the stable branch will be broken regularly, imo. It also makes it much easier to just commit fixes as you go when developing a new feature or doing testing, without interrupting, switching to another directory or whatever, and potentially changing out some other components due to feature mismatch (e.g. X server due to protocol or interface changes). For better or worse (based on the rest of this thread), it sounds like stable is missing a lot of fixes and development it would otherwise get, due to the development model we have today. Jesse ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie airl...@gmail.com wrote: Alex Deucher 2 0 - pci ids My development pattern also favors work on master with cherry-picks to stable. Usually I notice bugs when working on new code, then have to go back and apply to stable. I also try and backport fixes from master when I see them, but that means cherry-picking. I'd prefer master with cherry-picks to stable. Alex ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
On Fri, Apr 30, 2010 at 7:39 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie airl...@gmail.com wrote: Alex Deucher 2 0 - pci ids My development pattern also favors work on master with cherry-picks to stable. Usually I notice bugs when working on new code, then have to go back and apply to stable. I also try and backport fixes from master when I see them, but that means cherry-picking. I'd prefer master with cherry-picks to stable. Let me just add a me-too here. For me it's not so much the workflow of checking out stable to commit the patch, after all, to cherry pick the patch, I would have to check it out anyway (I usually only use one checkout of mesa). The problem for me is that I really don't want to merge all of 7.8 into master. I just don't know what's in there or who comitted what's there and I can't vouch for it. When cherry-picking, I pick just the commit that I did and understand, not a branch of potential unrelated fixes. The other thing, which I haven't seen brought up so far, is that a bug sometimes requires different fixes for master and for a stable branch. For the stable branch you often want to take a more conservative approach, that avoids affecting too much other code, or maybe even back out the feature that's broken. On the master branch, you typically want to fix the root cause and fix it the right way however. In that case you simply can't merge the stable branch into master, since you'll have two conflicting approaches to fixing the bug. I guess I've never understood what the merging policy is supposed to acheive? Are we trying to avoid dropping fixes or is there something else going on? It sure seems like we're dropping/losing more fixes the way things work now... Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Høgsberg wrote: I guess I've never understood what the merging policy is supposed to acheive? Are we trying to avoid dropping fixes or is there something else going on? It sure seems like we're dropping/losing more fixes the way things work now... I don't think we're losing more now, but we do seem to be losing a lot. Before we changed to this model, Brian and I were basically the only ones that cherry-picked stuff back. It was difficult to figure out which changes from three months ago should be brought from master to stable. I'll point out that we basically had *no* process, and anything is an improvement over nothing. Through the course of this discussion I've begun to wonder whether it's maybe time to move to a subsystem maintainer model. A lot of the problems seem to root from the inability for any one person to be on top of everything. Dunno. Just thinking out loud... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAkvbdQkACgkQX1gOwKyEAw8/vgCYju4jFTTiojobvpkDwabW8fRx eQCdFLYW1CszvhT/vg+kpV6kfMOK+us= =h8KL -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
idr wrote : Before we changed to this model, Brian and I were basically the only ones that cherry-picked stuff back. It was difficult to figure out which changes from three months ago should be brought from master to stable. I'll point out that we basically had *no* process, and anything is an improvement over nothing. I think everyone would agree that the problem you describe needed a solution - the only debate seems to be about whether branch-first submission is the best solution for everyone. How about something simple like the following ? 1. fixes go in master first 2. developer who submits a fix to master also decides if it should be cherry-picked to one or more release branches, and does so either immediately or (ideally) after a day in master, long enough for obvious problems to get noticed 3. if developer doesn't have time to cherry-pick immediately then a tag is used to make sure the fix doesn't get lost 4. if developer isn't sure whether fix should go to a release branch then email the list 5. changes specific to release branch (update of release #s, docco etc.) go directly to release branch and don't get merged back to master ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] so the development model is working?
So in the spirit of being less of a dickhead, 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. Like if you want to know where mesa is shipping most units, its in Ubuntu and Fedora, there is probably 100-1000 more copies of mesa shipping in these two distros than everything else ever produced by this project. 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. (The TG model didn't work so well either but it was part of TG's business model and we had a smaller community back then, it mainly consisted of driver code drops appearing at misc times and releases happening on a whenever we have time approach, this was fine then I'm not sure with it now, also CVS sort of drove a lot of the problems.). 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. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] so the development model is working?
Dave Airlie wrote: So in the spirit of being less of a dickhead, 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. Like if you want to know where mesa is shipping most units, its in Ubuntu and Fedora, there is probably 100-1000 more copies of mesa shipping in these two distros than everything else ever produced by this project. Sounds good. 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. (The TG model didn't work so well either but it was part of TG's business model and we had a smaller community back then, it mainly consisted of driver code drops appearing at misc times and releases happening on a whenever we have time approach, this was fine then I'm not sure with it now, also CVS sort of drove a lot of the problems.). 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. Dave. Dave, I'm sorry you're frustrated, but let's see if we can at least come to a better understanding of where we're each coming from. Your message seems to boil down to cherry-pick fixes from master back to the stable branch vs. fix bugs in the stable branch and periodically merge to master. If you have issues with the timing of releases, take it up with Intel. They're the ones who suggested the quarterly release model. I've been OK with that so far, but I don't think it's ideal. Sometimes the quantity and collection of changes/fixes don't neatly fall into the calendar months. I'd like to respond to some of your arguments: 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. Of course not. Many of us are working on new features or redesigning things. That's what master (and feature branches) is for and is totally inappropriate for stable branches. 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,
Re: [Mesa-dev] so the development model is working?
Dave, I'm sorry you're frustrated, but let's see if we can at least come to a better understanding of where we're each coming from. Your message seems to boil down to cherry-pick fixes from master back to the stable branch vs. fix bugs in the stable branch and periodically merge to master. If you have issues with the timing of releases, take it up with Intel. They're the ones who suggested the quarterly release model. I've been OK with that so far, but I don't think it's ideal. Sometimes the quantity and collection of changes/fixes don't neatly fall into the calendar months. I'm quite happy that we have timed based releases at least, since we know when stuff needs to be stabilised and when we can get away with not having master as good as it should be. I'd like to respond to some of your arguments: 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. Of course not. Many of us are working on new features or redesigning things. That's what master (and feature branches) is for and is totally inappropriate for stable branches. 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. Hmmm, here's how I work: I have several separate git check-outs in different directories. At the moment I have four that I'm actively working on (plus ~30 inactive/older ones). My active directories contain different branches (master vs. 7.8 vs. 7.7 etc) with different builds (swrast vs. DRI vs. llvm, etc). I typically have a terminal/tab open on each of my active check-outs. This lets me quickly and easily compare the results of Mesa 7.7 vs. 7.8 vs. master when I find a bug or want to compare performance, etc. Do you really do all your work in one directory with just one check-out?? I happen to do mesa development work on about 10 different machines, so yes I generally keep one mesa tree on each as close to master as I can get. Again you are developing for swrast or for vmware. Try developing for something like radeon and intel on different days, I have to keep a number of test boxes with r100-r600 cards in them, along with laptops at home where I idly do gallium work and also a pile of laptops in the office. I don't do any mesa development on my main workstation because I try to use it to read emails and stuff. I know you guys have worked on hw drivers in the past, but its always been quite focused on one platform at a time. I don't get that luxury working on a distro, the open bug list for 3D drivers on Fedora is quite large and involves hopping machines and swapping hw configurations quite a lot. So when you are working on multiple hw drivers you don't really get the liberty of just keeping a bunch of trees in one place that you regularly up date and test. Its a lot easier to just work in master on those machines, and when you get around to it later pulling the changes back into stable, and dedicating a day to retesting stable on as many configurations as you think require it for you to be happy with the work done. I'm usually working on master. If I think I've found a bug (or someone reports a bug in 7.8, for example) I just change terminal tabs and start debugging in my 7.8 directory. I don't have to save my work on master or check out a different branch, etc. Just switch to a different terminal and fire up emacs. After I fix the bug, I commit it to the 7.8 branch and document it in the release notes file (I'm practically the _only_ person who bothers to do that, btw!). If I think it's important to get the fix into master quickly (or there's any doubt about applicability) I'll do a merge right away. Otherwise, I just resume whatever I was doing before, knowing that the fix will propogate into master whenever we do a merge. Again I don't think is what the majority of developers at least the part-time ones do or anything close. They restrict their limited time to making master at any point in time work well for them. If you are developing a feature, and you fix a bug in a separate commit while working on the feature, taking a divergent path into 7.8 land is quite a detour, it usually involved git rebasing the stable 7.8 you checked out a month ago up to whatever is latest version, rebuilding it, applying your patch, building, testing, pushing, pulling into master, rebasing your current development work which may also need the bug fixed to continue on top of it. I really don't see this as a small divergence. If you are focused on doing development, this is a complete task switch, which could reliably be done in a separate
