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

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

[Michael Kubacki]

Hello,

A topic over the last few weeks in the TianoCore Tools & CI meeting has 
been establishing a transition from Bugzilla to GitHub issues. I've 
drafted the following RFC to help explain the rationale and a proposed 
process to do so.

I think it is easier to read with formatting, so I've placed a version 
in the following link that is open to comments in the GitHub discussion. 
I recommend reading this version.

https://github.com/tianocore/edk2/discussions/5926

---

I've also copied that content below if you prefer to read and respond 
directly to the email.

---

Background
----------

TianoCore currently uses Bugzilla as its issue tracking system. However, 
with the recent transition from a mailing list
based code contribution process to GitHub pull requests, there is a 
growing need and value to consolidate development
activities on a single platform.

This RFC proposes a process for transitioning from Bugzilla to GitHub 
issues to improve issue tracking and engagement.
Feedback is welcome to refine the process in a way that best meets the 
needs of the TianoCore community.

General information about GitHub issues is available in the GitHub 
Issues Guide.

Advantages of GitHub Issues
---------------------------

* Automation

   * GitHub issues can use the same GitHub action based automation as
     pull requests, enabling the process to be more tailored to the
     project's needs. The same GitHub REST API can also be reused
     allowing for reuse of external automation tools and scripts that are
     used with extracting pull request information.

   * An example already in use in edk2 PRs today is the stale bot which
     auto closes stale PRs to reduce review noise and keep open issues
     relevant.

* Centralization of Issue Activity

   * GitHub issues automatically track the places they are mentioned such
     as comments, commits, and pull requests. This provides a central
     location for tracking the discussion and related work for an issue.

* Collaboration Features

   * GitHub issues support features like labels, milestones, and project
     boards, that enable better organization and tracking of issues if
     leveraged by the community.

* Consistent User Account

   * Users can use the same account for both code contributions and issue
     tracking, making it easier to identify and track that developer's
     contributions and related activities.

* Financial Cost Savings

   * Bugzilla requires dedicated hosting provided by TianoCore members.
     GitHub issues use the exact same infrastructure already used for
     code hosting with no additional cost.

* Dev Tool Support

   * Many of the tools already being used for GitHub based development
     support integrated issue tracking such as VS Code GitHub issue
     integration.

* Ease of Access

   * GitHub issues are accessible to anyone with a GitHub account,
     simplifying the registration and tracking process.

* Emoji and Reaction Support

   * Community members can quickly vote on issues so the most upvoted can
     be sorted for awareness and prioritization. Emoji and reaction data
     can be externally queried and exported via the GitHub REST API.

* Integration with Git

   * GitHub issues are tightly integrated with Git repositories, making
     it easier to reference commits and individual code changes with
     permalinks.

* Issue Templates

   * GitHub issues support templates, enabling standardization of issue
     reporting and customized validation in the template.

* Longer Lived Accounts

   * Even after users leave their companies, their GitHub accounts remain
     active, reducing the loss of user history and accessibility to that
     user in the future.

* Markdown Support

   * GitHub issues support Markdown formatting, allowing for rich text
     formatting and embedding of images and links. This provides a
     consistent experience with the PR process.

* Pull Request Automation

   * GitHub issues can be linked to pull requests simply by including the
     issue number in the pull request description, enabling better
     tracking and visibility. The issue will automatically close when the
     pull request is merged preventing dangling issues.

* Visibility

   * GitHub issues are more visible to developers and users who are
     already using GitHub for code development. The number of active
     issues is visible at the top of the repository page.

Goals
-----

1. More issues will be filed since registration and access is
    consolidated with the code repository.
2. Issues will have more relevant and frequently updated information due
    to the built-in integration to the repo code and pull requests.
3. The submission process will be streamlined with better opportunities
    for automation and customization.
4. Ultimately, developers will need to spend less effort to track and
    manage issues over time using built-in linking and auto close
    features.

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
        * Current Behavior
        * Expected Behavior
        * Steps to Reproduce
        * Build Environment
          * Host Information (if applicable) such as OS and Tool Chain
            and/or container information
          * Target Information (if applicable) such as DEBUG/RELEASE,
            architecture, and relevant features enabled
        * Version Information
          * Commit SHA or stable tag
        * Urgency
          * Low
            * A minor change with little to no important functional
              impact
            * It is not important to fix this in a specific time frame
          * Medium
            * An important change with a functional impact
            * Will be prioritized above low issues in the normal course
              of development
          * High
            * A critical change that has a significant functional impact
            * Must be fixed immediately
        * Are you planning to submit a PR?
          * Yes
          * No
        * Do you need maintainer feedback?
          * Yes
          * No
        * Additional information including attachments (optional)

    * Feature Request

      * Fields:
        * Title
        * Packages Affected
        * Feature Overview
        * Proposed Solution
        * Alternatives Considered (optional)
        * Urgency
          * Low
            * A minor enhancement
            * It is not important to address this request in a specific
              time frame
          * Medium
            * An important enhancement
            * Will be prioritized above low requests in the normal course
              of development
          * High
            * A critical enhancement with significant value
            * Should be prioritized above low and medium requests
        * Are you planning to implement this feature?
          * Yes
          * No
        * Do you need maintainer feedback?
          * Yes
          * No
        * Additional information including attachments (optional)

    * Documentation Request

      * Fields:
        * Title
        * Packages Affected
        * Request Description
        * Are you going to make the change?
          * Yes
          * No
        * Do you need maintainer feedback?
          * Yes
          * No
        * Additional information including attachments (optional)

2. Automatically apply labels to the issue based on submission
    information:

    * Type
      * Bug Report
        * type:bug
      * Feature Request
        * type:feature-request
      * Documentation Request
        * type:documentation-request

    * Urgency
      * Low
        * priority:low
      * Medium
        * priority:medium
      * High
        * priority:high

    * State
      * Maintainer Feedback Requested
        * state:maintainer-feedback-requested
      * Submitter Not Planning to Complete
        * state:needs-owner

3. Define GitHub labels that can be manually added:

    * Duplicate
      * state:duplicate

    * Help Wanted
      * state:help-wanted

    * Insufficient Submitter Information
      * state:needs-submitter-info

    * Decision Not to Fix
      * state:wont-fix

    * Issue is Understood But Invalid
      * state:invalid

    * Issue is Not Actively Being Fixed
      * state:backlog

      * Note: This would also prevent the stale bot from closing the
        issue due to inactivity.

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.

5. Enable basic GitHub actions for GitHub issues:

    * Automatic application of labels based on issue template input at
      time of issue creation.

    * Daily check for issues that have not been updated in 45 days to
      apply the state:stale label (already used for pull requests in
      edk2) and leave a warning comment. If still no activity in 7 days,
      close the issue with a comment that it can be reopened if the issue
      is still relevant.

6. Stage updates to the TianoCore documentation to reflect the new
    process and provide a user guide for transitioning to GitHub Issues
    from Bugzilla.

7. Establish a date to begin accepting GitHub issues and disable the
    creation of new issues in Bugzilla. This RFC proposes the date of
    Monday, August 26, 2024 the following business day after the 202408
    stable tag is released.

8. Communicate this date to the community alongside the staged
    documentation.

9. Enable GitHub issue submission in edk2 on the transition date.

10. Learn from GitHub issue usage and adjust the process as needed.

11. During this first one month, review open issues in Bugzilla to
     determine if they are still relevant and if so, transfer them to
     GitHub issues. Close the Bugzilla issue with a link to the new
     GitHub issue. This is possible to do programmatically.

12. Manually review the transferred issues to ensure accuracy and
     completeness.

Additional Resources
--------------------

* GitHub Issues Documentation: [GitHub Issues 
Guide](https://docs.github.com/issues)
* Tracking Work with GitHub Issues: [GitHub Issues - About 
issues](https://docs.github.com/issues/tracking-your-work-with-issues/about-issues)
* GitHub Markdown Guide: [Mastering 
Markdown](https://guides.github.com/features/mastering-markdown/)

---

Thanks,
Michael


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119986): https://edk2.groups.io/g/devel/message/119986
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Michael D Kinney]

Hi Michael,

Thank you for the detailed proposal.  Overall looks like a great
start.  Some comments included below.  I would be in favor of 
moving in this direction as soon as possible.

I would like to hear if there are any objections to this proposal
from any community members so those can be addressed quickly.

Mike

> -----Original Message-----
> From: Michael Kubacki <mikuback@linux.microsoft.com>
> Sent: Friday, July 19, 2024 2:20 PM
> To: devel@edk2.groups.io; rfc@edk2.groups.io
> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> <quic_llindhol@quicinc.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>; 'Sean Brogan' <sean.brogan@microsoft.com>
> Subject: [RFC] Transitioning from Bugzilla to GitHub Issues
> 
> Hello,
> 
> A topic over the last few weeks in the TianoCore Tools & CI meeting has
> been establishing a transition from Bugzilla to GitHub issues. I've
> drafted the following RFC to help explain the rationale and a proposed
> process to do so.
> 
> I think it is easier to read with formatting, so I've placed a version
> in the following link that is open to comments in the GitHub discussion.
> I recommend reading this version.
> 
> https://github.com/tianocore/edk2/discussions/5926
> 
> ---
> 
> I've also copied that content below if you prefer to read and respond
> directly to the email.
> 
> ---
> 
> Background
> ----------
> 
> TianoCore currently uses Bugzilla as its issue tracking system. However,
> with the recent transition from a mailing list
> based code contribution process to GitHub pull requests, there is a
> growing need and value to consolidate development
> activities on a single platform.
> 
> This RFC proposes a process for transitioning from Bugzilla to GitHub
> issues to improve issue tracking and engagement.
> Feedback is welcome to refine the process in a way that best meets the
> needs of the TianoCore community.
> 
> General information about GitHub issues is available in the GitHub
> Issues Guide.
> 
> Advantages of GitHub Issues
> ---------------------------
> 
> * Automation
> 
>    * GitHub issues can use the same GitHub action based automation as
>      pull requests, enabling the process to be more tailored to the
>      project's needs. The same GitHub REST API can also be reused
>      allowing for reuse of external automation tools and scripts that are
>      used with extracting pull request information.
> 
>    * An example already in use in edk2 PRs today is the stale bot which
>      auto closes stale PRs to reduce review noise and keep open issues
>      relevant.
> 
> * Centralization of Issue Activity
> 
>    * GitHub issues automatically track the places they are mentioned such
>      as comments, commits, and pull requests. This provides a central
>      location for tracking the discussion and related work for an issue.
> 
> * Collaboration Features
> 
>    * GitHub issues support features like labels, milestones, and project
>      boards, that enable better organization and tracking of issues if
>      leveraged by the community.
> 
> * Consistent User Account
> 
>    * Users can use the same account for both code contributions and issue
>      tracking, making it easier to identify and track that developer's
>      contributions and related activities.
> 
> * Financial Cost Savings
> 
>    * Bugzilla requires dedicated hosting provided by TianoCore members.
>      GitHub issues use the exact same infrastructure already used for
>      code hosting with no additional cost.
> 
> * Dev Tool Support
> 
>    * Many of the tools already being used for GitHub based development
>      support integrated issue tracking such as VS Code GitHub issue
>      integration.
> 
> * Ease of Access
> 
>    * GitHub issues are accessible to anyone with a GitHub account,
>      simplifying the registration and tracking process.
> 
> * Emoji and Reaction Support
> 
>    * Community members can quickly vote on issues so the most upvoted can
>      be sorted for awareness and prioritization. Emoji and reaction data
>      can be externally queried and exported via the GitHub REST API.
> 
> * Integration with Git
> 
>    * GitHub issues are tightly integrated with Git repositories, making
>      it easier to reference commits and individual code changes with
>      permalinks.
> 
> * Issue Templates
> 
>    * GitHub issues support templates, enabling standardization of issue
>      reporting and customized validation in the template.
> 
> * Longer Lived Accounts
> 
>    * Even after users leave their companies, their GitHub accounts remain
>      active, reducing the loss of user history and accessibility to that
>      user in the future.
> 
> * Markdown Support
> 
>    * GitHub issues support Markdown formatting, allowing for rich text
>      formatting and embedding of images and links. This provides a
>      consistent experience with the PR process.
> 
> * Pull Request Automation
> 
>    * GitHub issues can be linked to pull requests simply by including the
>      issue number in the pull request description, enabling better
>      tracking and visibility. The issue will automatically close when the
>      pull request is merged preventing dangling issues.
> 
> * Visibility
> 
>    * GitHub issues are more visible to developers and users who are
>      already using GitHub for code development. The number of active
>      issues is visible at the top of the repository page.
> 
> Goals
> -----
> 
> 1. More issues will be filed since registration and access is
>     consolidated with the code repository.
> 2. Issues will have more relevant and frequently updated information due
>     to the built-in integration to the repo code and pull requests.
> 3. The submission process will be streamlined with better opportunities
>     for automation and customization.
> 4. Ultimately, developers will need to spend less effort to track and
>     manage issues over time using built-in linking and auto close
>     features.
> 
> 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?

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

>           * Target Information (if applicable) such as DEBUG/RELEASE,
>             architecture, and relevant features enabled

Would this be free form text or a multi select list of allowed options?

>         * Version Information
>           * Commit SHA or stable tag
>         * Urgency
>           * Low
>             * A minor change with little to no important functional
>               impact
>             * It is not important to fix this in a specific time frame
>           * Medium
>             * An important change with a functional impact
>             * Will be prioritized above low issues in the normal course
>               of development
>           * High
>             * A critical change that has a significant functional impact
>             * Must be fixed immediately
>         * Are you planning to submit a PR?
>           * Yes
>           * No
>         * Do you need maintainer feedback?
>           * Yes
>           * No
>         * Additional information including attachments (optional)
> 
>     * Feature Request
> 
>       * Fields:
>         * Title
>         * Packages Affected

Would this be free form text or a multi select list of allowed options?

>         * Feature Overview
>         * Proposed Solution
>         * Alternatives Considered (optional)
>         * Urgency
>           * Low
>             * A minor enhancement
>             * It is not important to address this request in a specific
>               time frame
>           * Medium
>             * An important enhancement
>             * Will be prioritized above low requests in the normal course
>               of development
>           * High
>             * A critical enhancement with significant value
>             * Should be prioritized above low and medium requests
>         * Are you planning to implement this feature?
>           * Yes
>           * No
>         * Do you need maintainer feedback?
>           * Yes
>           * No
>         * Additional information including attachments (optional)
> 
>     * 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?

>         * Request Description
>         * Are you going to make the change?
>           * Yes
>           * No
>         * Do you need maintainer feedback?
>           * Yes
>           * No
>         * Additional information including attachments (optional)
> 
> 2. Automatically apply labels to the issue based on submission
>     information:
> 
>     * Type
>       * Bug Report
>         * type:bug
>       * Feature Request
>         * type:feature-request
>       * Documentation Request
>         * type:documentation-request
> 
>     * Urgency
>       * Low
>         * priority:low
>       * Medium
>         * priority:medium
>       * High
>         * priority:high
> 
>     * State
>       * Maintainer Feedback Requested
>         * state:maintainer-feedback-requested
>       * Submitter Not Planning to Complete
>         * state:needs-owner
> 
> 3. Define GitHub labels that can be manually added:
> 

This set looks good.  Please add brief descriptions of that each label represents.

>     * Duplicate
>       * state:duplicate
> 
>     * Help Wanted
>       * state:help-wanted
> 
>     * Insufficient Submitter Information
>       * state:needs-submitter-info
> 
>     * Decision Not to Fix
>       * state:wont-fix
> 
>     * Issue is Understood But Invalid
>       * state:invalid
> 
>     * Issue is Not Actively Being Fixed
>       * state:backlog
> 
>       * Note: This would also prevent the stale bot from closing the
>         issue due to inactivity.
> 
> 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?

> 
> 5. Enable basic GitHub actions for GitHub issues:
> 
>     * Automatic application of labels based on issue template input at
>       time of issue creation.
> 
>     * Daily check for issues that have not been updated in 45 days to
>       apply the state:stale label (already used for pull requests in
>       edk2) and leave a warning comment. If still no activity in 7 days,
>       close the issue with a comment that it can be reopened if the issue
>       is still relevant.
> 
> 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?

> 
> 7. Establish a date to begin accepting GitHub issues and disable the
>     creation of new issues in Bugzilla. This RFC proposes the date of
>     Monday, August 26, 2024 the following business day after the 202408
>     stable tag is released.
> 
> 8. Communicate this date to the community alongside the staged
>     documentation.
> 
> 9. Enable GitHub issue submission in edk2 on the transition date.
> 
> 10. Learn from GitHub issue usage and adjust the process as needed.
> 
> 11. During this first one month, review open issues in Bugzilla to
>      determine if they are still relevant and if so, transfer them to
>      GitHub issues. Close the Bugzilla issue with a link to the new
>      GitHub issue. This is possible to do programmatically.
> 
> 12. Manually review the transferred issues to ensure accuracy and
>      completeness.
> 
> Additional Resources
> --------------------
> 
> * GitHub Issues Documentation: [GitHub Issues
> Guide](https://docs.github.com/issues)
> * Tracking Work with GitHub Issues: [GitHub Issues - About
> issues](https://docs.github.com/issues/tracking-your-work-with-
> issues/about-issues)
> * GitHub Markdown Guide: [Mastering
> Markdown](https://guides.github.com/features/mastering-markdown/)
> 
> ---
> 
> Thanks,
> Michael


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120069): https://edk2.groups.io/g/devel/message/120069
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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Michael Kubacki]

>> 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]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Michael D Kinney]

> -----Original Message-----
> From: Michael Kubacki <mikuback@linux.microsoft.com>
> Sent: Wednesday, July 31, 2024 7:42 AM
> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>;
> rfc@edk2.groups.io
> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Michael Kubacki]

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 <mikuback@linux.microsoft.com>
>> Sent: Wednesday, July 31, 2024 7:42 AM
>> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>;
>> rfc@edk2.groups.io
>> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
>> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

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

[gaoliming via groups.io]

Michael:
  Thanks for your great effort. This is a good direction to consolidate code and issue together. My feedbacks are below:

1. BugZilla supports code first process. What proposal will handle this process in Github issue flow?
2. BugZilla supports Edk2-Platform and Edk2-Test repo. After their issues are migrated to Github, their code process will be migrated to Github pull request. Right?
3. Edk2 Stable Tag Release Note will list the resolved issue and feature. I think they can be found in GitHub issue. I will learn the way how to find them. 

Thanks
Liming
> -----邮件原件-----
> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Michael Kubacki
> 发送时间: 2024年8月1日 3:36
> 收件人: Kinney, Michael D <michael.d.kinney@intel.com>;
> devel@edk2.groups.io; rfc@edk2.groups.io
> 抄送: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@microsoft.com>
> 主题: Re: [edk2-devel] [RFC] Transitioning from Bugzilla to GitHub Issues
> 
> 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 <mikuback@linux.microsoft.com>
> >> Sent: Wednesday, July 31, 2024 7:42 AM
> >> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>;
> >> rfc@edk2.groups.io
> >> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> >> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@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 (#120246): https://edk2.groups.io/g/devel/message/120246
Mute This Topic: https://groups.io/mt/107746608/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-

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

[Michael Kubacki]

Hi Liming,

I apologize for the delayed response.

Thanks,
Michael

On 8/6/2024 1:34 AM, gaoliming via groups.io wrote:
> Michael:
>    Thanks for your great effort. This is a good direction to consolidate code and issue together. My feedbacks are below:
> 
> 1. BugZilla supports code first process. What proposal will handle this process in Github issue flow?

For the Tianocore specifications, the proposal is that each respective 
repository in the tianocore-docs organization 
(https://github.com/tianocore-docs) maintain their issues.

I'm open to suggestions for the UEFI Specification issues.

> 2. BugZilla supports Edk2-Platform and Edk2-Test repo. After their issues are migrated to Github, their code process will be migrated to Github pull request. Right?

Yes. The RFC focuses on edk2 right now, but that would be the plan as 
we're trying to consolidate process across the repos. For clarity, I 
will add that as a section in the RFC.

> 3. Edk2 Stable Tag Release Note will list the resolved issue and feature. I think they can be found in GitHub issue. I will learn the way how to find them.

We'll have many options to streamline this process. We can create a 
single dashboard that can show issues from all the repos if that helps 
and I think we'll be able to better track issues to features and code 
changes for the reasons mention in the RFC.


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

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

[Michael D Kinney]

> -----Original Message-----
> From: Michael Kubacki <mikuback@linux.microsoft.com>
> Sent: Wednesday, August 14, 2024 7:30 PM
> To: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Kinney, Michael D
> <michael.d.kinney@intel.com>; rfc@edk2.groups.io
> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@microsoft.com>
> Subject: Re: 回复: [edk2-devel] [RFC] Transitioning from Bugzilla to GitHub
> Issues
> 
> Hi Liming,
> 
> I apologize for the delayed response.
> 
> Thanks,
> Michael
> 
> On 8/6/2024 1:34 AM, gaoliming via groups.io wrote:
> > Michael:
> >    Thanks for your great effort. This is a good direction to consolidate
> code and issue together. My feedbacks are below:
> >
> > 1. BugZilla supports code first process. What proposal will handle this
> process in Github issue flow?
> 
> For the Tianocore specifications, the proposal is that each respective
> repository in the tianocore-docs organization
> (https://github.com/tianocore-docs) maintain their issues.
> 
> I'm open to suggestions for the UEFI Specification issues.

Code first has 2 categories.  One is for spec changes and the other 
is for the code changes associated with the spec changes.

Code first uses branches in the edk2-staging repo, so perhaps all
code first related bugs should migrate to the edk2-staging repo.

We do want to make these very visible and have ways to integrate/test
code first changes with latest edk2 repo content.  SO perhaps we can
have a wiki page or discussion with active code first branches.

> 
> > 2. BugZilla supports Edk2-Platform and Edk2-Test repo. After their issues
> are migrated to Github, their code process will be migrated to Github pull
> request. Right?
> 
> Yes. The RFC focuses on edk2 right now, but that would be the plan as
> we're trying to consolidate process across the repos. For clarity, I
> will add that as a section in the RFC.
> 
> > 3. Edk2 Stable Tag Release Note will list the resolved issue and feature.
> I think they can be found in GitHub issue. I will learn the way how to find
> them.
> 
> We'll have many options to streamline this process. We can create a
> single dashboard that can show issues from all the repos if that helps
> and I think we'll be able to better track issues to features and code
> changes for the reasons mention in the RFC.


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

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

[Michael Kubacki]

On 8/14/2024 11:49 PM, Michael D Kinney wrote:
> 
>> -----Original Message-----
>> From: Michael Kubacki <mikuback@linux.microsoft.com>
>> Sent: Wednesday, August 14, 2024 7:30 PM
>> To: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Kinney, Michael D
>> <michael.d.kinney@intel.com>; rfc@edk2.groups.io
>> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
>> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@microsoft.com>
>> Subject: Re: 回复: [edk2-devel] [RFC] Transitioning from Bugzilla to GitHub
>> Issues
>> On 8/6/2024 1:34 AM, gaoliming via groups.io wrote:
>>> Michael:
>>>     Thanks for your great effort. This is a good direction to consolidate
>> code and issue together. My feedbacks are below:
>>>
>>> 1. BugZilla supports code first process. What proposal will handle this
>> process in Github issue flow?
>>
>> For the Tianocore specifications, the proposal is that each respective
>> repository in the tianocore-docs organization
>> (https://github.com/tianocore-docs) maintain their issues.
>>
>> I'm open to suggestions for the UEFI Specification issues.
> 
> Code first has 2 categories.  One is for spec changes and the other
> is for the code changes associated with the spec changes.
> 
> Code first uses branches in the edk2-staging repo, so perhaps all
> code first related bugs should migrate to the edk2-staging repo.
> 
> We do want to make these very visible and have ways to integrate/test
> code first changes with latest edk2 repo content.  SO perhaps we can
> have a wiki page or discussion with active code first branches.

I updated the RFC to mention the edk2-staging repo approach and the need 
to migrate to the appropriate repository.


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

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

[Michael D Kinney]

Another option to consider for all Code First tasks is to 
use PRs against the edk2 repo.  PRs can be synced periodically
and can be in open state until the spec updates are public and
then merged into edk2.  

Mike

> -----Original Message-----
> From: Michael Kubacki <mikuback@linux.microsoft.com>
> Sent: Friday, August 16, 2024 12:54 PM
> To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>;
> gaoliming@byosoft.com.cn; rfc@edk2.groups.io
> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@microsoft.com>
> Subject: Re: 回复: [edk2-devel] [RFC] Transitioning from Bugzilla to GitHub
> Issues
> 
> On 8/14/2024 11:49 PM, Michael D Kinney wrote:
> >
> >> -----Original Message-----
> >> From: Michael Kubacki <mikuback@linux.microsoft.com>
> >> Sent: Wednesday, August 14, 2024 7:30 PM
> >> To: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Kinney, Michael D
> >> <michael.d.kinney@intel.com>; rfc@edk2.groups.io
> >> Cc: 'Andrew Fish' <afish@apple.com>; 'Leif Lindholm'
> >> <quic_llindhol@quicinc.com>; 'Sean Brogan' <sean.brogan@microsoft.com>
> >> Subject: Re: 回复: [edk2-devel] [RFC] Transitioning from Bugzilla to
> GitHub
> >> Issues
> >> On 8/6/2024 1:34 AM, gaoliming via groups.io wrote:
> >>> Michael:
> >>>     Thanks for your great effort. This is a good direction to
> consolidate
> >> code and issue together. My feedbacks are below:
> >>>
> >>> 1. BugZilla supports code first process. What proposal will handle this
> >> process in Github issue flow?
> >>
> >> For the Tianocore specifications, the proposal is that each respective
> >> repository in the tianocore-docs organization
> >> (https://github.com/tianocore-docs) maintain their issues.
> >>
> >> I'm open to suggestions for the UEFI Specification issues.
> >
> > Code first has 2 categories.  One is for spec changes and the other
> > is for the code changes associated with the spec changes.
> >
> > Code first uses branches in the edk2-staging repo, so perhaps all
> > code first related bugs should migrate to the edk2-staging repo.
> >
> > We do want to make these very visible and have ways to integrate/test
> > code first changes with latest edk2 repo content.  SO perhaps we can
> > have a wiki page or discussion with active code first branches.
> 
> I updated the RFC to mention the edk2-staging repo approach and the need
> to migrate to the appropriate repository.


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