Re: [UDD] Suggested table: release_order
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 might be useful as such.
ACK.
> Now, according to that principle, a possible proper way of storing
> release dates would be to have the corresponding field NULLABLE and
> store NULL for suites not yet released. That way released suite can be
> easily sorted by date, taking care of filtering out NULL values before
> hand.
What do you consider as proper release date for *-security and
*-proposed-updates (NULL, same as release or my suggestion releasedate +
1/2 days).
> That of course leave the problem of how to respectively sort squeeze,
> sid, and experimental. I do wonder however if it is really needed to do
> that;
I'd vote for having a defined sorting between squeeze (= current
testing) and sid because it is definitely ordered in the sense of "some
existing point in the future" and "infinite" (=never).
> 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? Yes, that's
possible, but are there practical cases where a version in testing is
higher than in sid? Well, there might be reasons to push older versions
in and it might happen. However my use case is a *defined* reasonable
ordering when listing versions of releases (no matter what exact version
the package has - but you should always find the releases listed in the
same sequence). A sequence of
<past releases> - <testing> - <unstable>
makes definitely sense.
> Andreas: can you please give an use case where
> sorting sid vs experimental is needed?
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 experimental do not necessarily follow this ordering.
My application is the "Versions and Archs" button on the tasks pages
and I'm just seeking a way to make sure that we do not get something
like
http://debian-med.alioth.debian.org/tasks/bio.en.html#seaview
If you move the mouse cursor on the Button "Newer upstream" you see a
sequence "sid - squeeze - etch - lenny" which is just unlogically. So
any determinable sequence which includes experimental is fine.
> After that convincing example, I'd vote for an extra column which will
> be used to totally order unreleased suite, that would preserve the
> ability to filter out non-release suites. (Yes, you can do that also
> filtering out future dates, but that sounds incredibly like not the
> right thing to do, at least in my eyes.)
So I try to reiterate
CREATE TABLE releases (
release text, /* keep name column as in other tables */
releasedate date,
sort int,
PRIMARY KEY (releasename)
);
INSERT INTO releases VALUES ( 'etch', '2007-04-08', 400 );
INSERT INTO releases VALUES ( 'etch-security', '2007-04-09', 401 ); /* date or NULL ?? */
INSERT INTO releases VALUES ( 'etch-proposed-updates', '2007-04-10', 402 ); /* date or NULL ?? */
INSERT INTO releases VALUES ( 'lenny', '2009-02-14', 500 );
INSERT INTO releases VALUES ( 'lenny-security', '2009-02-15', 501 ); /* date or NULL ?? */
INSERT INTO releases VALUES ( 'lenny-proposed-updates', '2009-02-14', 502 ); /* date or NULL ?? */
INSERT INTO releases VALUES ( 'squeeze', NULL, 600 );
INSERT INTO releases VALUES ( 'squeeze-security', NULL, 601 );
INSERT INTO releases VALUES ( 'squeeze-proposed-updates', NULL, 602 );
INSERT INTO releases VALUES ( 'sid', NULL, 100000 );
INSERT INTO releases VALUES ( 'experimental', NULL, 100001 );
Any other comments are welcome
Andreas.
--
http://fam-tille.de
Reply to: