Asheesh Laroia writes ("Re: mentors.debian.net runs the debexpo code now"):
> Paul Wise answered this, basically -- it's kind of a mess. Debexpo doesn't
> really improve the situation yet.
Right. And thanks to Paul for answering the question.
> "All" it does is give us a solid platform on top of which to build a
> decent solution to that problem.
Right.
> Paul's list is quite comprehensive, and could serve as a blueprint for
> places that debexpo could harvest information from. That way, the debexpo
> page for a package could show the latest info from all those sources.
It might be a good idea to think about how the mentor workflow is
supposed to work and arrange (for example) that there is one place
where it is recorded who is working on a particular
package-in-need-of-a-mentor. (Obviously "who" might include more than
one person.)
We also need to formally track the state of such mentor requests, in
the same way we do bugs. Perhaps a mentors bug psuedopackage would do
as a stopgap ? We could evolve some usertags as we went.
What I'm trying to get to is a point where it's reasonably
straightforward for an existing experienced DD, who knows about
packaging but not very much about the mentor process details, and has
a bit of spare time, to:
1. Find a package that needs a mentor and/or a sponsor that interests
them or that they might know something about
2. Download the actual package and review it (this part debexpo
currently seems to do fairly well)
3. Find the comments made by mentors (whether themselves or someone
else) on previous versions of the package
4. Make a decision, eg to decide to upload the package, to provide
a list of things to fix to the maintainer, to join the package's
team, or whatever
5. Know where to send their comments and how to communicate their
decision (in particular, to stop the package appearing in the list
of packages that are in need of attention from a mentor, in step 1)
6. Be able to request or decline email notifications and copies when
a new version is proposed for sponsoring, when other people make
comments, etc.
It's fine if much of this involves traffic on a public list, but
mentors should not be expected to subscribe to such a list.
Much of this could perhaps be done with the BTS already.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20046.47064.983443.11...@chiark.greenend.org.uk
