On Fri, Feb 13, 2009 at 3:36 PM, Owen Winkler <[email protected]> wrote:
> > > I suppose I am meant to understand that you disagree with the policy > addition. Very good. > > > In the past I know there have been things that got voted down because > > they weren't consistent with the "spirit of Habari" or "why Habari was > > started". Largely that equates to not being in line with the opinions > > you, Scott, Chris J. Davis, Rich, etc. hold, being the "core" group. I > > object to that logic because it seems to place your values (and > > therefore the ones that originally defined the "Habari spirit") above > > those of other participating members, potentially even in a vast > > majority, throwing off the "one voice, one vote" equilibrium. > > I recall having discussions about features and how they are influenced > by that vision, perhaps resulting in votes. I'm not aware of any commit > that was made in opposition of a majority of voting PMC members. Please > indicate where this has occurred so it can be rectified. > > What I'm hearing now though, is a sentiment that it should be reasonable > to apply one's own vision to Habari without discussion by means of > reverting others' commits. I don't agree with that. That is, by definition, exactly what you're doing every time you commit a single change to the project. You are constantly shaping the product by applying your vision of the ideal software to it. Let's look at one of your other examples here, from the opposite perspective. The first time a color was committed to the admin someone was applying their own vision to the project. It turned out that was not a vision shared by everyone and the revert brought it back in line with the overall vision. You keep portraying reverts as an insult with huge ramifications that damage the end result, while ignoring the fact that any commit can be and is exactly the same. You shape the product more by adding things to it, not by removing them, and the door swings both ways. To treat the two differently is utterly ludicrous. > Sure, we don't need to have a post over every commit, but it seems > reasonable and valuable to discus cases on which we don't all agree, of > which a revert is a clear and obvious example. There is no rush to fix > these things that are reverted - they're only in HEAD, and users there > should expect this kind of "breakage". > > > Extending that logic to essentially revoking Cabal membership would seem > > much more like a tight-knit aristocracy than the oligarchy it's supposed > > to be. > > It seems to me that you've taken my original message as a personal > attack, and have responded in kind. No, I just thought it was a dumb idea and gave examples as to why. Silly me, I thought that was the point of discussing things on -dev... Mostly, I was referring to the admin color changes that occasionally > bounce their way into and out of the core code. I believe that frequent > abuses of commit privileges like these that insight perpetual reverts > should be reviewed. I recall one intentional color commit / revert and much discussion (on -dev and not) about a number of people wanting to make the admin a little less drab. I would hardly consider that a frequent abuse - in fact it seems like exactly what you want to happen. > > Please open separate threads to discuss the merits of specific past > > reverts if it is not directly relevant to this policy topic. Thanks. > > > > > > I would like to bring up the Apache license notice revert (r3185) that > > originated this "discussion" here, since it seems directly relevant. > > Then one might also bring up these instances: And I could go through all your commits and find tons of examples of things I don't agree with. The issue is not how things are working, but apparently how you're portraying them. > r2832 - Reverting r2831, it's absolutely horrid. I'll fix it in a moment. > > Then why not fix it and then commit the fix? Not only did the fix take > an additional measly 5 minutes, but it could have avoided the insult in > the commit log. Obviously it was easier to revert the change automatically with SVN and start closer to the goal with the original code than to modify the modified code. If we're being honest here, you've been the prime example of a code perfectionist. I'm sure we can all think of at least two people you've run off because their code never seemed to be up to your standards. Again, using the word "revert" seems to be your problem here. The fact that I didn't like the patched solution and changed it isn't at issue, it's calling it a "revert" that is. How stupid is that? r2889 - Reverting the error_reporting changes in r2886 while we further > discuss if and how we really want to handle settings like this. See > habari-dev for a discussion if you have an opinion one way or another. > > Oddly, precedent for the suggestion I made in this thread. Because it's common sense. We'd been talking about it on IRC, obviously there was discussion going on. It wasn't as a matter of course because some policy said it had to be done. > r3070 - Reverting r3068 and restoring the spam count to the dashboard. > > An instance of not agreeing with how a feature should work or whether it > should exist that ultimately results in a perplexing new site-wide > option -- but no -dev discussion, despite the volley of commits. No, there was IRC discussion and all parties, including the one who originally made the ill-advised change (which, by the way, removed a feature - a *gasp* "revert") were happy with it. Again, common sense. There was no additional discussion seemingly required, and no one started one. > r2846 - Re-applying button styles. In this instance Heilemann has been > out-voted by a number of people (PMC and non-PMC) on IRC. > > This is the one you would expect to see in this list, regarding the > button styling. No discussion was logged on this topic until later when > Khaled posted to -dev, and that was the first time many people even knew > it was happening. Unless we've changed something, IRC votes are not > binding, and for this second volley of commits and the general sentiment > that it aroused, it arguably should have been called to a binding vote. And guess what, someone who felt so did. The majority of the voting Cabal is present on IRC on a regular basis. That obviously makes it an ideal place to "get the lay of the land" among voting members and their "constituents". When someone had an issue and wanted to "elevate" it to -dev, they did. Again, things worked out through common sense application of your suggested policy. > In terms of where r3185 went wrong, moeffju saw a need to make Habari > better in terms of applying Apache licensing. I think that complying > with SHOULD clauses is a good thing, not an optional thing that should > be dismissed at whim. I think this case was a good commit, although I > agree that the size increase is undesirable. I never said it wasn't a good idea. Good ideas don't necessarily translate into good practice. Obviously you need to look at the whole picture. When you do, this *still* seems like a no-brainer, and no one has, as yet, disagreed with that. > What I'm suggesting is that posting this concern to the dev list before > reverting could avoid tension and result in a better overall outcome. > As an example alternative, all of the Habari files should have PHPDoc > headers as part of our code standards compliance. Adding a simpler > licensing notice in the PHP Doc would add minimal additional size, and > fulfill the requirement. Moeffju was in IRC. We discussed it in IRC. He was not overly passionate about the matter in IRC. He has yet, to my knowledge, to complain about the revert in any venue. Had he felt the need to bring it up on -dev or stimulate further discussion on IRC, he surely would have been welcome to do so. You seem to be the one with the issue here... > If there was discussion on the topic, I can't tell solely from the > commit log. No conversation on IRC was referenced in the commit log, > and no -dev thread exists indicating the discussion. For all I know, > moeffju said, "Yeah, you're right, get rid of it." That would appease > me, but I'd like to see that happen; I'd like to know that people are > discussing these things and arriving at compromises, not just reverting > commits on "wager" that everyone else will agree. Again, reverts are somehow different from commits. I'm sure we could find hundreds of instances where you in particular, being the largest coder, have come up with an idea and implemented it without further discussion. Discussion has often happened afterward, asking you to explain it or your reasoning, offering up helpful ideas or criticisms, and (I'm sure) once or twice resulting in an idea being scrapped. Again, there are seemingly different standards for different people... > All that said, none of these instances are directly relevant to the > policy suggestion I offered, which is future-facing. I would simply > like to know when a commit is reverting the work of others who have also > earned the privilege of committing directly to Habari's core, and be > able to discuss the rationale for either change. Better yet, if some > way to improve the code in compromise can be reached that avoids the > revert altogether, that would be the superior solution. There it is again. To me, and I think many other people, a revert isn't a kick in the balls to the original committer. It doesn't mean their idea was horrible, or, as pointed out in one of your examples, that it was being removed entirely. Sometimes the shortest path to improving an idea is to take a step back and go in a slightly different direction. > Fine if you don't want to call it a policy. Call it a courtesy -- A > personal favor to me, or out of respect to the gifter of the code you > revert. For so rare an occurrence, I think it would not be too much > trouble. > > > If you would > > consider having a feature or piece of code you contributed being removed > > or changed a personal slight, you probably shouldn't be contributing it > > to an open source project in the first place; once it leaves your hands > > it's not yours anymore, it's the community's. > > I think we should handle other people's submissions with respect. Even > if a revert is technically just another commit, it has additional social > implications that should be considered. > > Reverts don't move the code forward, both in a literal sense, and in the > sense that they don't help to achieve the objective of the original > commit at all. In addition, the negative social aspects of reverts > leave them as something to be avoided entirely if possible, and > well-documented and discussed if not possible. This would seem to be your opinion, not necessarily one held at large. Obviously I disagree, and the consensus thus far seems to think reverts are somewhat less of an issue than you make them out to be. If a commit breaks something, obviously it's moving the code backwards and the revert would be moving the code forward again, so your example is a bit flawed. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
