Re: [Mesa-dev] Release workflow with gitlab issues
On Wed, Sep 18, 2019 at 2:08 PM Mark Janes wrote: > Right now, anyone can create milestones. Is there a way to limit the > capability to release managers? Would that be desirable? > I don't think so. We may want to use milestones for other task tracking beyond just releases such as "Switch radeonisi to NIR by default". --Jason ___ 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
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] Release workflow with gitlab issues
On Wed, 18 Sep 2019 at 20:43, Mark Janes wrote: > Adam Jackson writes: > > Strictly, the "Reporter" access level and above can manage labels, > > milestones require "Developer" or above. Not super meaningful since the > > mesa group really only has Developer or above. > > > > I'm not super worried about it to be honest, people tend not to be > > malicious. > > I agree that malicious users will be less of a problem with gitlab > issues. I am somewhat worried about inadvertent mistakes. "I thought I > was in the browser tab with my forked repo..." > > That particular mistake would be hard to make, but it's hard to > anticipate accidents. > > When you delete a label, gitlab warns that you can't get it back. > Labels will hold a lot of information for us. We keep daily backups. Obviously it would be an enormous pain to deal with, but we could get the label information back if we really needed to. I have a strong suspicion that the bugs keep their association to the label, so we could probably even pull it out with some local Ruby, without resorting to backups. Cheers, Daniel ___ 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
Adam Jackson writes:
> 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.
>
> For the avoidance of doubt and confusion, I don't plan to migrate any
> of the components with bugs on the 19.2 release tracker until 19.2 is
> actually released.
>
>> > 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.
>
> Strictly, the "Reporter" access level and above can manage labels,
> milestones require "Developer" or above. Not super meaningful since the
> mesa group really only has Developer or above.
>
> I'm not super worried about it to be honest, people tend not to be
> malicious.
I agree that malicious users will be less of a problem with gitlab
issues. I am somewhat worried about inadvertent mistakes. "I thought I
was in the browser tab with my forked repo..."
That particular mistake would be hard to make, but it's hard to
anticipate accidents.
When you delete a label, gitlab warns that you can't get it back.
Labels will hold a lot of information for us.
>> > 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.
>
> - 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 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.
For the avoidance of doubt and confusion, I don't plan to migrate any
of the components with bugs on the 19.2 release tracker until 19.2 is
actually released.
> > 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.
Strictly, the "Reporter" access level and above can manage labels,
milestones require "Developer" or above. Not super meaningful since the
mesa group really only has Developer or above.
I'm not super worried about it to be honest, people tend not to be
malicious.
> > 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.
- 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
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}
Is there an advantage to the !{issue} format? Perhaps gitlab parses it
and closes the issue?
> 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?
>
> 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
