My WebLog at Intitut Mines-Telecom, Télécom SudParis
We have made some progress towards more CAS-ified applications installable in Debian, and now have several RFS pending :
libauthcas-perl : Client library for CAS 2.0 / AuthCAS Perl modulelibcas-php : CAS client library for PHP / phpCAS PHP librarySo if you’re a Debian Developer and wish to help improve CAS support in Debian, please sponsor these packages.
Part of our work in the Helios project will be on bugtrackers synchronisation.
I happened to notice that bts-link‘s maintainer called for help, which triggered more interest in that tool.
I’ve started working on bts-link to see how it works (cool, it’s Python 😉 and if it can be useful for Helios, and started implementing GForge tracker support in bts-link. That should help keep track of Debian bugs wrt upstream bugs for projects hosted in GForge forges (like Sympa, for instance, whose bugtracker is hosted in SourceSup).
You may find my git repo at http://www-public.it-sudparis.eu/~berger_o/git/bts-link.git which hopefull contains my proposed changes (I’m new to git, so I hope I did everything right…).
We’re busy on the first tasks of the HELIOS project… nothing spectacular to announce publicly, so far.
Still, we have registered a domain for the project (http://www.helios-platform.org/ … which currently redirects to our internal workspace on a LibreSource forge), and there are minimal informations about the project available already here.
I hope we’ll have news to provide soon about the project progress. Keep tuned 😉
P.S.: we’re going to hire an engineer for HELIOS to work with us in Evry. If you want to work on a R&D project involving Free/Libre/Open Source software (bugtrackers infrastructure, etc.), don’t hesitate to get in touch… more detailed position offer to come in the future.
It seems that TWiki community is forking as there was a dispute between TWiki.net (under pressure of venture capitalists) and the rest of the community, over the trademark 🙁
Always amazing these community issues on open source software.
More details here for instance.
We’re seriously considering switching from phpGroupware to eGroupware for some infrastructure needed for a picoforge-based platform that we need to deploy soon.
phpGroupware is unfortunately kinda dead these days, whereas eGroupware seems to have managed to keep some momentum.
Of course we had preferred keeping with phpGroupware when the two projects initially switched apart, in particular because the GNU project-linked QA/copyright policies were a guarantee that our contributions may be better protected in such a collaboration environment (we tried and help the phpGroupware as much as we could, btw, and parts of this history is told when looking at : http://www-public.it-sudparis.eu/~berger_o/weblog/tag/phpgroupware/).
But the copyright policy is not all about successful collaboration, and it happens that phpGroupware fails to deliver from quite a few months now. Btw, I’m not so close to the project to tell exactly what’s happening and why, but looking at the mailing-lists, at least, the situation looks very bad.
So I dare say it lound : the phpGroupware project is quietly dying (at least from my point of view).
But as we need some improvements that were initially planned for its 0.9.18 release (filemanager, accounts, various stuff I’m not really qualified to list completely)… we need to consider what the options are…
And fortunately, it looks like eGroupware has not forked in a too much differing way, from a technical point of view, and that they have even improved some of the things we expected to be coming from phpGroupware 0.9.18.
So it’s very much likely that we’re going to try and switch to eGroupware for some parts of the platform to be deployed in the next month.
This may not concern the whole of the PicoForge infrastructure but only a particular project that builds on top of the current PicoForge infrastructure, with some variations.
As for the future of PicoForge as the libre software forge, it’s not really clear what’s gonna happen, but I think that we may be making a more radical switch some day, for instance by forgetting the old legacy PHP code, and so neither depending on phpGroupware nor eGroupware, but using some more modern tools/frameworks (and why not something like Tine 2.0 ? … no, but we may be inspired by some of its characteristics ;).
Qui vivra verra.