Re: Allura API

[Phil Holmes]

- Original Message - 
From: "Phil Holmes" 

To: 
Sent: Monday, August 31, 2015 4:10 PM
Subject: Re: Allura API


- Original Message - 
From: "Phil Holmes" 

To: 
Sent: Monday, August 31, 2015 2:26 PM
Subject: Allura API


You might like to know that I'm investigating the Allura API to see how 
we

could use it for Patchy, git-cl, etc.  With any luck I'll have a demo web
page up in an hour or so.


Very quick and dirty proof of concept.  This lists all the patches with 
the status "Started" and finds their Rietveld URLs.  The theory works just 
as well with patch:new, but there were so few results it didn't 
demonstrate much.


http://philholmes.net/lilypond/allura/

--
Phil Holmes



Been doing other things recently, but this link is now updated to show 
patch:new and to provide links to the issue tracker and the Rietveld.


--
Phil Holmes 



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

Re: thinking twice about the new issue tracker

[Federico Bruni]

Il giorno gio 3 set 2015 alle 11:03, Trevor Daniels 
 ha scritto:

 It works quite well. Status and labels are migrated correctly.
 Attachments are saved on Github server and displayed inline if they 
are

 images (Type-Ugly issues usually have image attachments).


Are you sure?  The first three I tried
https://github.com/fedelibre/lilyissues/issues/4551
https://github.com/fedelibre/lilyissues/issues/4548
https://github.com/fedelibre/lilyissues/issues/4491
seem to have broken links rather than images.


I did a quick test and I found only one broken link out of 10 issues.
Allura imported all the attachments correctly?


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

Re: thinking twice about the new issue tracker

[Federico Bruni]

Il giorno mer 2 set 2015 alle 18:52, Federico Bruni 
 ha scritto:
Il giorno mer 2 set 2015 alle 12:51, Federico Bruni 
 ha scritto:
I'm running the import on github. It takes more time, even if I've 
been

whitelisted by github team. I'm currently at:
Issue: 659/4567

Let's see how it works.


Now, after 6 hours, I'm at 3500/4567.
A bit slow because Github API has a rate limit of 5000 reqs/hour.

I'm leaving this computer. I'll send the link tomorrow.


It took about 10 hours. You can see the result here:
https://github.com/fedelibre/lilyissues/issues

It works quite well. Status and labels are migrated correctly. 
Attachments are saved on Github server and displayed inline if they are 
images (Type-Ugly issues usually have image attachments).


There's only one minor problem: issue IDs are different (as explained 
in the google IssueExporter page):


"""
GitHub pull requests and issues share the same ID namespace, so it is 
not possible to keep the same Google Code issue IDs when exporting 
issues to GitHub.


You can however rewrite exported comments to update issue references on 
GitHub after all issues have been migrated. After you have exported all 
issues and comments, rerun the exporter adding the 
{{--rewrite_comments}} flag.


This flag will build up a mapping between former Google Code issues and 
their new home on GitHub, and then regenerate comments after replacing 
text like " issue #42 " or "bug10" to be " issue #53 " or " bug50 ", 
etc.

"""

But the old ID is mentioned at the beginning of each issue and internal 
links can be rewritten (as explained above).


Github, unlike Bitbucket, does not put any restriction to the number of 
contributors. And public repositories are free of charge.

So IMO this could have been a possible interim solution.


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

Re: Improve wording for an NR paragraph (issue 259710043 by simon.albre...@mail.de)

[pkx]

https://codereview.appspot.com/259710043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

https://codereview.appspot.com/259710043/diff/1/Documentation/notation/spacing.itely#newcode3490
Documentation/notation/spacing.itely:3490: Or dynamics that @q{stick
out} of a system can be moved closer to the staff:
On 2015/09/03 01:28:06, Dan Eble wrote:

Starting a sentence with "or" seems too informal.  How about, "Another

example

is..."?  Perhaps we could keep just one good example and throw away

the other

one; or if they are both equally important, maybe they deserve to be

separate

items.


Yes I'd concur with Dab. I'd simply remove the word 'Or', use a
semi-colon instead of a full stop and continue with the sentence as it
is. We  typically use a semi colon at the end of 'sentences' that are
about to be illustrated by an @lilypond example (i.e. instead of the
colon you've put here).

https://codereview.appspot.com/259710043/

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

Re: thinking twice about the new issue tracker

[Federico Bruni]

Il giorno gio 3 set 2015 alle 11:07, David Kastrup  ha 
scritto:

"Trevor Daniels"  writes:


 Federico, you wrote Thursday, September 03, 2015 9:24 AM


 It took about 10 hours. You can see the result here:
 https://github.com/fedelibre/lilyissues/issues


 It's a pity you didn't do this a couple of months ago so we could
 have compared Github with Allura properly.  It's a bit late now.


Well, I do prefer self-hosting since it means nobody can pull the rug
from under us like Google did.  And GitHub's software does not allow
that.


This test was made just to consider an interim solution (as an 
alternative to Sourceforge).

But I see that the decision is using Allura.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Beautify Grob_array and stop using std::vector::data() (issue 264950043 by nine.fierce.ball...@gmail.com)

[dak]

On 2015/09/02 23:27:41, Dan Eble wrote:


If the sorting criterion uses attributes of the Grob that are changed

by

replacement, the array might not be sorted afterward (or might be

sorted when it

wasn't before).  Grob_array does not appear to dictate the sorting

criterion.

So the routine should reset the "sorted" flag when any changes are made?

https://codereview.appspot.com/264950043/

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

Re: thinking twice about the new issue tracker

[Trevor Daniels]

Federico, you wrote Thursday, September 03, 2015 9:24 AM

> It took about 10 hours. You can see the result here: 
> https://github.com/fedelibre/lilyissues/issues

It's a pity you didn't do this a couple of months ago so we could
have compared Github with Allura properly.  It's a bit late now.

> It works quite well. Status and labels are migrated correctly. 
> Attachments are saved on Github server and displayed inline if they are 
> images (Type-Ugly issues usually have image attachments).

Are you sure?  The first three I tried
https://github.com/fedelibre/lilyissues/issues/4551
https://github.com/fedelibre/lilyissues/issues/4548
https://github.com/fedelibre/lilyissues/issues/4491
seem to have broken links rather than images.

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

Re: thinking twice about the new issue tracker

[David Kastrup]

"Trevor Daniels"  writes:

> Federico, you wrote Thursday, September 03, 2015 9:24 AM
>
>> It took about 10 hours. You can see the result here: 
>> https://github.com/fedelibre/lilyissues/issues
>
> It's a pity you didn't do this a couple of months ago so we could
> have compared Github with Allura properly.  It's a bit late now.

Well, I do prefer self-hosting since it means nobody can pull the rug
from under us like Google did.  And GitHub's software does not allow
that.

-- 
David Kastrup

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

Re: thinking twice about the new issue tracker

[David Kastrup]

Federico Bruni  writes:

> Github, unlike Bitbucket, does not put any restriction to the number
> of contributors. And public repositories are free of charge.  So IMO
> this could have been a possible interim solution.

"Free of charge" also means they reserve the right to dump you at any
time for any reason.

-- 
David Kastrup

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

Re: thinking twice about the new issue tracker

[David Kastrup]

Federico Bruni  writes:

> Il giorno gio 3 set 2015 alle 11:07, David Kastrup  ha
> scritto:
>> "Trevor Daniels"  writes:
>>
>>>  Federico, you wrote Thursday, September 03, 2015 9:24 AM
>>>
  It took about 10 hours. You can see the result here:
  https://github.com/fedelibre/lilyissues/issues
>>>
>>>  It's a pity you didn't do this a couple of months ago so we could
>>>  have compared Github with Allura properly.  It's a bit late now.
>>
>> Well, I do prefer self-hosting since it means nobody can pull the rug
>> from under us like Google did.  And GitHub's software does not allow
>> that.
>
> This test was made just to consider an interim solution (as an
> alternative to Sourceforge).

Well, nobody wanted to use Sourceforge in the first place.  But time was
running out on us, and migrating to Allura should be straightforward
from there.

> But I see that the decision is using Allura.

Well, who does the work gets to call the shots.  At any rate, as a GNU
project there was sort of the goal to decrease the dependency on GitHub,
a closed service.  I'll readily admit that I'd have wished for stuff to
go smoother and faster but reality sometimes interferes and takes some
time to change.

-- 
David Kastrup

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

Re: thinking twice about the new issue tracker

[Trevor Daniels]

Federico Bruni wrote Thursday, September 03, 2015 10:21 AM
>
> Il giorno gio 3 set 2015 alle 11:03, Trevor Daniels  
> ha scritto:
>>
>>> It works quite well. Status and labels are migrated correctly. 
>>> Attachments are saved on Github server and displayed inline if they 
>>> are images (Type-Ugly issues usually have image attachments). 
>>
>> Are you sure? The first three I tried 
>> https://github.com/fedelibre/lilyissues/issues/4551
>> https://github.com/fedelibre/lilyissues/issues/4548 
>> https://github.com/fedelibre/lilyissues/issues/4491 
>> seem to have broken links  rather than images.
>
> I did a quick test and I found only one broken link out of 10 issues. 
> Allura imported all the attachments correctly?

Well, I've not checked them all, but I've not seen any and no one has 
reported any broken.

The three above are all correct (issue numbers differ, the Allura ones are
unchanged from those at GoogleCode):

https://sourceforge.net/p/testlilyissues/issues/4559/
https://sourceforge.net/p/testlilyissues/issues/4556/
https://sourceforge.net/p/testlilyissues/issues/4499/

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

Re: Improve wording for an NR paragraph (issue 259710043 by simon.albre...@mail.de)

[simon . albrecht]

Thanks for the input.


https://codereview.appspot.com/259710043/diff/1/Documentation/notation/spacing.itely
File Documentation/notation/spacing.itely (right):

https://codereview.appspot.com/259710043/diff/1/Documentation/notation/spacing.itely#newcode3489
Documentation/notation/spacing.itely:3489: will take up more space than
if they are on the same system.
On 2015/09/03 01:28:05, Dan Eble wrote:

"If these endings are spread over two systems, they take up more space

than if

they were on the same system."


Done.

https://codereview.appspot.com/259710043/diff/1/Documentation/notation/spacing.itely#newcode3490
Documentation/notation/spacing.itely:3490: Or dynamics that @q{stick
out} of a system can be moved closer to the staff:
On 2015/09/03 09:27:51, pkx wrote:

On 2015/09/03 01:28:06, Dan Eble wrote:
> Starting a sentence with "or" seems too informal.  How about,

"Another example

> is..."?  Perhaps we could keep just one good example and throw away

the other

> one; or if they are both equally important, maybe they deserve to be

separate

> items.



Yes I'd concur with Dab. I'd simply remove the word 'Or', use a

semi-colon

instead of a full stop and continue with the sentence as it is. We

typically

use a semi colon at the end of 'sentences' that are about to be

illustrated by

an @lilypond example (i.e. instead of the colon you've put here).


A look into the beginning of the NR showed that either a full stop or a
colon is being used.

https://codereview.appspot.com/259710043/diff/1/Documentation/notation/spacing.itely#newcode3490
Documentation/notation/spacing.itely:3490: Or dynamics that @q{stick
out} of a system can be moved closer to the staff:
On 2015/09/03 01:28:06, Dan Eble wrote:

Starting a sentence with "or" seems too informal.  How about, "Another

example

is..."?  Perhaps we could keep just one good example and throw away

the other

one; or if they are both equally important, maybe they deserve to be

separate

items.


I chose ‘As another example,’.
It’s plain to me that in this is only one item in the list, with two
examples. I think they’re both valuable.

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

Small error in Allura issue import

[Simon Albrecht]

Hello,

I just came across a small error in the issue import: in the summary for 
, " <> " has been 
omitted. It’s present in the Google Code DB.
I won’t fix this now, because we have no solution for the problem that 
all comments on the issue are deleted if e.g. the summary is changed – a 
quite unpleasant ‘feat’ of Allura which I discovered by fortunately only 
junking the two comments on issue 3900. Beware of that!


Yours, Simon

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