Re: [Audacity-manual] Tracking changes across pages

[James C. <cr...@in...>]

On 26/02/2012 01:32, Gale Andrews wrote:
> It's at least +4 (including Peter) - I want commit logs to be more useful
> for both quality and documentation.
>
> A good commit message:
>
>   "FIXED Bug 2332 (P4):<hyperlink>Memory leaks in Equalisation
>     effect (now 20 times faster);
>     rewording of EQ buttons (affects Manual)."
+1 to the bug number and priority and style of description.
-1 to hyperlink.
+1 to ";" to separate the distinct things done.
+1 to text "rewording of EQ buttons"
-1 to "(affects Manual)"

> I think the best way is for some single known person to do that,
> but if someone has a better idea, please state it.
-1.
Could only work if we could edit the log descriptions, and one person 
were responsible for doing that.

Could however aim for a GSoC student to write us a tool that links 
bugzilla numbers, SVN log messages and wikipedia manual pages.

> Without a system, however much the developers improve their commit
> logs, things WILL be missed.  When the Manual people have a system,
> the issue of commit logs should IMO be taken to the -quality list. We
> have a much stronger case if we have a system.
So to accelerate that process, suppose we say that we WILL use the 
'null-pot-file' differences, we will run a script every night as part of 
our build process to do it and keep the differences list up to date.  
We'll post that list automatically to a wiki page.   Is that plan enough 
to now take discussion of commit messages to the quality list?

> We also I think want to ensure when a substantial feature is added
> that the developer adds user-level documentation in the Manual,
> probably in a Talk page. That probably does need an e-mail to this
> list (or a hyperlink in the commit log).
+1.  With substantial features there will usually be things only the 
developer knows.

> Personally I feel all Forum Crew or above should be having commit
> logs fed or e-mailed to them. It can only help the quality of response
> on the Forum to know what is going on.
It's their choice what to do.  Do we need to enable anything for them Gale?

> I too think automated screenshots may not save as much time as
> anticipated.
OK, so they are slipping down as a priority for post 2.0.0, and 
null-pot-file is rising.

>
>> I'd also like to lobby again for manual freeze being a few days after
>> code freeze.
> I think there is a general problem that developers tend to commit things
> right up to just before the freeze. Not only does that give the Manual
> workers no time to adjust the Manual, it gives QA no time to test
> changes (some of which may affect the README).
+1, kind of.
Committing MIDI a day before code freeze is not on.  Changing a dialog 
so that its contents are in a scroller is just fine - provided manual is 
not frozen on the same day and release notes are not needed on the same day.

> It depends what the changes were - if a formal three days of Manual/
> QA freeze is not needed on a particular occasion then there may be no
> reason to add a delay. If it worked that way, then QA and Manual would
> have to lobby RM for more time. If we had a formal "cooling off" period
> after code freeze for QA/Manual catch up, that time could possibly be
> used for some kind of testing.
>
> This should be raised on -quality, too, I think.
+1 to raising on quality.

--James.