On Thu, May 05, 2011 at 08:46:10AM +0200, Raphael Hertzog wrote:
> Yeah, experimental is not really the good place. We really want in
> rolling only packages where we have the assurance that they will land
> in unstable the day after the release (so automatically and not with
> a manual source upload).
Isn't the ability to "copy" .changes file around suites a completely
orthogonal problem? I'd love to have the ability, on demand, to
"upload" a package which is currently in experimental to unstable, no
matter rolling. If we had that ability, we can leave up to maintainers
the ability to do .changes-only upload to unstable the day after a
release, no matter if the former sources upload targeted unstable or
r-p-u/unstable-next/experimental/whatever.
I don't think it'd be reasonable to have scenarios in which I might have
uploaded to one such suite 1.5 years ago and having that upload be
scheduled for as long as that automatically to unstable the day after
the release. Having the maintainer to choose that sounds much better.
Yes, nowadays that is painful to do, but due to the lack of
.changes-only upload.
Also, having the unstable-next suite you've mention would tight more the
deployment of rolling to other project mechanisms, while the rest of the
proposal enjoyed much more decoupling.
(Yes, all this are minor points, but since it's being discussed... :-))
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
Attachment:
signature.asc
Description: Digital signature