On Tue, Apr 18, 2017 at 03:03:35PM +0200, Sascha Steinbiss wrote: > just my 2 cents, but I've done it like this so far: > > - If there is a new version of a package which is not in testing (e.g. > entered unstable after the NEW freeze) then I upload straight to > unstable as there's no need to stay close to the frozen testing for > fixes.
+1 > - If there's a frozen version in testing, I open a new 'next' or > 'experimental' branch in git with the new version and upload it to > experimental. Since experimental is separate, once the freeze is > over it should just be a matter of rebuilding and re-uploading the > new version to unstable. This is exactly the only reason to avoid unstable. > - If a package is completely NEW, then it's fine to upload directly to > unstable since there's no way it will affect the frozen stretch. +1 > Any comments or suggestions from the others? You follow exactly freeze policy. > I didn't to this out of habit for ariba (uploading to unstable) and of > course now there's an (upstream related) RC bug for the stretch version > with a newer version in unstable :/ > This would have been more of a routine if unstable would have been clean... That's Murphy's law: You only need to fix something in testing if you failed to follow release policy and uploaded to unstable for a single package. Kind regards Andreas. -- http://fam-tille.de