Created attachment 454792 [details] proposed-changes In order to support an improved stabilisation workflow, I have proposed some changes to bugzilla on the gentoo-dev mailing list (see $URL). Attached is an implementation plan based on testing I've been doing on bugstest - feedback welcome.
(In reply to Michael Palimaka (kensington) from comment #0) > Created attachment 454792 [details] > proposed-changes As a side note: "1. Restore Keywording & Stabilisation component" -> Could then KEYWORDREQ and STABLEREQ keywords be removed then? Sometimes they cause issues (even currently that the components are not available) as many people forget to set them when CCing arches, then, it's not clear if AT should go ahead or not. I would prefer to keep it simpler and, if the component is used and arches are CCed, nothing more is needed Thanks!
(In reply to Pacho Ramos from comment #1) > "1. Restore Keywording & Stabilisation component" -> Could then KEYWORDREQ > and STABLEREQ keywords be removed then? Sometimes they cause issues (even > currently that the components are not available) as many people forget to > set them when CCing arches, then, it's not clear if AT should go ahead or > not. I would prefer to keep it simpler and, if the component is used and > arches are CCed, nothing more is needed Thanks for the feedback Pacho, this is what I think about: The KEYWORDS should remain as is because when the bot will parse the request, it should understand if it is a stablereq or a keywordreq and then what to do. Also the new rules should prevent that people will file stablereq+keywordreq togheter (same bug) or the bot will be crazy.
Wouldn't it be covered by having two components, one for keywording and other for stable? I don't mind any solution... but I would like to prevent people from forgetting to set STABLEREQ/KEYWORDREQ keywords and, then, bugs being stalled forever That is happening even today that we don't have a stable/keyword component, and was happening in the past. Currently, I manually look from time to time for this kind of bugs for appending the KEYWORD when needed... but, of course, that relies on me or others doing the manual intervention :) That could be solved by having either two splitted components or having a parent component and then a subcomponent for specifying if it's stable or keyword.. that we people wouldn't be able to open "incomplete" bug reports as currently. In summary, what I am trying to achieve is that, as soon as the maintainer "starts the stabilization process" (probably CCing arches), things are not unexpectedly stalled because of forgetting to set the KEYWORD
if we have 2 separate components, is fine have no keywords.
kensington: Could you comment on keywords vs 2 separate components? If that's resolved, we're going to make this live.
Created attachment 455876 [details] proposed-changes v2 Updated proposal to include separate components for keywording and stabilisation as per earlier comments.
How does that deal with security workflow?
(In reply to Michał Górny from comment #7) > How does that deal with security workflow? It doesnt change? Security bugs are marked with keywords STABLEREQ or KEYWORDREQ same as now, while for normal stabilizations / keywording the keywords become unnecessary.
Created attachment 455992 [details, diff] Patch to increase the component list box size in BZ by one line Here's an (untested but trivial) patch to increase the size of the component list in the "enter bug" form by one line. In case that's the only problem holding things up...
@kensington: What do you want for component description, default assignee, default CC for each of the new component?
kensington: I created per your changes v2. I used some defaults for the places you had not provided values. (assignee, cc, sortkey).
idl0r: opinion on dilfridge's patch for the box sizing?
(In reply to Robin Johnson from comment #12) > idl0r: > opinion on dilfridge's patch for the box sizing? Make it +3, so it'd be more future proof.
(In reply to Robin Johnson from comment #11) > kensington: > I created per your changes v2. > I used some defaults for the places you had not provided values. (assignee, > cc, sortkey). Thanks for working on this. Two things that have come up: 1. Component says 'Stabilization' and the new field says 'Atoms to stabilise' - it would be nice to use consistent grammar between the two 2. I don't seem to be able to set the new bug or attachment flag. I guess I incorrectly assumed that the archtester group would also apply to developers. Is there a grant group that will cover both? If not, just switching it to developers should be fine.
Thanks for all the work, only a few doubts I have: - When filling a new "stabilization" bug report I think it is not clear for the reporter about the meaning of leaving "Runtime testing required" in the default "--" - Regarding security stabilizations, if they are going to keep using the "traditional" system of filling stabilizations, I guess they won't benefit from the advantages of the new system and, hence, they could also suffer from the delays on some arches. Why is security team simply not filling a normal "stabilization" bug blocking the security one? That would also allow them to set a summary specifying the versions they need for CVEs while using the concrete version for stabilization in the stable bug.
(In reply to Pacho Ramos from comment #15) > Thanks for all the work, only a few doubts I have: > - When filling a new "stabilization" bug report I think it is not clear for > the reporter about the meaning of leaving "Runtime testing required" in the > default "--" The default '--' is the same as we have now - no information / arch tester's best judgement. I have no problem with making a response mandatory for this field, but didn't include it in the initial proposal to minimise bikesheddings. > - Regarding security stabilizations, if they are going to keep using the > "traditional" system of filling stabilizations, I guess they won't benefit > from the advantages of the new system and, hence, they could also suffer > from the delays on some arches. Why is security team simply not filling a > normal "stabilization" bug blocking the security one? That would also allow > them to set a summary specifying the versions they need for CVEs while using > the concrete version for stabilization in the stable bug. The new fields appear in security bugs too as to not disrupt their usual workflow.
(In reply to Michael Palimaka (kensington) from comment #16) [...] > The default '--' is the same as we have now - no information / arch tester's > best judgement. I have no problem with making a response mandatory for this > field, but didn't include it in the initial proposal to minimise > bikesheddings. > great, maybe that explanation about "--" meaning that it is up to AT to decide could be added to the help at https://bugs.gentoo.org/page.cgi?id=fields.html#cf_runtime_testing_required > The new fields appear in security bugs too as to not disrupt their usual > workflow. Ah, nice :)
(In reply to Michael Palimaka (kensington) from comment #14) > Two things that have come up: > > 1. Component says 'Stabilization' and the new field says 'Atoms to > stabilise' - it would be nice to use consistent grammar between the two Changed to use american spelling (with "z") everywhere possible (you cannot rename custom fields after creation, so that will forever remain cf_stabilisation_atoms. > 2. I don't seem to be able to set the new bug or attachment flag. I guess I > incorrectly assumed that the archtester group would also apply to > developers. Is there a grant group that will cover both? If not, just > switching it to developers should be fine. Changed to gentoo-dev group instead, as no group covers both presently (we could add an implicit group in future if needed).
(In reply to Pacho Ramos from comment #15) > Why is security team simply not filling a normal "stabilization" bug blocking > the security one? In that way the security bugs won't appear in the saved search for the security bugs and they didn't get enough attention/priority.
Ah, ok. Of course if security team is fine with that, great :) Anyway, for the case in the future the rethink the workflow and want to give higher priority to security related stabilizations, they could maybe simply add "SECURITY" keyword to that stabilization bug reports for treating them faster
After people fill "Atoms to stabilize", we run a bot and apply the sanity-check+ but if people will change the atoms, they don't delete the sanity-check flags. Robin, is possible on the bugzilla side that if "Atoms to stabilize" has been changed, the sanity-check+ flag is auto-deleted?
(In reply to Agostino Sarubbo from comment #21) > After people fill "Atoms to stabilize", we run a bot and apply the > sanity-check+ but if people will change the atoms, they don't delete the > sanity-check flags. > > Robin, > is possible on the bugzilla side that if "Atoms to stabilize" has been > changed, the sanity-check+ flag is auto-deleted? idl0r: I don't know the answer to this. Can you comment more knowledgeably? I think we'd probably have to write a small Bugzilla plugin to do it, but you've undertaken that before and I haven't.
(In reply to Robin Johnson from comment #22) > (In reply to Agostino Sarubbo from comment #21) > > After people fill "Atoms to stabilize", we run a bot and apply the > > sanity-check+ but if people will change the atoms, they don't delete the > > sanity-check flags. > > > > Robin, > > is possible on the bugzilla side that if "Atoms to stabilize" has been > > changed, the sanity-check+ flag is auto-deleted? > idl0r: > I don't know the answer to this. Can you comment more knowledgeably? > > I think we'd probably have to write a small Bugzilla plugin to do it, but > you've undertaken that before and I haven't. That's possible but it would require some changes to the submit bug/changes part. An extension with hooking bug/changes submission could work. Doing that client side via JS or so could work as well but it might be better to do it via extensions, so server side I think. I'd like to see a3li's opinion on that.
It's a little more complex as there's other factors beyond the atoms field that could affect the validity of a request: * an attachment marked as a stabilisation list instead of the atom field * arch teams in CC * new "depends on" bugs * changes in all of the above in "depends on" bugs Currently, bugbot does its best to detect these sorts of changes in bug state and revalidate the request.
@infra: Can we apply the point N° explained here: https://archives.gentoo.org/gentoo-dev/message/c5560c2a247e7dd7af003c7522ac7be4 ? THX
Done. I made it 'package list' to be gramatically correct.
Would it be possible to hide "Package list" box when an attachment is tagged as stabilization list? Otherwise, there are cases of both being present, but not synced and, then, causing confusions to arch teams :/
(In reply to Pacho Ramos from comment #27) > Would it be possible to hide "Package list" box when an attachment is tagged > as stabilization list? Otherwise, there are cases of both being present, but > not synced and, then, causing confusions to arch teams :/ the attachment should not exist anymore for that...
I also prefer to use the box... but some people are still using the lists... Then, we should probably stop offering to flag attachments as "stabilization-list" as it's allowed currently... otherwise some people will still rely on that :/
Ah, also... I am not sure if it would be technically possible but, regarding Packages list box, would it be possible to move it to the left side and allow it to take advantage of more width? I know that I can resize the box... but usually we need to see more in the "width" dimension and that leads to needing to open more the box to the right leading to us needing to scroll to the right :/ That is easily noticed when we have long package names and need to list a lot of arches (:S, I am not sure if I have been able to explain it well enough )
I also prefer using the box exclusively, but implemented attachment flag support so as not to interrupt the workflow of people that use attachments, and as noted above the box can be cumbersome when working with large lists. I'm happy to drop attachment flag support if there's agreement for that. (In reply to Pacho Ramos from comment #30) > Ah, also... I am not sure if it would be technically possible but, regarding > Packages list box, would it be possible to move it to the left side and > allow it to take advantage of more width? I know that I can resize the > box... but usually we need to see more in the "width" dimension and that > leads to needing to open more the box to the right leading to us needing to > scroll to the right :/ This could be possible by playing with the bugzilla templates, but unfortunately I have no way of testing potential patches.
