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 :|
