Any consideration for merging back a fork with more frequent/recent contribution?

[drawks]

After a few years of having not really watched this project I've recently found a place for it again in my architecture. Yet I've found that this, main project, lags considerably behind several of it's child forks

https://github.com/lyft/statsite and https://github.com/twitter-forks/statsite in particular seems to be the REAL head of development including higher quality packaging/release efforts, bugfixes, new features, modern build infra, and frequent (and usable) releases.

Reading back through the issues of this project in #217 when the decision was made by @armon to move to an organization at least some of the motivation seemed to be to allow room for reintegrating back some of these changes from these forks.

IMHO it would be a great move to cut a nice stable back compat release from the current 0.8.x codebase here and then do a real barn raising around merging broad swaths of breaking changes from the twitter-forks/theatrus/lyft forks and release at 0.9.x with those improvements.

[armon]

@drawks I'm very supportive of this approach! The goal of the organization was to remove me as the bottleneck and let us bring the fork features upstream

[theatrus]

Happy to try to back-port or merge in changes from my long-lived multi-company source tree :)

[drawks]

Having been mostly a back seat observer to these types of efforts in the past I'd say the OOO should be something like:

1. tag and cut a new "final" 0.8.x release
2. create a 0.8.x maint branch for future bug fix releases for a reasonable period of support
3. create a development branch to avoid making master a moving target while accepting breaking changes
4. solicit PRs against development for some reasonable window of time until feature parity for major breaking changes from quality forks is achieved.
5. merge dev -> master
6. tag and cut first 0.9.x release from master
7. have a drink

does that sound about right?

[drawks]

I suppose there is some meta-work which is outstanding as well.

• Document contribution guidelines in CONTRIBUTING.md
• Document (and hopefully automate) the release process, AFAICT only @armon has ever cut a release

[johnkeates]

I was planning on releasing a 0.8.1 with better debian packaging, corrected build setup, making sure no version number mismatches happen and a cleaner dist target in make so the resulting tarball is bootstrapped already. I wasn't aware of the multitude of actively maintained forks (I knew there were a few, but didn't know about the progress), but we should definitely shape up and get at least release management and contributing guidelines on the way. Some more example configurations and better docs would probably help a lot of people as well.

A quick look around the current active forks shows there are a ton of different changes, some of which are incompatible. One goal (at least for me) would be to also have a 'stable' release that is actually added to downstream archives, like for example, Debian's repository, but possibly an official PPA and a Fedora COPR as well. With travis' build matrix support, we could test against multiple Linux targets fairly easily, making for less breakage (which right now is happening sometimes).

[drawks]

A quick look around the current active forks shows there are a ton of different changes, some of which are incompatible.

Well, in my plan above I did say 0.9.x and breaking which is a semver nono (my bad). The real goal here is to find changes worth adopting. And determining if there is a way to adopt them in a backwards compatible way. For example: One of the largest changes is support for multiple sinks, is there a way to implement multi sink support such that existing configs work without modification? If so, that would vote for going to 0.9.x, if not then the value of the change should be weighed against API breakage and we would go to 1.0.x AND once we've breached that MAJOR release threshold the gloves are off for evaluating breaking changes for inclusion at that major.

If we only go to 0.9.x then your desire to be stable upstream for distribution is already satisfied;
if we cut the first 1.0.x, then that would become a new stable release AND by moving to a maint branch for 0.8.x we'd have an "old-stable" to still offer.

This isn't new territory as far as how to manage software. Being a stable upstream source doesn't mean you support the same API forever.

[sleepybishop]

@theatrus , would you be able to outline the features from the lyft and twitter forks that are good candidates for merging upstream? that would help in creating a roadmap for this initiative.