Re: [qemu-web PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

["Michael S. Tsirkin" <mst@redhat.com>]

thanks! sorry probably just me being dense but some things
here I don't get. might be worth clarifying:

On Thu, Jun 18, 2026 at 05:07:10PM +0100, Daniel P. Berrangé wrote:
> On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote:
> > > + * The maintainer(s) will develop and/or review patch(es)
> > > +   for the issue privately, optionally attaching work in
> > > +   progress fixes to the GitLab issues.
> > 
> > attaching how? how do i ask reported to test the fix?
> > was easy in the email flow.
> 
> You can add arbitrary attachments in gitlab issue comments.
> 
> > > All patches must
> > > +   include the issue URL in the commit message(s).
> > 
> > you mean the commit message of the patches I presume?
> > there's no commit at that point.
> 
> Well I presume the maintainer will have a local git tree
> with a work-in-progress commit.

sorry I don't get it.

what does it have to do with patches then?


who cares about my local tree?

and why is this mentioned twice?










> > > The
> > > +   **"Workflow::In Progress"** label should be assigned when
> > > +   a maintainer starts working on a fix.
> > 
> > That's a bit heavy, and what is "working" anyway.
> > It's an issue tracker not a planning app.
> > Don't try to make it one.
> 
> Various "Workflow::" labels are already present in our gitlab
> instance. We don't use them consistently - this text is just
> a pointer that the're there.
> 

maybe "can be assigned" then?

> 
> > 
> > 
> > > + * When a CVE is allocated, it must be recorded as a comment on
> > > +   the GitLab issue, and the **"CVE::Required"** label replaced by
> > > +   the **"CVE::Assigned"** label.
> > 
> > Recorded as a comment how exactly, in what format?
> 
> In plain text.

yes but in what format? 

> > 
> > > + * The maintainer(s) will update the commit message(s)
> > 
> > what does it mean to "update the commit message"?
> 
> The commit message for the patch the maintainer has in their
> tree.

then you mean "before sending a pull request"?

> 
> > > to include
> > > +   the assigned CVE and issue URL. If multiple commits are required
> > > +   to fix an issue the CVE must be included in the final commit in
> > > +   the series, and may optionally be included in all prior commits.
> > 
> > And here, included in what format?
> 
> The CVE just needs to exist somewhere/anywhere in the commit message.
> It is common to put it in the first line, or with tags before SoB
> but it doesn't really matter as long as we have a record of it in
> the patch.
> 
> With regards,
> Daniel

Will be really annoying if any tools try to consume this e.g.
to decide what to backport.

I suggest deciding on something for these free text fields,
how important is it to be able to write ❤️❤️❤️CVE-1234💰🔥🎯 really?

> -- 
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|