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 <pmla...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
