Do not ship work in progress: An open letter(dont-ship.it) |
Do not ship work in progress: An open letter(dont-ship.it) |
> Supporting Manjaro has historically done very little to facilitate the development of the software stack which is necessary for these devices [Pinephone/Pinephone Pro] to work. In some cases the Manjaro involvement actually causes extra workload for the developers by shipping known broken versions of software and pointing to the developers for support. Which is why https://dont-ship.it/ was started.
Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?
https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.htm...
It's not a "nightly" distro, it's a "let's take patches that are unfinished, release them into the wild onto unsuspecting users, and let the upstream developers deal with it" distro.
Void Linux
These all fell on deaf ears because they thought it would be important to get early feedback from our customers. I told them we could demo it, but we shouldn't onboard them. Again, they refused to listen.
Things ended up being exactly as you expected, and I quit the job so that I didn't have to deal with this PM any more.
FWIW, I recognize it's fun to target PMs for ignoring technical constraints & carrying water for marketing... but for many PMs (in USA at least), they roll up to Marketing dept, rather than Eng.
So while it can seem PMs are (willfully?) technically Invincibly ignorant by default, their bosses are worse.
The best way to 'manage' your PM is help them build the biz case for your position. Eg "reduce risk of $XX loss" from bugs, opty costs, network effects of customer losing faith in your product. Plus I've found the "walk before you can run" argument works: they want to expand customer excitement by showing bright/shiny/new things. Promise them an even faster cadence of new things, after they give you time to get the fundamentals deployed.
Unexpected self-calibration completed. Nice.
A better title would be "Do not ship someone else's work in progress"
I wonder why publishers don't realize people expect the product to be done when you remove "beta" from its name.
Or reach out to the developer who does not respond to email (who is likely also not a signer of this open letter and who may or may not agree with it).
Multiply this (futile) reach-out step times however many developers are involved in touching any code of any project being shipped during any if the multiple days, weeks, or months between releases.
Which is probably hundreds of unanswered emails. Mmmkay.
> We thank all the distribution package maintainers for backporting patches that improve security, fix bugs, etc. who coordinate with upstream. Often times this means creating or pulling patches to fix issues with inactive/abandoned/unresponsive upstream projects. These distribution package maintainers are doing a tremendous job and their work is not the subject of this letter.
> This letter wants to address the cases where actively-developed features, huge changes, etc. of active upstream projects are being included without the knowledge of the project maintainers or end users.
Unfortunately, some projects do not have any tagged releases (or, at least, doesn't have any yet), and might still be stable. I intend to add tagged releases to my "Free Hero Mesh" project eventually, in order to avoid this problem, that you can clearly have a released and tagged, with version numbers.
A distribution may need to patch bugs or other things in the software, to work with the distribution. This is OK, but they should probably mark this in some way, such as a nonstandard version number (e.g. "1.5.2.debian.1") or a different name. Possibly such nonstandard version numbers should also be included in the software itself if it has the capability to display its own version number, and not limited to the package manager. Sometimes there is a separate list of patches applied than the version number; this might also be usable (instead of or in addition to the version number).
Not always. https://github.com/clementine-player/Clementine is a great software, being developed but for some reason without release since 2016.
Last release does not work anymore, shipping master branch works.
Just because some project without a proper release cycle does it doesn't make this statement any less true.
Those same licenses also disclaim any warranty, so the buck stops with whomever applies random patches and takes money for it. In this case, the phone manufacturer shipping OS images. The phone manufacturer can duke it out with Manjaro, of course, and Manjaro folks can tell them to go pound sand and use Debian stable. This is well before upstream should even notice a shadow of kerfuffle happening.
The developers have come up with a multitude of ideas on how to be passive aggressive towards anyone either trying to contribute or submit an issue, stalebot and radio silence being only two of them, so I'm wondering why they just won't apply those techniques this time.
Popular, OSI-approved licenses include clauses like "Neither the name of the <copyright holder> nor the names of its contributors may be used to endorse or promote products derived from this software" (BSD) or restrictions on the use of the original name (see Firefox/Iceweasel drama).
If you put in a clause like "You may not keep the software's name or support URL unless distributing an officially-released version", perhaps it would still be open-source as per OSI, and address those distribution issues? It's easy enough for distributors to patch in their own support mailing-list...
Indeed, most patches I see in off-beat systems like nixpkgs, homebrew, etc, are not plucked from preexisting pull requests, but rather are fixes developed by the person who did the packaging and submitted upstream, then included as a patch until the first tagged release that has them merged.
But it would probably create even more legal issues and also risks. A lot of people don’t use software, that has a non-standard way of licensing (like MIT, BSD, Apache, GPL). Just because there is a risk that you step into a legal trap.
In a roundabout way it's pretty much trying to re-invent the trademark system (ie. "don't distribute this code and call it MyProject without it being an authorised release"). Quite frankly far easier to just get a trademark if that's the desired effect.
It's weird to call someone's site about Linux patches clickbait because it's not about shipping half-finished furniture.
Author does not even mention that the post is specifically related to Pine64’s dependency on the Manjaro distro; a dependency that they not only self selected, but are funding. If they have such a major issue, solution is obvious, either change distros or fork it and only allow patches they are happy with into their ecosystem; not post a petition, of which so far only 16 people have signed since it was posted in June. Also, worth noting that Pine64 originally was built on Ubuntu, which has long-term releases, which is basically what author is asking for.
If this is such a problem that people need to be warned about it, why not just keep development on branches and make sure master is always stable?
If only they would ship master, that's at least somewhat sane.
Now, of course, no one here is doing anything illegal. But, everything would be better for everyone if distroB, instead of taking packageA@master had taken packageA@1.0.1 or whatever the latest release is: better working software for distroB users, less support work (bug triage etc) for distroB, less work for packageA maintainers.
Since this is ultimately a social issue, I think an open letter seeking to convince the people involved to think about it and modify their behavior is the best way of going about improving this for everyone. Now, it may well be that the maintainers of distroB have valid reasons not to change their behavior and ignore this letter: all fine. Not saying we should tar and feather them, in any way shape or form. But if this is maybe a fixable problem, why not try to fix it?
Also, why should it “bother” anyone at all. You duke it out with whoever brought it to you.
It’s only a problem if you feel a need to please everyone knocking on your doors, which inevitably turns into burnout and you actually behaving harshly towards everyone in the end.
Trademarks cost serious upfront money - Germany alone is 290€ [1], EU-wide 850€ [2], the US 250$ [3] and worldwide is a hot mess [4]. Additionally, it seems like you need a lawyer in the US to handle the process if you're not an US resident, and you have to renew them every couple of years and not forget to tell the patent/trademark office of address changes. Not everyone is willing to put up that much money and effort for an open-source project that won't generate any income.
Additionally, trademarks usually force the holder to publicly register their name and address, which is simply not a good idea at all for many persons - trolls, spammers and outright criminals can and will use every bit of information they get to cause harm. And for collectives that run an open-source project, trademarks will be yet another issue - what to do when the holder of the trademark dies or disappears, or when they get into some sort of conflict?
[1] https://www.dpma.de/marken/
[2] https://euipo.europa.eu/ohimportal/en/fees-and-payments
[3] https://www.uspto.gov/trademarks/basics/how-much-does-it-cos...
Software licenses need to work in a lot of different legislations, and it’s really hard to make a license that means the same thing in all countries.
There is a big difference between:
1) Shipping low features but high quality SaaS aap: OK
2) Shipping low quality services with lots of features that are buggy: NOT OK
From a customer standpoint, I reject half-baked SaaS services that reek with lack of quality control. If you are ashamed of your first version because of bugs, stop and fix those. If you're ashamed of how minimal your first app is? That's fine. Make sure those features are high quality and work as intended.
The real world is a lot more complicated. As Rumsfeld put it, "You go to war with the army you have, not the army you might want or wish to have at a later time."
A startup might have a product with a promising and unique core feature, but still have many other features that are buggy. It's common for startups to be overambitious, and that often manifests as buggy features.
Startups like this will often have a high churn rate with early customers and trials. But that changes over time as they get experience with which features and which issues matter.
If you want to kill a new business quickly, "stop and fix" the bugs in your first version. The problem is, your first version may very well not be the one with the best product/market fit, and you just wasted your precious investment money, time, and resources fixing bugs that ultimately won't matter.
The software that actually has good release hygiene pales into comparison to the software that is actually more stable by just pulling from main.
Of course this is a very one sided view. I've been on the receiving end of reckless upstream projects far too often not to understand why distributions which are expected to maintain compatibility with releases for years dislike a fast moving upstream for anything too important.
Manjaro Linux is accused of something different far less justifiable: forking upstream projects in all but name by shipping heavily patched packages without supporting them and even worse putting the support burden and blame on the upstream projects when things break (and oh boy do they break).
It's just that some distributions make a huge mess of it, don't want to work with developers and actively push off all the work to the developers for patches that have not even shipped, not even been merged or most painfully: not even been reviewed yet.
Then don't do 15 different versions of your software. I ask again: Why do i need GTK1, 2, 3 and 4 on my system ? Why KDE 5 is not compatible with KDE4 ?
But also this should mean that the buck stops with the distribution, not with the developers.
Then make absolutely sure your users all realise this, and that they should come to you for support not the devs (unless they themselves are devs, have read the relevant documentation, all of it, and able to offer useful help with the matter).
> But also this should mean that the buck stops with the distribution, not with the developers.
The clarifying points further down the article, that is the thrust. The basic rule for releasing WiP code being “don’t” and the advanced rule being “don’t, unless you really know what you are doing and can support it yourself”.
Here's one example where I've done it: https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c... since new rust has already been merged and rbspy still has no release with the required patch, there are two options: a broken package or an unreleased patch.
It's a cost/benefit calculation for the maintainers.
I think the issue isn't an individual patch that hasn't been completed, such patches are unlikely to be checked-in anywhere.
It is patches that are part of unfinished work, or that have not been integration tested with the rest of the product, or are not stable/useful/safe without other work that has not yet been merged. Basically patches intended fr other project devs, not the general userbase yet.
But to answer the question directly, in case it is literally unfinished patches:
> What is the use case for shipping unfinished patches?
“Being the latest & greatest” willy waving in end-user aimed distributions.
I can see a use case for some dev communities, though mainly for proactive compatibility testing purposes, not for dev or non-test deployment environments.
Like the fun example of manjaro shipping a merge request of the SMS/chat application on the PinePhone that causes a database upgrade that can't be rolled back. This code was not intended to be merged, even less shipped.
I'm guessing that what you did fits within the article's guidelines so long as you could do it as a tagged release.
I understand the desire to get an early warning of breaking changes coming from elsewhere, but surely scraping together all work-in-progress is likely to raise a lot of false concerns?