[gentoo-dev] RFC: New Project: Bug Cleaners

[gentoo-dev] RFC: New Project: Bug Cleaners

[Tom Wijsman]

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

Hello

This is a request for comments on a new project:

http://wiki.gentoo.org/wiki/Project:Bug_Cleaners

The Gentoo Bug Cleaners project aims to clean up the oldest bugs in
Bugzilla. Our goal is twofold, the main purpose of this project is to
close bugs on Bugzilla that do no longer apply due to versions and/or
packages that are no longer present in the Portage tree; as a side
effect, it also tries to look for solutions to the oldest bugs.

For those that still have use, it attempts to inform the persons
involved in the bug that the bug is still open if the bug is important;
inviting them to take a decision on it.

Because one cannot just rush in and go hunt at random bugs and expect
people to agree with one's actions; the very first steps we will take
is to raise the necessary discussion here with you to receive feedback
on what you as the community want us to do, which clarifies the further
limits and scope of this project.

There are some questions that need further discussion:

 * How old is "oldest"?

   While we intend to work from the back of the bug queue, we might or
   might not get closer to more recent bugs; so, one would wonder if we
   need a limit on which bugs we can and can't touch.

 * When is a bug considered still useful?

   There are clear cases like a bug that's no longer reproducable and
   thus clearly doesn't apply; however, there are cases where one might
   be in doubt (eg. Do people still want it resolved? Do we still want
   to add a package that stopped its development X years ago?) that
   might not be so clear cut. I'd like to get clearer borders defined.

 * Are there other types of bugs we could or need to look into?

   We start with the oldest bugs; but the project name does not include
   "Old", are there other types of bugs you would like to see cleaned?

 * Do we need a mail alias so we can get assigned or CC-ed on bugs?

   This one gets me in doubt, the only case I can come up with is that
   being able to CC bug-cleaners@gentoo.org allows users to effectively
   help us out as well by marking bugs they consider old.

   Another reason might be that we can assign related trackers to it.

 * Do you have any useful resources that we should be aware of?

   I know of the QA bug reports and the ability to search queries, are
   there any other tools already made to indicate or deal with old bugs?

 * Can this effort replace the Bug Day that didn't receive interest lately?

   At the last Bug Days, I did not see much users join us; which makes
   me wonder if that concept (still) works. Since this project does a
   very similar thing, I am wondering if we can perhaps make the Bug
   Day concept obsolete and form a more permanent effort than a monthly
   meeting; in order to allow for more effort on every single day.

-- The rest of the mail shows results of cleaning, feel free to skip. --

I've walked through a few old bugs in the past as part of the Bug Day
efforts as well as some moments outside of that, I've closed and pinged
some bugs without any negative feedback on them which appeared to be a
good thing; under the form of a project, I like to invite more people
to join forces as well as do this in a more organized way to avoid
future conflicts and get more work done.

One tracker that resulted out of the above effort is:

https://bugs.gentoo.org/show_bug.cgi?id=472746

Which covers old interesting conceptual, abstract and unimplemented
ideas and feature requests; it gathers a lot of ideas together, let me
list some examples:

 * Offload work by distributing trivial ebuild maintenance to users,
   introduce a simple stability voting system and have a core team
   approve them to the Portage tree.

 * (portage / gentoolkit) Show dependencies in detail; clarifying
   whether they are DEPEND, RDEPEND or PDEPEND and optional.

 * Implement a reverse dependency tracker using LDD information and
   compare it against the run-time dependencies listed in the ebuild.

 * Checkpointing and restoring packages states, e.g. `emerge undo`.

 * Please add GraphViz output to equery depgraph.

 * Automatic testing infrastructure (send build erros to Gentoo Infra)

I think that if we identify more of such bugs we get together a very
useful list for people that want to contribute to Portage to look into
for ideas; perhaps also useful for GSoC, to be inspiring for students.

Feel free to raise any other questions, comments or remarks.

Thank you very much in advance.

-- 
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 --]

Re: [gentoo-dev] RFC: New Project: Bug Cleaners

[Damien Levac]

+1

I was an user very interested by the bug day event, but the timing was
never right. A permanent effort where everyone can help whenever they
can seems more interesting. The only thing needed then is documentation
on exactly what can be done by users with varying skills.

Damien

On 11/16/2013 06:16 AM, Tom Wijsman wrote:
> Hello
>
> This is a request for comments on a new project:
>
> http://wiki.gentoo.org/wiki/Project:Bug_Cleaners
>
> The Gentoo Bug Cleaners project aims to clean up the oldest bugs in
> Bugzilla. Our goal is twofold, the main purpose of this project is to
> close bugs on Bugzilla that do no longer apply due to versions and/or
> packages that are no longer present in the Portage tree; as a side
> effect, it also tries to look for solutions to the oldest bugs.
>
> For those that still have use, it attempts to inform the persons
> involved in the bug that the bug is still open if the bug is important;
> inviting them to take a decision on it.
>
> Because one cannot just rush in and go hunt at random bugs and expect
> people to agree with one's actions; the very first steps we will take
> is to raise the necessary discussion here with you to receive feedback
> on what you as the community want us to do, which clarifies the further
> limits and scope of this project.
>
> There are some questions that need further discussion:
>
>  * How old is "oldest"?
>
>    While we intend to work from the back of the bug queue, we might or
>    might not get closer to more recent bugs; so, one would wonder if we
>    need a limit on which bugs we can and can't touch.
>
>  * When is a bug considered still useful?
>
>    There are clear cases like a bug that's no longer reproducable and
>    thus clearly doesn't apply; however, there are cases where one might
>    be in doubt (eg. Do people still want it resolved? Do we still want
>    to add a package that stopped its development X years ago?) that
>    might not be so clear cut. I'd like to get clearer borders defined.
>
>  * Are there other types of bugs we could or need to look into?
>
>    We start with the oldest bugs; but the project name does not include
>    "Old", are there other types of bugs you would like to see cleaned?
>
>  * Do we need a mail alias so we can get assigned or CC-ed on bugs?
>
>    This one gets me in doubt, the only case I can come up with is that
>    being able to CC bug-cleaners@gentoo.org allows users to effectively
>    help us out as well by marking bugs they consider old.
>
>    Another reason might be that we can assign related trackers to it.
>
>  * Do you have any useful resources that we should be aware of?
>
>    I know of the QA bug reports and the ability to search queries, are
>    there any other tools already made to indicate or deal with old bugs?
>
>  * Can this effort replace the Bug Day that didn't receive interest lately?
>
>    At the last Bug Days, I did not see much users join us; which makes
>    me wonder if that concept (still) works. Since this project does a
>    very similar thing, I am wondering if we can perhaps make the Bug
>    Day concept obsolete and form a more permanent effort than a monthly
>    meeting; in order to allow for more effort on every single day.
>
> -- The rest of the mail shows results of cleaning, feel free to skip. --
>
> I've walked through a few old bugs in the past as part of the Bug Day
> efforts as well as some moments outside of that, I've closed and pinged
> some bugs without any negative feedback on them which appeared to be a
> good thing; under the form of a project, I like to invite more people
> to join forces as well as do this in a more organized way to avoid
> future conflicts and get more work done.
>
> One tracker that resulted out of the above effort is:
>
> https://bugs.gentoo.org/show_bug.cgi?id=472746
>
> Which covers old interesting conceptual, abstract and unimplemented
> ideas and feature requests; it gathers a lot of ideas together, let me
> list some examples:
>
>  * Offload work by distributing trivial ebuild maintenance to users,
>    introduce a simple stability voting system and have a core team
>    approve them to the Portage tree.
>
>  * (portage / gentoolkit) Show dependencies in detail; clarifying
>    whether they are DEPEND, RDEPEND or PDEPEND and optional.
>
>  * Implement a reverse dependency tracker using LDD information and
>    compare it against the run-time dependencies listed in the ebuild.
>
>  * Checkpointing and restoring packages states, e.g. `emerge undo`.
>
>  * Please add GraphViz output to equery depgraph.
>
>  * Automatic testing infrastructure (send build erros to Gentoo Infra)
>
> I think that if we identify more of such bugs we get together a very
> useful list for people that want to contribute to Portage to look into
> for ideas; perhaps also useful for GSoC, to be inspiring for students.
>
> Feel free to raise any other questions, comments or remarks.
>
> Thank you very much in advance.
>

[gentoo-dev] Re: RFC: New Project: Bug Cleaners

[Ryan Hill]

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

On Sat, 16 Nov 2013 12:16:01 +0100
Tom Wijsman <TomWij@gentoo.org> wrote:

> Hello
> 
> This is a request for comments on a new project:
> 
> http://wiki.gentoo.org/wiki/Project:Bug_Cleaners

Sounds like a good idea to me.

>  * When is a bug considered still useful?
> 
>    There are clear cases like a bug that's no longer reproducable and
>    thus clearly doesn't apply; however, there are cases where one might
>    be in doubt (eg. Do people still want it resolved? Do we still want
>    to add a package that stopped its development X years ago?) that
>    might not be so clear cut. I'd like to get clearer borders defined.

I'd like it if maintainer-wanted bugs stayed open.  They often have useful
discussion, ebuilds, patches, etc.  I have one from 2006 that just got pinged
yesterday.  One thing you could do is CC teams that you think might be
interested in the package.

Of course if the project is dead and buried then the bug should just be closed.

>  * Do we need a mail alias so we can get assigned or CC-ed on bugs?
> 
>    This one gets me in doubt, the only case I can come up with is that
>    being able to CC bug-cleaners@gentoo.org allows users to effectively
>    help us out as well by marking bugs they consider old.
> 
>    Another reason might be that we can assign related trackers to it.

Well, once you touch an old bug it won't be old anymore, so you're going to
need some way of keeping track of them.  


-- 
Ryan Hill                        psn: dirtyepic_sk
   gcc-porting/toolchain/wxwidgets @ gentoo.org

47C3 6D62 4864 0E49 8E9E  7F92 ED38 BD49 957A 8463

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