[gimp-web/testing] Scrub bugzilla links



commit 164fe19e89567278771d954835422b3615df504c
Author: Pat David <patdavid gmail com>
Date:   Thu Jan 10 21:58:55 2019 -0600

    Scrub bugzilla links

 content/about/meta/git-workflow.md | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
---
diff --git a/content/about/meta/git-workflow.md b/content/about/meta/git-workflow.md
index e0ae7927..ba66b179 100644
--- a/content/about/meta/git-workflow.md
+++ b/content/about/meta/git-workflow.md
@@ -25,7 +25,7 @@ The general workflow is:
 3. If it builds ok on *testing*...
     1. merge the changes to *master* and push.
         [www.gimp.org][] will re-build every 20 minutes.
-    2. create a patch and attach it to bugzilla
+    2. create a patch and attach it to a Gitlab issue
 
 [testing.gimp.org]: //testing.gimp.org
 [www.gimp.org]: //www.gimp.org
@@ -88,7 +88,7 @@ When it is finished and working fine, I can test it on [testing.gimp.org][] by m
 
 Wait for a rebuild to happen on the server, then check the site to make sure your changes propagated without 
breaking something.
 
-**If** you don't have write access to gimp-web, you can instead [create a patch against 
*testing*](#creating-a-patch) from your branch and submit it to [bugzilla][report].
+**If** you don't have write access to gimp-web, you can instead [create a patch against 
*testing*](#creating-a-patch) from your branch and submit it to [Gitlab issues][report].
 
 If it did and you're happy with the result, go ahead and get it into the *master* branch.
 If you're allowed, simply switch to *master* and merge your *newstuff* branch into it also.
@@ -106,7 +106,7 @@ The reason why you would merge from *newstuff* rather than *testing* is in case
 
 But what if you don't have rights to push to gimp-web?
 No problem!
-You can create patches instead that you can attach to [bug reports][report] in bugzilla.
+You can create patches instead that you can attach to [bug reports][report] in Gitlab.
 
 Again, assuming you were working in your own branch (*which you should be*).
 Say you've made a bunch of commits to your branch and are ready to have someone test it and possibly push it 
to *testing*.
@@ -114,9 +114,9 @@ You can use `format-patch` to generate one nice big patch for all of your work a
 
 `git format-patch testing --stdout > my_awesome_work.patch`
 
-Now attach that to a bug/enhancement report in [bugzilla][report] and wait to hear back!
+Now attach that to a bug/enhancement report in [Gitlab issues][report] and wait to hear back!
 
-[report]: https://bugzilla.gnome.org/enter_bug.cgi?product=gimp-web
+[report]: 
https://gitlab.gnome.org/Infrastructure/gimp-web/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=
 
 
 
@@ -148,10 +148,10 @@ This is helpful if there's a different author but we need to track down who actu
 
 
 
-## Bugzilla Logging
-If you fix something and need to reference what was fixed in a bugzilla thread, you can get consistent
+## Logging
+If you fix something and need to reference what was fixed in a Gitlab issue thread, you can get consistent
 output with the rest of GIMP log messages by using:
 
 `git show --stat`
 
-and pasting the results into the bugzilla message.
+and pasting the results into the Gitlab message.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]