[HN Gopher] Sync for Thunderbird
___________________________________________________________________
Sync for Thunderbird
Author : mariuz
Score : 27 points
Date : 2022-03-20 17:49 UTC (5 hours ago)
(HTM) web link (bugzilla.mozilla.org)
(TXT) w3m dump (bugzilla.mozilla.org)
| nine_k wrote:
| The scoop: An issue opened 14 years ago with a patch that solves
| it.
|
| Never merged. The issue is kept alive by people wanting the
| feature.
| technobabbler wrote:
| Thank you for the explanation.
|
| Submissions like this are when I wish HN didn't have the
| "original title" policy. It doesn't give you any context about
| a link and why someone should care about it.
| majkinetor wrote:
| Nothing stops OP to comment it.
| jcranmer wrote:
| One of the chief issues preventing the merge at that time was
| that it was the era of maximum hostility of the Mozilla
| community to anything not named Firefox. Adding any code to
| support Thunderbird in the core codebase would have been at the
| mercy as to whether that module owner was nice or not.
| tomrod wrote:
| This brings up an interesting point. It is my opinion that
| we're in the reverse now. Mozilla seems deadset on ruining
| Firefox's competitive advantages -- some through reasonable
| evolution (forcing new features on the community that only a
| small subset ask for) to user hostility (Firefox mobile
| redesign that dropped summer 2021, tanking its Android
| reviews after it dropped extension support [and for me, text
| scaling managed via about:config killed accessibility]).
|
| While I can appreciate that there is funding to be found in
| password managers and VPN services, I'd much rather see Rust
| take over the world!
| pigeons wrote:
| They've dropped that password manager "Lockwise" faster
| than a google product.
| toyg wrote:
| Rust taking over the world would bring Mozilla the same
| sort of income that "Java taking over the world" brought
| SUN. It's fundamentally irrelevant, in the great scheme of
| things, because monetising a programming language has
| always been very hard (and now all competitors are free,
| they've effectively been commoditised).
|
| I don't think they're "ruining" FF; if anything they're
| again entirely focused on it after a decade spent in the
| wilderness throwing money at doomed efforts. But they seem
| somewhat lost on their actual mission, and make it very
| hard to like them. Mozilla is not about making a browser,
| nor it is a social-justice charity. It should be a beacon
| of public interest in the darkness of everyday
| commercialisation of the web. The browser should be a mean
| to that end, not the be-all of the company.
| charcircuit wrote:
| >if anything they're again entirely focused on it after a
| decade spent in the wilderness throwing money at doomed
| efforts
|
| But what features have they really added lately? I looked
| over the the change logs over the last year and the only
| notable new features to the browser was a theme color
| wheel and adding search results (Ctrl + F) showing up on
| the scroll bar. It doesn't seem like they are innovating
| the browsing experience.
| kevingadd wrote:
| It sounds like within a year or so the underlying system was
| refactored enough that the patch couldn't be landed as-is,
| which makes sense. It's big enough that I can also imagine it
| being hard to get a review if only 1-2 people know the system
| well enough and don't find the time to review it... still quite
| unfortunate.
|
| I run into this sort of situation with OSS a lot lately, for
| one PR I spent probably at least a dozen days total of my time
| just rebasing it over and over because a project with hundreds
| of contributors lands lots of commits every day.
| throwaway984393 wrote:
| I don't know your PR, but the way this is helped in
| corporate-land is with very small PRs and feature flags. Some
| maintainers are a lot more of a pain in the ass than others,
| though.
| yjftsjthsd-h wrote:
| This is great when it works, but I'm personally not
| convinced that it works for every change. Some things are
| genuinely just big changes, and doing them piecemeal is
| (IMO) actually impractical. Granted, this is more likely to
| be true with refactoring then features or bugfixes.
|
| All of which is not to say that it's not a preferred style
| when it does work. And as a _policy_ choice it is perfectly
| reasonable to simply decree that the codebase will never be
| refactored at that scale.
| LadyCailin wrote:
| Another alternative is to have code freezes, though that
| comes with its own sets of cons. But you just need them
| to be long enough to do the last rebase and merge, so in
| theory can be relatively short.
___________________________________________________________________
(page generated 2022-03-20 23:01 UTC)