My enthusiasm got away with me and I've already started a 8.x branch in the repo. Sorry!

Mostly it's converting entries in the routing system. I've already gotten parts of the module to work, despite the unstable APIs. I'm more than willing to spearhead the port, and I certainly accept that there'll be more than a little hair pulling (and rewriting) as the APIs change.

Webchick said they needed people to port their modules. That was back in April. I for one, am ready to get my hands dirty.

If necessary, we can delete the 8.x branch in the repo and move it to a sandbox, but I'd rather not. I know I'd rather have a canonical repo than have the ported code floating around in one or more sandboxes.

The routing system has a lot of DX improvements in the pipeline, so it feels very much like a moving target to me.

I'd like us to think more about how the architecture is going to work on D8 -- how we're going to use config entities and plugins. I'd also want to look at whether we can split off the UI: #2071245: [meta] Decoupling flag links from Flag -- but again there we're waiting on potential changes to do with unified entity fields.

(And yes, I'd really rather we didn't have another branch to worry about fixing the same bugs on. If we need a sandbox, we can agree to work on the same one, surely.)

The routing system has a lot of DX improvements in the pipeline, so it feels very much like a moving target to me.

Some, yes. I actually hit one of those already. Much of the rest of the system is still fairly solid and I doubt the controller idea will change *that* much in the future. Everything else I've done is PSR-0 stuff. Yes, there's PSR-4 on the horizon, but that should only mean moving the now organized PSR-0 files into a shorter directory structure.

Personally, I think we should leave #2071245 until Flag 4.x. It's a major enough change that it warrants a major change in version as well.

(And yes, I'd really rather we didn't have another branch to worry about fixing the same bugs on. If we need a sandbox, we can agree to work on the same one, surely.)

Do people really clone the repo and run the module directly from that? As long as the branch isn't tagged, who other than developers would know?

> And yes, I'd really rather we didn't have another branch to worry about fixing the same bugs on

What I mean by that is that right now, if we have a bug, we:

- fix it on 7-3
- hopefully cherry-pick to 7-2, or backport with s/entity/content
- hopefully cherry-pick to 6-2, provided it's to do with Flag internals and not core APIs
- cherry-pick to 6-1 if it works, and otherwise leave it

Now you've made an 8-3 branch, any bugs that crop up on 7-3 we ideally should be first fixing on 8-3. Which doesn't work yet anyway. And is using changing APIs.

What's been done in the past is a big dump commit to get the new branch caught up with all the fixes from the older branch, but a) that won't work because for 8 all the files have moved and renamed and b) it's a total PITA for our version history (I once tracked a bug with git blame or bisect as far as a big dump commit we have in our history where code was copied en masse from something like 6-2 to 7-2. and it's a TOTAL PITA because then you don't have an issue number for the change).

So what I'd like to happen is this 8-3 branch to be deleted, and for preliminary work to be done in a common sandbox, either here or on github.