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

GitHub Package Registry

github.com

Post reply on HN
Print view View original

361–370 of 389 posts

Re: GitHub Package Registry

#361

Post by GordonS »

your-nanny wrote: post #351
GordonS wrote: post #339

Earlier quoted context omitted.

Please have an alternative then!

If I post code to a GitHub, I'm happy for you to use it, and I'm happy to learn about bugs in the code. But what obligates me to facilitate support, or respond to support requests? People should grow up.

Plainly you're not obligated to, but if you want to actually grow the userbase it makes sense. If you really don't want to help with (reasonable) support requests, then an alternative is to make that abundantly clear in your README.

> People should grow up

Not sure what this childish quip adds to your otherwise sensible comment?

Re: GitHub Package Registry

#362

Post by chriswarbo »

soulofmischief wrote: post #276
akavel wrote: post #271

Earlier quoted context omitted.

There's a Git application on Scuttlebutt, already used by people in the community - see e.g.: https://github.com/noffle/git-ssb-intro

Your sister comment had another project to share based on IPFS: https://radicle.xyz/ One thing that seems clear is that there needs to be a standard interchangeable format for storing PRs and issues, so that it's not just the point of origin that's decentralized, but the data itself (in case the maintainers vanish). I'm not really sure how to go about that sort of thing either myself or as a community effort but I'd…

> One thing that seems clear is that there needs to be a standard interchangeable format for storing PRs and issues, so that it's not just the point of origin that's decentralized, but the data itself (in case the maintainers vanish).

I use Artemis for issue tracking, and that uses maildir (a widely supported standard). I compose issues with Emacs message-mode and render them to HTML using mhonarc.

Re: GitHub Package Registry

#363

Post by chriswarbo »

soulofmischief wrote: post #212
sho_hn wrote: post #127

Earlier quoted context omitted.

Yes, but that's not a new concern - to some, GitHub has always represented an anathema to what git was supposed to be and bring. Centralization at a proprietary vendor, instead of open systems interacting. Then locking people in further by network effect and adding centralized products around git. That it's become so popular many people equate GitHub with git adds insult to injury. I completely understand why this al…

I just wish a PR and issue tracking system with pluggable credentials had been simultaneously developed and implemented alongside git, so that I could migrate my issue and PR history, or plug them in to multiple hosts. I prefer Gitlab for a multitude of reasons but since all the action takes place on Github, my Gitlab account just serves as a repo mirror.

Git has always had integration with email, which makes it compatible with a vast amount of existing servers, clients, credential systems, Web UIs, scripting languages, etc.

As an example I think SourceHut is mostly based around email (which it provides a Web UI for) https://sourcehut.org

Re: GitHub Package Registry

#366

Post by carapace »

I think it's worth considering a different "angle" or emphasis on software releases.

This went by the other day: "Software Heritage and GNU Guix join forces to enable long term reproducibility" https://news.ycombinator.com/item?id=19699031

So that's an interesting "4 dimensional" way to think about your software packaging, eh? When does it make sense to "push" your code to the long-term archive?

And this: "The Great Adobe Purge of ’19" https://news.ycombinator.com/item?id=19863481 and https://news.ycombinator.com/item?id=19888429

Here the issue is apparently licensing.

Re: GitHub Package Registry

#367

Post by exabrial »

This is extraordinarily generous of github, but I don't think having a hundred maven repositories is a good idea. We have central and a process for putting signed artifacts there

Re: GitHub Package Registry

#368

Post by writepub »

diggan wrote: post #283

It's a really nice project overall, having a registry that supports many different projects and run by a company that today is good, is always nice. But we been here before. We trusted npm and now they are trying to squeeze out a profit, and it ruins it for the users. I'm happy to be proven wrong, but every for-profit company that runs a package registry, eventually stagnates, and ends up implementing things that are…

I'm unsure if this is willfully ignorant marketing, or naivety. Profitability is a GOOD thing -profit typically means people getting paid, livelihoods supported, lives built, etc. I hope NPM becomes profitable, to support the awesome team that builds useful tools for millions

It's noble that you are building a non-profit, neutral registry, but framing the contrarian view as evil, and pitching this as a sacred good vs evil fight is bad.

Maybe your value-add is that the registry works for the good of more than the parent funding org, and that in itself is valuable. However, not-for-profit is scary because you will refuse to go the extra mile for any one customer, even if they pay you money, and only prioritize whatever YOU deem fit and moral.

Re: GitHub Package Registry

#369

Post by soulofmischief »

toyg wrote: post #357
soulofmischief wrote: post #355

Earlier quoted context omitted.

> It looks the business but it lacks the single most important feature for popularity: a GUI. It's a matter of perspective. My first thought when reading the docs was, "All someone needs to do is slap a GUI on this baby. Good thing the designers made a simple CLI that it could interface with." They've already done most of the heavy lifting. At this point a GUI is trivial to add. "Terminal–first" doesn't imply "termin…

I agree that the GUI situation is a glass-half-full sort of thing, I'm just saying it needs that as a priority if they want any network effect. > The patch command [0] has a propose subcommand that describes what you're talking about. Yeah but in the tutorial it says it will fail to work if you are on a different branch from master - I took it to mean that the patch command can only target the same branch it was gene…

Hmm okay, I guess I'll just have to play around with it and see.

Re: GitHub Package Registry

#370

Post by OJFord »

user5994461 wrote: post #358
OJFord wrote: post #356

Earlier quoted context omitted.

I was assuming a global perspective, for which Google is obviously first. (And I quoted Wikipedia confirming that at a shade under 93% market share.)

Funny thing, you're describing exactly why you're not assuming a global perspective. Forget about a first, the world is fragmented. To be global is precisely to cater to individual locations around the world. If we are to believe these stats, Google is at 3% market share in China. It's basically non existent. http://gs.statcounter.com/search-engine-market-share/all/chi... Microsoft has developers everywhere in the wo…

Okay, so s/global/whatever you want me to say, for what you definitely know that I mean.
Post reply on HN