Hi,
forget this mail - I just missed the fact that it is realised since
a long time and was beaten by a typo of mine.
Sorry for the noise
Andreas.
On Fri, Dec 17, 2010 at 02:11:06PM +0100, Andreas Tille wrote:
> Hi,
>
> I would like to bring up again the issue which was discussed in Febr
Hi,
I would like to bring up again the issue which was discussed in February
on this list starting with[1]. I commited
svn://svn.debian.org/svn/collab-qa/udd/sql/releases.sql
which to my perspective implements the result of the discussion. If
nobody insists I would like to move this into th
>> after all sid can well have a version of a package which is newer
>> than its version in experimental and vice-versa, the same is potentially
>> true for testing.
> You mean testing can have a never version as experimental?
Unstable:
VersionChecks
{
MustBeNewerThan
On Wed, Feb 03, 2010 at 04:47:56PM +0100, Stefano Zacchiroli wrote:
>
> I fully understand your use case, in fact it is the same the PTS has for
> sorting the lines of the various releases in all package pages. Still, I
> wanted to point out that that order is somehow arbitrary, for non
> released
On 03/02/10 at 16:47 +0100, Stefano Zacchiroli wrote:
> As an alternative suggestion that just occurred to me, we can actually
> define a new datatype for releases (as we did for package versions)
> which is an enumeration sorted as we please. That way "<" ordering would
> work automagically. I'm n
On Wed, Feb 03, 2010 at 04:32:36PM +0100, Andreas Tille wrote:
>
> CREATE TABLE releases (
>release text, /* keep name column as in other tables */
>releasedate date,
>sortint,
>PRIMARY KEY (releasename)
> );
>
> INSERT INTO releases VALUES ( 'etch',
On Wed, Feb 03, 2010 at 04:32:36PM +0100, Andreas Tille wrote:
> My idea was primarily not about sorting package versions but rather to
> list releases in a determined sequence. Listing "experimental" in the
> end sounded reasonable to me. I admit that the versions of packages
> inside experiment
On Wed, Feb 03, 2010 at 03:14:09PM +0100, Stefano Zacchiroli wrote:
>
> I personally don't particularly like the idea of faking dates to mean
> something specific such as "not release yet". On the other hand I like
> the idea of storing the release date because it is an information per se
> and mi
On Wed, Feb 03, 2010 at 02:08:41PM +0100, Andreas Tille wrote:
> On Wed, Feb 03, 2010 at 01:12:38PM +0100, Lucas Nussbaum wrote:
> > If we are going this way, it would make more sense to provide the
> > release date as the value to sort on. And use a specific date in the
> > future for releases whi
On Wed, Feb 03, 2010 at 01:12:38PM +0100, Lucas Nussbaum wrote:
> If we are going this way, it would make more sense to provide the
> release date as the value to sort on. And use a specific date in the
> future for releases which haven't happened yet.
That's a really good idea and I think I'll go
On 02/02/10 at 14:54 +0100, Andreas Tille wrote:
> Hi,
>
> recently the type 'release' was dropped because it creates much hasle to
> add a new release (needs recreation of tables containing this type etc).
> Because I would like to be able to sort entries per release I would like
> to suggest a l
Hi,
recently the type 'release' was dropped because it creates much hasle to
add a new release (needs recreation of tables containing this type etc).
Because I would like to be able to sort entries per release I would like
to suggest a lookup table
CREATE TABLE releases (
releasename text,
12 matches
Mail list logo
