> 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.
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.
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.
