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

John LeMoyne Castle píše v Po 13. 06. 2011 v 15:27 -0700:
> Hi Petr, 
> I was thinking about cranking through the past emails like this one and
> generating Development Summary pages on the wiki by hand.  
> Then I discovered the related easy hack --
> http://wiki.documentfoundation.org/Development/Easy_Hacks_Complete_List#Weekly_summary_.2F_Release_summary
>   
>
> I am now looking at adding a -w=<yyyy-ww> (weekly wikify) option to
> lo-commit-stat that would generate a suitable weekly wiki page entire.  Then
> only the page creation is manual labor that I can look forward to. I see
> from the wiki that the bug number handling could be more powerful, there may
> be ways to look more deeply at the commits and the resulting bug numbers on
> the Wiki should be links back to the related bug @ xxx.  There is also the
> extraction of commits common to all repos. 

Sounds like a great plan. I am happy that someone is interested into
improving the lo-commit-stat tool.

> I assume that you wrote lo-commit-stat... 
> Anything else that should go into -wikify?

I think that we still could improve unification of the messages. It
currently modifies the message to use lower case in the beginning, put
bugzilla numbers into brackets at the end of the message, ...

The bugzilla number detection is still not perfect. For example, the
sentence "fix for fdo#12345" is transformed into "fix for (fdo#12345)"
which is even more dumb than the original summary ;-)

Also it would be great to remove the dot "." from the end of the line if it
is there...

This transformations are currently done in the subroutines "search_bugs"
and "standardize_summary"

> Any internal tips?

I guess that you need to clone the suboutines: "print_stat" and 
"print_summary_in_stat". The clones should generate the output that is
suitable for wiki. Alternatively you might just modify them to give
different result for text file and for wiki. The output might be quite
similar after all.

Note that bugzilla numbers are already filtered out of the original
message and stored separately. It might help you to create the links
from them.


Hmm, it still does not detect common messages. It happens only from
time to time, so I modify the generated result by "sed" manually. I am
not sure if we need to implement it. It is not trivial. We are going to
reduce the number of git repositories and merge most of them into a
single one.

Anyway, if you would want to implement it, I would compare original
strings before they are unified and before the bug numbers are removed.
Note the it is not enough to count the number of string occurrences
because the sting might be repeated in the same module. You need to
make sure that the same string is used in all git modules. You could
create a hash of hashes. The global key will be the original string. It
will point to hash with names of used modules. You could count the
number of modules at the end and move the common strings to a separate
hash.

> What is standard week boundary here (i.e. Monday->Sunday)?

Yes, it is from Monday to Sunday. I define the exact dates on the
command line as the filter for the "git log" command, e.g.
--after="2011-05-15" --before="2011-05-23"

I call the it as:

bin/lo-commit-stat --log-suffix=week-2011-20 . --after="2011-05-15" --before="2011-05-23"
bin/lo-commit-stat --bugs --log-suffix=week-2011-20 . --after="2011-05-15" --before="2011-05-23"

Note that I use the command also the generate commit statistics for
releases. It needs to filter the log also by tags, ... For example, I use

bin/lo-commit-stat --log-suffix=release-libreoffice-3.4.1.1 . 
libreoffice-libreoffice-3.4.0.2..libreoffice-3.4.1.1
bin/lo-commit-stat --bugs  --log-suffix=release-libreoffice-3.4.1.1 . 
libreoffice-libreoffice-3.4.0.2..libreoffice-3.4.1.1

Please, keep this possibility.

I suggest to separate the date and output format definitions. For
example, you could add the option --wiki to force the output for wiki.
If you want to define the week, just by the week number, you could add
new option --week=<year-week>. Then you need to implement the code that
will define the correct --before and --after options for the "git log"
command.


Anyway, I do not say that the current options are the best way to
define all the things. Feel free to come up with a better proposal.

Also feel free to refactor the whole script. It is possible that you
would need another structure of the subroutines, more parameters, ...

> Can I put a (c) TDF header on it?

Good point. We should define the copyright and license in the file. It
will be part of the LO sources (bootstrap module), so I would use the
preferred header, for example, see bootstrap/Module_tail_build.mk. It
means that the license will be MPL 1.1 / GPLv3+ / LGPLv3+. The
copyright should belong to authors. It would be me:
Petr Mladek <pmladek@suse.cz>, you and other potential contributors.

I am looking forward to see changes from you.

Feel free to ask if you are in doubts with anything.

Best Regards,
Petr