Re: Feature idea: show upstream release dates on packages

[Borden <borden_c@tutanota.com>]

Thank you for your quick response. I have some responses, below:

> - no upstream ever existed
> - the upstream no longer exists
>
>From my experience, the package usually gets delisted when there is no upstream. If there's no upstream, where is the source coming from?

> - the upstream doesn't release; the DD had to pick a particular git/svn/hg... version and use that
> - the package is synthetic and has multiple release dates, possibly including other problems
>
Rolling releases, if that's what you're referring to, usually date-stamp their releases. Things like LineageOS and Mobian packages come to mind.

> - the official release date for the version was X, but this is the eleventh time a DD has patched in fixes from later versions
>
In fairness, Debian has its own versioning notation for non-upstream patches, which doesn't seem to have caused chaos yet.

> - there are roughly 60,000 packages in Trixie. At five minutes per package to research the date, make a decision, add the header and re-upload, that's 5000 hours of new work you are asking volunteers to do. Two and a half years of full-time employment.
>
I wasn't suggesting this is feasible for  Trixie. Even if it were, as not to break backwards compatibility, it would have to be an optional field, which I think would address the above issues. Much of it could be automated away: on the next release pull, add the upstream release date to the package. If there's no decent date stamp or controversy, leave empty.

I'm hearing a lot of technical challenges, which at least tells me that my idea isn't inherently bad. Yes, most packages might not use it, but, honestly, how many packages are truly, 100% compliant to any specification? Even if 20% of the 60,000 packages can feasibly implement this feature, that's still greater than 0%, and it sounds like it could be useful.