the consequences of the Git migration for Enzyme

Danny Allen danny at commit-digest.org
Fri Dec 31 16:20:38 CET 2010


I've just checked, and commits can be viewed at links like https://projects.kde.org/projects/extragear/network/ktorrent/repository/revisions/7325c1594622d6d3cd0ce16f513a047402f64248

The current problem is that there is no machine-readable list (XML, etc) for the projects listed at https://projects.kde.org/projects/ which means it would be fairly difficult to maintain such links at this time (Sho is aware of my concerns here)

The move to Git does present quite a few issues, and from the Commit-Digest perspective, I wish it hadn't happened.
It seems to change the behaviour of developers too: I have also noted that commits seem to be much less descriptive now, and also bunched together which is fairly useless.

I plan to put my recent work on Enzyme live on 2nd Jan, i'll try and prioritise the automatic classification stuff for then too.
An issue with further guessing is that all commits with BUG:XXX bug reports aren't bug fixes: some close feature bug reports.
I'll experiment with the right balance of other tags in the near future (it's on my long todo list!)

Danny


----- Original Message -----
From: "Alexander van Loon" <a.vanloon at alexandervanloon.nl>
To: digest at kde.org
Sent: Friday, 31 December, 2010 10:23:25 AM
Subject: the consequences of the Git migration for Enzyme

This morning I was reviewing commits and noticed that Enzyme also reads commits from Git now. However, this introduces a 
few problems:

I can’t view the details for the commits in Git because they aren’t linked like the commits to Subversion in Enzyme. I assume 
links to commit details will be implemented for Git too?

With Git I see commits with comments mentioning that a branch was merged quite often. For example, if you take a look at 
https://projects.kde.org/projects/playground/artwork/oxygen-gtk/activity you see the same comment ‘Merge branch '1.0'’ 
showing up very often. If you view the commits for details there, it doesn’t show any changes that were introduced by the 
commit. So far I’ve excluded all comments mentioning a branch merge because they simply aren’t descriptive, but I do not 
know if this is the right choice, because I don’t know what changes were introduced with the merger?

Currently all Git commits are not automatically assigned to an ‘area’ in ‘Classify’, unlike the commits from Subversion. Danny 
mentioned in one of his e-mails yesterday that he intends to add a user interface in Enzyme so we can control the automatic 
sorting of commits in ‘areas’. I was wondering Danny, do you have any idea when that feature is ready? With the percentage 
of commits from Git increasing, classifying is becoming a more time-consuming task as long as the automatical assigning of 
‘areas’ for commits is not available.

Slightly off-topic, I wonder if it’s possible to also automatically assign the type for classifying in certain cases? For example, 
every commit with a bug report could be automatically assigned the bug fix type. Also, I notice some developers use 
keywords in their commits which could be used to automatically determine the type, such as ‘optimize’, ‘fix’ and ‘feature’.
_______________________________________________
Digest mailing list
Digest at kde.org
https://mail.kde.org/mailman/listinfo/digest


More information about the Digest mailing list