2.21.0 Issues all verified!

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

2.21.0 Issues all verified!

Carl Sorensen
I just verified the last of the issues with Fixed_2_21_0.  Thanks everybody
for all the work!

I found a few issues that had misspelled labels, and relabeled them to the
proper spelling.

It looks like we still need to verify issues for 2.20, as well as for 2.21.1

There are also a few unverified issues from older releases, but I'll work
through those this afternoon.

Thanks,

Carl
Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Carl Sorensen
On Sat, May 16, 2020 at 2:12 PM Carl Sorensen <[hidden email]> wrote:
>
> I just verified the last of the issues with Fixed_2_21_0.  Thanks everybody for all the work!
>
> I found a few issues that had misspelled labels, and relabeled them to the proper spelling.
>
> It looks like we still need to verify issues for 2.20, as well as for 2.21.1

I've now verified all of the outstanding issues for 2.20 (some of them
had to be moved to 2.21.0, as they had not been placed into 2.20.

It looks like we have 33 issues to be verified for 2.21.1.  Muuch
better than 522+ for 2.21.0!  Thanks to all who have helped us get
back to a more regular release schedule!

Carl

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Valentin Villenave-3
On 5/16/20, Carl Sorensen <[hidden email]> wrote:
> Thanks to all who have helped us get
> back to a more regular release schedule!

Well, thanks to you!  And to everybody who gave a hand (Federico,
Karlin, and a few others?).  For a little while I was reminded of the
Google tracker era, and of all the great work Graham contributed to.
(Though today some of us evidently have a different approach in mind
-- and didn’t seem to be impressed by this collective effort, which
Jonas criticized as favoring "quantity over quality".)

We’ll see what the issue-tracking policy becomes in the future
(marking issues as "Verified" may well go the way of the dodo, since
from what Jonas told me GitLab pushes us to only have two states: Open
and Closed).  My main concern is that merge requests shoudn’t get
prioritized over code consistency and QA.  (From a personal point of
view, I am feeling quite discouraged but that’s my sort-of default
mode so it doesn’t carry much meaning.)

Cheers,
-- V.

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Karlin High
On 5/16/2020 5:05 PM, Valentin Villenave wrote:
> Well, thanks to you!  And to everybody who gave a hand (Federico,
> Karlin, and a few others?).

Thanks also, Carl! I verified exactly one issue, slowly and carefully
just to learn the process. Last week didn't give me capacity to get much
beyond that. I expect that an effort like this one is easier to
crowd-source than things like the Python3 upgrade.

I'm increasingly convinced that group efforts are best raised by giving
step-by-step instructions. As was seen here, or in Knut Petersen's
"Please Test GUB" work.
--
Karlin High
Missouri, USA

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

David Kastrup
In reply to this post by Valentin Villenave-3
Valentin Villenave <[hidden email]> writes:

> On 5/16/20, Carl Sorensen <[hidden email]> wrote:
>> Thanks to all who have helped us get
>> back to a more regular release schedule!
>
> Well, thanks to you!  And to everybody who gave a hand (Federico,
> Karlin, and a few others?).  For a little while I was reminded of the
> Google tracker era, and of all the great work Graham contributed to.
> (Though today some of us evidently have a different approach in mind
> -- and didn’t seem to be impressed by this collective effort, which
> Jonas criticized as favoring "quantity over quality".)
>
> We’ll see what the issue-tracking policy becomes in the future
> (marking issues as "Verified" may well go the way of the dodo, since
> from what Jonas told me GitLab pushes us to only have two states: Open
> and Closed).  My main concern is that merge requests shoudn’t get
> prioritized over code consistency and QA.  (From a personal point of
> view, I am feeling quite discouraged but that’s my sort-of default
> mode so it doesn’t carry much meaning.)

Uh, I think it's the wrong point of time to feel discouraged: we are at
the current point of time figuring out what the tool does well and not
so well under which usage.

Personally, so far my main issue is, well, the workflow bypassing
issues.  Changes that are only presented as merge requests without any
accompanying issue are just too intangible for my taste: those
correspond more to what we previously said "things like that you can
push directly to staging".  I find it awkward to find my way around
them, and after pushing there does not seem an obvious reverse relation
to a tangible report that one could easily derive from seeing the commit
in the repository.

I prefer having an actual issue number for the details for anything of
non-trivial nature.

But there is no point in being discouraged as long as we haven't even
decided on particular workflows: instead one should bring up problems
one sees.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Karlin High
On 5/16/2020 5:28 PM, David Kastrup wrote:
> I prefer having an actual issue number for the details for anything of
> non-trivial nature.

I don't know how related this is, but GitLab has "Description templates."

<https://docs.gitlab.com/ee/user/project/description_templates.html>

It looks like that could prefill descriptions for issues and merge
requests with common questions, like does this need a regtest, does it
need documentation, does it need a "Changes" entry, etc.
--
Karlin High
Missouri, USA

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Carl Sorensen
In reply to this post by David Kastrup
On Sat, May 16, 2020 at 4:28 PM David Kastrup <[hidden email]> wrote:

>
> Uh, I think it's the wrong point of time to feel discouraged: we are at
> the current point of time figuring out what the tool does well and not
> so well under which usage.

I completely agree with this.  I miss the Rietveld review process, but
mostly I'm not familiar at all with the GitLab one.

>
> Personally, so far my main issue is, well, the workflow bypassing
> issues.  Changes that are only presented as merge requests without any
> accompanying issue are just too intangible for my taste: those
> correspond more to what we previously said "things like that you can
> push directly to staging".  I find it awkward to find my way around
> them, and after pushing there does not seem an obvious reverse relation
> to a tangible report that one could easily derive from seeing the commit
> in the repository.
>
> I prefer having an actual issue number for the details for anything of
> non-trivial nature.

+1

I believe we should declare (and try to enforce) a policy that the
name of a branch in a merge request should include an issue number.

With git-cl upload, an issue was automatically created if it didn't
already exist.  I really liked that functionality.  If we can't do
such a thing automatically in GitLab, I think we should do it by
policy.  As you say, it's very hard to track merge requests without a
tie to the issue tracker.

Thanks,

Carl

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Dev mailing list
In reply to this post by David Kastrup
Am Sonntag, den 17.05.2020, 00:28 +0200 schrieb David Kastrup:

> Personally, so far my main issue is, well, the workflow bypassing
> issues.  Changes that are only presented as merge requests without any
> accompanying issue are just too intangible for my taste: those
> correspond more to what we previously said "things like that you can
> push directly to staging".  I find it awkward to find my way around
> them, and after pushing there does not seem an obvious reverse relation
> to a tangible report that one could easily derive from seeing the commit
> in the repository.
>
> I prefer having an actual issue number for the details for anything of
> non-trivial nature.
I agree on having an issue for every bug we fix, especially those
coming from the bug-lilypond list. It's easier to have those in one
place instead of searching if a merge request happens to fix a problem.
For cleanups, compiler warnings or performance work I think having only
a MR is fine. In my opinion creating an issue for about any code change
is somewhat overkill. But there are guidelines mandating this, so I'd
be open to discussing the merits if somebody thinks it's the better
approach. After all, we had this previously...

Regards
Jonas

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

Re[2]: 2.21.0 Issues all verified!

Trevor Daniels
Jonas Hahnfeld wrote 17/05/2020 11:57:10

>Am Sonntag, den 17.05.2020, 00:28 +0200 schrieb David Kastrup:
>>  Personally, so far my main issue is, well, the workflow bypassing
>>  issues.  Changes that are only presented as merge requests without any
>>  accompanying issue are just too intangible for my taste: those
>>  correspond more to what we previously said "things like that you can
>>  push directly to staging".  I find it awkward to find my way around
>>  them, and after pushing there does not seem an obvious reverse relation
>>  to a tangible report that one could easily derive from seeing the commit
>>  in the repository.
>>
>>  I prefer having an actual issue number for the details for anything of
>>  non-trivial nature.
>
>I agree on having an issue for every bug we fix, especially those
>coming from the bug-lilypond list. It's easier to have those in one
>place instead of searching if a merge request happens to fix a problem.
>For cleanups, compiler warnings or performance work I think having only
>a MR is fine. In my opinion creating an issue for about any code change
>is somewhat overkill. But there are guidelines mandating this, so I'd
>be open to discussing the merits if somebody thinks it's the better
>approach. After all, we had this previously...
>
I agree we need an issue for every bug we uncover, but fixes that are
trivial (in the sense that they are most unlikely to break anything) are
fine to simply issue a MR. In this past we left this judgement to the
fixer and it seemed not to cause any problems. Such trivial fixes are
now more visible than they were, so are even less likely to cause
problems or be applied inappropriately.

It is important to be able to move easily from Issue to Fix and back
when investigating possible problems in the future, so we should
ensure all the tags and links are in place before a fix is pushed.

Trevor


Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Han-Wen Nienhuys-3
In reply to this post by Carl Sorensen
On Sun, May 17, 2020 at 3:12 AM Carl Sorensen <[hidden email]> wrote:

> > Personally, so far my main issue is, well, the workflow bypassing
> > issues.  Changes that are only presented as merge requests without any
> > accompanying issue are just too intangible for my taste: those
> > correspond more to what we previously said "things like that you can
> > push directly to staging".  I find it awkward to find my way around
> > them, and after pushing there does not seem an obvious reverse relation
> > to a tangible report that one could easily derive from seeing the commit
> > in the repository.
> >
> > I prefer having an actual issue number for the details for anything of
> > non-trivial nature.
>
> +1
>
> I believe we should declare (and try to enforce) a policy that the
> name of a branch in a merge request should include an issue number.

I want to dissent here: I think that issues should not be used unless
there is an actual bug or other effort that needs to be tracked
separately from the code.

We now have 3 distinct places to put information

1) issue discussion
2) merge request
3) commit message

for posterity, it is usually easier to put all info inside the commit
message, because it doesn't rely on external sites (rietveld,
sourceforge, gitlab). We need the MRs to discuss the code and commit
message. What benefit do we get from also having an issue?

There is a definite downside to using the issue tracker, which is that
filing bugs becomes harder, because all the chatter from the
development process makes it harder to find relevant bugs.

> With git-cl upload, an issue was automatically created if it didn't
> already exist.  I really liked that functionality.  If we can't do
> such a thing automatically in GitLab, I think we should do it by
> policy.  As you say, it's very hard to track merge requests without a
> tie to the issue tracker.

what does "track" mean in this context?

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

David Kastrup
Han-Wen Nienhuys <[hidden email]> writes:

> On Sun, May 17, 2020 at 3:12 AM Carl Sorensen <[hidden email]> wrote:
>> > Personally, so far my main issue is, well, the workflow bypassing
>> > issues.  Changes that are only presented as merge requests without any
>> > accompanying issue are just too intangible for my taste: those
>> > correspond more to what we previously said "things like that you can
>> > push directly to staging".  I find it awkward to find my way around
>> > them, and after pushing there does not seem an obvious reverse relation
>> > to a tangible report that one could easily derive from seeing the commit
>> > in the repository.
>> >
>> > I prefer having an actual issue number for the details for anything of
>> > non-trivial nature.
>>
>> +1
>>
>> I believe we should declare (and try to enforce) a policy that the
>> name of a branch in a merge request should include an issue number.
>
> I want to dissent here: I think that issues should not be used unless
> there is an actual bug or other effort that needs to be tracked
> separately from the code.
>
> We now have 3 distinct places to put information
>
> 1) issue discussion
> 2) merge request
> 3) commit message
>
> for posterity, it is usually easier to put all info inside the commit
> message, because it doesn't rely on external sites (rietveld,
> sourceforge, gitlab). We need the MRs to discuss the code and commit
> message. What benefit do we get from also having an issue?

The merge requests are not referenceable in the same manner as issues
are.  We have carried over our issue numbers but not the Rietveld
numbers.  So the link from commit message to merge request is just not
there: a merge request does not really fill more of a need than Rietveld
did previously.

The commit message is not, in my book, the right place to carry an
adversarial discussion.  Rather it's the place for the conclusion.
Circumstances may change invalidating the conclusion: without the
possibility to refer back to the previous discussion, understanding the
premises under which a conclusion has been drawn is not possible.

We want to avoid developers stomping over the efforts of other
developers unwittingly because they were not able to look up the
discussions leading to a certain outcome.

> There is a definite downside to using the issue tracker, which is that
> filing bugs becomes harder, because all the chatter from the
> development process makes it harder to find relevant bugs.

The chatter is under a heading.  If you don't select the heading, you
don't get the chatter.

>> With git-cl upload, an issue was automatically created if it didn't
>> already exist.  I really liked that functionality.  If we can't do
>> such a thing automatically in GitLab, I think we should do it by
>> policy.  As you say, it's very hard to track merge requests without a
>> tie to the issue tracker.
>
> what does "track" mean in this context?

Figuring out what discussions and decisions led to a certain approach
being implemented.  In a colloborative development environment, you
don't want every developer inventing the wheel new while deflating
wheels other developers have installed.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 2.21.0 Issues all verified!

Han-Wen Nienhuys-3
On Sun, May 17, 2020 at 3:22 PM David Kastrup <[hidden email]> wrote:

> > for posterity, it is usually easier to put all info inside the commit
> > message, because it doesn't rely on external sites (rietveld,
> > sourceforge, gitlab). We need the MRs to discuss the code and commit
> > message. What benefit do we get from also having an issue?
>
> The merge requests are not referenceable in the same manner as issues
> are.  We have carried over our issue numbers but not the Rietveld
> numbers.  So the link from commit message to merge request is just not
> there: a merge request does not really fill more of a need than Rietveld
> did previously.
>
> The commit message is not, in my book, the right place to carry an
> adversarial discussion.  Rather it's the place for the conclusion.
> Circumstances may change invalidating the conclusion: without the
> possibility to refer back to the previous discussion, understanding the
> premises under which a conclusion has been drawn is not possible.
>
> We want to avoid developers stomping over the efforts of other
> developers unwittingly because they were not able to look up the
> discussions leading to a certain outcome.

So, how about we add the MR URL to the commit message? That provides
an easy pointer to the discussion if that is needed afterwards.

--
Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen