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 -~----------~----~----~----~------~----~------~--~---
