On Wed, 7 Aug 2013 09:46:49 -0400 Rich Freeman <[email protected]> wrote:
> Having two bug wrangler projects whose main function ends up being > fighting revert wars over subject line formatting and writing policies > denouncing the other project is counter-productive. Whether you have two individuals or two projects, that's not going to make any difference; they'll still be fighting, that's why the matter needs to be discussed, (decided,), documented and then acted upon. > If you have strong feelings and want to contribute to how bugs are > managed, join the bug wranglers. Asked several times to be added, I'm still not listed; and as far as I am aware, people aren't eligible to just ask themselves to the page without acknowledgment. > The bug wranglers project does need to hold elections for leads per > the policy you just cited. It is better for people to first try to > work together before they just dig in and start fighting each other. The lead has final words on the project, things like the alias and the project documentation; but that doesn't give the lead final words on how things should go on Bugzilla, which needs to be agreed (or at least opposed for trivial matters) with by other developers. > If things are out of hand ask the Council to step in. The things we're discussing are too trivial, I really hope this isn't necessary; but yeah, there's going to come a point we need to do that if it keeps going on like this. > My two cents - I think that what Jer is doing is mostly a value-add. > I wouldn't go changing subject lines to just remove a period, but more > substantive edits should be welcome if it improves consistency. Same thought here, but it's the flip side of that what we're discussing; the noise that it brings, perhaps we should aim for a solution where the noise can be filtered out. Perhaps create a permission group whom gets a checkbox option to not send a mail; then list the changes made with that checkbox option on a separate easy to skim page, such that they can still be processed to check for tampering if it is suspected. I'll be happy to massively apply changes people have agreed on; but, I currently don't do such thing because of the amount of mails it generates. As well as the amount of people that are unaware of the decision thus requiring the extra work to explain the matter. > It might be nice if we could somehow flag such revisions so that > emails are either suppressed or marked as trivial edits, so that > everybody could filter their bugspam accordingly. Hmm, haven't read your full mail; I see now that you suggest something similar. So, let's just say I agree verbosely with trivial edit filter. > Don't get me wrong - I like GLEP 39 and the idea of allowing > "competing projects." However, the intent of that wasn't really to > endorse wars over things that are basically indivisible, like > bugzilla. When I read words like "wars" I'd hope you consider good faith from people; I don't thing anyone here is really trying to make war on purpose, as in trying to overtaking the lead of a project or forcing something particular. On the other hand, I think there are some people assuming that they have more priveleges and permissions than they really have; which causes some changes to happen that might be perceived as competing / war while they really are meant to do good. > If you wanted to start up your own alternative next-gen > bugzilla go ahead, though the distro should probably treat it like an > experiment until it is ready to go. Possibly, but it be just another experiment waiting in a slowly progressing queue; the one the CVS --> Git move is in. We have to be fair, while experiments are neat and all that; they have hardly became successful lately, it's as if our base is somewhat stable and we're afraid to change it. Thinking it through, it's more worth it to fork than to fight something which doesn't happen any time soon; and perhaps might never happen in the future. That's just my perceived view; there are possibly some other views, like lack of man power, as well... > Also, starting over simply to avoid the need to cooperate is dumb - > it might not be forbidden, but it is dumb. When we start something > over it should be because it just makes sense to do it that way. Not really; I would love to see Portage heavily refactored or rewritten, because its Portage tree recalculation is getting slower and slower with time and with upcoming EAPI features as well as problems like not being able to parallelize it it is becoming worse and worse. Do you think zmedico will collaborate if I start sending massive patches that break possibly all other patches filed against him, or that I would ever finishing refactoring or rewriting if I have to port all those patches; I don't think so, sometimes you need to throw things overboard and start over without any form of collaboration. Some of the greatest efforts are done alone, not by a team but by an individual; because unnecessary collaboration slows things down a lot. http://www.bennorthrop.com/Essays/2013/pair-programming-my-personal-nightmare.php -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
