Unless anyone objects, I'm happy to act as a facilitator for this discussion, and draft up a proposal for consensus based on the discussions that we have here. If anyone else wants to take up that role, feel free to nominate yourself as well.

I think, if anything, there should be at least one other pair of eyes looking at changes before they get merged.

As far as putting together proposals and whatnot, I've definitely got no qualms with you being the facilitator/drafting a proposal ^w^

How do we structure/organize commits within our patchset?
What merge strategies do we use when merging pull requests?

i moved treehouse from merge to rebase (via a painful manual process) because the merge was gnarly

What is our relationship to upstream?
What versions do we base on?
How often do we update?
How do we contribute our changes back to upstream?

the most successful mastodon fork, glitch, is manually updated against mainline with very high frequency.

in my experience as a glitch downstream, there's:
- changes that affect the files that you're patching
- free rebases
- security updates

if treehouse were directly branched off of vanilla, i'd honestly consider "any tagged version" rebase policy, with an expectation of "bite the bullet asap" or potentially even "intermediate rebases"

as for versioning: definitely do something like gts v0.12.3-rc4.wl.5. from painful experience, your version number needs to strictly comply with semver. unfortunately, people parse your version numbers using semver-validating libraries. you will get breakage reports otherwise.

@kouhai Agreed on the rebase point - merge commits get real hairy real fast when we're regularly reapplying ontop of upstream.

On the versioning end, who do you anticipate to be parsing our version numbers? I don't have much of an objection to complying with semver, but I'm wondering what issues not going with semver might cause.

@srxl clients will parse version numbers for… reasons. also, other instances, maybe.

and this will cause hard-break in at least one (misbehaving) client. there's a treehouse bug somewhere for this.

more practically, we want our version number to be distinct from upstream's, which means we ideally have to consistently use a prerelease label, and unfortunately there's not really a great way to handle downstream distributions if you don't have access to the prerelease fields

so maybe it ends up being v0.12.3+wl.v5.abcdef0123456789deadbeef

this is very bikeshed, though

http://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html

Discovered this today

When it comes to the structure of the patchset, the overall vision I have is "1 commit = 1 PR to upstream". My take is that this makes upstreaming changes really easy, since we just need to cherry-pick one commit onto upstream HEAD, resolve any conflicts there once, and that's a PR ready to go. This would necessarily inform a few things on the workflow:

• Merging PRs is always done with a squash and fast-forward. No merge commits - every PR is one commit added right on top of our patched stable.
  • Commits should ideally avoid depending on each other - sometimes this is unavoidable though. Some way to track which commits depend on others might be useful, so we can tell if something is ready to upstream. Taking suggestions here
• Each PR should be one upstreamable feature. This encourages us to ensure our patchsets are well tested, well written, and in a condition where they'd likely be good to go upstream - all things we want in our software
• Bumping to a new stable release should just be a matter of git checkout patch-stable; git rebase upstream/tagged-version, and resolving any conflicts there. Maybe that's a job for a nominated release manager or something?

@ruby sounds fine to me

@ruby this mostly makes sense; this is roughly what we've been doing anyway, at least for patch: commits. I've been labelling commits that aren't meant to be upstreamed as ci: for all the changes to get builds / related working.

WRT. one-commit-one-change: I think if we have larger patches in the future, fitting it all into one commit might be too much (but maybe thats a sign it should be split up anyway. :shrug:).

Definitely agree with no merge commits. That makes rebases easier and the end history cleaner.

I'd be fine with taking the release manager position and wrangling out rebasing stuff.

Our patch versions have so far been UPSTREAM-wl# with our RCs as `UPSTREAM-wl#rc#.

The -wl# suffix does bump versions as we expect but -wl#rc# sorts above non-rc. If we add a tilda (-wl#~rc#), that sorts correctly as tilda suffix sorts lower than no suffix (following systemd's version format spec and DEB and RPM package specs). This isn't strictly semver-compatible, but semver doesn't account for multiple suffixes in the version string like this.