On Fri, Aug 12, 2016 at 1:48 PM, M. J. Everitt <m.j.ever...@iee.org> wrote: > > I regret to say, although it's a well-known problem .. that the Gentoo > bike-shed is never ever going to fall down - as the layers of paint > applied will grossly outlive the materials it might once have been built > from ... Perhaps someone might like to address the problem of the > nuclear reactor which will otherwise never ever be functional ... ;) >
Bikeshedding is only a problem if you let it be one. Gentoo does not require unanimous consensus to get things done. If you choose to wait for it, and then complain about bikeshedding, then YOU are the problem. If I were James I would: 1. Consider the advice given and propose the best way forward. Indicate that I intend to commit the changes to the Gentoo repo in 48h if there are no objections raised by QA or to Council. 2. If there are no objections raised to Council or by QA then go ahead with the commits, unless personally convinced by any further arguments. 3. If an objection was raised to QA, then comply with it for now, and if in disagreement first work with QA, and appeal to Council if necessary. 4. If somebody appeals to Council, then let them make their case, and offer my own, and await a decision. If you do the above you'll never get in trouble, and you've basically put the ball in somebody else's court if they want to hold you up. Usually you won't delay your change by more than 48h, and if you do it won't be by more than a month, unless the Council overrides you (in which case you're "stuck" though presumably they would have good reasons for doing so). Some mistakes I see people make all the time: 1. Give up as soon as a few devs make vocal complaints. This is not a shouting match. The person with the most thread posts doesn't automatically win the argument. 2. Wait until everybody agrees. While there are things everybody agrees on, there aren't many of them. I'm not sure the last sentence even falls into that list of things everybody agrees on. :) 3. Plow forward without giving some time for appeals. This can lead to revert wars and such. 4. Ignore official QA notices. If a member of QA notifies you that QA is taking action, you must comply until you resolve the issue with QA or by appeal. 5. Fail to work with QA. The fact that a random QA member takes an action doesn't mean that all of QA is necessarily behind it. You may find the issue resolved by spending 30 seconds on IRC. The QA lead is responsible to deal with these kinds of issues. 6. Fail to let the Council clear roadblocks. If you're trying to do something, and you feel that something is blocking you, the Council can help resolve that. Devs get frustrated by bikeshedding because they're imposing rules and limitations upon themselves that aren't actually community rules. You don't have to give up just because a few devs complain. You ought to listen, and if it is really controversial push for a decision. However, strictly speaking if you have commit rights to the tree and aren't violating a documented policy, then the onus is on others to stop you, not for you to obtain permission to do something. You shouldn't abuse that, and hence I suggest giving people time to lodge formal objections. However, if you care about getting something done it is completely fair to force those who wish to impede you to step up and do the work to actively block you. Devs don't have to prove the "innocence" of each commit. -- Rich
