On Sun, Aug 12, 2012 at 5:37 PM, Dan S <danstowell+de...@gmail.com> wrote: > 2012/8/12 peter green <plugw...@p10link.net>: >>> >>> I'd like to mark this as "won't fix" because we're dropping the scons >>> build system. The latest version of supercollider 3.5.x (which I'm >>> currently asking debian-multimedia maintainers to upload) uses cmake >>> instead which is much less mess. >>> >> >> Supercollider 1:3.5.2-1 was uploaded just before the freeze deadline, >> however >> it did not migrate to testing due to build failures. >> >> So if supercollider is going to release with wheezy you either need to open >> discussions with the release team about either getting a freeze exception >> for >> the version in sid or making a TPU upload to fix the scons build system in >> the wheezy package > > Thanks. I'm not very familiar with debian processes so I'd appreciate > guidance from pkg-multimedia-maintainers on this. I don't know how to > do either of the things you describe, or which is better. (What's > TPU?) In git I made a branch "3.4debianfixes" which potentially > contains a fix for the scons issue.
The basic process is described by Raphael Hertzhog at [1]. The description, however, does not describe the current issue. What happens if testing is frozen, there is a bug in the package in testing, and there is a newer release in unstable? There are three options: 1. Remove the software from testing (and therefore, from the next stable release). 2. Somehow convince the release team that the new version in unstable should migrate to testing. 3. Upload a localized fix to testing-proposed-updates (TPU for short, a special "distribution" meant for fixes that cannot go through unstable). Each option has its benefits and drawbacks. The release team usually prefers option 3. Rewriting the choices for our current situation, we have: 1. Do not release supercollider in wheezy 2. Somehow convince the rt that 3.5 should migrate. 3. Ship 3.4 with the fix, via an upload to tpu. As I see it, there are significant drawbacks with the standard option (n° 3), because I'm not quite sure if 3.4 offers the best experience for users. However, I'd prefer if you (Dan) made this call, because you know sc much better, and thus can make a more informed decision. At this point, option 2 looks very unlikely, though. We can try to do it, but it is more likely that we will end up doing either 1 or 3. But we need to be clear on which one to do. [1] http://raphaelhertzog.com/2010/10/18/understanding-debians-release-process/ -- Saludos, Felipe Sateler _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
