On Fri, Dec 7, 2012 at 4:53 PM, Thiago Macieira <thiago.macie...@intel.com>wrote:
> In the general sense, those are the bug fixes that have a high benefit / > risk > ratio. That is, the changes they introduce are of low risk to introduce > more > regressions and unexpected behaviour changes, while fixing some important > issue. > > Does it require precognition? No, it requires experience. Yes, it's > subjective. That's what the Spirit Fit guidelines for. All Approvers are > supposed to exercise their grey mass and decide whether the change is right > and in the right branch. When in doubt, consult with someone more > experienced. > > > Going from the general case to this specific case: the Release Team has the > right to set stricter guidelines concerning their release. We have not yet > created the releases branch, which is where the RCs should be coming from. > So > that team is telling us that we would like to have an even higher benefit / > risk ratio than would be normal. > > Hi Thiago Thanks for using some time to answer, but I am not sure the problem is solved now ... >In the general sense, those are the bug fixes that have a high benefit / risk ratio. That statement is quite obvious. It does not change the vague definition, and there are different views on what it means. Now the situation is that Marc (maintainer) preferred my patch in stable, while Andy Shaw (approver) preferred it in dev. I (not a Qt-newbie) think it would be ok in stable, but as the patch-writer my opinion might not be objective. Andy does not want to block the patch from stable, and Marc (nor I) want to enforce it into stable. We want to do the right thing. This is not itself a major issue and we could call for more reviewers to decide or maybe even ask Lars, but it would be easier if the directions could be made more clear. Beside the problem is a bit worse than that. I uploaded to dev and considered it would be no problem to get it into stable if we wanted to do that (dealing with one problem at a time) I can however see I was wrong after reading http://qt-project.org/wiki/Branch-Guidelines and the ML-mail from Oswald: *submit fixes to the lowest applicable branch (generally stable, later release for release-critical problems) and wait for them being forward-merged to dev by a qualified merge master. * However this is an annoying regression to the Qt work flow. Before I always uploaded to master and then it could afterwards be considered if we wanted to back-port it to 4.8. Now, not only I - but regular newcomers - have to decide which level their bugfix/improvemnt should be in. This is not reasonable since even the most experienced Qt-developers will often need to see a given patch, before they can decide on if it should be in stable or dev (that is *if they can agree*). >When in doubt, consult with someone more experienced. Well, Marc gave a link to the case... :) regards Thorbjørn
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development