* Martin Hejl <mar...@hejl.de> schrieb:
> Just in case it got overlooked - we have a (mostly) working setup for
> creating a buildenv and packages, for storing the sources and for
> generating the packages page for the homepage including a changelog.
Git has an cvs-server for such legacy purposes, so we can do a
smooth migration (eg. starting w/ migrating the whole repo - as it
is - into git and let the clients talk via cvs protocol to the
git repo, until they're ported to git directly).
> 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.
> 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/
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 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.
Going this road also give benefits to distros/downstreams, since it's
a generic infrastructure for both up- and downstreams: many parties
can push their branches into the OSS-QM repos in their own namespaces,
or they can easily implement its underlying model on there own repos
and let my robots fetch automatically. (BTW: i'm working quite closely
w/ certain upstreams to get a better integration).
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
------------------------------------------------------------------------------
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
