Do not ship work in progress: An open letter • Hacker News Board

Re: Do not ship work in progress: An open letter

#31

Post by COGlory » Wed, Aug 17, 2022, 1:56 PM UTC

rob74 wrote: post #6

kop316 wrote: post #4

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=32494659 > 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 v…

So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

openSUSE Tumbleweed

Re: Do not ship work in progress: An open letter

#32

Post by ddevault » Wed, Aug 17, 2022, 1:57 PM UTC

WesolyKubeczek wrote: post #14

ddevault wrote: post #7

Earlier quoted context omitted.

Distributions like Manjaro should change their behavior and quit shipping unfinished patches.

What if the whole point is about shipping unfinished patches? But also this should mean that the buck stops with the distribution, not with the developers.

If the point of your product is shooting yourself in the face, you should find a different point. Not all ideas are worth pursuing.

Re: Do not ship work in progress: An open letter

#33

Post by srmrqaz » Wed, Aug 17, 2022, 1:59 PM UTC

rob74 wrote: post #6

kop316 wrote: post #4

For some additional context: https://blog.brixit.nl/why-i-left-pine64/ Comments: https://news.ycombinator.com/item?id=32494659 > 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 v…

So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

I always thought that the whole point of Manjaro was to be the "more stable" Arch linux, since it holds the rolling updates and releases them at once every month. Is that not right anymore?

Re: Do not ship work in progress: An open letter

#34

Post by rcxdude » Wed, Aug 17, 2022, 2:15 PM UTC

viraptor wrote: post #21

mannykannot wrote: post #17

Earlier quoted context omitted.

What is the use case for shipping unfinished patches?

Depends what you mean by unfinished. Does it work and need a style polish? Is the developer trying to debug some tests failing for reasons unrelated to the patch? Is the functionality still missing/broken? There can be lots of reasons why you'd want an unpolished patch rather than wait for a release. Especially with projects that release every few months rather than after each pr. Here's one example where I've done i…

Yeah, it's a balancing act, and it's best when the users and maintainers are on the same page: I don't like maintainers futzing about with packages to fit to arbitrary standards (debian can be quite bad here, and the general policy of 'as close to as vanilla as possible' is something I like about arch), but on the other hand it's much appreciated when packages come with fixes for bad upstream decisions (of which there are many examples), or even important features which upstream has sat on for years (see pulseaudio support for high-quality bluetooth codecs for an example which eventually led to the patch author rage-quitting the project because they strung him along for years). As a user I'm generally happiest when I get the software with the features I want without the bugs which cause me trouble, and it's situation dependent whether the packager or upstream are working against me on that. Usually the biggest source of friction is who actually winds up supporting the result: for all that distros may encourage filing bugs on their own tracker usually users wind up going to upstream for support, even if the issue is caused by the distro's patches. Some badly behaving maintainers (and it sounds like manjaro have been far too aggressive in trying to pull in new features) have I think caused a general pushback from upstream developers as they wind up with a bunch of support requests from someone else's screw-up (see for example home-assistant's attitude to anyone else distributing their software).

Re: Do not ship work in progress: An open letter

#35

Post by zdragnar » Wed, Aug 17, 2022, 2:24 PM UTC

srmrqaz wrote: post #33

rob74 wrote: post #6

Earlier quoted context omitted.

So distros like Manjaro should stop calling themselves "rolling release" distros and start calling themselves "nightly" distros, so everyone is aware of the potential instability? Is there any rolling release distro that already follows the suggestion of only distributing tagged releases?

I always thought that the whole point of Manjaro was to be the "more stable" Arch linux, since it holds the rolling updates and releases them at once every month. Is that not right anymore?

I've been using Manjaro for quite awhile and have yet to have an issue with a broken update. YMMV I guess.

Re: Do not ship work in progress: An open letter

#36

Post by kirbyfan64sos » Wed, Aug 17, 2022, 2:27 PM UTC

natch wrote: post #30

So if there’s a patch that fixes a devastating bug then distros should ship with the bug, got it. 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,…

The page literally addresses this:

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

Re: Do not ship work in progress: An open letter

#37

Post by jwildeboer » Wed, Aug 17, 2022, 2:33 PM UTC

Without concrete examples of good v bad behaviour it’s a lonely call in the void, IMHO. Without a clear commitment to solid versioning, where it is clear what is considered ready and stable v WIP it also doesn’t really help. Good will on all sides depends on understanding and communicating. This is a task for all.

Re: Do not ship work in progress: An open letter

#38

Post by mannykannot » Wed, Aug 17, 2022, 2:38 PM UTC

viraptor wrote: post #21

mannykannot wrote: post #17

Earlier quoted context omitted.

What is the use case for shipping unfinished patches?

Depends what you mean by unfinished. Does it work and need a style polish? Is the developer trying to debug some tests failing for reasons unrelated to the patch? Is the functionality still missing/broken? There can be lots of reasons why you'd want an unpolished patch rather than wait for a release. Especially with projects that release every few months rather than after each pr. Here's one example where I've done i…

If I understand your example, you are using your good judgement as a developer/maintainer to release a workaround that ideally would have been released as a bug fix by the maintainers of the root cause. This is not, however, the issue here, which is the judgement-free release of every work-in-progress as soon as it is made available to anyone, with the bag being foisted on the developers. If that solved your problem, and did so without introducing other problems, that would have been just a matter of luck.

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?

Re: Do not ship work in progress: An open letter

#39

Post by eastbound » Wed, Aug 17, 2022, 2:42 PM UTC

antonvs wrote: post #19

mittermayr wrote: post #3

Funny how I was instantly triggered as a SaaS maker by the title, ready to unroll in the comments and then quickly realized upon reading that I am not the audience here and the title does make a lot of sense for the intended audience :) Unexpected self-calibration completed. Nice.

Many startups wouldn't ever be able to get started under a restriction like that.

“If you’re not ashamed of your first version, you shipped too late.” Reid Hoffman

Re: Do not ship work in progress: An open letter

#40

Post by remram » Wed, Aug 17, 2022, 2:45 PM UTC

mittermayr wrote: post #3

Funny how I was instantly triggered as a SaaS maker by the title, ready to unroll in the comments and then quickly realized upon reading that I am not the audience here and the title does make a lot of sense for the intended audience :) Unexpected self-calibration completed. Nice.

To be honest this is a very click-baity title that doesn't have the context to make it a truth. A lot of us probably came here expecting something else, like you.

A better title would be "Do not ship someone else's work in progress"