Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Do not ship work in progress: An open letter

dont-ship.it

Post reply on HN
Print view View original

61–70 of 78 posts

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

#61

Post by pessimizer »

natch wrote: post #45
kirbyfan64sos wrote: post #36

Earlier quoted context omitted.

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

I wouldn’t say it addresses it so much as it acknowledges it as an issue without offering a workable solution.

What's a more workable solution for urgent patches than not including them in the request to "not ship work in progress."

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

#62

Post by purpleblue »

I worked with a "brilliant" product manager whose idea was to onboard several of our enterprise customers right after our first major deliverable, ie. midway through feature development. I vehemently pushed back, saying that it would be disruptive to our customers since the feature wasn't fully finished and it would slow us down, because we would need to change the order in which we would do development since customers expect a certain level of quality. I also said that any timelines after customers were onboarded were at risk, because if things were buggy, which they probably were since the feature wasn't finished yet, it would mean we would have to jump on them since they were our biggest customers.

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.

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

#63

Post by pessimizer »

O__________O wrote: post #13

Title is click-bait, it’s about a very, very narrow subset of the topic — that is Linux patches.

If an article in Stamp Collectors Weekly has the headline "The Market is Getting Irrational," is it clickbait for that article to be about the stamp market?

It's weird to call someone's site about Linux patches clickbait because it's not about shipping half-finished furniture.

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

#64

Post by systemvoltage »

eastbound wrote: post #39
antonvs wrote: post #19

Earlier quoted context omitted.

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

This is bullshit.

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.

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

#65

Post by TeeMassive »

pledess wrote: post #55

Although "not ship work in progress" has many advantages, it interferes with "staying very close to HEAD of our dependencies" as discussed in the https://aboodman.medium.com/in-march-2011-i-drafted-an-artic... post. In other words, if your code is being consumed by another project that has extremely good test coverage, and your HEAD changes, then they can manage the risk of proceeding - even if they have no a priori…

Solution seems to be features toggles, but then that means you have a somewhat complete product to begin with; and it being mature enough to support feature toggles.

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

#66

Post by hedora »

remram wrote: post #51

I wonder if this could be solved with license terms. Popular, OSI-approved licenses include clauses like "Neither the name of the 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…

I think you could just assert that unmerged PR's have the following license:

"All Rights Reserved"

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

#67

Post by O__________O »

pessimizer wrote: post #63
O__________O wrote: post #13

Title is click-bait, it’s about a very, very narrow subset of the topic — that is Linux patches.

If an article in Stamp Collectors Weekly has the headline "The Market is Getting Irrational," is it clickbait for that article to be about the stamp market? It's weird to call someone's site about Linux patches clickbait because it's not about shipping half-finished furniture.

To me anything that intentionally misleads or overly generalize a topic which might be clearly and specifically addressed is click-bait by definition.

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.

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

#68

Post by zzo38computer »

It is sensible; it is better to ship released versions in the package manager, instead of unreleased versions, at least by default. (If the package manager does not have the capability to distinguish in this way, then a user who wishes to use unreleased versions could compile it by themself instead.)

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

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

#69

Post by remram »

hedora wrote: post #66
remram wrote: post #51

I wonder if this could be solved with license terms. Popular, OSI-approved licenses include clauses like "Neither the name of the 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…

I think you could just assert that unmerged PR's have the following license: "All Rights Reserved"

This won't work with most licenses, if you don't own copyright over the totality of trunk. The PR is definitely a derivative of the trunk...

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

#70

Post by worthless-trash »

kop316 wrote: post #16
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?

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

I believe the term is 'cowboy' distros.
Post reply on HN