[gimp-web/testing] Scrub bugzilla links
- From: Pat David <patdavid src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gimp-web/testing] Scrub bugzilla links
- Date: Fri, 11 Jan 2019 03:59:06 +0000 (UTC)
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]