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

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

#21

Post by viraptor » Wed, Aug 17, 2022, 1:41 PM UTC

mannykannot wrote: post #17

WesolyKubeczek wrote: post #14

Earlier quoted context omitted.

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.

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

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

#22

Post by dspillett » Wed, Aug 17, 2022, 1:42 PM UTC

mannykannot wrote: post #17

WesolyKubeczek wrote: post #14

Earlier quoted context omitted.

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.

What is the use case for shipping unfinished patches?

> What is the use case for shipping unfinished patches?

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.

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

#23

Post by simiones » Wed, Aug 17, 2022, 1:42 PM UTC

WesolyKubeczek wrote: post #15

But then again, free and open source licenses enable everyone to do any modifications for any purpose whatsoever. That's the whole point. I would like it if the developers quit being patronizing towards people exercising their rights under those licenses. Yes, don't ship it, don't theme my app. We all heard you. Some people choose to not care, and that's okay. Those same licenses also disclaim any warranty, so the bu…

The problem is something like this: you develop packageA. A user of distroB is installing pacakgeA from distroB latest, and packageA is not working for them. distroB maintainers tell them to go ask packageA about the bug. So, the user comes and bothers packageA about this issue - even though packageA had no intention of distributing this in-progress version to users.

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?

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

#24

Post by MartijnBraam » Wed, Aug 17, 2022, 1:42 PM UTC

Spivak wrote: post #18

kop316 wrote: post #16

Earlier quoted context omitted.

> start calling themselves "nightly" distros 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.

Which, to be fair, is pretty much what all upstream developers have been asking for for years and years because getting bug reports for 50 different builds of 15 different versions of your software all with different disto provided patches is exhausting. The software that actually has good release hygiene pales into comparison to the software that is actually more stable by just pulling from main.

It is generally not a problem, distributions are doing absolutely great things and I like working with distributions a lot more than dealing with something like flatpak.

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.

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

#25

Post by jstanley » Wed, Aug 17, 2022, 1:44 PM UTC

> In short: when a project is being actively developed, tagged releases are the only safe option to ship to users.

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?

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

#26

Post by MartijnBraam » Wed, Aug 17, 2022, 1:45 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…

In the case of manjaro which triggered this post, it's not that manjaro is fixing things. It's manjaro trying their absolute hardest to ship new features faster than the rest, even when those features are completely broken.

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.

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

#27

Post by dspillett » Wed, Aug 17, 2022, 1:46 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.

> What if the whole point is about shipping unfinished patches?

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

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

#28

Post by selfhoster11 » Wed, Aug 17, 2022, 1:48 PM UTC

blueflow wrote: post #2

Would it fix the problem to develop with a more restrictive license, and only license the releases with a more permissive license?

Why would it fix the problem? That's besides the fact that this would complicate the legal situation of the project, including that of contributions.

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

#29

Post by MartijnBraam » Wed, Aug 17, 2022, 1:54 PM UTC

jstanley wrote: post #25

> In short: when a project is being actively developed, tagged releases are the only safe option to ship to users. 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?

That wouldn't help because they're not picking master to ship, they're picking mailing list patches and unmerged or rejected Gitlab merge requests directly.

If only they would ship master, that's at least somewhat sane.

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

#30

Post by natch » Wed, Aug 17, 2022, 1:55 PM UTC

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, or months between releases.

Which is probably hundreds of unanswered emails. Mmmkay.