labels on GitLab

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

labels on GitLab

Jonas Hahnfeld
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 that could be fixed is not helpful.)

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Carl Sorensen-3


On 5/12/20, 6:43 AM, "lilypond-devel on behalf of Jonas Hahnfeld" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> 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 and configure this appropriately. (Adding a label for every
possible warning that could be fixed is not helpful.)

->CS  And following up on this, it seems like we should move away from Fixed_x_y_z to Fixed::x.y.z

->CS  Although, that is still one label per release, at least the labels are all grouped under the prefix Fixed::

Carl


Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Jonas Hahnfeld
Am Dienstag, den 12.05.2020, 13:43 +0000 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 first contemplate on what we
> really need and configure this appropriately. (Adding a label for every
> possible warning that could be fixed is not helpful.)
>
> ->CS  And following up on this, it seems like we should move away from Fixed_x_y_z to Fixed::x.y.z
>
> ->CS  Although, that is still one label per release, at least the labels are all grouped under the prefix Fixed::
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 that have been backported. I'm still building
ideas for how to handle this.

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Valentin Villenave-3
In reply to this post by Jonas Hahnfeld
On 5/12/20, Jonas Hahnfeld <[hidden email]> 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 number of
concurrent labels in use, by merging midi with MIDI, warning with
Warning, musicxml2ly with musicxml, Build with Type::Build and so on.
(Case-sensitivity in this instance is cumbersome, as you can see from
the number and inconsistency of fixed_ and Fixed_ prefixed labels.)

I have indeed created a new label for type conversion issues, which
seemed appropriate, and another one for SVG output. This is the sort
of thing some of us used to find useful a dozen years ago; it may be
less so today but that remains to be seen.

> Instead we should first contemplate on what we
> really need and configure this appropriately. (Adding a label for every
> possible warning that could be fixed is not helpful.)

That is not my intent.

V.

Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Jonas Hahnfeld
Am Dienstag, den 12.05.2020, 16:58 +0200 schrieb Valentin Villenave:

> On 5/12/20, Jonas Hahnfeld <[hidden email]> 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 number of
> concurrent labels in use, by merging midi with MIDI, warning with
> Warning, musicxml2ly with musicxml, Build with Type::Build and so on.
> (Case-sensitivity in this instance is cumbersome, as you can see from
> the number and inconsistency of fixed_ and Fixed_ prefixed labels.)
>
> I have indeed created a new label for type conversion issues, which
> seemed appropriate, and another one for SVG output. This is the sort
> of thing some of us used to find useful a dozen years ago; it may be
> less so today but that remains to be seen.
>
> > Instead we should first contemplate on what we
> > really need and configure this appropriately. (Adding a label for every
> > possible warning that could be fixed is not helpful.)
>
> That is not my intent.
>
> V.
And I just saw you changed prioritized labels. This breaks the ordering
in merge requests, so I'm going to revert this now. I'd really hope we
can discuss things before changing...

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Valentin Villenave-3
On 5/12/20, Jonas Hahnfeld <[hidden email]> 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 and
you’re obviously much more familiar with the tools at hand; therefore,
I’m not gonna bother spending any more time trying to lend a hand
before *you* update the CG and properly explain what it is you want us
to do and/or not do, and how you want us to do and/or not do it.

Cheers,
-- V.

Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

James Lowe-9

On 12/05/2020 16:15, Valentin Villenave wrote:
> On 5/12/20, Jonas Hahnfeld<[hidden email]>  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 blind Valentin, He did explain why he reverted it.

Be fair.

We've all got to get used to this 'new' instance, and there will be some
bumps before it is all smooth.

I am sure Jonas will, once we see how it all pans out, suggest and get
some doc done.

Regards

James

Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Jonas Hahnfeld
In reply to this post by Valentin Villenave-3
Am Dienstag, den 12.05.2020, 17:15 +0200 schrieb Valentin Villenave:
> On 5/12/20, Jonas Hahnfeld <[hidden email]> 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”.

I think this statement is exaggerating. I've been working with James to
carry over as much of the process as possible. This includes mechanisms
to automatically add Patch::new to merge requests and a script to get
this into a form that can be used for both the email text and (still
manual) testing.
With SourceForge we used to rely on Phil's page to get a nice list of
where each patch is. During the trial I looked at how to do this in
GitLab and came up with issue priorities. When sorting like this:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
we get a very similar list. I'm not saying this is the only way and
maybe not even the best solution, but it works for the beginning.
The reason I was so quick about "reverting" the additions to
prioritized labels is that we'll (hopefully) see the next countdown
tomorrow. This will be the first using GitLab and merge requests
entirely. Adding even more bumps in there is likely frustrating for
everybody involved.

I fully acknowledge that none of the above is documented. That's
actually yet another reason to be careful when changing project-wide
settings. For what it's worth, I consider this to also apply to myself:
You'll not see me converting the Fixed_x.y.z to milestones without
discussing this first. LilyPond is a large project where most certainly
nobody understands all reasons. This applies to the code, but also to
the infrastructure.

Whew, this took much longer than expected to write calmly. Off to
something else for the rest of the evening.
Jonas

> Look, you’ve obviously spent quite some time setting this up and
> you’re obviously much more familiar with the tools at hand; therefore,
> I’m not gonna bother spending any more time trying to lend a hand
> before *you* update the CG and properly explain what it is you want us
> to do and/or not do, and how you want us to do and/or not do it.
>
> Cheers,
> -- V.

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Valentin Villenave-3
In reply to this post by James Lowe-9
On 5/12/20, James <[hidden email]> 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”, as I said,
anything and everything. (Furthermore, I have to wonder about the
order in which they are now: in order of priority, "push",
"countdown", "review", ""new", "waiting", "needs_work" -- how does
that make any sense? The order I suggested was the one we had on
SourceForge, starting with "new" -- but that got reverted with the
rest.)

OTOH, since this is _also_ a bug tracker, then Type::* and Statuf::*
labels should also, IMO, be prioritized (albeit at a lower level than
patches) since this is what quite a few contributors are gonna need --
speaking as one of the former Lily bug meisters here; I used to spend
a _lot_ of time daily on the Google tracker.

I did offer a rationale as to what I’d been doing in my previous
message; if we’re talking about “fairness” and “discussing” stuff,
then reverting stuff and disregarding proposals is hardly the way to
go.

V.

Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Trevor Daniels
In reply to this post by Jonas Hahnfeld
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. (Adding a label for
every
 > possible warning that could be fixed is not helpful.)

+1

Labels are most useful when they form a limited set. That way we all
know
what they are and what they mean. Inventing new labels is not really
helpful
as they can rarely be applied to anything else and after a short while
no one
knows they exist or what they mean.

Is there any way of limiting the set of labels which may be applied?
That
would also eliminate spelling mistakes as well as making selecting
Issues
by label more reliable.

Trevor
Reply | Threaded
Open this post in threaded view
|

Re[2]: labels on GitLab

Trevor Daniels
In reply to this post by Jonas Hahnfeld
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 that have been backported. I'm still building
>ideas for how to handle this.
Why do we need labels indicating a patch has been applied to several
releases when a patch has been back-ported? Indicating the earliest
release to which the patch has been applied should be adequate, or
am I missing something here?

Scoping the Fixed labels sounds good to me.

Trevor


Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Jonas Hahnfeld
In reply to this post by Trevor Daniels
Am Dienstag, den 12.05.2020, 17:00 +0000 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 contemplate on what we
> > really need and configure this appropriately. (Adding a label for every
> > possible warning that could be fixed is not helpful.)
>
> +1
>
> Labels are most useful when they form a limited set. That way we all know
> what they are and what they mean. Inventing new labels is not really helpful
> as they can rarely be applied to anything else and after a short while no one
> knows they exist or what they mean.
>
> Is there any way of limiting the set of labels which may be applied? That
> would also eliminate spelling mistakes as well as making selecting Issues
> by label more reliable.
Every user with at least "Reporter" permission level can add labels:
https://gitlab.com/help/user/permissions#project-members-permissions
That's not bad per se, and I'm not a fan of restricting everybody to
the smallest set of action they require.

That said, the situation is far better than on SourceForge: In the
GitLab UI you can only select existing labels. If you have a typo, the
dropdown will simply be empty and you need to explicitly click "Create
project label". If I remember correctly on SF, it would just create the
label without asking you which is likely responsible for the
inconsistency we have right now.

So I think we should just have some kind of policy where to discuss
things first.

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re[2]: labels on GitLab

Jonas Hahnfeld
In reply to this post by Trevor Daniels
Am Dienstag, den 12.05.2020, 17:08 +0000 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 you also get with the scoped labels). This is not
> > correct for some patches that have been backported. I'm still building
> > ideas for how to handle this.
> Why do we need labels indicating a patch has been applied to several
> releases when a patch has been back-ported? Indicating the earliest
> release to which the patch has been applied should be adequate, or
> am I missing something here?
This would be easiest solution for this. But some strategy is required
because we do have issues with multiple labels applied right now. As I
said, I think this needs some thought and discussion first.

> Scoping the Fixed labels sounds good to me.

This would still leave us with 329 labels even after merging duplicates
(if my script is to be trusted). All of these will be listed in the
dropdown for eternity, right next to things like "Regression" and such.
With milestones instead we can close all except the last three or so,
and they will not be selectable for new issues. This shrinks the list
considerably and makes the UI much easier to use.

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

James Lowe-9
In reply to this post by Jonas Hahnfeld
Hello

On 13/05/2020 07:15, Jonas Hahnfeld wrote:
> So I think we should just have some kind of policy where to discuss
> things first.

OK would there be any objection to removing the 'countdown-specific'
labels (i.e. new/review/countdown/push) from closed issues, or issues
that have been abandoned or have duplicate by them.

e.g.

https://gitlab.com/lilypond/lilypond/-/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=Patch%3A%3Apush

Later issues would not (or should not) have the push label assigned to
them but just 'fixed' or 'abandoned' or 'duplicate' labels.

While I know this may generate a lot of email noise, it will make things
clearer for me.

Ditto for those closed issues with 'review' label.

James


Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Jonas Hahnfeld
Am Mittwoch, den 13.05.2020, 10:24 +0100 schrieb James:

> Hello
>
> On 13/05/2020 07:15, Jonas Hahnfeld wrote:
> > So I think we should just have some kind of policy where to discuss
> > things first.
>
> OK would there be any objection to removing the 'countdown-specific'
> labels (i.e. new/review/countdown/push) from closed issues, or issues
> that have been abandoned or have duplicate by them.
>
> e.g.
>
> https://gitlab.com/lilypond/lilypond/-/issues?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=Patch%3A%3Apush
>
>
> Later issues would not (or should not) have the push label assigned to
> them but just 'fixed' or 'abandoned' or 'duplicate' labels.
>
> While I know this may generate a lot of email noise, it will make things
> clearer for me.
>
> Ditto for those closed issues with 'review' label.
In favor for Patch::new, Patch::review, Patch::countdown, and
Patch::push on closed issues. Not sure about Patch::abandoned and even
less about Patch::needs_work - these might still contain some work that
could be revived later on. However I haven't looked through them yet.

Regarding email noise, I think only removing a label will not send
notifications. We can even do so very efficiently by "bulk editing"
those issues: https://docs.gitlab.com/ee/user/project/bulk_editing.html

Regards
Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re[4]: labels on GitLab

Trevor Daniels
In reply to this post by Jonas Hahnfeld
Jonas, you wrote 13/05/2020 07:19:54

>Am Dienstag, den 12.05.2020, 17:08 +0000 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 you also get with the scoped labels). This is not
>>  > correct for some patches that have been backported. I'm still building
>>  > ideas for how to handle this.
>>  Why do we need labels indicating a patch has been applied to several
>>  releases when a patch has been back-ported? Indicating the earliest
>>  release to which the patch has been applied should be adequate, or
>>  am I missing something here?
>This would be easiest solution for this. But some strategy is required
>because we do have issues with multiple labels applied right now. As I
>said, I think this needs some thought and discussion first.
>
>>  Scoping the Fixed labels sounds good to me.
>
>This would still leave us with 329 labels even after merging duplicates
>(if my script is to be trusted). All of these will be listed in the
>dropdown for eternity, right next to things like "Regression" and such.
>With milestones instead we can close all except the last three or so,
>and they will not be selectable for new issues. This shrinks the list
>considerably and makes the UI much easier to use.
Milestones seem to have the wanted characteristics. But would we have
a hiatus with Labels before and Milestones after some changeover
release, both indicating the same thing? Even if that is so, it doesn't
seem too
problematic to me.

Trevor


Reply | Threaded
Open this post in threaded view
|

Re: Re[4]: labels on GitLab

Jonas Hahnfeld
Am Mittwoch, den 13.05.2020, 15:23 +0000 schrieb Trevor:

> Jonas, you wrote 13/05/2020 07:19:54
>
> > Am Dienstag, den 12.05.2020, 17:08 +0000 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 you also get with the scoped labels). This is not
> > >  > correct for some patches that have been backported. I'm still building
> > >  > ideas for how to handle this.
> > >  Why do we need labels indicating a patch has been applied to several
> > >  releases when a patch has been back-ported? Indicating the earliest
> > >  release to which the patch has been applied should be adequate, or
> > >  am I missing something here?
> > This would be easiest solution for this. But some strategy is required
> > because we do have issues with multiple labels applied right now. As I
> > said, I think this needs some thought and discussion first.
> >
> > >  Scoping the Fixed labels sounds good to me.
> >
> > This would still leave us with 329 labels even after merging duplicates
> > (if my script is to be trusted). All of these will be listed in the
> > dropdown for eternity, right next to things like "Regression" and such.
> > With milestones instead we can close all except the last three or so,
> > and they will not be selectable for new issues. This shrinks the list
> > considerably and makes the UI much easier to use.
> Milestones seem to have the wanted characteristics. But would we have
> a hiatus with Labels before and Milestones after some changeover
> release, both indicating the same thing? Even if that is so, it doesn't
> seem too problematic to me.
If we agree on milestones, I'd actually propose to add them to all
existing issues and get rid of the current labels afterwards. That's
some work (well, mostly orchestrating some scripts; not going to do
this by hand), but I don't think we'll want to live with ~500 labels
forever.

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

James Lowe-9
In reply to this post by Jonas Hahnfeld
On 12/05/2020 14:49, Jonas Hahnfeld wrote:

> Am Dienstag, den 12.05.2020, 13:43 +0000 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 first contemplate on what we
>> really need and configure this appropriately. (Adding a label for every
>> possible warning that could be fixed is not helpful.)
>>
>> ->CS  And following up on this, it seems like we should move away from Fixed_x_y_z to Fixed::x.y.z
>>
>> ->CS  Although, that is still one label per release, at least the labels are all grouped under the prefix Fixed::
> 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 that have been backported. I'm still building
> ideas for how to handle this.
>
> Jonas

I have some time today, so I am going through the '[FI|fi|Fi]xed' labels
and making sure we end up with just the 'Fixed_x_y_z' version. I then
delete the FI/fi labels once I have checked there are no issues with
then assigned that doesn't have a correct label.

I know that there maybe some decision eventually to go to 'Fixed::x.y.z'
but for now getting it all to a style that is consistent and what we
were using before.

I believe the old x_y_z style was used simply to make scripting easier -
no white space/escaping space to bother about for git-cl and whatever
other tools we had and we just carried this style over to Allura.

It might be possible to use gitlab's API to do this, but I don't know
how to do that and I might as well make a start and try to tidy up as
many of the FI/fi versions as possible.

James



Reply | Threaded
Open this post in threaded view
|

Re: labels on GitLab

Jonas Hahnfeld
Am Sonntag, den 17.05.2020, 11:14 +0100 schrieb James Lowe:

> On 12/05/2020 14:49, Jonas Hahnfeld wrote:
> > Am Dienstag, den 12.05.2020, 13:43 +0000 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 first contemplate on what we
> > > really need and configure this appropriately. (Adding a label for every
> > > possible warning that could be fixed is not helpful.)
> > >
> > > ->CS  And following up on this, it seems like we should move away from Fixed_x_y_z to Fixed::x.y.z
> > >
> > > ->CS  Although, that is still one label per release, at least the labels are all grouped under the prefix Fixed::
> > 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 that have been backported. I'm still building
> > ideas for how to handle this.
> >
> > Jonas
>
> I have some time today, so I am going through the '[FI|fi|Fi]xed' labels
> and making sure we end up with just the 'Fixed_x_y_z' version. I then
> delete the FI/fi labels once I have checked there are no issues with
> then assigned that doesn't have a correct label.
>
> I know that there maybe some decision eventually to go to 'Fixed::x.y.z'
> but for now getting it all to a style that is consistent and what we
> were using before.
>
> I believe the old x_y_z style was used simply to make scripting easier -
> no white space/escaping space to bother about for git-cl and whatever
> other tools we had and we just carried this style over to Allura.
>
> It might be possible to use gitlab's API to do this, but I don't know
> how to do that and I might as well make a start and try to tidy up as
> many of the FI/fi versions as possible.
I don't have a script ready for moving the issues yet, and I'm not
convinced it's a good idea to automate this. However I can offer to
bulk-create all the milestones so that you can directly assign these.
Is that fine for everyone?

Jonas

signature.asc (499 bytes) Download Attachment