ged to miss it until recently...
> It doesn't really matter, the step in the release procedure is just
> there to catch merge request without a milestone assigned. If there are
> some where the author has already taken care of this, that's fine.
I'll leave my merged MRs w
the release in a few
> clicks, without having to go through each MR
... and I already use it (and Phil used it before me).
> which reduces the incentive to assign milestones manually just
> after merging. Should we declare having the milestone assigned
> on release as the norm?
Le jeudi 22 juin 2023 à 14:32 +0200, Jean Abou Samra a écrit :
> So far, I think different people have different habits on when to set MR
> milestones — some do it just after merging, some don't, I do it when I
> remember to, and the MRs without milestone get their
> milestone o
So far, I think different people have different habits on when to set MR
milestones — some do it just after merging, some don't, I do it when I remember
to, and the MRs without milestone get their
milestone on the release day.
Recently, GitLab gained a "bulk edit" button in th
entually not me who builds and tags the releases.
> Personally I don't see much harm in moving a few issues and MRs across
> milestones from a short period of "contention". It causes some
> additional notification emails, but not more than other activity does.
I'm not to
ve to monitor a separate branch?
If this is of concern to you, please propose something that would work
for you and get feedback from Phil. While I happen to be involved, it's
eventually not me who builds and tags the releases.
Personally I don't see much harm in moving a few issues and M
On Oct 12, 2020, at 02:21, Jonas Hahnfeld wrote:
>
> Am Sonntag, den 11.10.2020, 12:12 -0400 schrieb Dan Eble:
>> On Oct 11, 2020, at 10:33, Jonas Hahnfeld wrote:
>>> 2.21.7 has already been built and tagged (see git), the commits will
>>
>> I need a little more help than "see git".
>
> I was
Am Sonntag, den 11.10.2020, 12:12 -0400 schrieb Dan Eble:
> On Oct 11, 2020, at 10:33, Jonas Hahnfeld wrote:
> > 2.21.7 has already been built and tagged (see git), the commits will
>
> I need a little more help than "see git".
I was referring to the new tag in the repository, which gives a pret
On Oct 11, 2020, at 10:33, Jonas Hahnfeld wrote:
>
> 2.21.7 has already been built and tagged (see git), the commits will
I need a little more help than "see git". I can see, after the fact, a merge
from release/unstable into master that updated the version. I guess I need to
check the relea
t;
> The MR added regression tests with \version "2.21.7". The VERSION file says
> this:
>
> MAJOR_VERSION=2
> MINOR_VERSION=21
> PATCH_LEVEL=7
> MY_PATCH_LEVEL=
> VERSION_STABLE=2.20.0
> VERSION_DEVEL=2.21.6
>
> But the milestone for the MR now set to 2.2
I do not understand which version/milestone to use when I add regression tests
and close a merge request or issue.
To pick a specific example,
https://gitlab.com/lilypond/lilypond/-/merge_requests/445
The MR added regression tests with \version "2.21.7". The VERSION file says
this:
MAJOR_VER
s related to a single issue.
> >
> > ...
> > > I think it would be sufficient to have the final release that included
> > > all commits, but wanted to check back if everybody agrees on that.
> >
> > Sounds reasonable to me.
>
> Great. I'll go ahead w
have the final release that included
> > all commits, but wanted to check back if everybody agrees on that.
>
> Sounds reasonable to me.
Great. I'll go ahead with creating and assigning the milestones
tomorrow morning.
Regards
Jonas
signature.asc
Description: This is a digitally signed message part
Jonas, you wrote 29/06/2020 12:49:08
I got the list down to five corner cases, all involving multiple
commits related to a single issue.
https://gitlab.com/lilypond/lilypond/-/issues/154
https://gitlab.com/lilypond/lilypond/-/issues/1861
These two issues saw additional fixes after several yea
On Jun 29, 2020, at 07:49, Jonas Hahnfeld wrote:
>
> I got the list down to five corner cases, all involving multiple
> commits related to a single issue.
...
> I think it would be sufficient to have the final release that included
> all commits, but wanted to check back if everybody agrees on th
on't have time to search the archives, though, but I recall it has
> > > been discussed already).
> >
> > Yes, see:
> > https://lists.gnu.org/archive/html/lilypond-devel/2020-05/msg00323.html
> >
> >
> > Actually, it might be a good idea to deal with
https://lists.gnu.org/archive/html/lilypond-devel/2020-05/msg00323.html
>
> Actually, it might be a good idea to deal with these issues before
> running the script, so all (initial) milestones can be assigned
> automatically. Ok for everyone?
I'll start working on these issue
Am Mittwoch, den 24.06.2020, 13:23 +0200 schrieb Jonas Hahnfeld:
> Am Dienstag, den 23.06.2020, 13:04 -0400 schrieb Dan Eble:
> > On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote:
> > > Pretty much that: You can only have one label from the same scope, and
> > > assigning a second automatically rem
s opinion too, if I remember well
> (I don't have time to search the archives, though, but I recall it has
> been discussed already).
Yes, see:
https://lists.gnu.org/archive/html/lilypond-devel/2020-05/msg00323.html
Actually, it might be a good idea to deal with these issues before
runnin
Am Dienstag, den 23.06.2020, 13:04 -0400 schrieb Dan Eble:
> On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote:
> > Pretty much that: You can only have one label from the same scope, and
> > assigning a second automatically removes the old (cf. Patch::*). I
> > actually agree that multiple Type's mi
all of them in order to make the procedure work.
> > I think it makes more sense to set the milestone when closing the issue
> > (see above) and afterwards search for issues in Status::Fixed. Again,
> > no change from the current procedure except for adapting the technical
>
nd again, I don't think there's a
change in action here except for replacing the labels by milestones.
[...]
Whether we want to continue to verify issues this way is another question.
Assuming we do, here is how I would envision the process on GitLab:
- When a merge request adressing
James writes:
> On 23/06/2020 20:47, Jonas Hahnfeld wrote:
>> Never understood the difference between Started and Accepted either.
Presumably "New" and "Accepted". "Started" means that somebody is
working on it, to avoid duplication of effort.
>
> While we have definitions in the CG as Carl po
On 23/06/2020 20:47, Jonas Hahnfeld wrote:
Never understood the difference between Started and Accepted either.
While we have definitions in the CG as Carl pointed out the context of
this was, if I remember correctly, to a make sure developers could see
clearly if a tracker issue entered ha
Am Dienstag, den 23.06.2020, 23:40 +0200 schrieb Valentin Villenave:
> On 6/23/20, Jonas Hahnfeld wrote:
> > I knew that description and, honestly, that would be a show stopper for
> > me reporting any issue to a project in 2020.
>
> Why? Because mailing lists are a thing of the past in your vie
On 6/23/20, Jonas Hahnfeld wrote:
> I knew that description and, honestly, that would be a show stopper for
> me reporting any issue to a project in 2020.
Why? Because mailing lists are a thing of the past in your view? :-)
Sending an e-mail to an open mailing list is much more universal and
ac
On Tue, Jun 23, 2020 at 2:25 PM Jonas Hahnfeld wrote:
>
> Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen:
> > Accepted: the Bug Squad added it, or reviewed the item.
> > Started: a contributor is working on a fix. Owner should change to be
> > this contributor.
> >
> > Closed issu
Am Dienstag, den 23.06.2020, 14:11 -0600 schrieb Carl Sorensen:
> On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote:
> > Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra:
> > > Hi,
>
>
> > > Actually, I think the while Status family of scoped labels will no longer
> > > need t
On Tue, Jun 23, 2020 at 2:04 PM Jonas Hahnfeld wrote:
>
> Am Dienstag, den 23.06.2020, 20:54 +0200 schrieb Jean Abou Samra:
> > Hi,
> > Actually, I think the while Status family of scoped labels will no longer
> > need to exist. Status::Fixed and Status::Verified are replaced as above.
> > In add
x27;d like to propose that we replace the labels Fixed_x_y_z
> > > > with milestones x.y.z and use these to track which issues were fixed
> > > > for a particular release. This has the advantage of a) less labels
> > > > which makes the drop-downs more usable and
Hi,
Le 23/06/2020 à 17:50, Jonas Hahnfeld a écrit :
Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave:
On 6/22/20, Jonas Hahnfeld wrote:
In short, I'd like to propose that we replace the labels Fixed_x_y_z
with milestones x.y.z and use these to track which issues were
On Jun 23, 2020, at 04:40, Jonas Hahnfeld wrote:
>>
> Pretty much that: You can only have one label from the same scope, and
> assigning a second automatically removes the old (cf. Patch::*). I
> actually agree that multiple Type's might be useful. If others are in
> favor as well, we can just re
Am Dienstag, den 23.06.2020, 15:54 +0200 schrieb Valentin Villenave:
> On 6/22/20, Jonas Hahnfeld wrote:
> > In short, I'd like to propose that we replace the labels Fixed_x_y_z
> > with milestones x.y.z and use these to track which issues were fixed
> > for a partic
On 6/22/20, Jonas Hahnfeld wrote:
> In short, I'd like to propose that we replace the labels Fixed_x_y_z
> with milestones x.y.z and use these to track which issues were fixed
> for a particular release. This has the advantage of a) less labels
> which makes the drop-downs more
Hi James,
Am Dienstag, den 23.06.2020, 08:00 +0100 schrieb James:
> Hello
>
> On 22/06/2020 18:33, Jonas Hahnfeld wrote:
> > In short, I'd like to propose that we replace the labels Fixed_x_y_z
> > with milestones x.y.z and use these to track which issues were fixed
&g
Hello
On 22/06/2020 18:33, Jonas Hahnfeld wrote:
In short, I'd like to propose that we replace the labels Fixed_x_y_z
with milestones x.y.z and use these to track which issues were fixed
for a particular release.
Just so you know I have just gone through all the 'Fixed_' label
In short, I'd like to propose that we replace the labels Fixed_x_y_z
with milestones x.y.z and use these to track which issues were fixed
for a particular release. This has the advantage of a) less labels
which makes the drop-downs more usable and b) the possibility to close
milestones. Afte
37 matches
Mail list logo
