From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:36
On Mon, 12 May 2008, Sverre Rabbelier wrote:
[Sorry, I hit 'send' instead of 'save']
And now you apparently forgot to add git mailing list to receipients...
On Mon, May 12, 2008 at 2:40 PM, Jakub Narebski [off-list ref] wrote:
quoted
This is, IMHO, the most complex example (at least to do properly).
It begins with: does given author have code touching given subsystem
(i.e. is it for him/her new contribution wrt. subsystem)? How many
commits he/she has affecting given subsystem? How often he/she rewrites
code? How many bugs were introduced?
Ah, there is a lot more to this example than I thought. Perhaps this
data could all be shown and then, using some "importance" metric per
item a "grade" can be calculated?
Weighting different statistics, bayesian hypotesis/filtering, expert
system, machine learning... I guess that would be quite a work to do
it well. Probably would require to calculate and adjust scoring of code
(difficulity) and authors (skill), and matching them...
This is certainly in the "wishlist" scope.
quoted
Details I think need to be provided by maintainer...
Do you mean Junio, or the user of the program?
I mean that all I can provide is speculation. I'm not, and never was
a maintainer of OSS project, and I don't know what criteria one use
(perhaps unvoiced criteria) to decide whether given patch needs to be
examined more closely, or the cursory browsing should be enough.
quoted
quoted
quoted
* Contributor: what happened with my code?
Do you mean a "track my code" like feature? Showing the movement of a
particular piece of code through the code? (Displaying information
like "moved from foo.c to bar.c in commit 0123456789abcd"?)
I was thinking there about "git blame --reverse".
Do you mean, filter it's output for a specific user?
I mean, given the code at given version, what happened to this code?
Filtering "git blame --reverse" by user might be one way of solving it.
quoted
quoted
quoted
* Searching where to contribute: what are oldest part of code dealing
with error messages (find ancient code)?
Or find the lines with oldest modification stamp with "die" or "warn",
or find which messages are oldest, even if wrapper have changed.
In that case, perhaps a regexp would be more suitable, to allow the
user to search for any specific line, not just "die" or "warn"?
What I had in mind here, but didn't explain clear enough, was an
extension to pickaxe search. You want to find when current error
message was created, even if the way of handling it (fprintf vs. die)
changed, or if code was indented, or was moved.
Or find all error messages, in the order they were created, for example
in git case to find ancient error messages and replace it by something
more user-friendly (or less selective about choosing friends ;-).
quoted
P.S. I wonder how hard to be to plug-in such SCM statistic system
into something like project management, see
"Joel On Software: Evidence based scheduling" (of programming tasks)
http://www.joelonsoftware.com/items/2007/10/26.html
Interesting article, I think integrating statistics
(http://www.statsvn.org/ for example) can be a very powerful tool for
project management.
You meant http://git.koha.org/gitstat/, didn't you? ;-P
Siriously, what I had in mind was to integrate author dates and commit
dates into project management system scheduling.
--
Jakub Narebski
Poland
On Tue, May 13, 2008 at 3:07 PM, Jakub Narebski [off-list ref] wrote:
And now you apparently forgot to add git mailing list to receipients...
I guess mailinglists are not my thing huh?
> On Mon, May 12, 2008 at 2:40 PM, Jakub Narebski [off-list ref] wrote:
> Ah, there is a lot more to this example than I thought. Perhaps this
> data could all be shown and then, using some "importance" metric per
> item a "grade" can be calculated?
Weighting different statistics, bayesian hypotesis/filtering, expert
system, machine learning... I guess that would be quite a work to do
it well. Probably would require to calculate and adjust scoring of code
(difficulity) and authors (skill), and matching them...
This is certainly in the "wishlist" scope.
Yeah, I think it would go in the 'c' of 'MoSCoW', but it could be very
useful when done right.
>> Details I think need to be provided by maintainer...
>
> Do you mean Junio, or the user of the program?
I mean that all I can provide is speculation. I'm not, and never was
a maintainer of OSS project, and I don't know what criteria one use
(perhaps unvoiced criteria) to decide whether given patch needs to be
examined more closely, or the cursory browsing should be enough.
I reckon more input from actual maintainers would be needed then.
Junio: aside from the original list with suggestions you provided,
could you shine your light as git maintainer on this?
I mean, given the code at given version, what happened to this code?
Filtering "git blame --reverse" by user might be one way of solving it.
It sounds like it would not be too hard to implement' maybe another
'C' in 'MoSCoW' (or perhaps that first 'C' should be a 'W'...)
What I had in mind here, but didn't explain clear enough, was an
extension to pickaxe search. You want to find when current error
message was created, even if the way of handling it (fprintf vs. die)
changed, or if code was indented, or was moved.
I'm not familiar with pickaxe, what you suggest sounds like grepping
the content also throughout history?
Or find all error messages, in the order they were created, for example
in git case to find ancient error messages and replace it by something
more user-friendly (or less selective about choosing friends ;-).
I understand what you want, a search for specific content, from old to
new, stopping when you have a match?
From: Jakub Narebski <hidden> Date: 2016-06-15 22:44:36
On Tue, 13 May 2008, Sverre Rabbelier wrote:
On Tue, May 13, 2008 at 3:07 PM, Jakub Narebski [off-list ref] wrote:
[on helping maintainer decide how closely patch should be examined]
quoted
Weighting different statistics, bayesian hypotesis/filtering, expert
system, machine learning... I guess that would be quite a work to do
it well. Probably would require to calculate and adjust scoring of code
(difficulity) and authors (skill), and matching them...
This is certainly in the "wishlist" scope.
Yeah, I think it would go in the 'c' of 'MoSCoW', but it could be very
useful when done right.
Errr... what do you mean by 'MoSCoW'?
[here I think you cut a bit too much]
quoted
What I had in mind here, but didn't explain clear enough, was an
extension to pickaxe search. You want to find when current error
message was created, even if the way of handling it (fprintf vs. die)
changed, or if code was indented, or was moved.
I'm not familiar with pickaxe, what you suggest sounds like grepping
the content also throughout history?
Documentation/glossary.txt (linked from git(7), in "Git User's Manual")
pickaxe::
The term <<def_pickaxe,pickaxe>> refers to an option to the diffcore
routines that help select changes that add or delete a given text
string. With the `--pickaxe-all` option, it can be used to view the full
<<def_changeset,changeset>> that introduced or removed, say, a
particular line of text. See linkgit:git-diff[1].
git-diff(1):
-S<string>
Look for differences that contain the change in <string>.
--pickaxe-all
When -S finds a change, show all the changes in that changeset, not
just the files that contain the change in <string>.
--pickaxe-regex
Make the <string> not a plain string but an extended POSIX regex to
match.
quoted
Or find all error messages, in the order they were created, for example
in git case to find ancient error messages and replace it by something
more user-friendly (or less selective about choosing friends ;-).
I understand what you want, a search for specific content, from old to
new, stopping when you have a match?
But let me elaborate a bit. What I wanted in my example is for each
die("<message>") and error("<message>") to have commit and date where
<message> was introduced (even if it was in fprintf(stderr, ...) then).
quoted
Seriously, what I had in mind was to integrate author dates and commit
dates into project management system scheduling.
I'm not sure what gain that would bring though, as it can only provide
end dates, not 'starting work now' timestamps...
Well, if you use patch management system such like StGit, it could
trace when patch was created, when was refreshed, when was temporarily
abandoned (push, pop, float, new), ans when was finalized (commit or
clean).
But that is also in the realm of vague ideas, not concrete applications.
--
Jakub Narebski
Poland
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:44:37
Jakub Narebski wrote:
On Tue, 13 May 2008, Sverre Rabbelier wrote:
quoted
On Tue, May 13, 2008 at 3:07 PM, Jakub Narebski [off-list ref] wrote:
[on helping maintainer decide how closely patch should be examined]
quoted
quoted
Weighting different statistics, bayesian hypotesis/filtering, expert
system, machine learning... I guess that would be quite a work to do
it well. Probably would require to calculate and adjust scoring of code
(difficulity) and authors (skill), and matching them...
This is certainly in the "wishlist" scope.
Yeah, I think it would go in the 'c' of 'MoSCoW', but it could be very
useful when done right.
Errr... what do you mean by 'MoSCoW'?
Must have
Should have
Could have
Won't have
It's a priority scheme used in agile development techniques, where
developers, customers and users work close together. The customer
decides "must have this, or we scrap this project", "should have this,
or users will be unhappy", "could have this, many would appreciate it"
and "won't have this, it's too expensive to develop" after the devs
have estimated the time required to develop the individual components.
Agile development is usually used to go under-feature instead of
over-budget. Since opensource projects are more driven by whatever
passing-by developers happen to find interesting (or annoying) at the
moment (nearly as predictable as Brownian motion), agile development
techniques are very rarely used successfully to develop oss in
anything but extremely tight communities.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:37
"Sverre Rabbelier" [off-list ref] writes:
quoted
>> Details I think need to be provided by maintainer...
>
> Do you mean Junio, or the user of the program?
I mean that all I can provide is speculation. I'm not, and never was
a maintainer of OSS project, and I don't know what criteria one use
(perhaps unvoiced criteria) to decide whether given patch needs to be
examined more closely, or the cursory browsing should be enough.
I reckon more input from actual maintainers would be needed then.
Junio: aside from the original list with suggestions you provided,
could you shine your light as git maintainer on this?
A cursory browsing is enough only when you trust the contributor well.
For example, I read patches from Nico to code around the pack generation
only once or at most twice before I apply them, and the same thing can be
said about git-svn patches from or acked-by Eric. These come mostly from
the fact that (1) I know they know the area a lot better than myself do,
and more importantly that (2) I know they care deeply about the subsystem
they are modifying, and they have good taste.
Project maintainers and old timers become familiar with habits, strengths
and weaknesses of known contributors over time, and that is the source of
such trust.
A clever enough automated way may be able to identify links between the
contributors and the areas they are familiar with, and using such a
mechanism people might be able to decide that a patch falls into category
(1) above. I am not sure if any automated way could ever decide if a
patch falls into category (2) above, though.
[And once more with 'reply to all' instead. Wouldn't it be nice if
gmail had an 'auto-reply-to-all' feature...]
On Sat, May 17, 2008 at 2:02 AM, Junio C Hamano [off-list ref] wrote:
A cursory browsing is enough only when you trust the contributor well.
For example, I read patches from Nico to code around the pack generation
only once or at most twice before I apply them, and the same thing can be
said about git-svn patches from or acked-by Eric. These come mostly from
the fact that (1) I know they know the area a lot better than myself do,
and more importantly that (2) I know they care deeply about the subsystem
they are modifying, and they have good taste.
This makes sense, patches only get a 'cursory browsing' when they come
from a trusted author, which is defined mostly by how active and how
'good' they are in the area they modify.
Project maintainers and old timers become familiar with habits, strengths
and weaknesses of known contributors over time, and that is the source of
such trust.
This could only partially be done by an algorithm, while git excels in
the 'over time' part, the definition of 'habits, strengths and
weaknesses' is harder to make.
A clever enough automated way may be able to identify links between the
contributors and the areas they are familiar with, and using such a
mechanism people might be able to decide that a patch falls into category
(1) above. I am not sure if any automated way could ever decide if a
patch falls into category (2) above, though.
Yes, your solution in determining patches from (1) is in the same
direction of what I have been thinking on myself. I don't think it is
possible to determine (2) without having access to the review system
(in git's case, the mailing list). When the review system would become
part of the analysis it could provide information on what improvements
had to be made to a commit before it was accepted. If 'style
improvements' would be marked in such a system then people with 'good
taste' are people whose commits do not often need 'style
improvements'. Alas, implementing something like that would be beyond
the scope of 1 GSoC. Ah well, 't is a nice dream about to implement at
a later time perhaps. (Although such would be more suited in a team
collaboration suite than in a [D]VCS).
--
Cheers,
Sverre Rabbelier