> 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
