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/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
