Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bugzilla+Github workflow
69 views
Skip to first unread message
Vivien
Oct 3, 2012, 10:33:47 AM10/3/12
to dev-...@lists.mozilla.org
Hey folks,
The new Github -> Bugzilla process is here and and many seems
disapointed (like me)!
I would like to amend a little bit Tim's proposal and here is my
suggestion of workflow depending on your goals:
*You want to open an issue and that's it?*
- Never open an *issue* in github. Open *issues* in bugzilla.
https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko
- If you think the bug should block the release, please ask for
*blocking-basecamp ?* in the flags section
*You want to attach a patch for review?*
- Make a Pull Request to github that reference the bugzilla bug
number in the commit message (e.g "Bug xxxxxx - commit message.")
- Go to the bugzilla page and add an attachment (see [1]) and ask a
review *r?* to someone on the attachment
*You want to review a patch?*
- Go to github and do like usual.
*Your patch is beeing reviewed and you have things to changed?*
- Don't forget to squash (git rebase master -i) your commits into one.
*You want to merge a reviewed patch?"
- If the patch is blocking-basecamp+, then you can merge it
- If the patch is not blocking-basecamp+ then you need an approval
(Vivien Nicolas, Chris Jones) to land the patch. See
https://etherpad.mozilla.org/b2g-stabilization-plan
I hope this helps.
Vivien.
[1] bugzilla attachment to add. Replace XXX_PR_NUMBER by the Pull
Request number on bugzilla.
-----------------start patch.html----------------
<html>
<head>
<meta http-equiv="Refresh" content="2;
url=https://github.com/mozilla-b2g/gaia/pull/XXX_PR_NUMBER">
</head>
<body>
Redirect to pull request XXX_PR_NUMBER
</body>
</html>
-----------------end patch.html------------------
The new Github -> Bugzilla process is here and and many seems
disapointed (like me)!
I would like to amend a little bit Tim's proposal and here is my
suggestion of workflow depending on your goals:
*You want to open an issue and that's it?*
- Never open an *issue* in github. Open *issues* in bugzilla.
https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko
- If you think the bug should block the release, please ask for
*blocking-basecamp ?* in the flags section
*You want to attach a patch for review?*
- Make a Pull Request to github that reference the bugzilla bug
number in the commit message (e.g "Bug xxxxxx - commit message.")
- Go to the bugzilla page and add an attachment (see [1]) and ask a
review *r?* to someone on the attachment
*You want to review a patch?*
- Go to github and do like usual.
*Your patch is beeing reviewed and you have things to changed?*
- Don't forget to squash (git rebase master -i) your commits into one.
*You want to merge a reviewed patch?"
- If the patch is blocking-basecamp+, then you can merge it
- If the patch is not blocking-basecamp+ then you need an approval
(Vivien Nicolas, Chris Jones) to land the patch. See
https://etherpad.mozilla.org/b2g-stabilization-plan
I hope this helps.
Vivien.
[1] bugzilla attachment to add. Replace XXX_PR_NUMBER by the Pull
Request number on bugzilla.
-----------------start patch.html----------------
<html>
<head>
<meta http-equiv="Refresh" content="2;
url=https://github.com/mozilla-b2g/gaia/pull/XXX_PR_NUMBER">
</head>
<body>
Redirect to pull request XXX_PR_NUMBER
</body>
</html>
-----------------end patch.html------------------
Robert Kaiser
Oct 3, 2012, 11:03:57 AM10/3/12
to mozilla-...@lists.mozilla.org
Vivien schrieb:
successfully.
Note that a but exists that can mark the bug fixed when the PR get
merged, and I guess that bot could be improved to make the workflow even
smoother.
Feel free to ask the Socorro guys in #breakpad on details on their
GitHub+Bugzilla workflow.
Robert Kaiser
> I would like to amend a little bit Tim's proposal and here is my
> suggestion of workflow depending on your goals:
This sounds very similar to the process that Socorro is using quite
> suggestion of workflow depending on your goals:
successfully.
Note that a but exists that can mark the bug fixed when the PR get
merged, and I guess that bot could be improved to make the workflow even
smoother.
Feel free to ask the Socorro guys in #breakpad on details on their
GitHub+Bugzilla workflow.
Robert Kaiser
David Flanagan
Oct 3, 2012, 1:09:48 PM10/3/12
to dev-...@lists.mozilla.org
On 10/3/12 7:33 AM, Vivien wrote:
> Hey folks,
>
> The new Github -> Bugzilla process is here and and many seems
> disapointed (like me)!
>
> Hey folks,
>
> The new Github -> Bugzilla process is here and and many seems
> disapointed (like me)!
>
> I would like to amend a little bit Tim's proposal and here is my
> suggestion of workflow depending on your goals:
>
>
> suggestion of workflow depending on your goals:
>
>
> *You want to open an issue and that's it?*
> - Never open an *issue* in github. Open *issues* in bugzilla.
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko
> - If you think the bug should block the release, please ask for
> *blocking-basecamp ?* in the flags section
>
>
> *You want to attach a patch for review?*
> - Make a Pull Request to github that reference the bugzilla bug
> number in the commit message (e.g "Bug xxxxxx - commit message.")
> - Go to the bugzilla page and add an attachment (see [1]) and ask a
> review *r?* to someone on the attachment
>
This step seems like a baroque workaround to the fact that bugzilla
> - Never open an *issue* in github. Open *issues* in bugzilla.
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko
> - If you think the bug should block the release, please ask for
> *blocking-basecamp ?* in the flags section
>
>
> *You want to attach a patch for review?*
> - Make a Pull Request to github that reference the bugzilla bug
> number in the commit message (e.g "Bug xxxxxx - commit message.")
> - Go to the bugzilla page and add an attachment (see [1]) and ask a
> review *r?* to someone on the attachment
>
doesn't allow review requests without an attachment. If our reviewer is
a fellow gaia developer who is used to github, can we just handle the
review process through github? Otherwise the first steps for any review
request will be "1) find that email from Vivien 2) Copy his redirect
header tags..."
>
> *You want to review a patch?*
> - Go to github and do like usual.
>
>
> *Your patch is beeing reviewed and you have things to changed?*
> - Don't forget to squash (git rebase master -i) your commits into one.
>
backed out?
For those, like me, who are scared of git rebase, it is also possible to
do this with git diff; switch to new branch; patch or something like that.
>
> *You want to merge a reviewed patch?"
> - If the patch is blocking-basecamp+, then you can merge it
> - If the patch is not blocking-basecamp+ then you need an approval
> (Vivien Nicolas, Chris Jones) to land the patch. See
> https://etherpad.mozilla.org/b2g-stabilization-plan
>
then land it ourselves? Or do we ask you to land it. What is the
equivalent of the checkin-needed flag for reviewed non-blocking patches?
Do we request approval in bugzilla or in github?
>
>
> I hope this helps.
>
It does help, particularly the task-oriented nature of it. Thanks.
But I do want to end with a plea to allow us to continue using github
for as much work as possible. I have worked at mozilla for 17 months.
During that time, I have used github daily. I've used bugzilla to file
bugs once or twice a week. I've attached patches to bugzilla bugs maybe
once a month. And I think I have reviewed a patch on bugzilla once.
I wasn't hired for B2G, but quite a few Gaia developers were, and I
assume that they are bugzilla newbies like me. We will learn to use
Bugzilla, but it is going to be a productivity hit at a time when we
really can't afford one. My understanding is that we need to be filing
bugs in bugzilla so that the managers who track how close we are to
release ready can do that important job.
But there's no reason the code review process has to happen in bugzilla
(as Tim suggested) or be split between bugzilla and github (as Vivien
suggests here) is there?
David
> Vivien.
>
>
> [1] bugzilla attachment to add. Replace XXX_PR_NUMBER by the Pull
> Request number on bugzilla.
> -----------------start patch.html----------------
> <html>
> <head>
> <meta http-equiv="Refresh" content="2;
> url=https://github.com/mozilla-b2g/gaia/pull/XXX_PR_NUMBER">
> </head>
> <body>
> Redirect to pull request XXX_PR_NUMBER
> </body>
> </html>
> -----------------end patch.html------------------
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
Nicolas B. Pierron
Oct 3, 2012, 6:37:03 PM10/3/12
to mozilla-...@lists.mozilla.org
On 10/03/2012 10:09 AM, David Flanagan wrote:
> But there's no reason the code review process has to happen in bugzilla (as
> Tim suggested) or be split between bugzilla and github (as Vivien suggests
> here) is there?
There is one reason, which has not yet happen in gaia, but should happen at
> But there's no reason the code review process has to happen in bugzilla (as
> Tim suggested) or be split between bugzilla and github (as Vivien suggests
> here) is there?
least before the release, which are security patches. For security issues,
you *should never* push to github or any other public repository, before
your patch got approved on bugzilla and can be landed in the main repository.
But don't worry, I guess all would be explained in time.
--
Nicolas B. Pierron
Tim Guan-tin Chien
Oct 3, 2012, 10:23:22 PM10/3/12
to Vivien, nicolas....@mozilla.com, dev-...@lists.mozilla.org
I don't like the way patch.html is designed (i.e. a dummy file for
people to upload to Bugzilla so we can record the r+ bit), but I am
running out of ideas also...
Just to avoid that dummy file and also fit the security requirement that
Nicolas points out, I will probably just send the patch for review to
Bugzilla directly.
On 10/3/12 10:33 PM, Vivien wrote:
> Hey folks,
>
> The new Github -> Bugzilla process is here and and many seems
> disapointed (like me)!
>
> I would like to amend a little bit Tim's proposal and here is my
> suggestion of workflow depending on your goals:
>
>
> *You want to open an issue and that's it?*
> - Never open an *issue* in github. Open *issues* in bugzilla.
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko
> - If you think the bug should block the release, please ask for
> *blocking-basecamp ?* in the flags section
>
>
> *You want to attach a patch for review?*
> - Make a Pull Request to github that reference the bugzilla bug
> number in the commit message (e.g "Bug xxxxxx - commit message.")
> - Go to the bugzilla page and add an attachment (see [1]) and ask a
> review *r?* to someone on the attachment
>
>
Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
people to upload to Bugzilla so we can record the r+ bit), but I am
running out of ideas also...
Just to avoid that dummy file and also fit the security requirement that
Nicolas points out, I will probably just send the patch for review to
Bugzilla directly.
On 10/3/12 10:33 PM, Vivien wrote:
> Hey folks,
>
> The new Github -> Bugzilla process is here and and many seems
> disapointed (like me)!
>
> I would like to amend a little bit Tim's proposal and here is my
> suggestion of workflow depending on your goals:
>
>
> *You want to open an issue and that's it?*
> - Never open an *issue* in github. Open *issues* in bugzilla.
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko
> - If you think the bug should block the release, please ask for
> *blocking-basecamp ?* in the flags section
>
>
> *You want to attach a patch for review?*
> - Make a Pull Request to github that reference the bugzilla bug
> number in the commit message (e.g "Bug xxxxxx - commit message.")
> - Go to the bugzilla page and add an attachment (see [1]) and ask a
> review *r?* to someone on the attachment
>
>
> *You want to review a patch?*
> - Go to github and do like usual.
>
>
> *Your patch is beeing reviewed and you have things to changed?*
> - Don't forget to squash (git rebase master -i) your commits into one.
>
>
> - Go to github and do like usual.
>
>
> *Your patch is beeing reviewed and you have things to changed?*
> - Don't forget to squash (git rebase master -i) your commits into one.
>
>
> *You want to merge a reviewed patch?"
> - If the patch is blocking-basecamp+, then you can merge it
> - If the patch is not blocking-basecamp+ then you need an approval
> (Vivien Nicolas, Chris Jones) to land the patch. See
> https://etherpad.mozilla.org/b2g-stabilization-plan
>
>
>
> I hope this helps.
> - If the patch is blocking-basecamp+, then you can merge it
> - If the patch is not blocking-basecamp+ then you need an approval
> (Vivien Nicolas, Chris Jones) to land the patch. See
> https://etherpad.mozilla.org/b2g-stabilization-plan
>
>
>
>
> Vivien.
>
>
> [1] bugzilla attachment to add. Replace XXX_PR_NUMBER by the Pull
> Request number on bugzilla.
> -----------------start patch.html----------------
> <html>
> <head>
> <meta http-equiv="Refresh" content="2;
> url=https://github.com/mozilla-b2g/gaia/pull/XXX_PR_NUMBER">
> </head>
> <body>
> Redirect to pull request XXX_PR_NUMBER
> </body>
> </html>
> -----------------end patch.html------------------
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
--
> Vivien.
>
>
> [1] bugzilla attachment to add. Replace XXX_PR_NUMBER by the Pull
> Request number on bugzilla.
> -----------------start patch.html----------------
> <html>
> <head>
> <meta http-equiv="Refresh" content="2;
> url=https://github.com/mozilla-b2g/gaia/pull/XXX_PR_NUMBER">
> </head>
> <body>
> Redirect to pull request XXX_PR_NUMBER
> </body>
> </html>
> -----------------end patch.html------------------
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
Tim Guan-tin Chien, Front-end Dev, Mozilla Corp. (Taipei)
Ben Francis
Oct 4, 2012, 10:37:32 AM10/4/12
to Tim Guan-tin Chien, nicolas....@mozilla.com, Vivien, dev-...@lists.mozilla.org
On Thu, Oct 4, 2012 at 3:23 AM, Tim Guan-tin Chien <timd...@mozilla.com>wrote:
> I don't like the way patch.html is designed (i.e. a dummy file for people
> to upload to Bugzilla so we can record the r+ bit), but I am running out of
> ideas also...
>
> Just to avoid that dummy file and also fit the security requirement that
> Nicolas points out, I will probably just send the patch for review to
> Bugzilla directly.
Is it not enough to just link to a pull request in a comment, then for a
> I don't like the way patch.html is designed (i.e. a dummy file for people
> to upload to Bugzilla so we can record the r+ bit), but I am running out of
> ideas also...
>
> Just to avoid that dummy file and also fit the security requirement that
> Nicolas points out, I will probably just send the patch for review to
> Bugzilla directly.
reviewer to just comment "r+me" either on the bugzilla bug or even on the
pull request itself, then merge the pull request with the reviewer added to
the commit message?
Pastor Alberto (UK)
Oct 4, 2012, 12:12:19 PM10/4/12
to Ben Francis, Tim Guan-tin Chien, nicolas....@mozilla.com, Vivien, dev-...@lists.mozilla.org
This plugin [1] creates a link attachment in Bugzilla from a Pull Request.
Dietrich told something about this in the IRC.
Does it help?
Thanks!
[1]
https://addons.mozilla.org/en-US/firefox/addon/github-tweaks-for-bugzilla/
Switchboard: +44 (0)113 272 2000
Email: feed...@o2.com
Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85
Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85
Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778 6037 85
Dietrich told something about this in the IRC.
Does it help?
Thanks!
[1]
https://addons.mozilla.org/en-US/firefox/addon/github-tweaks-for-bugzilla/
>_______________________________________________
>dev-gaia mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia
This electronic message contains information from Telefonica UK, Telefonica Europe or Telefonica Digital which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email.
>dev-gaia mailing list
>dev-...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia
Switchboard: +44 (0)113 272 2000
Email: feed...@o2.com
Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85
Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85
Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778 6037 85
0 new messages