I propose a scheme where official stable releases are uploaded to Debian unstable (if needed, selected patches from CVS can be applied), and packages based on tarballs like http://pike.ida.liu.se/generated/pikefarm/packages/7.%7B6,7%7D/latest [1] (but unambiguous versions would be preferred) are uploaded to experimental regularly.
Sure. Should it be automated?
Now, if we're going to follow this schedule and keep the debian packaging in Pike's CVS like before, there's gonna be obvious chronological problems. From the point of view of the Pike trunk, each series of Debian revisions based on a particular Pike version is a separate branch, but from the point of view of the Debian package, there is just one, parallel, branch, which from time to time pulls in new upstream versions. There's nothing wrong with keeping the Debian packaging in Pike CVS, but it should be kept in a separate tree. Otherwise ./packaging/debian should be moved to ./debian, development of it be more closely integrated with the main source, and pike?.? be made so-called native packages, but that's not recommended.
We can move to packaging files to a separate module if that helps.
[1] I think I've asked this before but without getting a satisfactory answer: What the heck *is* it you get from (the exact URL) http://pike.ida.liu.se/generated/pikefarm/packages/7.6/ (and .../7.7/)? "file" identifies the format as "Raw G3 data" (Group 3 fax??), but that can't be right.
As marcus said it's probably a raw UFS directory node. Aka a bug for an unhandled call.
It's no directory listing, because the files named in it don't exist, save for the most recent one. Why is there no public repository of older snapshot tarballs (in particular, the most recent well-defined version would be of >interest)?
There is no repository of old tar-balls because they aren't saved. They are volatile pieces of source that should only be used for testing. If you must retrieve an old snapshot you can use the date tag shown in Pikefarm.