StableLib – Stable Distribution of Go Packages
stablelib.com
stablelib.com
Second is that I worry that bugs won't get filled against the original repos for people using your version.
Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with. And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
Import paths are not the appropriate method of providing "credit". That's the sort of thing that is handled by copyright notices, documentation, and metadata.
It's generally preferred that if you're using a software distribution, you either test bugs against a "pure" upstream version before reporting them, or report them to the maintainers of the distribution, who can triage and, when appropriate, forward bug reports upstream (possibly with patches).
They get credit in README (the upstream path is there), on the website description of package, and, of course, their LICENSE, AUTHORS, CONTRIBUTORS files are all there. We do not want to take any credit from them.
Second is that I worry that bugs won't get filled against the original repos for people using your version.
We'll do it for them! When a StableLib subscriber reports a bug to us, after confirming it, we will file the bug upstream (possibly even a pull request fixing it), and: a) if the bug is critical or security related, and the patch is available — it gets applied to StableLib immediately, b) if the bug is minor or we couldn't figure out how to fix it ourselves, we wait until the upstream fixes it, and backport the fix to our version.
In fact, we will recommend ourselves as the first point of contact in case of a bug instead of upstream, and do all the upstream bug reporting/relations ourselves. This way upstream package authors won't be bothered if the bug report is invalid, or if the bug doesn't apply to their version.
Finally, I'd be worried about your version of packages drifting away from the original due to change in one or the other that the other party doesn't agree with.
I'd prefer to keep the package as close to the original as possible — it's in our best interest, as merges/backports are easier if it's so. In any debate, the author always wins (if their view won't damage security of package).
And then as a package author, it reflects badly on my project if your version of my library breaks, even if it's not my fault.
That's why StableLib subscribers would first report bug to us.
Thank you for your great points! This will help us with creating a FAQ.
I think the issue I can't get my head wrapped around is, at what point does your service become relevant? What happens if one of the libraries updates something in the original repo or adds a new feature, is that a dot release for you?
Details about versioning are still in development, but here's the rough idea:
If it's a small reviewable feature that can be applied without breaking anything, then yes, it will probably go into a dot release of the package.
For example, you use "github.com/dchest/siphash" package. In StableLib it's version v1.0.0 (vX.Y.Z), available via "stablelib.com/v1/crypto/siphash". Notice v1 in import path — this is the major version of the whole StableLib release (X). All version within v1.Y.Z are guaranteed to have the same API, so you can upgrade v1.0.0 to v1.0.1 or v1.1.0 and your application won't break. Now, if dchest/siphash fixes a bug, it will be releases as v1.0.1 in StableLib. If it introduces a new feature, which doesn't break API, say, additional function to calculate 128-bit hash, it will be v1.1.0 in StableLib. In general, you will be on the latest release within the major StableLib release.
Sometime in the far feature we will release StableLib v2, which will break API, and will be available at stablelib.com/v2/..., so your v1 packages will still work.
I'm happy to hear any suggestions.
I'm genuinely interested in this as a service, as I have ran into issues where packaged have API breaking changes that I'm not aware of until we pull code on the production server when we're ready to launch, but I'm just not sure if I'm clear on the intentions.
- uses proper stable versioning (e.g. gopkg.in), making sure not to introduce breaking changes in the same major version
- backports critical/security fixes into previous stable versions
- has their code reviewed by a third party
- provides notifications for critical fixes/security advisories
- provides support for package users
Not all packages are perfectly maintained, though (even my personal packages are not). Consider this sample of third-party packages from one of my project:
github.com/boltdb/bolt
github.com/dchest/cache
github.com/dchest/conf
github.com/dchest/validator
github.com/hashicorp/logutils
github.com/justinas/nosurf
github.com/stretchr/graceful
github.com/stretchr/pat/stop
golang.org/x/crypto/bcrypt
golang.org/x/crypto/blowfish
golang.org/x/net/netutil
Why say that? Are the bits rotting? Does your build process involve deleting dependencies? Is your disk lossy?
If this can fix that by checking to see if there are breaking changes and place them on a different major branch, that would be a nice feature.
I realize my build process could be better, and when I believe go 1.5 comes out I can compile native binaries on my dev machine to be deployed, but it was a pain nonetheless.
Maintaining a stable set of libraries for a complex project is incredibly time consuming. I would imagine many organizations would be interested in this, much like they purchase RHEL.
Do you have a provisional list of packages you're planning to include?
How will you make money, or is this a labour of love?
One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language.
Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it?
Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time? EDIT - oh I see you do suggest you might do this on your page lower down.
Are you planning managing patches/bug fixes yourself for packages which fall into disuse?
I do, but it's currently not published yet.
How will you make money, or is this a labour of love?
Red Hat-like subscription model. I will provide support, security advisories, etc.
One of the main benefits here is actually that someone has gone through publicly available packages and vetted them for code quality - that might be one of your bigger selling points, even above stability (which is relatively easy to achieve with vendoring). This could potentially be a sort of 'standard stack' for go for corps who want to try out the language.
Indeed.
Do you have permission from the package authors for this? I realise you don't need it, but it might be nice to involve them in some way, or even make sure it benefits them in some small way if you make money from it?
I didn't ask for permission, but I agree with you about involvement. The ultimate goal is to hire/sponsor as many package authors as possible :-)
BTW, after doing code reviews of some packages, I already submitted a few pull requests to them, so even thought right now there are no financial contributions to package authors, there are some benefits for being included in StableLib :-)
Perhaps you could even act as a broker between corporations who want features/fixes and package writers who want to get paid for their time?
This is a great idea, thank you!
Are you planning managing patches/bug fixes yourself for packages which fall into disuse?
Yes.
Edit: stablelibs is an inviting idea if you believe you must vendor, and plenty of people do believe that.
That's what vendoring is for — freezing your dependency on some version. What StableLib provides is a guarantee that the API of package remains stable, but also that all the latest major/security bugs are always fixed (by backporting them). Also, that you're always notified about any critical/security fixes. Of course, you can also do vendoring with StableLib-provided packages, and we plan to make it easy via the command-line tool.
[0] http://www.activestate.com/activepython/pypm-python-modulesToward the bottom of the page they talk about contributing back to open source projects and sponsoring the development of some packages, so it certainly appears to be a curated set of existing Go libraries.
> If the former, how are they going to guarantee their "3 years of bug fixes"?
Red Hat provides 10+ years on the code they ship. What's so shocking about 3?
Does Red Hat ship (and maintain) arbitrary 3rd party code?
I don't know what you mean by "arbitrary", though. It makes no sense in context, and is notably at odds with your earlier use of the word "curated". Nobody ships random code. That wouldn't be curated, nor would it be useful.
I've been using Go since its public release (I think I wrote the first public Go project — https://news.ycombinator.com/item?id=938046 :-). I also contributed to Go, mostly /x/crypto stuff such as scrypt and salsa, and wrote lots of open source packages — https://github.com/dchest.
StableLib is an effort to help businesses use third-party Go packages without worry.
Edit: should be fixed now.