Re: [Libreoffice] QA-hints ? -> question for devs !

Hi John,

LeMoyne Castle wrote (15-06-11 13:01)
> On Wed, Jun 15, 2011 at 1:02 AM, Cor Nouws <oolst@nouenoff.nl
> <mailto:oolst@nouenoff.nl>> wrote:
>
> >     ...
> > What I am more looking for, is sometimes the hints related to (some
> > of) the vast amount of code clean-ups/improvements, that possibly
> > have influence on area A or B. (In the commit-logs for master)
> >
> > Maybe maybe it is possible for the involved devs, when they think
> > it is possibly relevant, to add a few words to the description so
> > that it is indeed able to read that in the summaries.
> >       ...
> > Sounds reasonable?
>
> It is quite reasonable to try to get the dev work result to mesh with qa
> testing.  Sadly, git requests that the short commit message be <41
> characters. Personally, I struggle with that at each commit ;-)...
> Git does allow more lines in the commit header but those usually
> describe changes to the code, are often technical and some of the
> comments about the removed/replaced code do *not* belong on the wiki.

Thanks for this explanation.

> In the wiki of the future, the summary pages' bug numbers will link to
> the actual bug reports (at least for fdo) so that the summary indirectly
> provides the intended functional changes in LibreOffice.  The bug

Also with the present list it is not too difficult to go to the related 
issue.

> reports often contain steps to reproduce the bug that make it clear
> where to test the fix.  Perhaps the bug-fix section of the summary could
> eventually include the bug summary (short desc) next to the link as well.

What I am not looking for, is exact steps to reproduce / verify. When I 
know that some work has been done with function/area X, it gives the 
opportunity to work a bit around that area, according to my own habits 
and knowledge of the suite.

> The addition of a bug number to the short commit message is the most
> efficient way for the developers to pass testing info to qa.
>
> Thanks for raising and clarifying the issue of qa's need for clues about
> how to find and test the latest changes in any of master, 3.4 or the
> release branches,

And thanks to you and others for pointing to the current summaries as a 
good starting point for that, anyway as far as I am concerned. I 
understand the limitations now too.
Since there is much on the route in our QA-process/work, we can see if 
there shows up a natural, not too complicated, possibility to enhance it.

Kind regards,
Cor

--
 - Cor
 - http://nl.libreoffice.org