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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-10-09 at 10:57 +0100, Lars Kurth wrote:
> > 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.

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel