On Fri, 2015-10-09 at 10:57 +0100, Lars Kurth wrote: > > On 9 Oct 2015, at 10:09, Ian Campbell <ian.campb...@citrix.com> wrote: > > > > On Thu, 2015-10-08 at 18:04 +0100, Lars Kurth wrote: > > > Hi, > > > > > > because we are now branching and opening master before the release, I > > > have to make some changes to how I acknowledge Xen release > > > contributions. > > > > > > In the past, I took the time-stamps of the two RELEASE tags for a > > > release > > > and counted contributions to xen.git and osstest.git (I didn't count > > > qemu > > > -trad) > > > > How do the time-stamps get used? Are you doing git log --after=X - > > -before=Y? > > I was using git log -p -M --since=x --until=y, with master checked out, > which is what was recommended in GitDM when doing reporting. Mainly > because most of the scripts I have are used to do monthly and yearly > reporting.
OK, I suppose if that's what GitDM says to do there's no reason to deviate. > > Why don't you just look at the commits between the two tags (i.e. git log > > RELEASE-4.5.0..RELEASE-4.6.0 or whatever span you are using)? > > That's what I do for xen.git and was planning to do in future, but > unfortunately RELEASE-4.6.0 are not applied consistently to all repos > (aka OSSTEST, etc). Indeed, I only meant for repos which have the tags. > > The problem with using the time-stamp on a commit is that various git > > operations (git rebase, git send-email + git am) can end up preserving > > the > > original commit date in the authors tree, which can differ quite > > significantly from the date something was committed to be pushed to the > > repo. > > Does -M fix this issue? I can't find any docs for it. -M is "find renames", which makes the diff of code motion easier to follow, so I don't think so. > > > > 3: "Hypervisor other" will list contributions in a number of related > > > repos that are listed, but I would use the timestamps of the release > > > tags. I was planning to include the following repos: osstest.git - can > > > add friends also (as testing is important), raisin, mini-os (as it used > > > to be in xen.git). > > > > FWIW some of the "other" repos to also gain their own tags corresponding to > > the release (e.g. mini-os). Where it exists I suppose it makes sense to use > > it? > > It is too painful to do this at least for this release, Sure. > and some repos don't contain tags at all. The scripts I have, check out > all the repos I want to measure (e.g. all XAPI, all Mirage, ... repos) > into a directory and I use something like > > find $i/* -maxdepth 0 -type d | xargs -i git -C {} log $args >> > $root/output/$i/$ext.gitlog > > to aggregate all the logs for all the relevant repos. > > > > I could also include qemu-traditional into (3), which I have not > > > counted > > > in the past. So I was thinking I'd not do this. > > > > qemu-traditional doesn't get much traffic, but I don't see a reason to > > exclude it. The separation/change you are proposing here sounds like an > > ideal point to reintroduce it where it wasn't included before. > > That's what I was thinking and why I left it out I was proposing leaving it in based on that reasoning though. (did you mean this to be below the comment about upstream?). > > > Also including Linux, BSD, ... is hard as pinpointing the xen > > > -related > > > parts are too hard. > > > > I suppose qemu-upstream falls into this bucket too? (Which I suppose > > mght > > then be an argument for also excluding -trad?) > > Agreed, but the challenge is that it is near impossible to filter out > KVM, Linux, ... contributions. Right. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel