Re: Proposal of new control field: Date

[jidanni]

Speaking about new control fields, how about "Date:"?

Imagine, "freshness dating available right there on the grocer's
shelf, in Packages.gz. No need for the consumer to jump through
additional hoops to find out."

OK, never mind.


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

Re: Proposal of new control field: Date

[Paul Wise]

On Thu, Feb 12, 2009 at 9:11 AM,   wrote:

> Speaking about new control fields, how about "Date:"?
>
> Imagine, "freshness dating available right there on the grocer's
> shelf, in Packages.gz. No need for the consumer to jump through
> additional hoops to find out."

Which date would it contain?

> OK, never mind.

Hmm?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Proposal of new control field: Date

[Russ Allbery]

Paul Wise  writes:
> On Thu, Feb 12, 2009 at 9:11 AM,   wrote:

>> Speaking about new control fields, how about "Date:"?

>> Imagine, "freshness dating available right there on the grocer's shelf,
>> in Packages.gz. No need for the consumer to jump through additional
>> hoops to find out."

> Which date would it contain?

I've several times wished that our Packages list contained the date from
the corresponding entry in the debian/changelog file.  It's been a while
since the last time I wished for that, so I don't remember exactly what I
was going to use it for at the time, but I remember noticing its absence
more than once.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Proposal of new control field: Date

[jidanni]

>> Imagine, "freshness dating available right there on the grocer's
>> shelf, in Packages.gz. No need for the consumer to jump through
>> additional hoops to find out."

PW> Which date would it contain?

The date the maintainer made the polishing touches on the .deb.
That way one could tell, even when offline, if a package hasn't been
updated in ten years.

Well OK, assuming network connections, one can always just do e.g.,
$ apt-get -yyqq --print-uris install abiword|
   perl -F\' -alnwe 'print $F[1]'|xargs --verbose -n 1 HEAD -P|grep -i 
Last-Modified
HEAD -P 
http://ftp.tw.debian.org/debian/pool/main/libv/libvoikko/libvoikko1_2.0-1_i386.deb
Last-Modified: Tue, 13 Jan 2009 15:02:17 GMT
HEAD -P 
http://ftp.tw.debian.org/debian/pool/main/libg/libgsf/libgsf-gnome-1-114_1.14.11-2_i386.deb
Last-Modified: Fri, 30 Jan 2009 17:47:03 GMT

But the same could be said about some of the other fields, like Size.
Just do another HEAD to get the Size. But OK, Size is more important
than Date, so it gets a field in Packages.gz.


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

Re: Proposal of new control field: Date

[Paul Wise]

On Thu, Feb 12, 2009 at 12:40 PM,   wrote:

> PW> Which date would it contain?
>
> The date the maintainer made the polishing touches on the .deb.

We don't have that date. We do have:

The date from the changelog/changes file. Depending on the workflow
the maintainer uses, this could be when they first started working on
the package or just before they uploaded it.

The date stored in the GPG signature on the dsc file. This is probably
usually just before the package was uploaded. Probably closest to what
you want, except for NMUs.

The date stored in the GPG signature on the changes file. This is
probably usually just before the package was uploaded. This will
differ between architectures though.

The date the archive software imported the .deb into the archive.

> That way one could tell, even when offline, if a package hasn't been
> updated in ten years.

I hope we don't have any of those.

> But OK, Size is more important than Date, so it gets a field in Packages.gz.

I don't agree that Size is more much important than Date, both are
information that can be used when deciding to install a package.

At some point we have to stop including more info into Packages
though, I don't think that screenshots should be added uuencoded to
Packages for example.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Proposal of new control field: Date

[Robert Collins]

On Thu, 2009-02-12 at 11:40 +0800, jida...@jidanni.org wrote:
> >> Imagine, "freshness dating available right there on the grocer's
> >> shelf, in Packages.gz. No need for the consumer to jump through
> >> additional hoops to find out."
> 
> PW> Which date would it contain?
> 
> The date the maintainer made the polishing touches on the .deb.
> That way one could tell, even when offline, if a package hasn't been
> updated in ten years.
> 
> Well OK, assuming network connections, one can always just do e.g.,
> $ apt-get -yyqq --print-uris install abiword|
>perl -F\' -alnwe 'print $F[1]'|xargs --verbose -n 1 HEAD -P|grep -i 
> Last-Modified
> HEAD -P 
> http://ftp.tw.debian.org/debian/pool/main/libv/libvoikko/libvoikko1_2.0-1_i386.deb
> Last-Modified: Tue, 13 Jan 2009 15:02:17 GMT
> HEAD -P 
> http://ftp.tw.debian.org/debian/pool/main/libg/libgsf/libgsf-gnome-1-114_1.14.11-2_i386.deb
> Last-Modified: Fri, 30 Jan 2009 17:47:03 GMT

Thats the filesystem datestamp on the mirror, not the last time the
maintainer made an upload.

-Rob


signature.asc
Description: This is a digitally signed message part

Re: Proposal of new control field: Date

[Enrico Zini]

On Thu, Feb 12, 2009 at 01:27:14PM +0900, Paul Wise wrote:

> > That way one could tell, even when offline, if a package hasn't been
> > updated in ten years.
> I hope we don't have any of those.

And those that we have, we can also spot them by old Standards-Version
in lintian warnings.

If anyone can suggest me a decent heuristics to spot a 'rotting' package
(like, for example standards-version older than X, but you need to tell
me what X), I can automatically mine it and turn it into a debtags tag.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini 


signature.asc
Description: Digital signature

Re: Proposal of new control field: Date

[gregor herrmann]

On Thu, 12 Feb 2009 11:40:32 +0800, jida...@jidanni.org wrote:

> Well OK, assuming network connections, one can always just do e.g.,

Or `who-uploads --date $package'.

Cheers,
gregor 
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Donovan: Jennifer Juniper


signature.asc
Description: Digital signature

Re: Proposal of new control field: Date

[Joerg Jaspert]

>> > That way one could tell, even when offline, if a package hasn't been
>> > updated in ten years.
>> I hope we don't have any of those.
> And those that we have, we can also spot them by old Standards-Version
> in lintian warnings.

> If anyone can suggest me a decent heuristics to spot a 'rotting' package
> (like, for example standards-version older than X, but you need to tell
> me what X), I can automatically mine it and turn it into a debtags tag.

There is no such heuristic. Just because a package last upload is long
ago doesn't mean the package is outdated/broken/whatever. It may mean
that, but it may also just mean that there was no reason to update it.

-- 
bye, Joerg
"If you are using an Macintosh e-mail program that is not from Microsoft, we
recommend checking with that particular company. But most likely other e-mail
 programs like Eudora are not designed to enable virus replication" 
   -- http://www.microsoft.com/mac/products/office/2001/virus_alert.asp


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

Re: Proposal of new control field: Date

[Leo "costela" Antunes]

Enrico Zini wrote:
> If anyone can suggest me a decent heuristics to spot a 'rotting' package
> (like, for example standards-version older than X, but you need to tell
> me what X), I can automatically mine it and turn it into a debtags tag.

I would propose something like freshness of bugs vs. freshness of last
non-binary upload, possibly weighted. This would let old but
non-problematic packages off the radar.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Re: Proposal of new control field: Date

[Enrico Zini]

On Thu, Feb 12, 2009 at 08:44:16PM +0100, Leo costela Antunes wrote:

> I would propose something like freshness of bugs vs. freshness of last
> non-binary upload, possibly weighted. This would let old but
> non-problematic packages off the radar.

I don't have the time to design and test such an algorithm (and I'd have
to also brush up my statistics), but if anyone else wants to try and see
how it goes, that's fine to me.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini 


signature.asc
Description: Digital signature

Re: Proposal of new control field: Date

[Adeodato Simó]

* Enrico Zini [Thu, 12 Feb 2009 22:50:41 +]:

> On Thu, Feb 12, 2009 at 08:44:16PM +0100, Leo costela Antunes wrote:

> > I would propose something like freshness of bugs vs. freshness of last
> > non-binary upload, possibly weighted. This would let old but
> > non-problematic packages off the radar.

> I don't have the time to design and test such an algorithm (and I'd have
> to also brush up my statistics), but if anyone else wants to try and see
> how it goes, that's fine to me.

There was something akin to this (though targetted at spotting orphaning
/ removal candidates rather than just to assess the liveness of a package):

  http://wiki.debian.org/qa.debian.org/bapase

Not sure if that continues to be active or not. Bcc'ing bap...@qa.debian.org
in case they want to comment. Context is:

> If anyone can suggest me a decent heuristics to spot a 'rotting' package
> (like, for example standards-version older than X, but you need to tell
> me what X), I can automatically mine it and turn it into a debtags tag.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
A hacker does for love what other would not do for money.


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

Re: Proposal of new control field: Date

[jidanni]

OK, instead of a Date: field in Packages, I can get a better idea of how
well maintained a package is with an "updates vs. bugs" perspective, e.g.,

for package
do for u in http://packages.qa.debian.org/common/index.html?src=$package \
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=$package
do w3m -dump $u
done
done

OK, I withdraw my Proposal.


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

Re: Proposal of new control field: Date

[Guillem Jover]

Hi!

On Thu, 2009-02-12 at 13:27:14 +0900, Paul Wise wrote:
> On Thu, Feb 12, 2009 at 12:40 PM,   wrote:
> > PW> Which date would it contain?
> >
> > The date the maintainer made the polishing touches on the .deb.
> 
> We don't have that date. We do have:

> [...]

And the date the .deb was built:

  $ ar tv /var/cache/apt/archives/acpi_1.3-1_i386.deb debian-binary
  rw-r--r-- 0/0  4 Feb 11 12:23 2009 debian-binary

this one should be pretty exact (as long as the builder's system time
is approximately correct), as everyone in Debian should be using
dpkg-deb.

> > But OK, Size is more important than Date, so it gets a field in Packages.gz.
> 
> I don't agree that Size is more much important than Date, both are
> information that can be used when deciding to install a package.

Well, the difference is that the Size and Installed-Size fields fall
in the category of fields that can be used automatically by package
managers, for example to automatically check if there's enough disk
space before downloading, or similar. And dates are mostly informative.

> At some point we have to stop including more info into Packages
> though, I don't think that screenshots should be added uuencoded to
> Packages for example.

There's different possibly interesting dates, last changed (from
debian/changelog), source built date (currently only from stat .dsc)
and binary built date (from .deb ar entry).

Adding the fields is easy, and for binary built it would only need
changes in the Packages-file generators, but what we'd have to get
consensus about first is if including and propagating these is
worthwhile, and then if it is, which of them.

regards,
guillem


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

Re: Proposal of new control field: Date

[Thibaut Paumard]

Le 13 févr. 09 à 03:01, jida...@jidanni.org a écrit :

OK, instead of a Date: field in Packages, I can get a better idea of  
how
well maintained a package is with an "updates vs. bugs" perspective,  
e.g.,


I would also have a look at the package's popularity. An old, barely  
used, broken package may not have any bug report if the few people who  
tried it didn't care enough to write one.


Regards, Thibaut.


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