Am Dienstag, den 12.05.2020, 17:08 + schrieb Trevor:
> Jonas, you wrote 12/05/2020 14:49:27
>
> > Actually I think we should use milestones for this. They can be closed
> > and don't clutter the labels.
> > This comes with the disadvantage that there can be at most one
> > milestone set (which
Am Dienstag, den 12.05.2020, 17:00 + schrieb Trevor:
> Jonas wrote 12/05/2020 13:42:46
>
> > In my opinion, there are currently far too many labels on GitLab. To
> > avoid the situation getting worse, please do not create new labels out
> > of thin air for now. Instead we should first contempl
Em seg., 11 de mai. de 2020 às 20:45, Dan Eble escreveu:
> Run autogen.sh and/or configure?
> —
> Dan
>
Yes, that's extacly what I was missing. Sorrythanks!
Jonas, you wrote 12/05/2020 14:49:27
Actually I think we should use milestones for this. They can be closed
and don't clutter the labels.
This comes with the disadvantage that there can be at most one
milestone set (which you also get with the scoped labels). This is not
correct for some patches
Jonas wrote 12/05/2020 13:42:46
> In my opinion, there are currently far too many labels on GitLab. To
> avoid the situation getting worse, please do not create new labels out
> of thin air for now. Instead we should first contemplate on what we
> really need and configure this appropriately. (Ad
On 5/12/20, James wrote:
> It was't blind Valentin, He did explain why he reverted it.
> Be fair.
*Cough* If the point is to facilitate merge requests, I certainly can
understand why Patch::* labels need to be at the top of the list; then
again, rearranging them is easy enough without “reverting”
Am Dienstag, den 12.05.2020, 17:15 +0200 schrieb Valentin Villenave:
> On 5/12/20, Jonas Hahnfeld wrote:
> > I'd really hope we can discuss things before changing...
>
> And *I*’d really hope “discuss things” can amount to more than
> “blindly reverting everything and anything that’s been done by
On 12/05/2020 16:15, Valentin Villenave wrote:
On 5/12/20, Jonas Hahnfeld wrote:
I'd really hope we can discuss things before changing...
And*I*’d really hope “discuss things” can amount to more than
“blindly reverting everything and anything that’s been done by someone
else”.
It was't bli
On 5/12/20, Jonas Hahnfeld wrote:
> I'd really hope we can discuss things before changing...
And *I*’d really hope “discuss things” can amount to more than
“blindly reverting everything and anything that’s been done by someone
else”.
Look, you’ve obviously spent quite some time setting this up a
Am Dienstag, den 12.05.2020, 16:58 +0200 schrieb Valentin Villenave:
> On 5/12/20, Jonas Hahnfeld wrote:
> > In my opinion, there are currently far too many labels on GitLab.
>
> Well, we used to say `Labels are cheap’ back when we were using Google Code…
>
> > please do not create new labels ou
On 5/12/20, Jonas Hahnfeld wrote:
> In my opinion, there are currently far too many labels on GitLab.
Well, we used to say `Labels are cheap’ back when we were using Google Code…
> please do not create new labels out of thin air for now.
Not entirely out of thin air. I’ve actually decreased the
Werner LEMBERG wrote
>>>I have a hard time imagining a performer bringing this to life in a
>>>manner justifying the complexity written into the score.
>>
>> Why?
>>
>> It seems you haven"t heard enough of today"s highly qualified and
>> dedicated performers ...
>
> It's not about performing this
Il giorno mar 12 mag 2020 alle 15:52, Thomas Morley
ha scritto:
Am Di., 12. Mai 2020 um 14:23 Uhr schrieb James :
Hello
On 12/05/2020 13:09, Federico Bruni wrote:
>
> Il giorno mar 12 mag 2020 alle 07:40, Dan Eble
ha
> scritto:
>> Rietveld used to send email to lilypond-devel for
Am Di., 12. Mai 2020 um 14:23 Uhr schrieb James :
>
> Hello
>
> On 12/05/2020 13:09, Federico Bruni wrote:
> >
> > Il giorno mar 12 mag 2020 alle 07:40, Dan Eble ha
> > scritto:
> >> Rietveld used to send email to lilypond-devel for all comments by
> >> default, though one could disable that when
Am Dienstag, den 12.05.2020, 13:43 + schrieb Carl Sorensen:
> On 5/12/20, 6:43 AM, Jonas Hahnfeld wrote:
>
> In my opinion, there are currently far too many labels on GitLab. To
> avoid the situation getting worse, please do not create new labels out
> of thin air for now. Instead we should f
On 5/12/20, 6:43 AM, "lilypond-devel on behalf of Jonas Hahnfeld"
wrote:
In my opinion, there are currently far too many labels on GitLab. To
avoid the situation getting worse, please do not create new labels out
of thin air for now. Instead we should first contemplate on what we
really need
In my opinion, there are currently far too many labels on GitLab. To
avoid the situation getting worse, please do not create new labels out
of thin air for now. Instead we should first contemplate on what we
really need and configure this appropriately. (Adding a label for every
possible warning th
Hello
On 12/05/2020 13:09, Federico Bruni wrote:
Il giorno mar 12 mag 2020 alle 07:40, Dan Eble ha
scritto:
Rietveld used to send email to lilypond-devel for all comments by
default, though one could disable that when commenting. Are we
satisfied with GitLab's not doing that?
I think so b
Il giorno mar 12 mag 2020 alle 07:40, Dan Eble ha
scritto:
Rietveld used to send email to lilypond-devel for all comments by
default, though one could disable that when commenting. Are we
satisfied with GitLab's not doing that?
As non developer, I'm satisfied :-)
I'm interested in foll
Rietveld used to send email to lilypond-devel for all comments by default,
though one could disable that when commenting. Are we satisfied with GitLab's
not doing that?
—
Dan
Am Dienstag, den 12.05.2020, 11:19 + schrieb Trevor:
> Another question:
>
> How do I remove labels no longer relevant (or entered incorrectly!) eg
> Patch:Push for verified issues?
If using the UI, click "Edit" next to the labels, find the one you want
to remove and untick. For the lazy, ty
Another question:
How do I remove labels no longer relevant (or entered incorrectly!) eg
Patch:Push for verified issues?
Trevor
-- Original Message --
From: "Kevin Barry"
To: "Federico Bruni"
Cc: "lilypond-devel"
Sent: 12/05/2020 08:15:02
Subject: Re: Verifying issues on Gitlab
H
Am Dienstag, den 12.05.2020, 10:03 +0200 schrieb Davide Liessi:
> Dear Federico,
>
> I can contribute too, probably on the same order as Carl:
>
> Il giorno mar 12 mag 2020 alle ore 01:12 Carl Sorensen
> ha scritto:
> > I'll start jumping in, but it will probably be on the order of about 10 per
Hello,
While doing some sanity tests this morning building doc (making sure
everything works for me for testing with new infrastructure) I spent
more time looking at the terminal window than I usually do.
During the make doc part where the 'page numbers' all whiz by I noticed
occasionally I'
Dear Federico,
I can contribute too, probably on the same order as Carl:
Il giorno mar 12 mag 2020 alle ore 01:12 Carl Sorensen
ha scritto:
> I'll start jumping in, but it will probably be on the order of about 10 per
> day, give or take.
Can you give me the appropriate permissions?
My GitLab
Am Di., 12. Mai 2020 um 09:19 Uhr schrieb Thomas Morley
:
>
> Am Di., 12. Mai 2020 um 08:47 Uhr schrieb Jonas Hahnfeld :
> >
> > Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley:
> > > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld
> > > :
> > > > Am Dienstag, den 12.05.202
Il giorno mar 12 mag 2020 alle 08:15, Kevin Barry
ha scritto:
Another handy way to do this is to run git tag --contains
.
(For me this is faster than github.)
Right, I forgot it.
It's faster indeed.
Thanks to everybody for jumping in so quickly!
Am Di., 12. Mai 2020 um 08:47 Uhr schrieb Jonas Hahnfeld :
>
> Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley:
> > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld :
> > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley:
> > > > Hi,
> > > >
> > > > currently I
Hi Federico,
Thank you for the instructions. I will try to help get them done as
well.
On Tue, May 12, 2020 at 12:28:24AM +0200, Federico Bruni wrote:
> In the last comment you should find a commit id (if it's missing you'll have
> to search it).
> The easiest and quickest way to verify that a ce
29 matches
Mail list logo
