Re: labels on GitLab

[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.

James