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@g.o 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.
>