I don't see opening a discussion on -dev, preferably before but at least immediately after, a contemplated revert as a great hardship, whether it just makes us feel 'warm and fuzzy' or not. Though the policy is often honored in the breach, irc discussions alone have already been determined not to be binding.
The fact of the matter is that any contribution of code is a gift to the community. Sometimes the code might not be well thought through. Sometimes it is a piece of art. Very occasionally it is an attempt to further purely personal ends. Human feelings and ego attachments enter into any such contribution, whether we want them to or not. If you give someone a gift, and they return it with the comment that "it's ugly" or "that's stupid", how do you feel? Whether there is technical difference between a commit and a revert is irrelevant. An extra day or two of four to remove bad code from head in the quest to keep relations unstrained between people who have volunteered to work together is not too much. If one runs one's site on head, it is with the understanding that the code is not always stable, though we try to keep it so, and that sometimes things will be broken. Knowing this takes some of the urgency out of dealing with code that may be bad. One thing we need to remember is that a community is not an amorphous mass. It is composed of individuals. The feelings of the individuals involved may not be something we want to deal with, but we have to if we want to succeed as a community. I'd much rather deal with talking about why something is a bad idea or how we can go about accomplishing a given task, than have to spend time on unruffling feathers or dealing with and listening to defensiveness. This is much easier to accomplish when we treat each with a modicum of respect. </end soft and fuzzy> Rick Cockrum (Full knowing that I haven't followed such a policy myself in the very recent past) On Feb 13, 1:32 pm, Chris Meller <[email protected]> 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 -~----------~----~----~----~------~----~------~--~---
