On 9/15/11 8:32 AM, Sébastien Maret wrote: > Hello, > > Could gcc46 be moved to 10.5/stable and 10.6/stable ? One of my package > depends on that version of the compiler, so I can't move it to stable. > > A more general question: now that we've only have a stable branch in 10.7, > wouldn't it make sense to drop the unstable branches in 10.5 and 10.6 (or > rather rename the unstable branches to stable) ? Maintaining stable and > unstable versions on 5 different OS/arch (10.7/x86_64, 10.6/x86_64, 10.5/i386 > and 10.5/powerpc) is too much work for developers IMHO. > > Cheers, > Sébastien > > >
It definitely would simplify our lives. We probably don't want just to dump packages into stable without doing a little testing to make sure they all actually work. ;-) One option would be something like the following: 1) Declare a CVS freeze on the 10.4/unstable tree, so that there aren't any new commits there. 2) Have machines for each supported OS/architecture combo run buildworlds to assess what packages are in need of dependencies, don't work on particular OS/arches, etc. 3) Remove the cvs freeze, and stipulate that new packages go into the stable tree. 4) Move packages over which work, and either fix or get rid those that don't. 5) Repeat, because some packages will have been marked as not able to be built due to dependencies which can't be built. A second option would be just to have maintainers indicate whether their packages can be moved over, and for the project to stop allowing commits to unstable (I don't know if we can actually enforce that, however) after some definite date. However, someone would still need to go through the list of unmaintained packages and test them, e.g. via the method above. And while we're at this, it might also be useful to switch from 10.4/ to 10.5/ as the name of the 10.5/10.6 distribution. Also on my personal wishlist: if we migrated to git, it might be easier to keep stable stable, since maintainers would all be working on their own local branches rather than the main project repository, updates would be vetted by a -core member or other experienced developer before being merged, and we could thereby widen commit access. ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
