undefined | Better HN

0 pointsdisruptiveink2y ago0 comments

Eh. I don't think that argument holds water, unfortunately. Too often I've seen the "it's just a beta/unstable version, it's not finished, you can't raise issues like this!" attitude as an issue to shut down any form of discussion, or worse, to avoid having to think about the consequences of some action.

Of course, nearly 100% of the times the behaviour people were complaining about will be part of the stable release. There is no magical moment where things just magically get sorted pre-release unless people voice feedback, especially if it's intended behaviour, as it's very much the case here. So call me jaded, when someone says "it's just the main branch, don't complain!" I just hear "I will do whatever I want and when the new release rolls in everyone will just have to deal with it." Which is totally fair if that's how you want to run your project, just don't pretend otherwise.

An extra one, which isn't the case here but makes me roll my eyes every times it happens is the outrage of "how dare you raise an issue that was caused by a new pre-release iOS/MacOS version and very much seems to be an intended change in the OS behaviour, we don't support that!!", only for it to turn into the usual scramble "oh no, our software is broken on the new iPhones, who could have forseen this!!?" hours after the release version starts hitting the masses.

0 comments

yaantc2y ago

There's a misunderstanding here: I'm not saying "don't complain". Complaining in itself is fine, and others are complaining on this topic in a way that looks OK to me (and will probably be more efficient too). It's the nature of this specific article complaint that I have a problem with.

I agree with @tarsius on this: just give the discussion (and patches) some more time, and it's likely to end just OK from past experience.

achikin2y ago

I wonder why wasn’t this patch given time before merging it? Isn’t that the whole purpose of patches and merge process?

uranusjr2y ago

Because merging into main better exposes the proposal to a more diverse crowd and attracts needed feedback. Especially when you’re managing multiple proposed features, it’s not viable for a mass of users to check out and test those from their individual branches. Without merging fast, you can only gather opinions from people actively reviewing patches, which are a far more minority group and likely to be biased.

tsimionescu2y ago

What kind of time? It spent around two months between the first proposal and being merged. Do you think that people would have trawled through the mailing lists and found this and given their reviews if only it had been given 1 more week?

Ultimately, the consequences of a patch, especially one that changes UX, can only really be evaluated after the community starts using it. People using the master branch of Emacs are basically those who wish to work as the QA engineers of Emacs. End-users use release branches or even pre-packaged releases from their distro.

So, the normal process for a UX change is to merge it to master in order to get comments on the impact. Based on comments, you can either revert, move behind a flag, etc.

j / k navigate · click thread line to collapse