Am 30.09.2010 19:22, schrieb Enrico Weigelt: >> We also have the requirement (per Sourceforge terms of use) to provide >> the sources for a binary release in the FRS (which we currently don't >> do, since according to the link Mike provided, having those sources in >> CVS is not sufficient). > > I could host (and maintain) the git repos and automatically mirror > them to dozens of free repo services. That wouldn't really address the need to put the sources in FRS (but as the link Mike posted showed me, that should actually be trivial, once there is a means to gather all the required sources to put in a tarball and upload to FRS).
Regarding moving away from SF for hosting the source - that would be up to the other project members to decide. I'm not sure if "abusing" (I don't know if it would be) SF to simply provide space for a mailinglist and homepage and hosting the source somewhere else is within SF TOS (if it's within the TOS, I wouldn' have much of an issue with such a move, provided that access to the source would work reliably). >> I'm not emotionally attached to buildtool - if we can find something >> that's better (and find somebody who does the work of porting everything >> we currently have in buildtool), I see no reason not to switch. > > Perhaps you'd like to have a look at Briegel ;-P > > https://sourceforge.net/p/briegel/home/ Probably not. In case you haven't noticed - my last contribution to the project was on 2008-03-02 (at least according to the cvs-commits list), my latest significant contribution to something that's being used was in 2007. So while it would be interesting from an educational point of view, the project would not benefit at all. > One important note: it builds everything through a sysroot'ed > (cross-)toolchain. Certain packages might need to be fixed for that, > but that's scope of the OSS-QM project: > > https://sourceforge.net/p/oss-qm/home/ I'm sure you're right. Other alternatives to buildtool (alternatives that probably do a better job at what buildtool does, which I assume is also the case for Briegel/OSS-QM as well) have been suggested in the past, but as far as I know, no effort towards replacing buildtool with one of the alternatives has been made so far. >> I'm just not sure that the project has the manpower for replacing >> buildtool and migrating to a different SCM right now - and for the >> project, it's probably better, if people work on getting bering-uClibc4 >> "production ready". But if there's manpower to do both (and overhaul the >> webpage and docs), that would be great. > > I'd propose getting all packages we need built w/ Briegel. Once that's > done, you folks here probably have gained enough experience w/ it to > decide whether it can replace the current buildtool. Sounds fine to me - but I guess that depends on the people who will actually be stuck with the work. My take on things is this - nobody uses a distro because it has such a cool build system. People will use it (or not) because the distro lets them easily do what they need. Having a robust build system on top of a distro that people want to use would be great - but (IMHO) delaying getting bering-uClibc4 to a point where it's stable and provides what people need, in favor of changing the underlying build system, seems counterproductive. If both can be done (getting bering-uClibc4 ready for general use, and switching to a better build system) at the same time, that would be great. But that kind of thing would need to be discussed with people who are actually putting in their spare time to build/test/document bering-uClibc4 (and sadly, due to utter lack of spare time, I'm not one of those). As always - I'm not speaking for anybody else, and I'm not trying to kill the discussion about this topic (since talking about it could be worthwile) - I just want to point out that my part in a migration to a buildtool and/or CVS replacement will be nil, apart from answering questions on this list - if there are questions about why something was done in buildtool the way it's done, I'll do my best to respond, if I can still remember why something was done a certain way. Martin ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
