Meh. We can debate anything endlessly, the thing is if people just think a little before they do anything we would all be better off.
From: [email protected] [mailto:[email protected]] On Behalf Of Chris Meller Sent: 13. februar 2009 22:43 To: [email protected] Subject: [habari-dev] Re: Revert Policy On Fri, Feb 13, 2009 at 4:39 PM, Christian Mohn (h0bbel) <[email protected]> wrote: As far as I can see, this whole thing boils down to one thing, and one thing only: Consider the fact that someone spent some time on creating something, and sharing it with us, before you revert their changes. Be polite, and think before you both speak and revert other peoples work. It's not really that hard, is it? But just as with adding (committing), not everyone is going to necessarily agree with removing (reverting) things. The revert that spurred this discussion was thought about, discussed, and documented and it still apparently upset Owen, if not anyone else. Can you say damned if you do, damned if you don't? Christian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Arthus Erea Sent: 13. februar 2009 22:05 To: [email protected] Subject: [habari-dev] Re: Revert Policy I think you phrased it well as a "courtesy." I don't think this should be a set-in-stone policy, because there are simply too many cases where it is simply a waste of time. Instead, common sense and decency should be used in determining cases where discussion should take place. To help with that, I would suggest the following examples. Revert Immediately If: - The original commit causes data loss or security issues - The original commit was done accidentally or incorrectly (this has happened numerous occasions) - The original commit consisted of a single committer abusing commit privileges to go against the community consensus. (Of course, this speaks to larger issues of why said person still has commit access.) Additionally, the original committer should always have freedom to revert their commit at their discretion. In all other instances, there should probably be a discussion before the reversion. However, that doesn't mean this needs to be an official policy. On Feb 13, 2009, at 3:36 PM, Owen Winkler 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. > > 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. > > 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. > >> 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: > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > 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. > > Owen > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
