search

lauriii / drupalcores

A project to generate a list of core contributers
http://drupalcores.com
MIT License
27 stars 38 forks source link

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

Open timplunkett opened 8 years ago

timplunkett commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

+1

david-hernandez commented 8 years ago

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

pwolanin commented 8 years ago

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 commented 8 years ago

In the interim, just do https://github.com/ericduran/drupalcores/pull/82 ?

xjm commented 8 years ago

Sorry, was looking at the old repo. https://github.com/lauriii/drupalcores/pull/84

xjm commented 8 years ago

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 commented 8 years ago

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

git log origin/8.2.x 8.0.0..
xjm commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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