On Fri, Feb 13, 2009 at 1:58 PM, Chris J. Davis <[email protected]> wrote:
> I also agree with Chris for the most part, however we must be mindful of > revert wars, which have almost happened in this project more than once. > I definitely agree with that. In my mind it would work the same as a commit - someone does it and if anyone else has a problem they're free to pop up and ask "hey, what the hell is that?", at which point we discuss it. When you start re-applying the un-applied application of something we're obviously taking things a little far... > Also reverts should probably be made on the grounds of technical issues, > not personal preferences. I think the revert in question satisfies this > requirement. > Chris > > > On Feb 13, 2009, at 12:46 PM, Arthus Erea wrote: > > In essence, I agree with Chris. > The way I see it, a revert is simply a special type of committing. The same > rules for committing should apply: discussion isn't required beforehand, but > nothing is permanent. > > Regarding the issue of people abusing their commit privileges, I do think > there is a certain point where a conversation should be had. This point is > probably around the time when someone uses their commit privileges to > attempt to repeatedly bludgeon the same code through, despite having been > continually rejected by the community. > > –The uninformed opinion of a non-cabal community member > > On Feb 13, 2009, at 1:32 PM, Chris Meller wrote: > > > > On Fri, Feb 13, 2009 at 12:19 PM, ringmaster <[email protected]> wrote: > >> >> I would like to suggest an addition to Habari commit policy. >> >> When reverting a previous commit in whole due to a subjective issue >> (as opposed to an issue that causes demonstrable breakage or >> insecurity), some discussion on whether the revert should take place >> must take place, as is required by a veto based on technical grounds. >> This discussion needs to be recorded and available for the community >> to participate. The revert commit message must link to the discussion >> in a place where community-wide discussion can continue. In the case >> of a revert to fix breakage or insecurity, the commit message should >> clearly indicate the addressed issue, as usual. >> >> Opening a thread for discussion even immediately before commiting a >> revert should be the minimal requirement for any revert. Subsequent >> discussion on the topic should determine the outcome of the code; >> whether to keep the original code or keep the reverted code. > > > Why are reverts considered different than commits? We've always claimed > that change is freely welcomed under the condition that nothing is ever > understood to be permanent. We've gotten much more pissy about that lately, > insisting that features be "discussed" and voted on more thoroughly before > being added, but why is it so different if "the R word" is used? > > If you replace a feature with a different one, that's part of the process. > If you remove a feature, that's an affront to the person who originally > added it? That clearly makes no sense to me and seems very egotistical and > un-community. > > Just as we don't require discussion before every commit is made, why should > we require it before every revert? I don't believe adding red tape to the > process is in any way the answer. > > In most cases, a discussion on IRC precedes the revert, and in that >> case those present should be encouraged by the revert committer to >> record their +1/-1 on the linked thread to indicate that the revert >> had community support. >> >> I think the above is the best compromise between expedience and >> community review. It places little extra burden on the person >> committing the revert, and doesn't delay the commit process, while >> giving the community the opportunity for discourse. > > > It also accomplishes nothing except giving us a warm fuzzy feeling that > we're actually doing something. There is never a moratorium on discussion, > and this doesn't require any before the action is performed. If someone gets > offended because something they do gets reverted, that's going to be no > different under your plan - it just means we'll have a lot of extra -dev > posts created for things that probably don't need any more discussion. In > the fraction of instances where it does become an issue it still will > whether you create a new -dev thread and link to it or not. > > Like I said, we've always claimed (even if not actually acted) that any > change was welcome, but was free to be removed / altered / improved at any > time. Why is this different for a revert? The act of reverting code should > in no way guarantee it wouldn't be added back again or that discussion is > not permitted. > > I would also suggest that committers whose code is the target of >> persistent reversion should have their commit privileges reviewed. If >> someone repeatedly commits something despite lack of community >> support, there's little reason to continue to let that person commit >> unwanted code. > > > Does that not fly in the face of the Cabal spirit where you're a member > until you decide yourself you no longer want to be? > > 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. > > 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. > > > 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. Exhibit > A, the commit message: > > Reverting r3184 <https://trac.habariproject.org/habari/changeset/3184>. > The Apache page reference says you SHOULD include the license header, not > that you MUST include it. Since this adds somewhere between 200 and 300 KB > of extra text to our download and looks incredibly ugly, I'm inclined to say > we just won't. > > At the very least we should fix it in a better way, making sure it happily > gets tucked into the main <?php ?> block, instead of tacking on a new one. > > > Moeffju added the Apache license notice to the top of every PHP file in > Habari. It was added in its own <?php ?> block at the top of the file, > rather than as the first comment inside the already existing <?php tag; was > seemingly lacking line breaks that would make it more consistent with the > existing coding style; and added a whopping 250 KB of text. > > Unzipping habari_head.zip from /dist, I see that the directory is 2.77 MB > in size. That means the addition of a notice to every file added nearly 10% > (283.6 KB) to the Habari footprint. Since the Apache license docs indicate > that you SHOULD (not MUST) include this notice in every file, that it had > been previously discussed and ignored, and was pointed out to be a mostly > bad idea on IRC (the same place it was discussed before being added), it > seems like a no-brainer to revert that kind of change. > > The commit message was detailed, explained the issues, and left the > situation open to change by re-applying the notice in a better format. > Applying such a change would also be *significantly* easier from the > original non-noticed files than removing and re-adding the notice would have > been down the line after other changes had been made to the source and a > pure revert became more difficult. > > I would wager that the majority of people don't care one way or another > whether there's a notice in each file (and that most developers would > probably prefer there not be). I would also wager that they would agree > having a 10% smaller download footprint per install is desirable and in > keeping with the "Habari spirit" of a lean blogging solution, especially > since that 10% offers no added benefit. > > There is no additional red tape required here. > > Working with others is never going to be a 100% smooth process, but > requiring a -dev post be created or a vote taken before anything can be done > isn't going to make that any different. Regardless of who has done it, > everything should be considered totally expendable. 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. > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
