From Fedora Project Wiki

(added Possible Alternate Work Flow)
(→‎Work Flow: Added git commands.)
 
(7 intermediate revisions by 3 users not shown)
Line 3: Line 3:
# Bug is filed in Bugzilla
# Bug is filed in Bugzilla
# Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
# Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
## Procedure
### Create a new local branch for you to work: ''git checkout -b patch_for_BZ_<bug #>''
### Make your changes in your new branch.
### Once you have committed your changes create your patch: ''git format-patch master --stdout > BZ<bz number>.patch''
# Filer confirms the patch fixes the problem
# Filer confirms the patch fixes the problem
# Bug goes to Docs QA (Bug set to "ON QA")
# Bug goes to Docs QA (Bug set to "ON QA")
# Docs QA checks the items documented in the [[Docs QA Review Guidelines]] in the patch
# Docs QA checks the items documented in the [[Docs QA Review Guidelines]] in the patch
# Docs QA sets ticket as "VERIFIED"
# Docs QA sets ticket as "VERIFIED"
# Author patches guide, publishes the new version, closes bug
# Owner applies the fix to the master branch.
## Check for errors before applying: ''git apply --check BZ<bz number>.patch''
## If no errors, apply the patch: ''git am --signoff < BZ<bz number>.patch''
# Push the changes to the remote repo.
##If there has been no action from the QA after 10 days, the Owner contacts QA Wrangler (see below).
##If there has been no action from the QA after two weeks, the Owner applies the fix without QA approval.
# Owner publishes the new version, closes bug
## When a Guide is branched for release, all patches can be included, even if they are still "ON_QA," but the bug remains ON_QA so the QA contact can verify the fix eventually.


== Possible Alternate Work Flow ==
== Notes ==
This is proposed by [[user:Crantila|crantila]] as a way to deal with the issues of not having enough consistently active contributors.
# Docs components with no specified QA contact will be QA'ed by the docs-qa mailing list
# Patches should not be QA'ed by the component's owners or other regular contributors.
# The Docs lead is in charge of nagging the docs-qa mailing list about open QA tasks since the nag feature of BZ isn't enabled.  


# Problem is identified
== QA Wrangler ==
# Bug is filed in Bugzilla
The Docs QA Wrangler will be a quasi-official position within Fedora Docs. The person who volunteers for this task will be responsible for:
# Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
# Prodding assignees about stale tickets
# Filer confirms the patch fixes the problem
# Reporting regularly to the Docs groups about the ticket state (aggregate data on count, severity, status, etc)
# Bug goes to Docs QA (Bug set to "ON_QA")
# ensuring QA contacts are assigned for bugzilla components
# Guide owner patches guide.
# Performing spot checks on tickets to see if they follow the QA process and make determinations about the process' effectiveness.
## If a fix is needed for the current release, owner says so and requests immediate QA action. Patch is applied to current release and master.
# Opening tickets for new [[Features]] to ensure major changes to Fedora are reflected in each guide.
## Otherwise, the fix is applied to the master branch.
# Wrangling external review of their own commits
# Docs QA checks the items documented in the Docs QA Review Guidelines in the patch, on the timeline requested by the guide owner. If a Guide's dedicated QA contact does not respond within a week, or says they cannot fulfill their duties in the timeline requested, somebody else can jump in.
# Docs QA sets the bug to "VERIFIED"
# When a Guide is branched for release, all patches can be included, even if they are still "ON_QA," but the bug remains ON_QA so the QA contact can verify the fix eventually.


[[Category:Docs QA]]
[[Category:Docs QA]]

Latest revision as of 03:01, 8 October 2012

Work Flow

  1. Problem is identified
  2. Bug is filed in Bugzilla
  3. Someone fixes the bug and submits a patch to Bugzilla (same ticket) for consideration
    1. Procedure
      1. Create a new local branch for you to work: git checkout -b patch_for_BZ_<bug #>
      2. Make your changes in your new branch.
      3. Once you have committed your changes create your patch: git format-patch master --stdout > BZ<bz number>.patch
  4. Filer confirms the patch fixes the problem
  5. Bug goes to Docs QA (Bug set to "ON QA")
  6. Docs QA checks the items documented in the Docs QA Review Guidelines in the patch
  7. Docs QA sets ticket as "VERIFIED"
  8. Owner applies the fix to the master branch.
    1. Check for errors before applying: git apply --check BZ<bz number>.patch
    2. If no errors, apply the patch: git am --signoff < BZ<bz number>.patch
  9. Push the changes to the remote repo.
    1. If there has been no action from the QA after 10 days, the Owner contacts QA Wrangler (see below).
    2. If there has been no action from the QA after two weeks, the Owner applies the fix without QA approval.
  10. Owner publishes the new version, closes bug
    1. When a Guide is branched for release, all patches can be included, even if they are still "ON_QA," but the bug remains ON_QA so the QA contact can verify the fix eventually.

Notes

  1. Docs components with no specified QA contact will be QA'ed by the docs-qa mailing list
  2. Patches should not be QA'ed by the component's owners or other regular contributors.
  3. The Docs lead is in charge of nagging the docs-qa mailing list about open QA tasks since the nag feature of BZ isn't enabled.

QA Wrangler

The Docs QA Wrangler will be a quasi-official position within Fedora Docs. The person who volunteers for this task will be responsible for:

  1. Prodding assignees about stale tickets
  2. Reporting regularly to the Docs groups about the ticket state (aggregate data on count, severity, status, etc)
  3. ensuring QA contacts are assigned for bugzilla components
  4. Performing spot checks on tickets to see if they follow the QA process and make determinations about the process' effectiveness.
  5. Opening tickets for new Features to ensure major changes to Fedora are reflected in each guide.
  6. Wrangling external review of their own commits
Retrieved from "https://fedoraproject.org/w/index.php?title=Docs_QA_Procedure&oldid=305957"