Re: [Xen-devel] [RFC] Xen 4.6 Acknowledgements

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

> On 9 Oct 2015, at 10:09, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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.

> 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). 

> 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.

>> 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, 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

>> 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.

Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel