Hello!


The two web pages "Packages being worked on" [1] and
"Requested packages" [2] have several shortcomings:
* No sorting by age
* No importance/popularity tag of packages
* No combined requested-or-worked-on (== not packaged) view
* No easy status indicator, e.g. "license issues",
"upstream without maintainer", ...

Measuring popularity could be done either explicitly
(e.g. through votes) or implicitly (e.g. through
counting the number of people replying to a request).


With these features those pages would show better
what packages ...
* are potentially easy to package, therefore suitable
for motivated Debian rookies
* are really wanted
* are important though hard to package
* catching dust already


I think that a bit more infrastructure could do a lot
here, e.g. increase the package-per-minute rate.

Please let me know ...
* what you think
* how it can be done
* how I can help.

Yes, it's bullet list Thursday :-)

I hope to hear of you soon,



Sebastian


[1] http://www.debian.org/devel/wnpp/being_packaged
[2] http://www.debian.org/devel/wnpp/requested


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 03/01/08 at 23:50 +0100, Sebastian Pipping wrote:
> Hello!
>
>
> The two web pages "Packages being worked on" [1] and
> "Requested packages" [2] have several shortcomings:

The same shortcomings exist for the orphaned packages.

> I think that a bit more infrastructure could do a lot
> here, e.g. increase the package-per-minute rate.

Good idea, just do it

No, seriously, that's the kind of things that should probably be done
outside the debian infrastructure to start with, and moved "inside"
later.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Lucas Nussbaum wrote:

The two web pages "Packages being worked on" [1] and
"Requested packages" [2] have several shortcomings:


The same shortcomings exist for the orphaned packages.


Do I understand right that orphaned packages are packages
already left unmaintained while up-for-adoption means
the maintainer is still taking care but plans to leave?

I guess I should extend the scope to all sub pages of
"Work-Needing and Prospective Packages" [1].




Good idea, just do it

No, seriously, that's the kind of things that should probably be done
outside the debian infrastructure to start with, and moved "inside"
later.


Sounds good, great you like it.



Sebastian


[1] http://www.debian.org/devel/wnpp/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Sebastian Pipping <webmaster@hartwork.org> writes:

> Lucas Nussbaum wrote:
> >> The two web pages "Packages being worked on" [1] and
> >> "Requested packages" [2] have several shortcomings:
> >
> > The same shortcomings exist for the orphaned packages.
>
> Do I understand right that orphaned packages are packages already
> left unmaintained while up-for-adoption means the maintainer is
> still taking care but plans to leave?

No need to speculate; just refer to the Developer's Reference.

An orphaned package, by definition, is one that has gone through the
procedure for orphaning a package
<URL:http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-orphaning>;
"up for adoption" is one that meets the same document's guidelines on
adopting a package
<URL:http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-adopting>.

--
"Choose mnemonic identifiers. If you can't remember what |
` mnemonic means, you've got a problem." —Larry Wall |
_o__) |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hello,

Sebastian Pipping wrote:
> * what you think

It is a good idea to make those pages more useful

> * how it can be done

Ok, let's go point by point:

> * No sorting by age

AFAIR the SOAP interface can provide you with such information (refer to the
wiki page).

> * No importance/popularity tag of packages

popcon data is available at popcon.d.o, importance can be extracted from the
Packages files.
And for ITP/RFP bugs an external service could do the trick (like bugzilla's
votes system).

> * No combined requested-or-worked-on (== not packaged) view

This isn't very clear for me, why do you want to combine them?

> * No easy status indicator, e.g. "license issues",
> * *"upstream without maintainer", ...

That can be done by making use of usertags

Cheers,
Raphael Geissert




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Raphael Geissert wrote:

AFAIR the SOAP interface can provide you with such information (refer to the
wiki page).


I'd rather talk to SQL if possible. It's faster and much easier to me.




popcon data is available at popcon.d.o, importance can be extracted from the
Packages files.


Good idea.




* No combined requested-or-worked-on (== not packaged) view


This isn't very clear for me, why do you want to combine them?


When requesting new packages one currently has two search
both lists, which currently means browsing two pages.
But I found out now this page actually does this combination
already:
http://www.debian.org/devel/wnpp/prospective



Sebastian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 05/01/08 at 19:19 +0100, Sebastian Pipping wrote:
> Raphael Geissert wrote:
>> AFAIR the SOAP interface can provide you with such information (refer to the
>> wiki page).
>
> I'd rather talk to SQL if possible. It's faster and much easier to me.

Another solution is to use the BTS dump available at
http://qa.debian.org/data/bts2ldap/
It's very easy to parse (and import in an SQL DB, if you want)
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Lucas Nussbaum wrote:

Another solution is to use the BTS dump available at
http://qa.debian.org/data/bts2ldap/
It's very easy to parse (and import in an SQL DB, if you want)


Interesting. Thank you!



Sebastian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sat, 05 Jan 2008, Sebastian Pipping wrote:
> Raphael Geissert wrote:
>> AFAIR the SOAP interface can provide you with such information (refer to
>> the
>> wiki page).
>
> I'd rather talk to SQL if possible. It's faster and much easier to me.

There's no SQL to talk to. If you want actual accurate data, the SOAP
service is the thing to talk to. [Anything else has various delay
lengths in it before you actually see the data reported.]


Don Armstrong

--
An elephant: A mouse built to government specifications.
-- Robert Heinlein _Time Enough For Love_ p244

http://www.donarmstrong.com http://rzlab.ucr.edu


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Don Armstrong wrote:

There's no SQL to talk to. If you want actual accurate data, the SOAP
service is the thing to talk to. [Anything else has various delay
lengths in it before you actually see the data reported.]


Where does SOAP get the data from?



Sebastian


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org