> -----Original Message----- > From: Michael Kubacki <mikub...@linux.microsoft.com> > Sent: Wednesday, July 31, 2024 7:42 AM > To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kin...@intel.com>; > r...@edk2.groups.io > Cc: 'Andrew Fish' <af...@apple.com>; 'Leif Lindholm' > <quic_llind...@quicinc.com>; 'Sean Brogan' <sean.bro...@microsoft.com> > Subject: Re: [edk2-devel] [RFC] Transitioning from Bugzilla to GitHub > Issues > > >> Proposed Process > >> ---------------- > >> > >> 1. Create GitHub issue templates for the following categories that > >> include basic automation of validation for input. > >> > >> * Bug Report > >> > >> * Fields: > >> * Title > >> * Packages Affected > > > > Would this be free form text or a multi select list of possible packages? > > Drop down and check boxes are currently supported. To my understanding, > multi-select is not. I was planning to instead use check boxes which > would still allow multiple selection from a fixed set of options. > > >> * Current Behavior > >> * Expected Behavior > >> * Steps to Reproduce > >> * Build Environment > >> * Host Information (if applicable) such as OS and Tool Chain > >> and/or container information > > > > Would this be free form text or a multi select list of allowed options? > > For information where we can constrain the options to what is supported > in edk2, we can do that (with check boxes), for example, the tool chain > list. I planned to make Host OS and container information fields free form. > > >> > >> * Feature Request > >> > >> * Fields: > >> * Title > >> * Packages Affected > > > > Would this be free form text or a multi select list of allowed options? > > It would be consistent with other forms as check boxes. > > >> > >> * Documentation Request > >> > >> * Fields: > >> * Title > >> * Packages Affected > > > > Would this be free form text or a multi select list of allowed options? > > > > Some documents are not package specific such as the build system related > documents. > > Would the target spec be the right value here? > > That makes sense. In that case, would you like labels to be defined > based on the option selected so requests for individual spec issues can > be filtered?
For the edk2 repo, the documentation requests would have to be limited to documents in the edk2 repo itself or perhaps the edk2 Wiki. Many of build specifications are in independent repos in the tianocore-docs organization. So a GitHub issue opened in one of those spec repos is already scoped to the right specification. So perhaps, the "Packages Affected" field here is same as the code ones to request updates to Readme files in the source tree. May need an option to open an issue against the Wiki. > > >> > >> 3. Define GitHub labels that can be manually added: > >> > > > > This set looks good. Please add brief descriptions of that each label > represents. > > I will update the live version of this on the GitHub discussion page > with descriptions. > > >> > >> 4. Define GitHub milestones for the upcoming three edk2 stable tags so > >> that issues can optionally be tracked against those milestones. > >> > >> Note: The milestone box is a simple drop down that allows for easy > >> selection of defined milestones. > > > > Is milestone and release the same thing? Should we just use "release" > > Terminology? Or is there a needs to define one or more milestones > > Between releases? > > "Milestone" is a GitHub name for this concept - > https://docs.github.com/issues/using-labels-and-milestones-to-track- > work/about-milestones > > For us, I think of it as equivalent to stable tag release. The milestone > terminology is used here because on the issue/PR page that is the GitHub > controlled heading under which the appropriate milestone would be selected. Ok. So "Milestone" is the heading, but the values to select from would be stable tag names. Right? > > >> > >> 6. Stage updates to the TianoCore documentation to reflect the new > >> process and provide a user guide for transitioning to GitHub Issues > >> from Bugzilla. > > > > Bugzilla supports attachments. How will attachments be migrated to a > GitHub issue? > > > > Bugzilla also contains bugs that apply to may different GitHub repos. > Will > > all of the Bugzilla issues across all repos be migrated at the same time > > so Bugzilla can be converted to read-only for all issue types on the same > > date? > > There will be a box at the bottom of the form where attachments can be > added. > > This proposal did not plan to move all bugs at once and mark Bugzilla > read-only. I will need to do more extensive research on how feasible > that is. Other large open-source projects have successfully made that > transition. Thanks! Let's start with investigating what needs to be done to do the conversion and identify the sequence of tasks and we can discuss next steps based on resources available to perform the conversions and set feasible dates for the transition. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120157): https://edk2.groups.io/g/devel/message/120157 Mute This Topic: https://groups.io/mt/107442879/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
