Re: [edk2-devel] [RFC] Transitioning from Bugzilla to GitHub Issues

["Michael Kubacki" <mikuback@linux.microsoft.com>]

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

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

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


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120152): https://edk2.groups.io/g/devel/message/120152
Mute This Topic: https://groups.io/mt/107442879/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-