Rumoured death of projects.openmoko.org

Joachim Steiger roh at openmoko.org
Fri Aug 22 07:03:10 CEST 2008


Rod Whitby wrote:
> Carsten Haitzler (The Rasterman) rumoured:
>> as such - projects.om.org is desired to go as its gforge base is a bit
>> abandoned, and the solutions bandied about have been "use google code or
>> sourceforge etc."... so as the solution is to use someone elses infra. i know
>> i'll use my own :)
> 
> Looks like it's time to move MokoMakefile back to svn.nslu2-linux.org ...
> 
> Could we have official confirmation or denial of this rumour please, and
> an accompanying timeframe?

i can clearly deny that rumor.

its correct we were thinking about alternatives, but recently the the
debian gforge maintainer also offer his help, so we think we will find a
way to at least stabilize things.

google code tries to limit people in features, design, and even in
choice of 'allowed licenses' (please read the fineprint ;)
sourceforge has stability problems themselves from time to time as we
all know.

also there is clearly a intent of projects with or for openmoko to be
visible with it, and for us, to atleast provide something which is
comparedably cheap: some bandwith, and a slice of hosting.
projects is most the time not even noticeable compared to buildhost, our
own repos and all the webservices and the needed databases, so cost is
really not the issue here at all. if, then its in 'people keeping it alive'
i have to admit, we have tended to ignore it for a bit, even not touch
it if not neccessary, but i hope we can do that better in the future.


mokomakefile again, is kinda essential piece to build all our stuff easily.
it is only one file. which can from my pov also go directly to
svn.openmoko.org.

rwhitby: please find a nice path and tell it to me and i'll add you to
rw for it.

same goes with all the stuff developed for asu. i see no reason besides
'eat out own dogfood' (which isnt even ours, we did not write gforge)
to use projects there and complicate the setup of commitlog ml, repos,
commit-access, and tracking all that development.

one thing some people forget: everything committed to svn.openmoko.org
shows up in the search and the timeline (named changelog in our case) of
the docs.openmoko.org

git is not properly integrated yet since trac doesnt support multiple
repos within one 'project env' yet.
there is work being done towards that which will propably be merged to
stable in the next or the following major revision.


to summon it up: we will keep projects.openmoko.org running.
we provided the service, and i see no reason to 'pull the carpet' below
people, only because of some hickups here and there.
i think when we clean it up a bit, eventually hide or remove some unused
or unnecessary features we can make good use of it. (e.g. do we really
need cvs there? does anybody really use the forum feature?)

the biggest problems with gforge are currently that it sometimes doesnt
like the users which added their accounts via gforge anymore propably
due to some pam interaction trouble. also it tends to set groups too
restrictive in some crons 'sometimes' which is difficult to debug when
one is not 'that deep into' how gforge works internally.
most the time we just 'got it running again' easily, but could not find
the real cause, even after hours of grepping through gforge.
means we fixed the perms and left it doing its job (which it does fine
99% of the time.
also it uses a chroot internally which makes things one level more
exiting when getting 'some path or file' out of some log. ;)



-- 

Joachim Steiger
Openmoko Central Services



More information about the devel mailing list