[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Adam Jackson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|MOVED |--- --- Comment #5 from Adam Jackson --- Apologies, didn't intend to close this in the migration. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 --- Comment #4 from Mark Janes --- I thought we were going to leave the 19.2 tracker bugs in bugzilla until after the release. The migration of this bug doesn't hurt the release, because we can still see the list of bugs that need to be resolved. I don't think we can adequately reference unmigrated bugzilla bugs in the gitlab milestone. We should still use this tracker to gate the release, in spite of the migration. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab issue migration, labels & triage
On Wed, 2019-09-18 at 23:41 +0200, Bas Nieuwenhuizen wrote: > Has anybody put any though in how to best manage things here? e.g. > some process, or do we want some form of automatic labeling, or is my > concern overblown? Well, there's the list of issues with no label: https://gitlab.freedesktop.org/mesa/mesa/issues?scope=all=%E2%9C%93=opened_name[]=None We can almost certainly keep that list empty if we're diligent about it. And if there's volunteers sufficiently interested in triage but not necessarily development we can add them with Reporter access. I'm a _little_ surprised issue reporters don't automatically get that... but on the other hand, as Mark Janes pointed out, we're likely to be using labels for quite a lot now, so the ability to delete labels probably should be restricted to Developer and up. - ajax ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Release workflow with gitlab issues
On 2019-09-18 9:15 p.m., Adam Jackson wrote:
> On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote:
>>
>>> We'll also need to replace the Bugzilla: tag with a tag that gitlab
>>> recognizes
>>> for closing issues. Since we already use "Fixes:" for something else, I'd
>>> like
>>> to propose "Closes:"
>>>
>>> so we'd replace:
>>> Buzilla: https://...
>>> with:
>>> Closes: !0
>>
>> A more exact replacement would be:
>> Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/{issue}
>>
>> Is there an advantage to the !{issue} format? Perhaps gitlab parses it
>> and closes the issue?
>
> gitlab can parse both the !nnn format and full URLs, and yes, it does
> close issues when a commit with such a Closes: line is merged.
Just for the record, the "!" prefix is for MRs, issues use "#".
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Release workflow with gitlab issues
Quoting Juan A. Suarez Romero (2019-09-19 04:26:53)
> On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote:
> > Adding the release managers to the CC to make sure they see the thread...
> >
> > Dylan Baker writes:
> >
> > > Hi everyone,
> > >
> > > Since we're migrating to gitlab issues, it seems like a good time to
> > > review how
> > > we track stable releases, particularly release blockers.
> > >
> > > I'd like to use a gitlab milestone as a replacement for the tracker
> > > issues from
> > > gitlab. The process would work much the same way as it does now, but with
> > > a
> > > milestone.
> >
> > Right now, anyone can create milestones. Is there a way to limit the
> > capability to release managers? Would that be desirable?
> >
> > I see the same issue with labels... Anyone could delete a label, and
> > I'm not sure how we would recover that information.
> >
> > > We'll also need to replace the Bugzilla: tag with a tag that gitlab
> > > recognizes
> > > for closing issues. Since we already use "Fixes:" for something else, I'd
> > > like
> > > to propose "Closes:"
> > >
> > > so we'd replace:
> > > Buzilla: https://...
> > > with:
> > > Closes: !0
> >
> > A more exact replacement would be:
> > Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/{issue}
> >
>
> I also prefer this format. This would allow to reference other issues not in
> the
> GitLab.
I'd really prefer to use a tag gitlab will manage automatically. Having gitlab
automatically close an issue when the corresponding merge is created is *super*
useful for making sure issues are closed in a timely manner. Gitlab also will
cross reference that an issue has a closing MR, so it's easy to see at a glance
that "for issue !1, Jason has opened #1". That sort of automatic issue/mr
correlation would be incredibly useful.
>
> > Is there an advantage to the !{issue} format? Perhaps gitlab parses it
> > and closes the issue?
> >
>
> Yes, it does when you write something like "closes #issue". But I think I
> prefer
> to close the issue manually; several times I saw MR that should fix an issue
> but
> they actually didn't either because it requires other MR, or because there was
> another change in master that requires another change, etc.
That sounds like people incorrectly adding tags. My experience from projects on
github that use the Fixes/Closes notation is that the number of "false
positives" is inconsequential compared stale issues when you don't use them,
either because the submitter can't close the issue themselves manually, or,
because they forget to go back and close it; which is something we've clearly
struggled with a lot (looking at the number of issues migrated from bugzilla).
Dylan
>
>
>
> > > If we like this, I'll follow up with a script that can fetch issues
> > > information
> > > from gitlab and produce release information.
> > >
> > > Does this sound reasonable to everyone?
> > >
>
>
> Sounds nice for me.
>
> J.A.
>
> > > Dylan
> > > ___
> > > mesa-dev mailing list
> > > mesa-dev@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
signature.asc
Description: signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 --- Comment #3 from Adam Jackson --- See also the 19.2 release milestone in gitlab: https://gitlab.freedesktop.org/mesa/mesa/-/milestones/1 -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Release workflow with gitlab issues
On Wed, 2019-09-18 at 12:08 -0700, Mark Janes wrote:
> Adding the release managers to the CC to make sure they see the thread...
>
> Dylan Baker writes:
>
> > Hi everyone,
> >
> > Since we're migrating to gitlab issues, it seems like a good time to review
> > how
> > we track stable releases, particularly release blockers.
> >
> > I'd like to use a gitlab milestone as a replacement for the tracker issues
> > from
> > gitlab. The process would work much the same way as it does now, but with a
> > milestone.
>
> Right now, anyone can create milestones. Is there a way to limit the
> capability to release managers? Would that be desirable?
>
> I see the same issue with labels... Anyone could delete a label, and
> I'm not sure how we would recover that information.
>
> > We'll also need to replace the Bugzilla: tag with a tag that gitlab
> > recognizes
> > for closing issues. Since we already use "Fixes:" for something else, I'd
> > like
> > to propose "Closes:"
> >
> > so we'd replace:
> > Buzilla: https://...
> > with:
> > Closes: !0
>
> A more exact replacement would be:
> Gitlab: https://gitlab.freedesktop.org/mesa/mesa/issues/{issue}
>
I also prefer this format. This would allow to reference other issues not in the
GitLab.
> Is there an advantage to the !{issue} format? Perhaps gitlab parses it
> and closes the issue?
>
Yes, it does when you write something like "closes #issue". But I think I prefer
to close the issue manually; several times I saw MR that should fix an issue but
they actually didn't either because it requires other MR, or because there was
another change in master that requires another change, etc.
> > If we like this, I'll follow up with a script that can fetch issues
> > information
> > from gitlab and produce release information.
> >
> > Does this sound reasonable to everyone?
> >
Sounds nice for me.
J.A.
> > Dylan
> > ___
> > mesa-dev mailing list
> > mesa-dev@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab issue migration, labels & triage
During playing with notifications, I found out that actually gitlab allows to subscribe to exact labels https://about.gitlab.com/2016/04/13/feature-highlight-subscribe-to-label/ So, this may sort part of the issues related to "be up-to-date" according to interesting things in the big project. So as soon as somebody puts a label "RADV", for example, you will get a notification about it. And short "testing" of this feature from me: 1. Mark "Global" notifications level as "Disabled" (to be sure you won't get spam, for example) 2. Subscribe to any label 3. Create an issue WITH label You will get a notification about issue creation 4. Create an issue WITHOUT label and then - edit issue and add label You will get a notification about adding a label to the issue. So with this it might be quite flexible. On 19.09.19 10:41, Denys wrote: That's sad fact of gitlab, agree. The only thing came into mind - to get a "template" for issue, which should include all important information in the Summary (example - Intel. Vulkan. GPU hand during playing dota ...) There are many better ways to do this, for example, simply make a map of all needed labels, to be put into the summary. And then somebody with "edit" permissions will add correct labels according to the summary. So current approach will sort the problem 1 and 2. Issue 3 also can be workaround with it, because you may make filters based on "key words" in summary. On 19.09.19 00:41, Bas Nieuwenhuizen wrote: Hi all, One things I realized during the migration is that end users generally cannot edit labels on an issue[1] and there is no component selection anymore. So we end up with a bunch of changes: 1) Bugs come in without labels 2) People are not consistently fixing up labels for issues 3) Labels are not sent in email updates, prompting some IRC talk of adding the component in the titles already to make email filters work. While having email filtering work completely would be awesome I think my biggest issue here "ownership". When a bug came into the radv bugzilla component I took some ownership of managing it. e.g. bugs with a wrong component get moved, taking an initial stab at a fix etc. My fear would be that we don't consistently triage new bugs and that a number of them don't end up on anyone's radar. Contrary to MRs, where I expected most of them to be made by long-time developers, bugs tend to be filed by people who are not really affiliated with mesa and I feel the effect is probably stronger. Has anybody put any though in how to best manage things here? e.g. some process, or do we want some form of automatic labeling, or is my concern overblown? - Bas [1] https://docs.gitlab.com/ee/user/permissions.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] gitlab issue migration, labels & triage
That's sad fact of gitlab, agree. The only thing came into mind - to get a "template" for issue, which should include all important information in the Summary (example - Intel. Vulkan. GPU hand during playing dota ...) There are many better ways to do this, for example, simply make a map of all needed labels, to be put into the summary. And then somebody with "edit" permissions will add correct labels according to the summary. So current approach will sort the problem 1 and 2. Issue 3 also can be workaround with it, because you may make filters based on "key words" in summary. On 19.09.19 00:41, Bas Nieuwenhuizen wrote: Hi all, One things I realized during the migration is that end users generally cannot edit labels on an issue[1] and there is no component selection anymore. So we end up with a bunch of changes: 1) Bugs come in without labels 2) People are not consistently fixing up labels for issues 3) Labels are not sent in email updates, prompting some IRC talk of adding the component in the titles already to make email filters work. While having email filtering work completely would be awesome I think my biggest issue here "ownership". When a bug came into the radv bugzilla component I took some ownership of managing it. e.g. bugs with a wrong component get moved, taking an initial stab at a fix etc. My fear would be that we don't consistently triage new bugs and that a number of them don't end up on anyone's radar. Contrary to MRs, where I expected most of them to be made by long-time developers, bugs tend to be filed by people who are not really affiliated with mesa and I feel the effect is probably stronger. Has anybody put any though in how to best manage things here? e.g. some process, or do we want some form of automatic labeling, or is my concern overblown? - Bas [1] https://docs.gitlab.com/ee/user/permissions.html ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 111444] [TRACKER] Mesa 19.2 release tracker
https://bugs.freedesktop.org/show_bug.cgi?id=111444 Bug 111444 depends on bug 110395, which changed state. Bug 110395 Summary: Gen8 and lower. Shadows are flickering in SuperTuxKart https://bugs.freedesktop.org/show_bug.cgi?id=110395 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
