Package: ftp.debian.org Severity: normal Hi
To make the experimental suite more usable it would be extremely helpful if it was possible to migrate packages from experimental to unstable without needing another upload as is the case now. To that end I started an IRC conversation with mhy and phil: <luk> What would be needed from an archive point of view to be able to migrate packages from experimental to unstable? What interface would you prefer? <mhy> luk: the feeling last time we discussed it was that we should provide isolated "on-demand" experimental-like suites for transitions and so on and allow migrations of entire suites <mhy> in theory we could allow migration of individual packages from the existing experimental setup, I suppose the main thing would be to ensure that the version checks were applied <mhy> the right way to do that would be for control-suite to learn to apply the version checks, which we really need anyways <mhy> then some form of command or mail gateway to do it <mhy> but getting c-s to at least optionally apply the version checks would be stage 1 <mhy> I don't think it should even be *that* hard <mhy> the version check code is already in daklib IIRC <adsb> afaik it already does; Ganneff had to force the p-u -> unstable packages during the point release due to the versionning * mhy ponders - it certainly didn't used to, maybe it was fixed and I forgot <phil> luk: What's the incentive? Reusing the existing builds in experimental for unstable? <mhy> well bugger me <mhy> commit beea055f0a4d3514346c552da194e79d3640ed85 <mhy> Author: Ansgar Burchardt <ans...@debian.org> <mhy> Date: Thu Mar 24 16:38:18 2011 +0000 <mhy> control-suite: Validate version_checks <mhy> embarassingly, I think that was during the ftp-team sprint <luk> the incentive is to avoid having to reupload packages to get them to unstable <luk> so people are more willing to use experimental as a staging ground during freezes/transitions <mhy> well, assuming we don't wnat to bother validating the depends etc (i.e. we trust people not to screw that up, which they can already do with uploads to unstable), it'd be fairly easy; we probably just want some form of command interface to it <mhy> mail gateway with signed pgp message or something <phil> Builds that go into experimental post-copy ought to be copied into unstable aswell, though. <phil> Or deleted from there, so that subsequent uploads fail. <mhy> phil: urgh, that gets less fun <phil> Otherwise we get doublebuilds. <mhy> deleted would work <phil> mhy: If you drop it from experimental that would be ok. <mhy> so it's actually a *move* to unstable <phil> Aye. <mhy> don't see why not <mhy> it'd slightly reduce the manual cruft removals from exp too :-) <luk> indeed, a move would be best <phil> As long as you don't accept any new builds for that version into exp anymore I'm fine with it, I think. :> <mhy> you'd have to be a right moron to ask for the move before all the binary builds were there anyways <mhy> but that raises an interesting issue about whether binary-only builds should be accepted if the target suite isn't right but that binary build is missing in a suite which has that source version in it <phil> Not for stable at least. <phil> Not for testing, too. <phil> That would only concern sid+rc-buggy. <mhy> yeah <mhy> so sod it <mhy> don't do that then <luk> right, it would just also be built in unstable and that one can be accepted <mhy> as phil says, as long as it's a move <mhy> it'll all happen atomically at the next dinstall <phil> You might want to emit a mail to d-d-changes for the move, though. Possibly getting it to the PTS too. <mhy> we'd have to think what the mail should say <mhy> it can't be the changes because we don't necessarily have them to hand at that point <mhy> unless the info is in projectb somewhere <mhy> but if we have the info, the easy thing to do is the follow the email rules defined for the target suite (sid in this case) <luk> I thought the archive kept the changes (or at least its content)? <mhy> we keep a record that we've seen it and a hash <mhy> hmm, actually, we might have enough information to fake up a changes like thing <mhy> we can't guarantee the actual .changes files won't have been archived by the time of the move <mhy> but the info appears to be in projectb <mhy> now if only we kept a back reference from the source to its changes entry <mhy> ok, heading off for a bit <luk> ok, should I file a bug or how do we go from here? <mhy> luk: erm, file a bug and c+p this irc log in if you don't mind, I'll try and follow up later this evening <luk> ok <mhy> I'll have a chat with weasel about the ud-ldap mail/gpg gateway code as we might either want to nick some of that or not depending on how bitrotten it is Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
