Split drupalcores into 8.0.x commits and post-8.0.0 stuff?!

[timplunkett]

It'd be nice to cap the list off with all of the stuff from branching 8.x to tagging 8.0.0.
There have already been post-8.0.0 commits, and maybe those should be separate? Not sure what happens next.

[lewisnyman]

I don't really know what the best thing is to do here, if we should allow some kind of filter by time or tag as well as an overall count. Splitting commits by time would probably require us to refactor this project into a dynamic site... otherwise we just keep increasing the number of scripts that run through the commit log. Maybe this is a good time to do this.

[dawehner]

+1

[david-hernandez]

Make a tab per minor release, and have the most current one (I guess the in development one) be the default tab.

[pwolanin]

Yes, was discussing this with Lauri et al. I was going to work on a bigger code refactor, but let's just implement this to start.

[xjm]

In the interim, just do ericduran#82 ?

[xjm]

Sorry, was looking at the old repo. #84

[xjm]

BTW, it would be very easy to make the branch an argument rather than hardcoded, and the date already is. So we would just need the different tabs to run slightly different commands. Instead of --since-2011-03-09 we could make the date arguments --before=2015-11-19 --after=2011-03-09 for the "pre-release" tab, and adjust those dates as well as the version argument for each minor.

[pwolanin]

For everything except the start can't we use tag names?
e.g.

git log origin/8.2.x 8.0.0.. 

[xjm]

I guess that would work if we only wanted to separate pre-8.0.0 and post-8.0.0, and it's cleaner than using the release date.

It gets a little complicated for each minor though because there are unique commits in 8.2.x before 8.1.0 is tagged, for example. So technically to look for commits in 8.1.x after it was opened to development you could compare with the 8.0.0 tag, but for 8.2.x you'd need to compare with 8.1.0-beta1...

[xjm]

Also there's no guarantee when exactly 8.3.x might be branched. We currently plan to create it when 8.2.x goes into beta, but I can imagine other scenarios too.

[pwolanin]

Dates are fine too if you think that's more reliable. Starting on a branch for this. I'd think we want start -> 8.0.0, 8.0.0 (or whenever independent commits started going) to 8.1.x, 8.1.x to 8.2.x-dev (now)?

and maybe a tab that shows all-time contributions to 8?

[pwolanin]

How do we account for e.g. 8.3.x is branched and bug fixes to 8.2.x go there also? In general, the problem of bug fixes going 2 places.

[xjm]

I thought about that and I don't think it's a problem actually -- a bugfix is a contribution to both branches, so it should be credited in both. Sometimes the fixes even change for a safe production backport. The only risk is people not realizing there is overlap and thinking (e.g.) "xjm has contributed to 40 issues in 8.1.x and 18 in 8.2.x for 58 total" when those 18 are mostly the same as some of the 40.

I guess we could show an "overall" contributions tab to avoid that problem, but then that gets interesting with our use of cherry-pick and stuff. There's probably some command that works with the --cherry flag or something if we want to do that. Or, I think I have a version of the script somewhere that credits once per issue, which is starting to sound a lot like the crediting system on d.o.

For this issue, though, I'd suggest:
Drupal 8 development: git log 8.0.x --before=2015-11-09 --after=2011-03-09
Drupal 8.0.x maintenance: git log 8.0.x --after=2015-11-19 or git log 8.0.x 8.0.0.. as you suggested.
Drupal 8.1.x development: git log 8.1.x --before=2016-04-20 --after=2015-11-19 or etc.
Etc.

(Edit) updating the commands

And just stick a mapping in a yaml file where we hardcode the parameters for each tab we want to show, whether it's dates or tags or whatever.

[pwolanin]

I have started some refactoring for this on branch muti-tabs if someone wants to help work on it ping me in IRC