I made updates to the RFC on the GitHub Discussion page with rev tracking.
https://github.com/tianocore/edk2/discussions/5926
On 7/31/2024 1:56 PM, Kinney, Michael D wrote:
-----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
* 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.
That aligns more to what I was originally intending within the scope of
the issue in this repo.
That should mean that this page would be updated to describe a GitHub
issue based process and those spec repos would need a template as well?
- Today's Spec Documentation:
https://github.com/tianocore-docs/edk2-TemplateSpecification/wiki/TianoCore-Documents-GitBook-Overview
- Doc Repos: https://github.com/tianocore-docs
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?
Yes.
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.
Sounds good.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120158): https://edk2.groups.io/g/devel/message/120158
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]
-=-=-=-=-=-=-=-=-=-=-=-
