Re: [ANN] LIbreOffice 4.3.6 RC2 available

[Nino Novak]

On 11.02.2015 at 23:01, Christian Lohmaier wrote:

> A list of known issues and fixed bugs with 4.3.6 RC2 is available
> from our wiki:
> 
>   http://wiki.documentfoundation.org/Releases/4.3.6/RC2

the page is empty.

Regards,
Nino

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: LibreOffice Weekly News #5 waiting for reviews

[Nino Novak]

Am 13.09.2014 um 03:25 schrieb William Gathoye:

> I've just finished to write the fifth edition of LOWN. [1]

Very nice work, thanks :)


> The latter is waiting for your reviews.


just one observation: citation numbers in the text go up to 58, but the last
reference on the page bottom is 50, so a couple of refs seem missing

Nino

[1]
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Bug introduced during translation? (was: [Bug 39674] find / fix all German spellings in internal APIs)

[Nino Novak]

Hi,

by chance I looked into this commit and seeing the lines cited below, I'm
asking myself how many strange bugs or regressions are introduced this way.

Here, the names of two variables were translated - which would be ok, but
only if all of their occurences were changed accordingly.

In this case, the translation of only one occurence in my eyes (though I'm
not a dev) *must* break something.

Thomas, did you notice this?

Nino

partly citing
:
-
diff --git a/sc/source/core/tool/interpr2.cxx b/sc/source/core/tool/interpr2.cxx
index ac6d71e..1971e56 100644
--- a/sc/source/core/tool/interpr2.cxx
+++ b/sc/source/core/tool/interpr2.cxx
[...]
@@ -1399,9 +1397,9 @@ void ScInterpreter::ScVDB()
else
{
- double fDauer1=fDauer;
+ double fTimeLength1=fTimeLength;
-

On 30.08.2014 10:48, bugzilla-dae...@freedesktop.org wrote:
> Commit Notification 
> changed bug 39674 
> What  Removed Added
> WhiteboardEasyHack DifficultyBeginner SkillScript target:4.1.0
> target:4.2.0  EasyHack DifficultyBeginner SkillScript target:4.1.0
> target:4.2.0 target:4.4.0
> 
> *Comment # 16  on
> bug 39674  from Commit
> Notification  *
> 
> Jennifer Liebel committed a patch related to this issue.
> It has been pushed to "master":
> 
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=5605a36a31081875087ff5cb28b84790845ba695
> 
> fdo#39674: Improved translation
> 
> 
> 
> The patch should be included in the daily builds available at
> http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
> information about daily builds can be found at:
> http://wiki.documentfoundation.org/Testing_Daily_Builds
> Affected users are encouraged to test the fix and report feedback.
> 
> 
> You are receiving this mail because:
> 
>   * You are on the CC list for the bug.
> 
> 
> 

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: 10,000th Bug Report!

[Nino Novak]

Am 08.10.2012 19:43 schrieb Joel Madero:
> I just randomly did a pull on FDO of all bugs reported under LibO and saw that
> we've hit the 10,000 (exactly) number. 

Sure?

Isn't it just the maximum number of bugs bugzilla lets you export in a normal 
query?

;-)

Nino
AFAIR I counted ~14k Bugs a couple of days ago.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Triage Project Update

[Nino Novak]

Am 04.09.2012 23:05 schrieb Joel Madero:
> I agree that FDO has some benefits but the limitation is really that each user
> is needed to query every time,  the possibility of overlap is great, and no 
> one
> is really responsible for an individual bug until the query is made and 
> someone
> takes the time to look into it. I'm not sure if others would agree but it 
> seems
> like having a "group" of 50 or so and being able to just do those at your
> convenience makes people more likely to help and feel like their is an end in
> sight for "their portion". This is vs. just seeing a never ending list from 
> FDO
> or even having to "teach" new users (or even not new users) exactly what to
> search for every time with FDO.

As for me (a rather unexperienced QA Newbie), I've chosen a somewhat  different
approach: I've first created two custom searches,

1) all recent bugs (reported within the last two days) for curiosity (just to
see what people report recently)

2) all UNCONFIRMED bugs from the last 14 days

>From query 2 I picked a couple of bugs every couple of days to
reproduce/confirm/assign/close/whatever seemed appropriate.

That's just to show a slightly different approach, which is rather simple and
can be handled perfectly within bugzilla itself without any external tool.

Ok, the only problem was, that when a person starts reproducing a bug, it can
happen, that another triager just starts with the very same bug at the same
time. So some kind of lock signal was the only missing thing to prevent
duplication of work. However, this situation did not happen a single time during
my self-chosen "BugReviewWeek" ;-)

Another advantage: By the above process nobody (virtually) "blocks" 50 bugs for
a longer time period. Bugzilla queries are very adequate at every time, as all
works with live data.


> Similar to how developers assign themselves bugs and then can just go look at
> their own bugs ("My Bugs") it would be nice to have this ability for QA 
> triagers
> but have it somewhat automated since it's just triaging, not programming. In 
> the
> long run (once we're through the back log of 650+ that are really old), it 
> would
> be amazing if we had a team of QA staff that signed up to have bugs "auto
> assigned" to them for triaging.

We have the libreoffice-bugs@fdo mailing list, which contains (nearly?) every
new bug. Could we use it somehow for this purpose? E.g. by replying to a bug or
forwarding it to the qa list or some such? (Just thoughts, nothing concrete)



 What I imagine:
> 
> QA triagers "sign up" for components they are willing to triage and their 
> "max"
> load
> New bug is reported, if the bug has a component listed the bug gets "auto
> assigned" for triaging purposes according to some rule(s)

Personally, I prefer not to sign up for a special component but to pick a recent
bug which kind of "attracts" me spontanously. But there might be other
opinions/preferences/arguments/approaches.


> For now the google docs works, FDO does not as it is now but I'll discuss this
> further with Bjoern, Petr & Rainer to see if we can come up with something 
> more
> functional than the chaos that is FDO :) Or maybe I'm just not familiar enough
> with FDO to really feel comfortable myself with it, this is more likely than 
> not
> true :)

:-)

I like your initiative. Please don't feel discouraged by my comments, I just
wanted to add a slightly different view. If people like your approach, that's
great! It does not contradict to mine (IMHO), as it's rather obvious if a bug
has been triaged or not. So we can all work together towards our common goal.

Regards,
Nino
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Triage Project Update

[Nino Novak]

Am 04.09.2012 21:52 schrieb Joel Madero:
> Basically it would be really nice to be able to group and assign bugs the
> way that the document does. I think bugs are much more manageable this way
> and we've seen a relative spike in QA triaging activity since starting the
> process this way.

Ok, I see: it makes the process a bit more transparent/obvious. And thus is more
pleasant and possibly "invites" more contributors.


 Not sure if you looked at the document but it's basically
> manual everything,

I looked at it but could not see what is so special with it...

I'll try to compare (please comment if you find this inadequate):


 I download FDO bugs to Calc, group them based on
> Component,

can be done by a bugzilla query

 then manually copy and paste into groupings of no more than 50.

(is this really that important? for crowdsourcing, it might suffice to do
coordination by e-mail)

> It would be incredibly nice to have the list updated automatically based on
> FDO, group the bugs based on component and then group each of those to a
> max of 50 bugs per group.

if it's a live query, it's current every time you run it

 If each group of 50 could then be assigned to a
> user it would be easy for members of QA to get involved with this project
> and get this back log taken care of.

Ok, I don't know how to build such chunks of 50 bugs using a query - but - is it
so important? Couldn't we use e.g. time periods (weeks or months) to group the
bugs? Then the number would not be constant but who cares?


 I'm not sure if this is possible or
> incredibly time consuming (if it is, probably not worth it).

I don't know either but wanted to understand what exactly is needed and if it's
possible to find (slightly) different solutions which can be implemented more
quickly (or are already existing but not thought of)


 It would be
> even better if we, as the QA team could do a custom "group" and then it
> could assign us bugs based on that. For instance, I'm a QA member and I
> want to do 20 bugs that are either Writer, Calc or Presentation, and I want
> the oldest bugs (in terms of those that have been left UNCONFIRMED for the
> longest period of time). It could then give me the list and allow me to
> assign myself to the group, and thus prevent other QA members from getting
> those bugs in their list when they do a custom search.

There is a QA Contact field which has not been used extensively (at least
according to my recent search). Could it be used for this purpose? (Rainer? 
Björn?)


> Sorry I felt like that was a bit of rambling, let me know if you need it
> clarified, I can hardly understand it myself ;)

So let me be a bit of a devil's advocate, aka clarification helper :-)

(I've been working in a project as QA helper years ago for several months, they
used excel sheets, so I think I understand the need to master the bugs, and to
make the processes transparent and obvious. And thus lower the entry barrier for
noobs, too btw.)

So my present guess would be:
- asking for a web tool is ok but - if there's no better tools ATM, let's stay
with google docs for the time coming
- but let's also try to use bugzilla itself as much as possible
- we have also the wiki, but I do not see much advantage of using it compared to
a google spreadsheet as it does not support storing/handling structured data.
But it's a web, so we can document all processes nicely and link the documents
in the wiki.

Regards,
Nino
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Triage Project Update

[Nino Novak]

Hi Joel,

Am 04.09.2012 19:18 schrieb Joel Madero:

> I have done a complete update of the google document, this being said, if
> you named a sheet to your name, it's gone. Noel pointed out that a lot of
> the bugs on the sheet were already triaged so I just started from scratch.
> I'm still hoping the web team can help us move this away from google docs
> and get it automated a bit but for now, it is what it is.

I'm not sure to understand what you want to have automated, could you elaborate
just a little bit (or - if you have done so already - point me to the archived
mail)?

Thanks,
Nino
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

QA Mission Statement (was: Re: Fwd: Re: Closing NEEDINFO bugs)

[Nino Novak]

Hi,

On 20. Aug 2012 00:56, Bjoern Michaelsen wrote:

> [...]
> The first goal of the QA team is [...]

nice statement :-)

I had the impulse to put it in a prominent place on the QA Homepage[1]. Feel
free to complete it or improve wording.

Nino
[1] http://wiki.documentfoundation.org/QA


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] possible error in Wiki list of fixed bugs

[Nino Novak]

Am Montag, 1. August 2011, um 16:21:18 schrieb Korrawit Pruegsanusak:
> Hello all,
> 
> On Mon, Aug 1, 2011 at 17:53, leif  wrote:
> > But I agree that the issue number doesn't refer to the correct
> > issue and we should ask the developer list (done) for better and
> > more accurate information.
> 
> Seems to be a typo. It should be fdo#38457.

ok, fixed.

Nino
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] PM / was: Re: [libreoffice-l10n] [ANN] LibreOffice 3.4.2 RC1 available

[Nino Novak]

Hi Petr,

Am Montag, 18. Juli 2011, um 18:33:06 schrieben Sie:
> Nino Novak píše v Čt 14. 07. 2011 v 22:48 +0200:
> > Am Donnerstag, 14. Juli 2011, um 14:29:53 schrieb Florian 
Effenberger:
> > > The list of fixed bugs in this release is here:
> > > 
> > > http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libre
> > > offi ce-3-4-release-3.4.2.1.log
> > 
> > for a clickable version, look at
> > http://wiki.documentfoundation.org/User:Nnino/Drafts/bugfixes3.4.2
> 
> Looks great.
> 
> I wonder how you generated it. LeMoyne has been working on some
> scripting. Do you have any script as well? ;-)

just piped it through the following sed script to obtain Wiki markup:

s/fdo#[0-9]*/{{\0}}/g
s/bnc#[0-9]*/{{\0}}/g
s/i#[0-9]*/{{\0}}/g
s/i#/issue#/g
s/^\+ \(.*\)$/== \1 ==/
s/^. /* /

Nino
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [libreoffice-l10n] [ANN] LibreOffice 3.4.2 RC1 available

[Nino Novak]

Am Donnerstag, 14. Juli 2011, um 14:29:53 schrieb Florian Effenberger:

> The list of fixed bugs in this release is here:
> 
> http://dev-builds.libreoffice.org/pre-releases/src/bugfixes-libreoffi
> ce-3-4-release-3.4.2.1.log

for a clickable version, look at
http://wiki.documentfoundation.org/User:Nnino/Drafts/bugfixes3.4.2

Nino
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice