[Libreoffice] development summary: year 2011, week 23 - into wiki

[Petr Mladek]

LeMoyne Castle píše v Út 14. 06. 2011 v 14:19 -0600:
> On Tue, Jun 14, 2011 at 12:57 PM, Petr Mladek <pmladek at suse.cz> wrote:


> After poking at lo-commit-stat a little bit last night, I think the
> best plan is to write a lo-commit-wikify wrapper that converts
> year&week to git-args --after/since and --before/until and then calls
> lo-commit-stat

I am not sure if we need a wrapper. You could do something like:

sub define_git_log_week_args($)
{
	my ($week_opt) = @_;

        # process the "<year>-<week>" string defined by the --week
        # option; use your DateTime and define:

        my $git_log_after_opt="--after=...";
        my $git_log_before_opt="--before=...";

        return "$git_log_after_opt $git_log_before_opt";
}

foreach my $arg (@ARGV) {
[...]
  } elsif ($arg =~ m/--week=(.*)/) {
        my $git_log_week_args = define_git_log_week_args("$1");
        push @git_args, split(/\s/, $git_log_week_args);
  }
[...]


>  . The wrapper would also help us catch up with an -all [weeks] arg or
> some such and drive lo-commit-stat through the branch tags separately.

Did you mean --week=all? IMHO, we do not need it. In this case you just
omit all --week/--before/--after options.

>  This step through the branch/tags idea was so the log output doesn't
> have to be rewritten or parsed.  But after re-reading the note above
> about --log-suffix I see it may be easier that I thought...

Hmm, I do not understand this. I am afraid that you are a bit confused.

I detect the current branch name to define the output log name. Also I
use it to make sure that all repositories use the same branch. 

I use the "git log" option tagA..tabB to show commits between tags. Or I
use "git rev-list"[*] options branchA branchB to show different commits
between two branches.

These are two different things. One is definition of the log name. The
other is filtering of the output.

[*] I also want to see changes between LO-3.3 and LO-3.4. "git log" does
not allow to see changes between branches, so I have to use "git
rev-list" in this case. See the lo-commit-stat --rev-list option.


> The main additions in lo-commit-stat would be output changes: wiki
> formatted lines (====headers for sub-repos), wrapping the bug numbers
> to wiki external links and (maybe) log append 
> lo-commit-wikify would create the other parts of the wiki page before
> and after the commit list from lo-commit-stat.

lo-commit-wikify ??? Do you want to create a wrapper to filter the log
generated by lo-commit-stat? This would be ugly because you would need
to parser the generated log.

IMHO, much better is to modify lo-commit-stat to be able to generate
another type of output. You might use the existing "$print_mode"
variable to define the "wiki" output.

For example, you might modify the subroutine print_summary_in_stat and
do something like:

sub print_summary_in_stat($$$$$$$$$)
{
     my ($summary, $pprint_filters, $print_mode, $ppiece_title, $pflags, $pbugs, $pauthors, $prefix, $log) = @_;
[...]
# print piece title if not done yet 
    if ( defined ${$ppiece_title} && $print_mode ne "bugnumbers" ) {
	if ($print_mode eg "wiki") {
		printf $log "===${$ppiece_title}===\n";
	} else {
        	printf $log "${$ppiece_title}\n";	
	}
        ${$ppiece_title} = undef;
    }
   
# finally print the summary line 
    my $bugs = "";
    if ( %{$pbugs} ) {
        if ( $print_mode eq "bugnumbers" ) {
            $bugs = join ("\n", keys %{$pbugs}) . "\n";
        } elif ( $print_mode eq "wiki" ) {
            # it will be more complex, so you should transform the bug numbers into links in a subroutine, see below
            $bugs = wiki_print_bugs(keys %{$pbugs});
        } else {
   	    $bugs = " (" . join (", ", keys %{$pbugs}) . ")";
        }
    }
[...]


sub wiki_print_bugs($)
{
my $output="";
foreach my $bug (@_) {
# do some hacks to print $bug as link to bugzilla
                $output .= "???"
}

        return $output;
}

> 
> I will attempt some other improvements as well re: bug numbers and
> ordering commits by time (so msgs like: fixed prev commit [/somebody]
> are clearer)

sounds good

> I will also look at  rolling-up some stats like: # commits and
> #changes 

great

> I will not do the extraction of common to all because there is also
> the case of common to a few and -
> you have reminded me that a) it isn't trivial and b) it will all be
> moot if sub-repos are merged.

I agree.


> I do see that checking all branches for the presence of a patch or
> patch set is valuable, but code config study/debug is different than
> this statistic generator

Could you please explain the idea a bit more? I am not sure if I
understand it.

> CPAN provides access to handy week functions in DateTime so converting
> week/year to start/end dates looks straightforward

Cool

>         Also feel free to refactor the whole script. It is possible
>         that you
>          would need another structure of the subroutines, more
>         parameters, ... 
> 
> 
> I will try to avoid this if possible - at least on the first pass. 
> Perhaps in future after gaining experience

sure

> I know I need to pull to get the latest commits.  After 
> $> ga pull -r 
> in a repo on <some branch>, do I have the commit info for *all*
> branches/tags?

I suggest to do your changes only in master. We could cherry-pick them
to the other branches when needed.


Best Regards,
Petr