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