Coming to the party late (and only showing up now because I'm putting off writing peer reviews), but for what it's worth, I recall pyd mentioning to me his desire to not make policy changes for a year, but also being a little sad about that because there are at least a few things many of us would like to see evolve over time, and starting sooner rather than later would help me and perhaps others believe that the steering committee actually has control of the project and can make important decisions for the project's long-term future and health.
That there's so much discussion on a relatively minor point is a little concerning to me, and I wonder if it means that the steering committee should appoint a "style czar" so we don't end up with style-design-by-committee (eg, nothing ever gets better, because we can never reach consensus). We all seem agree that some style changes would be nice, but I don't know if we can reach consensus on enough to make meaningfully positive changes to the codebase if every decision takes this long to make. Also, FWIW, leaving it as is for now (mostly lowercase, a few exceptions), or changing it slowly over time by convention to UPPERCASE as Augie suggests, or coming up with a plan to move all consts to UPPERCASE carefully, in a reasonable time as pyd suggests -- all of these are reasonable approaches in my mind. I would love to avoid the tyranny of the status quo, though -- that way lies a cold, slow death. All this being said I understand the desire to transition carefully, and I don't participate anywhere near enough to deserve much of a voice on the matter though, so I'll leave it at these ideas. Cheers, ~Ryan On Mon, Jan 2, 2017 at 10:27 PM, Kevin Bullock < kbullock+mercur...@ringworld.org> wrote: > A few overall notes on this thread, and then some specific clarifications > below: > > First, it is not the current project policy to defer any decisions until > October 2017. It is also true that none of the core team is advocating > radical changes to the way we develop Mercurial, either before or after > that date. > > Second, this topic is a matter of project policy, so we should take it up > as the steering committee if we want to take any further action on it. > > > On Dec 28, 2016, at 10:17, Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > > > > On 12/15/2016 11:38 PM, Augie Fackler wrote: > >> (I’m trying to be brief here - hopefully it doesn’t come across as > upset, because I’m not - mostly I was blindsided by a policy claim that I > don’t remember.) > >> > >>> On Dec 15, 2016, at 3:40 PM, Pierre-Yves David < > pierre-yves.da...@ens-lyon.org> wrote: > >>> > >>> So, to sum up, my stance is "Let us not revisit decision made by Matt > for a while". Of course they might be case were we could make an exception > if it is really worth it. Code style does not seems to be high profile > enough for that (and is a lot of work to adjust). > >> > >> In broad strokes, I agree that we should make an effort to not cause a > wave of sea change. My perception of this particular issue is that: > >> > >> 1) The codebase is already somewhat inconsistent (despite the efforts > of mpm and others) when it comes to constant naming > > > > My perception (and apparently Kevin's too) is that the codebase is > currently consistent¹. A very quick check of the current code seems to > confirm it is consistent (but that was a quick check). So, I think you need > to back this statement with stronger fact than just your perception. > > No, I said there is a _prevailing_ style, not that we have consistency. > Augie was not the only one to draw the conclusion that we're not consistent > today. There are sufficient exceptions to question the strength of the > rule. Thank you for digging up the applicable section in CodingStyle, > though. It seems the convention is written down after all. > > >> I’ve seen some people say they’re fine with such a new policy, and many > contributors (including me when I’m on autopilot, despite a decade of > history with this codebase) are doing it by default, which was the thing > that really pushed me toward making this proposal. > >> > >> I’m fine to explicitly defer this (until the next sprint perhaps? Would > that be far enough in the future?), if that’s what the broader community > (rather than just one person) would like. I’m also fine to hear the > proposal rejected on its merits (rather than a “we’re not changing things > now” policy), > > > > [extracted the last bit on it own line to clarify what I'm replying to] > > > > > but I haven’t heard any objections to the actual proposal, only the > timing. > > > > That part is confusing to me, two emails ago, on this thread, Kevin > voted -0 on the proposal. (You are replying to my reply to that Kevin's > email.) > > Negative zero can be confusing (cf. IEEE 754), so let me make it explicit: > I have no objection to changing the convention, but I won't advocate for > the change either because of the churn it may create. > > pacem in terris / мир / शान्ति / سَلاَم / 平和 > Kevin R. Bullock > > _______________________________________________ > Mercurial-devel mailing list > Mercurial-devel@mercurial-scm.org > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel >
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
