2012/8/13 Felipe Sateler <fsate...@debian.org>: > 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.
As discussed, 3.4 is not a fantastic package, but it does provide the core language+server, so option 1 seems pointless when bug #674386 apparently has a fix we can go straight for. I don't have any strong motivation to go into negotiations with the RT for option 2: although 3.4 is less than ideal, once it's shipped we can focus on making the 3.5 sid package great. So I suggest let's go for TPU. Dan -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
