On Wed, Apr 16, 2008 at 3:26 PM, Adrian Bunk <bunk@kernel.org> wrote:I don't quite agree, as I explained in my proposal there are several ways to detect that a commit was a bugfix. From thereon you can deduct that if it was a bugfix, that the commit that introduced the fixed change was a bug! From thereon you can start sifting and get more confirmations. Junio has made several suggestions as to how this could be implemented and I'm confident that and algorithm can be devised that is at least capable of 'guessing' what type a commit is. Aside from the guessing part I think a lot of information can be gathered from commit msgs. Of course, some commits might not be able to be typed (as there might not be any 'follow up' information on them). Those commits can be marked as 'unknown' and be ignored. Agreed, should all commits be 'unknown' then the command wouldn't be very useful, but especially on large repos there is a very large dataset. As the size of the dataset increases I estimate that the correlation between commits increases (less commits that add new code which then is never changed therafter). The higher the degree of correlation between individual commits the more we can determine about the nature of a commit. Well, a dead giveaway would be: "http://bugzilla.kernel.org/show_bug.cgi?id=10124" As said above, I don't agree, you can 'guess' very reliably on a large dataset. Also, most commits are already 'tagged' in some way or another. The trick is to find the pattern in this tagging and use it. I hope this clears things up a bit, Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
