
StableLib – Stable Distribution of Go Packages - joshrotenberg
https://www.stablelib.com/
======
NateDad
I have three main concerns - one is that the original package authors get
credit... Right now it looks like you're obscuring that by totally replacing
the original import path with your own (leaving out the github username).

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.

~~~
nknighthb
Your concerns apply equally to software aggregations generally -- e.g. every
Linux distribution.

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

------
dchest
Hi, StableLib is my project. Happy to answer your questions!

~~~
dougbarrett
Is the purpose of this project just to guarantee that bug fixes will be
supported with projects? For example, I use martini, negroni, gorm and mgo on
a daily basis. If I switch to your repos, is it that there are no concerns
that the repo will ever disappear, or if there are critical bugs you will help
fix them if the project developer disappears?

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?

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

~~~
dougbarrett
Got it, and for the other part? I'm just wondering what makes this entirely
different from github assuming that the authors don't remove the project or
delete their account. I think I'm just unclear on what value you are adding
and for current projects why I would use your repositories over the actually
package developer.

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.

~~~
dchest
A perfectly maintained package would look like this:

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

If I'm having a production app running that uses these packages, I have to
track all of them, making sure I don't miss some critical bug fix. StableLib
will do this for you: just subscribe and you'll get notified of updates, and
you will receive backported fixes, so that you can update without worrying of
breaking our apps.

------
0xdeadbeefbabe
I still worry that devs who say, "oh crap we can't build because of this
library" are doing something wrong. I'm curious why I must depend on
complexities like this or godeps to write effective go either by myself or in
a team. Can't you just take a snapshot of the source including third party
libs and keep it somewhere safe?

Edit: stablelibs is an inviting idea if you believe you must vendor, and
plenty of people do believe that.

~~~
Zikes
I think vendoring is being officially promoted, with a concrete workflow/plan
in the works to be announced later.

~~~
dchest
Yes, here's a post by bradfitz [https://groups.google.com/d/msg/golang-
dev/nMWoEAG55v8/iJGgu...](https://groups.google.com/d/msg/golang-
dev/nMWoEAG55v8/iJGgur7W_SEJ)

------
wilsonfiifi
The first thing that came to mind was that this is similar to ActiveState's
PyPm [0] for Python but it seems this might be offering a bit more by way of
bug fixes etc... All in all seems like a great product/idea!

    
    
      [0] http://www.activestate.com/activepython/pypm-python-modules

~~~
dchest
Thank you! I new about ActiveState, but didn't know about PyPm.

------
sagichmal
I'm confused, is this a curated set of existing Go libraries, or a brand-new
set of libraries? If the former, how are they going to guarantee their "3
years of bug fixes"? If the latter, why should I trust them to produce higher-
quality code than the community has already?

~~~
nknighthb
> _I 'm confused, is this a curated set of existing Go libraries, or a brand-
> new set of libraries?_

Toward 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?

~~~
sagichmal
> 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?

~~~
nknighthb
All Linux distributions consist primarily of third-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.

------
ffk
Does anyone have any info on who is behind this? I can't find any details.

~~~
dchest
I'm behind this :-)

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](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](https://github.com/dchest).

StableLib is an effort to help businesses use third-party Go packages without
worry.

~~~
ffk
Fantastic, can you mention this on your page? :)

~~~
dchest
Yes, will do. It definitely needs a FAQ and more information about the team.

------
damian2000
The website isn't rendering properly for me .. lettering is borked across all
fonts - sort of when a bitmap has been resized without using anti-aliasing.
Using Firefox 37.0.1 on Win7.

~~~
dchest
Thank you, I will check with this configuration.

Edit: should be fixed now.

