date:20130929

2013/9/29 Federico Bruni fedel...@gmail.com

 2013/9/28 Federico Bruni fedel...@gmail.com


 2013/9/28 Phil Holmes m...@philholmes.net

 I believe lilypad for Windows is localised - see

 https://github.com/gperciva/**lilypad/tree/master/windowshttps://github.com/gperciva/lilypad/tree/master/windows

 All those .rc files are Windows resource files in different languages.
  I've no idea how it works, though.


 I think I can test it later
 I've just remembered that I have a virtualbox file with Windows inside


 I confirm that LilyPad is localized: let me know if you need screenshots
 for italian website..
 Two issues to fix IMO:

 1. Welcome_to_Lilypond should be translated
 2. The installation wizard was in english, even if my locale in Windows is
 italian


Generate PDF and Edit source (right-click menu) are not translated.
So only the menu items are translated.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Unverified issues?


The issue tracker shows for
URL:http://code.google.com/p/lilypond/issues/list?can=1q=status%3Afixed
48 unverified issues.  Most of them can be verified since 2.17.27 has
been released.  Some have Fixed_2_17_28 in spite of already being in
2.17.27.

I'd like a better record before branching the stable release branch.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypad is localized?

These both need a bit of study to work out how to fix them.  Can you raise an 
issue for them, please?

--
Phil Holmes

  - Original Message - 
  From: Federico Bruni 
  To: Phil Holmes 
  Cc: Graham Percival ; David Kastrup ; lilypond-devel 
  Sent: Sunday, September 29, 2013 10:57 AM
  Subject: Re: lilypad is localized?

  2013/9/29 Federico Bruni fedel...@gmail.com

2013/9/28 Federico Bruni fedel...@gmail.com

  2013/9/28 Phil Holmes m...@philholmes.net

I believe lilypad for Windows is localised - see

https://github.com/gperciva/lilypad/tree/master/windows

All those .rc files are Windows resource files in different languages.  
I've no idea how it works, though.

  I think I can test it later
  I've just remembered that I have a virtualbox file with Windows inside

I confirm that LilyPad is localized: let me know if you need screenshots 
for italian website..
Two issues to fix IMO:

1. Welcome_to_Lilypond should be translated
2. The installation wizard was in english, even if my locale in Windows is 
italian

  Generate PDF and Edit source (right-click menu) are not translated.
  So only the menu items are translated.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?

- Original Message - 
From: David Kastrup d...@gnu.org

To: lilypond-devel@gnu.org
Sent: Sunday, September 29, 2013 1:15 PM
Subject: Unverified issues?

The issue tracker shows for
URL:http://code.google.com/p/lilypond/issues/list?can=1q=status%3Afixed
48 unverified issues.  Most of them can be verified since 2.17.27 has
been released.  Some have Fixed_2_17_28 in spite of already being in
2.17.27.

I'd like a better record before branching the stable release branch.

--
David Kastrup

Traditionally Eluze works through these on a Monday.  Let's check the 
situation on Tuesday.

--
Phil Holmes 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: lilypad is localized?

https://code.google.com/p/lilypond/issues/detail?id=3586

2013/9/29 Phil Holmes m...@philholmes.net

**
These both need a bit of study to work out how to fix them. Can you raise
an issue for them, please?

--
Phil Holmes

- Original Message -
*From:* Federico Bruni fedel...@gmail.com
*To:* Phil Holmes m...@philholmes.net
*Cc:* Graham Percival gra...@percival-music.ca ; David
Kastrupd...@gnu.org;
lilypond-devel lilypond-devel@gnu.org
*Sent:* Sunday, September 29, 2013 10:57 AM
*Subject:* Re: lilypad is localized?

2013/9/29 Federico Bruni fedel...@gmail.com

2013/9/28 Federico Bruni fedel...@gmail.com

2013/9/28 Phil Holmes m...@philholmes.net

I believe lilypad for Windows is localised - see

https://github.com/gperciva/**lilypad/tree/master/windowshttps://github.com/gperciva/lilypad/tree/master/windows

All those .rc files are Windows resource files in different languages.
I've no idea how it works, though.

I think I can test it later
I've just remembered that I have a virtualbox file with Windows inside

I confirm that LilyPad is localized: let me know if you need screenshots
for italian website..
Two issues to fix IMO:

1. Welcome_to_Lilypond should be translated
2. The installation wizard was in english, even if my locale in Windows
is italian

Generate PDF and Edit source (right-click menu) are not translated.
So only the menu items are translated.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?

Phil Holmes m...@philholmes.net writes:

 - Original Message - 
 From: David Kastrup d...@gnu.org
 To: lilypond-devel@gnu.org
 Sent: Sunday, September 29, 2013 1:15 PM
 Subject: Unverified issues?

 The issue tracker shows for
 URL:http://code.google.com/p/lilypond/issues/list?can=1q=status%3Afixed
 48 unverified issues.  Most of them can be verified since 2.17.27 has
 been released.  Some have Fixed_2_17_28 in spite of already being in
 2.17.27.

 I'd like a better record before branching the stable release branch.

 Traditionally Eluze works through these on a Monday.  Let's check the
 situation on Tuesday.

Ah, ok.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?

dak wrote
 Phil Holmes lt;

 mail@

 gt; writes:
 

 The issue tracker shows for
 lt;URL:http://code.google.com/p/lilypond/issues/list?can=1amp;q=status%3Afixedgt;
 48 unverified issues.  Most of them can be verified since 2.17.27 has
 been released.  Some have Fixed_2_17_28 in spite of already being in
 2.17.27.


 Traditionally Eluze works through these on a Monday.  Let's check the
 situation on Tuesday.
 
 Ah, ok.

I will treat what's left tomorrow (I'm not the only bug squad member allowed
to do it!)

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Unverified-issues-tp151572p151585.html
Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?

- Original Message - 
From: Eluze elu...@gmail.com

To: lilypond-devel@gnu.org
Sent: Sunday, September 29, 2013 4:00 PM
Subject: Re: Unverified issues?

dak wrote

Phil Holmes lt;

mail@

gt; writes:

The issue tracker shows for
lt;URL:http://code.google.com/p/lilypond/issues/list?can=1amp;q=status%3Afixedgt;
48 unverified issues.  Most of them can be verified since 2.17.27 has
been released.  Some have Fixed_2_17_28 in spite of already being in
2.17.27.

Traditionally Eluze works through these on a Monday.  Let's check the
situation on Tuesday.

Ah, ok.

I will treat what's left tomorrow (I'm not the only bug squad member 
allowed

to do it!)

Eluze

But you seem the most efficient at this :-)

--
Phil Holmes 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?

Phil Holmes m...@philholmes.net writes:

 From: Eluze elu...@gmail.com

 I will treat what's left tomorrow (I'm not the only bug squad member
 allowed to do it!)

 But you seem the most efficient at this :-)

So what?  If you find that some worker in a factory line is more
efficient as the next best worker, do you think good management would be
to fire all the rest?  Will that get more work done or less?

As long as we don't work against another, there is no sense in leaving
all the work to the most efficient people.  It may be argued that
I should be most efficient in a number of categories.  But if I had to
cater for all of them, I'd not get much done at all.

And actually, most of the Meisters listed in our roll have developed
their respective efficiency only on the job.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

verification and bulk edit [Re: Unverified issues?]

2013/9/29 Eluze elu...@gmail.com

  Traditionally Eluze works through these on a Monday.  Let's check the
  situation on Tuesday.
 
  Ah, ok.

 I will treat what's left tomorrow (I'm not the only bug squad member
 allowed
 to do it!)


I've cleared some of them, you won't have to work too much tomorrow :-)
This is a boring task and it should be shared as possible between all bug
squad members.

Also, I'm thinking about a way of making it easier.
Most of the times we have only to check if the committish pasted by the
developer is really in master. If we add a field Committish (where the
developer should paste the committish), then the bug squad can show the
column Committish and work on the list page instead of having to open each
issue.
Then we copypaste each committish in gitk and when we have verified all of
them we can use the bulk edit to mark all the issues as Verified in one
shot (never tried but I hope it works).

What do you think about it?
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: verification and bulk edit [Re: Unverified issues?]

Federico Bruni fedel...@gmail.com writes:

 2013/9/29 Eluze elu...@gmail.com

  Traditionally Eluze works through these on a Monday.  Let's check the
  situation on Tuesday.
 
  Ah, ok.

 I will treat what's left tomorrow (I'm not the only bug squad member
 allowed
 to do it!)


 I've cleared some of them, you won't have to work too much tomorrow :-)
 This is a boring task and it should be shared as possible between all bug
 squad members.

 Also, I'm thinking about a way of making it easier.
 Most of the times we have only to check if the committish pasted by the
 developer is really in master. If we add a field Committish (where the
 developer should paste the committish), then the bug squad can show the
 column Committish and work on the list page instead of having to open each
 issue.
 Then we copypaste each committish in gitk and when we have verified all of
 them we can use the bulk edit to mark all the issues as Verified in one
 shot (never tried but I hope it works).

 What do you think about it?

It matches the theory.  In practice, I've been startled quite a few
times when bug squad members not just verified the commit to be present
but also reported back when it turned out that the claimed functionality
did not actually accompany the commit.

The verification you spell out here could be done by a web crawler and
would be done in seconds.  The verification from the bug squad appears
to do a more thorough job on average.

When changing the issue tracker, you get a field for specifying what the
tracker should do next after changing the current issue.  If you use go
to next issue, it will move to the next issue matching the search.
That seems rather efficient, and it would appear that the bug squad
reading the issue description and possibly more leads to an improvement
of the results.

The question is whether we can significantly improve the efficiency
without sacrificing more quality than desirable.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: verification and bulk edit [Re: Unverified issues?]

2013/9/29 David Kastrup d...@gnu.org

 It matches the theory.  In practice, I've been startled quite a few
 times when bug squad members not just verified the commit to be present
 but also reported back when it turned out that the claimed functionality
 did not actually accompany the commit.

 The verification you spell out here could be done by a web crawler and
 would be done in seconds.  The verification from the bug squad appears
 to do a more thorough job on average.


This makes sense for issues marked as defects.. Well, some of them: for
example, issue 3553 doesn't have a minimal example (I guess it cannot be
produced) and I have no idea about how to verify it in depth. In such
cases I'll follow the CG:
Quite a few of these will be issues tracking patches. You do not have to
prove these patches work - simply that they have been pushed into the code
base. BTW, what are tracking patches?

On the other hand, all the doc issues don't require other than checking
that the committish is in master.


 When changing the issue tracker, you get a field for specifying what the
 tracker should do next after changing the current issue.  If you use go
 to next issue, it will move to the next issue matching the search.
 That seems rather efficient, and it would appear that the bug squad
 reading the issue description and possibly more leads to an improvement
 of the results.

 The question is whether we can significantly improve the efficiency
 without sacrificing more quality than desirable.


Because of the release delay, the issues to verify for 2.17.27 were way
over the average, which is around 15 issues per release AFAICS.
So probably my proposal is not needed.
I'm curious to hear the opinion of Eluze
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: verification and bulk edit [Re: Unverified issues?]

- Original Message - 
From: David Kastrup d...@gnu.org

To: Federico Bruni fedel...@gmail.com
Cc: Eluze elu...@gmail.com; lilypond-devel lilypond-devel@gnu.org
Sent: Sunday, September 29, 2013 6:07 PM
Subject: Re: verification and bulk edit [Re: Unverified issues?]

Federico Bruni fedel...@gmail.com writes:

2013/9/29 Eluze elu...@gmail.com

 Traditionally Eluze works through these on a Monday.  Let's check the
 situation on Tuesday.

 Ah, ok.

I will treat what's left tomorrow (I'm not the only bug squad member
allowed
to do it!)

I've cleared some of them, you won't have to work too much tomorrow :-)
This is a boring task and it should be shared as possible between all bug
squad members.

Also, I'm thinking about a way of making it easier.
Most of the times we have only to check if the committish pasted by the
developer is really in master. If we add a field Committish (where the
developer should paste the committish), then the bug squad can show the
column Committish and work on the list page instead of having to open 
each

issue.
Then we copypaste each committish in gitk and when we have verified all 
of

them we can use the bulk edit to mark all the issues as Verified in one
shot (never tried but I hope it works).

What do you think about it?

It matches the theory.  In practice, I've been startled quite a few
times when bug squad members not just verified the commit to be present
but also reported back when it turned out that the claimed functionality
did not actually accompany the commit.

The verification you spell out here could be done by a web crawler and
would be done in seconds.  The verification from the bug squad appears
to do a more thorough job on average.

When changing the issue tracker, you get a field for specifying what the
tracker should do next after changing the current issue.  If you use go
to next issue, it will move to the next issue matching the search.
That seems rather efficient, and it would appear that the bug squad
reading the issue description and possibly more leads to an improvement
of the results.

The question is whether we can significantly improve the efficiency
without sacrificing more quality than desirable.

--
David Kastrup

Graham and I used to debate this.  His view was that all that is required of 
Bug Squad members is to verify that a claimed fix was committed.  This would 
lend itself well to autoverification, should someone have the time to write 
an autoverify-bot.  I would live with that for Issues marked as something 
like Patch-pushed.  I do think that claimed fixes to real bugs should have 
a tiny example, and the bug squad should confirm that the tiny example no 
longer fails.  This could argue for a more rigorous approach to bug 
acceptance: no example, no report.

--
Phil Holmes 

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: verification and bulk edit [Re: Unverified issues?]

Federico Bruni-5 wrote
2013/9/29 David Kastrup lt;

dak@

gt;

It matches the theory. In practice, I've been startled quite a few
times when bug squad members not just verified the commit to be present
but also reported back when it turned out that the claimed functionality
did not actually accompany the commit.

The verification you spell out here could be done by a web crawler and
would be done in seconds. The verification from the bug squad appears
to do a more thorough job on average.

This makes sense for issues marked as defects.. Well, some of them: for
example, issue 3553 doesn't have a minimal example (I guess it cannot be
produced) and I have no idea about how to verify it in depth. In such
cases I'll follow the CG:
Quite a few of these will be issues tracking patches. You do not have to
prove these patches work - simply that they have been pushed into the code
base. BTW, what are tracking patches?

On the other hand, all the doc issues don't require other than checking
that the committish is in master.

When changing the issue tracker, you get a field for specifying what the
tracker should do next after changing the current issue. If you use go
to next issue, it will move to the next issue matching the search.
That seems rather efficient, and it would appear that the bug squad
reading the issue description and possibly more leads to an improvement
of the results.

The question is whether we can significantly improve the efficiency
without sacrificing more quality than desirable.

Because of the release delay, the issues to verify for 2.17.27 were way
over the average, which is around 15 issues per release AFAICS.
So probably my proposal is not needed.
I'm curious to hear the opinion of Eluze

I have not much to add - yes it *is* boring if you only check that the
committish is there: a machine would do this faster and is probably less
error prone. but as dak observed, a few issues have been found to not really
solve the whole problem, just a part of it.

I have added a few issues to the tracker and many of them were originated by
myself. so it seems natural that I'm interested how the solution looks like
and not only that the patch has been committed.

I must confess that not every topics are of the same interest to me - that's
where I simply check the pre-/absence of the patch (and that's the boring
part). however that doesn't take much time (except for developers still
having a googlemail-account… because then you don't fall back to the issue
list) and I think it's a confirmation for the developers that their patch
has been definitely approved and confirmed. that's better than waiting for
days or weeks for a - maybe never coming - feedback. they may feel much
freer to put their energy into solving other issues.

a final remark: in the beginning of my bug squad member career it took me
much longer to verify a single issue - now with some routine I can open an
issue, search the commit, copy it, swap to Phil's tab, paste, check there is
something there, swap back, select verified and submit in clearly less than
a minute (and nearly blindly…).

Eluze

--
View this message in context:
http://lilypond.1069038.n5.nabble.com/verification-and-bulk-edit-Re-Unverified-issues-tp151595p151613.html
Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: verification and bulk edit [Re: Unverified issues?]

Phil Holmes-2 wrote
- Original Message -
From: David Kastrup lt;

dak@

gt;
To: Federico Bruni lt;

fedelogy@

gt;
Cc: Eluze lt;

eluzew@

gt;; lilypond-devel lt;

lilypond-devel@

gt;
Sent: Sunday, September 29, 2013 6:07 PM
Subject: Re: verification and bulk edit [Re: Unverified issues?]

Federico Bruni lt;

fedelogy@

gt; writes:

2013/9/29 Eluze lt;

eluzew@

gt;

Traditionally Eluze works through these on a Monday. Let's check
the
situation on Tuesday.

Ah, ok.

I will treat what's left tomorrow (I'm not the only bug squad member
allowed
to do it!)

I've cleared some of them, you won't have to work too much tomorrow :-)
This is a boring task and it should be shared as possible between all
bug
squad members.

Also, I'm thinking about a way of making it easier.
Most of the times we have only to check if the committish pasted by the
developer is really in master. If we add a field Committish (where the
developer should paste the committish), then the bug squad can show the
column Committish and work on the list page instead of having to open
each
issue.
Then we copypaste each committish in gitk and when we have verified all
of
them we can use the bulk edit to mark all the issues as Verified in one
shot (never tried but I hope it works).

What do you think about it?

The verification you spell out here could be done by a web crawler and
would be done in seconds. The verification from the bug squad appears
to do a more thorough job on average.

The question is whether we can significantly improve the efficiency
without sacrificing more quality than desirable.

--
David Kastrup

Graham and I used to debate this. His view was that all that is required
of
Bug Squad members is to verify that a claimed fix was committed. This
would
lend itself well to autoverification, should someone have the time to
write
an autoverify-bot. I would live with that for Issues marked as something
like Patch-pushed. I do think that claimed fixes to real bugs should
have
a tiny example, and the bug squad should confirm that the tiny example no
longer fails. This could argue for a more rigorous approach to bug
acceptance: no example, no report.

that would make our life more pictoral!
Eluze

--
View this message in context:
http://lilypond.1069038.n5.nabble.com/verification-and-bulk-edit-Re-Unverified-issues-tp151595p151614.html
Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: verification and bulk edit [Re: Unverified issues?]

Eluze wrote
 a final remark: in the beginning of my bug squad member career it took me
 much longer to verify a single issue - now with some routine I can open an
 issue, search the commit, copy it, swap to Phil's tab, paste, check there
 is something there, swap back, select verified and submit in clearly less
 than a minute (and nearly blindly…).

this just crossed Phil's last ten or so verifications - all in a minutes'
cadence - chapeau!

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/verification-and-bulk-edit-Re-Unverified-issues-tp151595p151616.html
Sent from the Dev mailing list archive at Nabble.com.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?

2013-09-29 Thread Janek Warchoł

2013/9/29 David Kastrup d...@gnu.org:
 Phil Holmes m...@philholmes.net writes:

 From: Eluze elu...@gmail.com

 I will treat what's left tomorrow (I'm not the only bug squad member
 allowed to do it!)

 But you seem the most efficient at this :-)

 So what?  If you find that some worker in a factory line is more
 efficient as the next best worker, do you think good management would be
 to fire all the rest?  Will that get more work done or less?

I think Phil's message was meant just as a compliment...

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Unverified issues?