public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-portage-dev] Bugzilla workflow
@ 2014-01-05 22:05 Sebastian Luther
  2014-01-05 22:19 ` Alexander Berntsen
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Sebastian Luther @ 2014-01-05 22:05 UTC (permalink / raw
  To: gentoo-portage-dev

Hi all,

since we're at documenting things, I wonder if we want to discuss and
document the bugzilla workflow.

For now I tried to handle bugs like Zac did. That is:

There always exists a tracker bug, named:
"[Tracker] sys-apps/portage-<next version>".

This bug is renamed from X.Y.Z to X.Y.Z+1 after a release, until it gets
closed when Y changes and a new one is opened.

Whenever a commit for a specific bug is made to the git repo, the
corresponding bug gets changed in the following ways:
* InVCS is added to Keywords
* The bug is marked as blocking the tracker for the next version
* A comment is added saying: This is fixed in git: <url to commit>
(note that the bug stays open)

After a release all open bugs blocking the tracker are closed with the
comment "This is fixed in <version>.".

I like this workflow because it makes it easy to see what has been fixed
since the last release. The only thing I have no use for, is this InVCS
keyword. I do not know what Zac used it for. Does anyone have a use for it?

Another topic is the bug status for open bugs, i.e. CONFIRMED,
UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them and
haven't found them useful, but Brian suggested to use IN_PROGRESS at
times. What are your thoughts?

Did I miss something? Any suggestions?

Sebastian


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 22:05 [gentoo-portage-dev] Bugzilla workflow Sebastian Luther
@ 2014-01-05 22:19 ` Alexander Berntsen
  2014-01-05 22:30   ` Brian Dolbec
  2014-01-05 22:35 ` Mike Frysinger
  2014-01-07 21:20 ` Sebastian Luther
  2 siblings, 1 reply; 11+ messages in thread
From: Alexander Berntsen @ 2014-01-05 22:19 UTC (permalink / raw
  To: gentoo-portage-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/01/14 23:05, Sebastian Luther wrote:
> I like this workflow because it makes it easy to see what has been
>  fixed since the last release. The only thing I have no use for, is
>  this InVCS keyword. I do not know what Zac used it for. Does
> anyone have a use for it?
I'm not sure what your confusion is. When a fix is pushed, it is InVCS.
The bug is not SOLVED, because it only InVCS, not in a release.

> Another topic is the bug status for open bugs, i.e. CONFIRMED, 
> UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them
> and haven't found them useful, but Brian suggested to use
> IN_PROGRESS at times. What are your thoughts?
My interpretation is that CONFIRMED bugs are bugs that a developer is
able to reproduce, and IN_PROGRESS bugs are bugs that a developer is
presently working on a fix for.

CONFIRMED is, in my opinion, very useful. IN_PROGRESS is not that
interesting.
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLJ2lYACgkQRtClrXBQc7WCUgEApkPtEfm+NbZ6h61++6LmBlUa
NXqlny20ZRtEqHFIDWMBAIl0meIaehTKe9Y/ZJZFhViCz/P9YOI0A2eJykPjLNdn
=ffkw
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 22:19 ` Alexander Berntsen
@ 2014-01-05 22:30   ` Brian Dolbec
  2014-01-05 22:54     ` Alexander Berntsen
  0 siblings, 1 reply; 11+ messages in thread
From: Brian Dolbec @ 2014-01-05 22:30 UTC (permalink / raw
  To: gentoo-portage-dev

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On Sun, 2014-01-05 at 23:19 +0100, Alexander Berntsen wrote:
> On 05/01/14 23:05, Sebastian Luther wrote:
> > I like this workflow because it makes it easy to see what has been
> >  fixed since the last release. The only thing I have no use for, is
> >  this InVCS keyword. I do not know what Zac used it for. Does
> > anyone have a use for it?
> I'm not sure what your confusion is. When a fix is pushed, it is InVCS.
> The bug is not SOLVED, because it only InVCS, not in a release.
> 
> > Another topic is the bug status for open bugs, i.e. CONFIRMED, 
> > UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them
> > and haven't found them useful, but Brian suggested to use
> > IN_PROGRESS at times. What are your thoughts?
> My interpretation is that CONFIRMED bugs are bugs that a developer is
> able to reproduce, and IN_PROGRESS bugs are bugs that a developer is
> presently working on a fix for.
> 
> CONFIRMED is, in my opinion, very useful. IN_PROGRESS is not that
> interesting.

Oh, but it does has uses.

If you open the tracker bug.  The bug numbers listed as blockers.
Hover your mouse over the bug number.  A small popup window appears and
shows the bug summary and status.  The keywords are not listed.  So, for
a bug that has a fix in git for already.  If you change the status to
IN_PROGRESS, then that status is visible in the popup.  Making it easier
to not keep revisiting a bug only to discover it is already fixed.  Same
applies to the bug search page.  The status is shown, but not the
keywords.

I don't know about you, but even though I have a good memory for
numbers.  It is not that good.  They all look alike ;)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 22:05 [gentoo-portage-dev] Bugzilla workflow Sebastian Luther
  2014-01-05 22:19 ` Alexander Berntsen
@ 2014-01-05 22:35 ` Mike Frysinger
  2014-01-07 21:20 ` Sebastian Luther
  2 siblings, 0 replies; 11+ messages in thread
From: Mike Frysinger @ 2014-01-05 22:35 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: Sebastian Luther

[-- Attachment #1: Type: Text/Plain, Size: 1145 bytes --]

On Sunday 05 January 2014 17:05:04 Sebastian Luther wrote:
> For now I tried to handle bugs like Zac did. That is:
> 
> There always exists a tracker bug, named:
> "[Tracker] sys-apps/portage-<next version>".

would be nice to start adding an alias field.  this way you can do:
	https://bugs.gentoo.org/show_bug.cgi?id=portage-2.2.8

> I like this workflow because it makes it easy to see what has been fixed
> since the last release. The only thing I have no use for, is this InVCS
> keyword. I do not know what Zac used it for. Does anyone have a use for it?

you can add a bug blocking the release tracker that hasn't yet been fixed in 
git.  the InVCS tag let's people filter between the two states.

> Another topic is the bug status for open bugs, i.e. CONFIRMED,
> UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them and
> haven't found them useful, but Brian suggested to use IN_PROGRESS at
> times. What are your thoughts?

i don't personally care about any of those, but some people find it useful.  
they all make sense, so it's just a matter of people using them to keep track 
of things.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 22:30   ` Brian Dolbec
@ 2014-01-05 22:54     ` Alexander Berntsen
  2014-01-05 23:04       ` Mike Frysinger
  0 siblings, 1 reply; 11+ messages in thread
From: Alexander Berntsen @ 2014-01-05 22:54 UTC (permalink / raw
  To: gentoo-portage-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/01/14 23:30, Brian Dolbec wrote:
> If you open the tracker bug.  The bug numbers listed as blockers. 
> Hover your mouse over the bug number.  A small popup window
> appears and shows the bug summary and status.  The keywords are not
> listed. So, for a bug that has a fix in git for already.  If you
> change the status to IN_PROGRESS, then that status is visible in
> the popup. Making it easier to not keep revisiting a bug only to
> discover it is already fixed.  Same applies to the bug search page.
> The status is shown, but not the keywords.
OK, let's drop InVCS and use IN_PROGRESS to mean "fix in git".

> I don't know about you, but even though I have a good memory for 
> numbers.  It is not that good.  They all look alike ;)
I tend to focus on a small subset of bugs (that I find interesting) at
the time, so I had not considered this use case. Thanks.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLJ4pQACgkQRtClrXBQc7UOsQEAtX0uK1qha4ttHD9HDimAnFJy
DzxGu8v4t86cTqgYY+4BAKS7DmGSc3Y1M+0voiWTcQCPNTX1j63vZ+m4rvj+p3Kj
=V1Bd
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 22:54     ` Alexander Berntsen
@ 2014-01-05 23:04       ` Mike Frysinger
  2014-01-05 23:42         ` Brian Dolbec
  0 siblings, 1 reply; 11+ messages in thread
From: Mike Frysinger @ 2014-01-05 23:04 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: Alexander Berntsen

[-- Attachment #1: Type: Text/Plain, Size: 752 bytes --]

On Sunday 05 January 2014 17:54:12 Alexander Berntsen wrote:
> On 05/01/14 23:30, Brian Dolbec wrote:
> > If you open the tracker bug.  The bug numbers listed as blockers.
> > Hover your mouse over the bug number.  A small popup window
> > appears and shows the bug summary and status.  The keywords are not
> > listed. So, for a bug that has a fix in git for already.  If you
> > change the status to IN_PROGRESS, then that status is visible in
> > the popup. Making it easier to not keep revisiting a bug only to
> > discover it is already fixed.  Same applies to the bug search page.
> > The status is shown, but not the keywords.
> 
> OK, let's drop InVCS and use IN_PROGRESS to mean "fix in git".

those aren't the same thing
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 23:04       ` Mike Frysinger
@ 2014-01-05 23:42         ` Brian Dolbec
  2014-01-15  2:58           ` Tom Wijsman
  0 siblings, 1 reply; 11+ messages in thread
From: Brian Dolbec @ 2014-01-05 23:42 UTC (permalink / raw
  To: gentoo-portage-dev

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

On Sun, 2014-01-05 at 18:04 -0500, Mike Frysinger wrote:
> On Sunday 05 January 2014 17:54:12 Alexander Berntsen wrote:
> > On 05/01/14 23:30, Brian Dolbec wrote:
> > > If you open the tracker bug.  The bug numbers listed as blockers.
> > > Hover your mouse over the bug number.  A small popup window
> > > appears and shows the bug summary and status.  The keywords are not
> > > listed. So, for a bug that has a fix in git for already.  If you
> > > change the status to IN_PROGRESS, then that status is visible in
> > > the popup. Making it easier to not keep revisiting a bug only to
> > > discover it is already fixed.  Same applies to the bug search page.
> > > The status is shown, but not the keywords.
> > 
> > OK, let's drop InVCS and use IN_PROGRESS to mean "fix in git".
> 
> those aren't the same thing
> -mike

IN_PROGRESS essentially means it is or has been looked after already.
Adding the InVCS keyword further indicates the fix is applied somewhere
already.

So, a suggested workflow is:

1) check a bug, 
    a) if you can reproduce, then mark it as CONFIRMED
    b) not enough info, can't reproduce,... mark or comment it
       accordingly.
2) start working on a solution,
   a) if you have significant progress, but need more time, mark it
      accordingly, assign it to yourself, leave a comment, etc.  
   b) If you have a patch but need
      it tested before committing, upload it there with the request.
   c) Optionally mark it as IN_PRROGRESS for a & b above when 
      appropriate.
3) commit the fix.  Mark it as InVCS, if not already, set status to
   IN_PROGRESS
4) make a release with the patch/fix. Mark the bug RESOLVED, FIXED.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 22:05 [gentoo-portage-dev] Bugzilla workflow Sebastian Luther
  2014-01-05 22:19 ` Alexander Berntsen
  2014-01-05 22:35 ` Mike Frysinger
@ 2014-01-07 21:20 ` Sebastian Luther
  2 siblings, 0 replies; 11+ messages in thread
From: Sebastian Luther @ 2014-01-07 21:20 UTC (permalink / raw
  To: gentoo-portage-dev

Here's a new version of the workflow that tries to incorporate
all the comments.

This should go into the DEVELOPING file once everyone agrees.

Bugzilla
--------

There always exists a tracker bug, named:
"[Tracker] sys-apps/portage-<next version>".

This bug is renamed from X.Y.Z to X.Y.Z+1 after a release, until
it gets closed when Y changes and a new one is opened.

Whenever a commit for a specific bug is made to the git repo,
the corresponding bug gets changed in the following ways:
* InVCS is added to Keywords
* The bug is marked as blocking the tracker for the next version
* A comment is added saying: This is fixed in git: <url to commit>
(note that the bug stays open)

After a release all open bugs blocking the tracker are closed
with the comment "This is fixed in <version>.".

For individual open bugs it is encouraged to set UNCONFIRMED,
CONFIRMED or IN_PROGESS as appropriate.

There are a number of bugs named "[TRACKER] *" that collect bugs
for specific topics. Confirmed bugs should be marked as blocking
these tracker bugs if appropriate.

It is encouraged to set the alias field for frequently used bugs.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-05 23:42         ` Brian Dolbec
@ 2014-01-15  2:58           ` Tom Wijsman
  2014-01-19  9:10             ` Mike Frysinger
  0 siblings, 1 reply; 11+ messages in thread
From: Tom Wijsman @ 2014-01-15  2:58 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: dolsen

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

On Sun, 05 Jan 2014 15:42:48 -0800
Brian Dolbec <dolsen@gentoo.org> wrote:

> So, a suggested workflow is:

I like this workflow the most; however, feedback on it appears to be
missing and the document incorporation seems to outright ignore it.

Can we please (re)consider and discuss this?

> 1) check a bug, 
>     a) if you can reproduce, then mark it as CONFIRMED

Filtering by CONFIRMED bugs if you want to start on a fix right away is
very handy to do.

>     b) not enough info, can't reproduce,... mark or comment it
>        accordingly.

Definitely, bugs lingering on in UNCONFIRMED for too long is a bad idea;
otherwise they would collect over time, not processing bugs in a timely
fashion is something we'd like to avoid as to not upset users.

> 2) start working on a solution,
>    a) if you have significant progress, but need more time, mark it
>       accordingly, assign it to yourself, leave a comment, etc.

Assigning it to oneself is a quite good idea as it allows to easily keep
track of the bugs you are working on, otherwise you have to rely on
techniques that aren't optimal; which are unfortunate.

In the lists of all bugs, that can be obtained by checking out the
product and/or categories; this gives a quite clear overview of who is
working on what, as well as which bugs are still free. As this is still
able to be done, there seems no need to assign the bug to Portage team.

Leaving a comment is something I'll try to do from now on too.

>    b) If you have a patch but need
>       it tested before committing, upload it there with the request.

I suppose URL or attachment suffices, this sounds good.

>    c) Optionally mark it as IN_PRROGRESS for a & b above when 
>       appropriate.

This should be more clear cut; if we want this to be effective, it
should be like before which has clear value on the blockers that we
use. As it gives a quick overview of what is in master and what is not.

> 3) commit the fix.  Mark it as InVCS, if not already, set status to
>    IN_PROGRESS

InVCS becomes redundant; other than that, good.

> 4) make a release with the patch/fix. Mark the bug RESOLVED, FIXED.

Sounds good.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-15  2:58           ` Tom Wijsman
@ 2014-01-19  9:10             ` Mike Frysinger
  2014-01-19 16:19               ` Tom Wijsman
  0 siblings, 1 reply; 11+ messages in thread
From: Mike Frysinger @ 2014-01-19  9:10 UTC (permalink / raw
  To: gentoo-portage-dev; +Cc: Tom Wijsman, dolsen

[-- Attachment #1: Type: Text/Plain, Size: 1756 bytes --]

On Tuesday 14 January 2014 21:58:38 Tom Wijsman wrote:
> On Sun, 05 Jan 2014 15:42:48 -0800 Brian Dolbec wrote:
> > 2) start working on a solution,
> >    a) if you have significant progress, but need more time, mark it
> >       accordingly, assign it to yourself, leave a comment, etc.
> 
> Assigning it to oneself is a quite good idea as it allows to easily keep
> track of the bugs you are working on, otherwise you have to rely on
> techniques that aren't optimal; which are unfortunate.
> 
> In the lists of all bugs, that can be obtained by checking out the
> product and/or categories; this gives a quite clear overview of who is
> working on what, as well as which bugs are still free. As this is still
> able to be done, there seems no need to assign the bug to Portage team.

i disagree.  dev-portage@ get's cc-ed on bugs when they're being kept abreast 
of developments (like PMS), or someone just wants an opinion/feedback on an 
issue.  so there's no way to differentiate between bugs that are assigned to 
the portage team and bugs where the portage team's opinion is being requested.  
i want a query for the former and i just rely on generated bugzilla e-mails 
for the latter.

what's wrong with using the whiteboard ?  it's a free text field and you can 
easily construct a query that produces exactly what you want.  just stick in 
your username in there.

> > 3) commit the fix.  Mark it as InVCS, if not already, set status to
> >    IN_PROGRESS
> 
> InVCS becomes redundant; other than that, good.

i don't see how it's redundant.  there is no other flag that indicates things 
have been fixed in the git tree and the only reason the bug remains open is 
that a release has not yet been cut.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [gentoo-portage-dev] Bugzilla workflow
  2014-01-19  9:10             ` Mike Frysinger
@ 2014-01-19 16:19               ` Tom Wijsman
  0 siblings, 0 replies; 11+ messages in thread
From: Tom Wijsman @ 2014-01-19 16:19 UTC (permalink / raw
  To: vapier; +Cc: gentoo-portage-dev

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

On Sun, 19 Jan 2014 04:10:20 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> i disagree.  dev-portage@ get's cc-ed on bugs when they're being kept
> abreast of developments (like PMS), or someone just wants an
> opinion/feedback on an issue.  so there's no way to differentiate
> between bugs that are assigned to the portage team and bugs where the
> portage team's opinion is being requested. i want a query for the
> former and i just rely on generated bugzilla e-mails for the latter.

We have a whole product that tracks the bugs as well as individual
components; as a query can be made for that, this forms no problem.

Whether Portage is CC-ed is out of this context.

> what's wrong with using the whiteboard ?  it's a free text field and
> you can easily construct a query that produces exactly what you
> want.  just stick in your username in there.

This is a very good idea; I think that I can also search the URL, we
could make it commonly known that if the URL or whiteboard respcetively
contains a patch or a name that we know the person works on it.

> On Tuesday 14 January 2014 21:58:38 Tom Wijsman wrote:
>
> > InVCS becomes redundant; other than that, good.  
>
> i don't see how it's redundant.  there is no other flag that
> indicates things have been fixed in the git tree and the only reason
> the bug remains open is that a release has not yet been cut.

It is redundant because IN_PROGRESS would mean that it is in VCS; which
is needed for better overview on the tracker, hence setting InVCS would
add no extra meaning but just reflect the IN_PROGRESS status.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2014-01-19 16:20 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-05 22:05 [gentoo-portage-dev] Bugzilla workflow Sebastian Luther
2014-01-05 22:19 ` Alexander Berntsen
2014-01-05 22:30   ` Brian Dolbec
2014-01-05 22:54     ` Alexander Berntsen
2014-01-05 23:04       ` Mike Frysinger
2014-01-05 23:42         ` Brian Dolbec
2014-01-15  2:58           ` Tom Wijsman
2014-01-19  9:10             ` Mike Frysinger
2014-01-19 16:19               ` Tom Wijsman
2014-01-05 22:35 ` Mike Frysinger
2014-01-07 21:20 ` Sebastian Luther

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox