Le 02/11/2020 à 21:03, Michael Käppler a écrit :
Am 02.11.2020 um 19:47 schrieb Jean Abou Samra:
Le 02/11/2020 à 18:18, Jean Abou Samra a écrit :
Thanks. I'm going ahead to change the labels right now.
Merge request put up at
https://gitlab.com/lilypond/lilypond/-/merge_requests/493
and
Am 02.11.2020 um 19:47 schrieb Jean Abou Samra:
Le 02/11/2020 à 18:18, Jean Abou Samra a écrit :
Thanks. I'm going ahead to change the labels right now.
Merge request put up at
https://gitlab.com/lilypond/lilypond/-/merge_requests/493
and labels renamed and deleted as appropriate, except for
Le 02/11/2020 à 18:18, Jean Abou Samra a écrit :
Thanks. I'm going ahead to change the labels right now.
Merge request put up at
https://gitlab.com/lilypond/lilypond/-/merge_requests/493
and labels renamed and deleted as appropriate, except for one,
namely Status::started. While verifying
Le 01/11/2020 à 20:50, Dan Eble a écrit :
On Nov 1, 2020, at 14:12, Jean Abou Samra wrote:
Le 01/11/2020 à 19:11, Jonas Hahnfeld a écrit :
Am Sonntag, den 01.11.2020, 17:03 +0100 schrieb Jean Abou Samra:
In order to finish things properly, I would like to implement
the resolution here.Is
On Nov 1, 2020, at 14:12, Jean Abou Samra wrote:
>
> Le 01/11/2020 à 19:11, Jonas Hahnfeld a écrit :
>
>> Am Sonntag, den 01.11.2020, 17:03 +0100 schrieb Jean Abou Samra:
>>> In order to finish things properly, I would like to implement
>>> the resolution here.Is this fine by everyone? Jonas?
Le 01/11/2020 à 19:11, Jonas Hahnfeld a écrit :
Am Sonntag, den 01.11.2020, 17:03 +0100 schrieb Jean Abou Samra:
In order to finish things properly, I would like to implement
the resolution here.Is this fine by everyone? Jonas?
To recap:
- Update CG,
- Delete the following under "Status":
Am Sonntag, den 01.11.2020, 17:03 +0100 schrieb Jean Abou Samra:
> In order to finish things properly, I would like to implement
> the resolution here.Is this fine by everyone? Jonas?
>
> To recap:
> - Update CG,
> - Delete the following under "Status": new, accepted, started,
> fixed,
In order to finish things properly, I would like to implement
the resolution here.Is this fine by everyone? Jonas?
To recap:
- Update CG,
- Delete the following under "Status": new, accepted, started,
fixed, verified.
- Rename Status::invalid and Status::duplicate into Invalid
and Duplicate,
On 10/26/2020 12:42 PM, Jean Abou Samra wrote:
the purpose is to cover also issues that are not actually bugs but were
opened because of a mis-expectation of the program's behavior
(currently, "Invalid").
"Not Applicable" or "N/A" or "Does Not Apply"?
"Not A Bug"?
Maybe too negative:
Le 26/10/2020 à 18:32, Karlin High a écrit :
On 10/26/2020 12:16 PM, Jean Abou Samra wrote:
Something like "Void" or "Won't fix" would be a good option in my
opinion.
Would "Inactive" be too negative or inaccurate?
Not sure about this one: the purpose is to cover also issues that are
not
On 10/26/2020 12:16 PM, Jean Abou Samra wrote:
Something like "Void" or "Won't fix" would be a good option in my opinion.
Would "Inactive" be too negative or inaccurate?
--
Karlin High
Missouri, USA
Le 26/10/2020 à 17:26, Dan Eble a écrit :
On Oct 26, 2020, at 11:50, Jean Abou Samra wrote:
- Status::invalid, Status::duplicate and Status::shelved converted
to plain labels.
What is the value of "shelved"? We have 3 issues with that label and I don't
see what makes them special.
for newbies) than undertaking this task.
I don't think that issue verification requires development knowledge,
quite the opposite as it was meant to be handled by non-programmers.
I do see some benefit in making sure that the original issue is indeed
fixed with the released binaries, but as it would
On Oct 26, 2020, at 11:50, Jean Abou Samra wrote:
>>> - Status::invalid, Status::duplicate and Status::shelved converted
>>> to plain labels.
>> What is the value of "shelved"? We have 3 issues with that label and I
>> don't see what makes them special.
>
>
> As far as I know, the
task.
I don't think that issue verification requires development knowledge,
quite the opposite as it was meant to be handled by non-programmers.
I do see some benefit in making sure that the original issue is indeed
fixed with the released binaries, but as it would not be me who does
the work, I d
Le 26/10/2020 à 13:14, Dan Eble a écrit :
On Oct 25, 2020, at 15:43, Jean Abou Samra wrote:
I propose that we:
- Remove this procedure.
- Also remove the "Status" scoped label, adding non-scoped labels
when necessary.
- Status::new and Status::accepted: no longer applicable since
On Oct 25, 2020, at 15:43, Jean Abou Samra wrote:
>
> I propose that we:
>
> - Remove this procedure.
>
> - Also remove the "Status" scoped label, adding non-scoped labels
> when necessary.
>
> - Status::new and Status::accepted: no longer applicable since
> there is no longer a
Hi all,
Before 2.21.80 is released, I'd like to restart this debate
(which might be contentious; we'll see).
Basically, I think our current processes obviate the effort
to go through all fixed issues and verify them. The primary job
was to ensure that patches had landed in master, due to a
of these issues.
This doesn't answer Jonas' initial question: what should be done,
in terms of policies, with regard to issue verification? I don't
know. Personally I think it's not really needed as long as every
bug fix contains a regression test.
Do we agree that 'verification' in the sense
bugs, for example. I reopened a few of these issues.
This doesn't answer Jonas' initial question: what should be done,
in terms of policies, with regard to issue verification? I don't
know. Personally I think it's not really needed as long as every
bug fix contains a regression test.
Do we agree
to reproduce memory-related
bugs, for example. I reopened a few of these issues.
This doesn't answer Jonas' initial question: what should be done,
in terms of policies, with regard to issue verification? I don't
know. Personally I think it's not really needed as long as every
bug fix contains a regression
Abou Samra"
; "lilypond-devel"
Sent: Friday, September 18, 2020 7:57 AM
Subject: Re: issue verification
Il giorno ven 18 set 2020 alle 14:48, Michael Käppler
ha scritto:
Having looked at only four issues now, there were already two that
described bugs, but lacked a description how to reproduce the problem
Yes, it's quite common: I would say >90% of cases.
In my experience verifying issues was
Am 18.09.2020 um 13:07 schrieb Michael Käppler:
Am 18.09.2020 um 11:15 schrieb Phil Holmes:
I don't know if this isn't clear, but just to state the original point
of verifying issues.
If the change is claimed to fix a bug, we compile the previously buggy
code with the release in which the bug
for 2.21.2 today.
Cheers,
Michael
--
Phil Holmes
- Original Message - From: "Jonas Hahnfeld"
To: "Michael Käppler" ; "Jean Abou Samra"
; "lilypond-devel"
Sent: Friday, September 18, 2020 7:57 AM
Subject: Re: issue verification
Am 18.09.2020 um 08:57 schrieb Jonas Hahnfeld:
Am Donnerstag, den 17.09.2020, 23:01 +0200 schrieb Michael Käppler:
From my point of view, if an issue is
1. closed
2. marked as "Status::Fixed"
3. assigned to milestone x.y.z
one can be sure that it is fixed in release x.y.z
What should we
Am Donnerstag, den 17.09.2020, 23:01 +0200 schrieb Michael Käppler:
> From my point of view, if an issue is
> 1. closed
> 2. marked as "Status::Fixed"
> 3. assigned to milestone x.y.z
>
> one can be sure that it is fixed in release x.y.z
> What should we verify?
See below.
> Another point is
Am 17.09.2020 um 23:01 schrieb Michael Käppler:
From my point of view, if an issue is
1. closed
2. marked as "Status::Fixed"
3. assigned to milestone x.y.z
one can be sure that it is fixed in release x.y.z
What I meant was: 'that the commit with the purpose of
fixing the issue has gone into
Am 17.09.2020 um 21:32 schrieb Jonas Hahnfeld:
Am Donnerstag, den 17.09.2020, 20:58 +0200 schrieb Jean Abou Samra:
What I do not yet understand is when milestones should be assigned
to issues and MRs. So far Jonas has done this from time to time. That was
after each release, right?
Yes, mostly
Le 17/09/2020 à 22:34, Jonas Hahnfeld a écrit :
Am Donnerstag, den 17.09.2020, 20:30 + schrieb Trevor:
Maybe I'm misunderstanding the problem, but a list of issues to verify
for a particular release, say 2.21.4, can be found by
Issues -> Milestones -> Release LilyPond 2.21.4 -> Milestone
Am Donnerstag, den 17.09.2020, 20:30 + schrieb Trevor:
> Jonas, you wrote 17/09/2020 20:32:31
> Subject: Re: issue verification
>
> > The problem I'm seeing is that it would become harder to find the
> > issues to verify: Most of the time, there will be fixed issue
Jonas, you wrote 17/09/2020 20:32:31
Subject: Re: issue verification
The problem I'm seeing is that it would become harder to find the
issues to verify: Most of the time, there will be fixed issues for the
current version still in development, which cannot be verified. Making
everybody wanting
Am Donnerstag, den 17.09.2020, 20:58 +0200 schrieb Jean Abou Samra:
> What I do not yet understand is when milestones should be assigned
> to issues and MRs. So far Jonas has done this from time to time. That was
> after each release, right?
Yes, mostly so. I'm just continuing what CG previously
Hi,
Le 17/09/2020 à 13:27, Michael Käppler a écrit :
Am 17.09.2020 um 09:47 schrieb Jonas Hahnfeld:
Hi all,
unless I'm missing something, there has been no activity on this since
the community effort in May [1][2] and issues since version 2.21.2
don't yet have Status::Verified labels. As
Am 17.09.2020 um 09:47 schrieb Jonas Hahnfeld:
Hi all,
unless I'm missing something, there has been no activity on this since
the community effort in May [1][2] and issues since version 2.21.2
don't yet have Status::Verified labels. As I'm currently updating CG to
mention our use of
Hi all,
unless I'm missing something, there has been no activity on this since
the community effort in May [1][2] and issues since version 2.21.2
don't yet have Status::Verified labels. As I'm currently updating CG to
mention our use of milestones (not sure why I forgot about this
previously),
36 matches
Mail list logo
