[Libreoffice] development summary: year 2011, week 24
Petr Mladek
pmladek at suse.cz
Mon Jun 27 11:06:07 PDT 2011
Hi John,
I am happy that your are working on it and have some nice results.
John LeMoyne Castle píše v Pá 24. 06. 2011 v 02:38 -0700:
> Hi Petr,
> Sorry about the confusion I created on a previous summary thread in my
> brainstorming attempt to get development summaries into the wiki.
> I know it was bad because it even seemed to infect your response a little.
I am not aware of any confusion. It is normal to have different views on
something and exchange ideas :-)
> This should be clearer.
>
> Here is an example of a wrapper (wiki-dev-sum)
> http://nabble.documentfoundation.org/file/n3103449/wiki-dev-sum wiki-dev-sum
OK, if I understand it correctly, it has the following purpose:
1. purpose is to generate the statistic for all active branches.
Well, this might make sense. I actually use a similar
wrapper that updates the repository to a given branch
and get the last changes. It is written in bash. Please,
find it attached.
It would be great to pass the list of branches via the
command line options.
You could use --option=<param> even in bash. You could get
the param via:
param=`echo $arg | sed "s/--option=//"`
Note that the situation is a bit complicated. I have separate
git tree for master, libreoffice-3-4* and libreoffice-3-3*
branches because they are not compatible:
+ libreoffice-3-3 uses "build" repo as the
toplevel dir ; "bootstrap" repo is in
build/clone/bootstrap.
+ libreoffice-3-4 uses "bootstrap" as the top level
module
+ master is going to be switched to "single" git
repository, see
http://wiki.documentfoundation.org/Development/One_Git_Conversion
Well, it might be interesting to move this functionality to
the lo-commit-stat script. You could add new option:
--branches=<branch>[,...]
I created extra wrapper because it was easier to do it in
bash and I wanted a quick solution ;-)
2. purpose is to define the start and end day according to the
week.
It would be great to have it in the lo-commit-stat script. It
is very useful also for generating the plain log for E-mail.
Could you please add --year=<year> --week=<week> --last-week
options int lo-commit-stat? You could do something like:
if (defined $last_week) {
$year = get_this_year();
$week = get_this_week();
}
if (defined $week && ! defined $year) {
$year = get_this_year();
}
if (defined $week && defined $year) {
die "Error: Do not define extra git arguments together
with --year, --week, --this-week options"
if (@git_args);
@git_args = get_git_args_for_feek($year, $week);
$log_suffix = "week-$year-$week" unless (defined
$log_suffix)
}
You need not process these options in the wiki-dev-sum
wrapper. It might be enough to pass them to the
lo-commit-stat script.
3. Is there any other purpose of the wiki-dev-sum script?
BTW1: I was not sure what the --echo option means. Such functionality is
usually enabled via the option "--verbose" ;-)
Also the following negative condition looks a bit cryptic:
(! defined $echo) || show_call
I think that
(defined $verbose) && show_call(...)
or
show_call(...) if (defined $verbose);
is slightly better readable ;-)
BTW2: Using /tmp/commit-log-$branch-wiki.log is a bit dangerous because
any user could write to this file (security hole, write access
problems). I suggest to create a temporary directory
under /tmp/wiki-dev-sum-XXXXXX and put files under it. The question is
why you need the temp file at all. It would be better if lo-commit-stat
generates the right file to the final location and no postprocessing is
needed.
> that operates on a slightly modified lo-commit-stat script (basically just
> adds --wiki format option)
> http://nabble.documentfoundation.org/file/n3103449/lo-commit-stat
> lo-commit-stat
It looks great. I am just not sure about the change:
--- cut ---
-(defined $top_dir) || die "Error: top directory is not defined\n";
+if (! defined $top_dir) {
+ usage();
+ exit;
+}
--- cut ---
I think that the user might be confused why it prints help and what is
the exact problem.
> The intention is to make as few changes as possible in lo-commit-stat while
> getting to where a Weekly Development Summary wiki page is generated easily.
Do not hesitate to do more changes in lo-commit-stat ;-)
> I attached full scripts and not patches because the pair is brand new and
> neither fully tested nor reviewed at all: i.e. not yet ready to patch in.
Yup, the full files are fine.
> In particular, I need to restore the linked bug numbers to the 1st commit
> line (except in the rare case there are three or more associated issues).
> That will reduce the page length quite a bit.
>
> I generated two wiki pages:
> http://wiki.documentfoundation.org/Development/2010/MasterWeek39 -- and
>
> http://wiki.documentfoundation.org/Development/2011/MasterWeek24 (last
> week)
It looks great. I like the number of commits in the titles. I prefer the
more compressed format used for the week 24.
I would omit the "LibreOffice issue", "Red Hat issue" strings. They are
repeated too many times. It would look ugly if there are more bug
numbers associated. People get this information after they click the
link. If there is an unknown bug, just print the number as a plain text.
Also I would switch the order of developer names and bugzilla numbers.
IMHO, people should use it in the following order:
+ read the short description
+ look into bugzilla for more details if needed
+ ask the author if still in doubts
You could actually read the E-mail addresses from the git log and create
E-mail link to the author.
> ** Please Note: Many of the commits listed for this week were actually
> merged into master as late as Spring 2011. The commits listed here have a
> patch date within week 39 of 2010. **
Great catch!
> In light of this snafu created by late submit and necessarily later merge, I
> will again approach/expose/question my confusion by attacking the utility of
> wiki-dev-sum as I had originally intended it: I don't think the present
> wiki-dev-sum script helps fill in the missing wiki summaries...
You might try to play with "git log" options. There are various options
about filtering the merged commits.
> It seems that in catching up the old pages, any wrapper needs to edit the
> original existing *-<branch>-week-<year>-<week>.log files into a wiki
> format. The alternative of trying to trace the history of the OOo patches
> through the merging branches to generate the correct commit list in wiki
> format (re-creating the true history - ferreting out the patch *application*
> dates) appears to be a real design and implementation challenge and
> difficult work to verify.
I think that it does not make sense to parse the old logs. I improved
the format over time, so it would be a nightmare.
I would either ignore the older weeks at all. Alternatively, I would
generate them using the last version of your scripts. Any problems with
merged commits should be solvable by the right git log flags. If it does
not work, it need not be 100% correct.
> To prevent the summaries from overwhelming the Dev category page I suggest
> they be moved to a form like Week<yyyy><ww>SummaryFor<branch> so that this
> long list of summaries is at the bottom of the category. They seem to be a
> better fit in QA with just an index page (per branch?) in Dev wiki so that
> they remain visible in Dev.
Good point!
Alternatively, you might create a top level page with links to the week
summary. I suggest to mention the last week on top of the page.
> If you don't have time to look at the scripts, please at least review my
> interpretation of the sudden appearance of dozens of commits 'back in the
> day' of the brand new master trunk (39-2010 Please Note...).
I hope that better "git log" options might help you. If you are lost,
you could ask Jan Holesovsky <kendy at suse.cz> or Norbert Thiebaud
<nthiebaud at gmail.com>. They are git experts. Please, do it in separate
mail. They are not interested into the rest of this long mail ;-)
> I apologize for the delay - I hope this post and wiki-dev-sum clarify the
> 'wikify' idea.
Do not worry. Everyone is busy. I am happy that you are working on it
and that it looks promising.
BTW: If you replay, please add me into CC. I might miss your answer on
the high traffic mailing list :-)
Best Regards,
Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lo-week-stat
Type: application/x-shellscript
Size: 2906 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110627/29f09891/attachment-0001.bin>
More information about the LibreOffice
mailing list