26
I Use This!
Activity Not Available

News

Analyzed almost 3 years ago. based on code collected over 3 years ago.
Posted almost 13 years ago
This is getting old news, and others have blogged about them before I did, but here's my summary of the recent activity in and around FusionForge. The early February meeting was a success, and gathered about twenty people on the first day and a ... [More] dozen or so on the second day (not planned initially). My impression is that there was a healthy mix of FusionForge hackers, FusionForge users, and people from other forge communities (Codendi, NovaForge, and even one representative from nFORGE, from South Korea). I'm not going to repeat all that was said then, especially since the proceedings are online. Beyond the technical points, I'll just advertise PlanetForge again, since everyone present agreed we had lots to share and that this site would be a good and relatively neutral place. If you're into forges, I recommend joining us in that community. On the purely FusionForge front, news are good too. Most of the major pieces we want to see in the next release (which is probably going to be called 5.0) are in place. The last blocker we had was the merge of the rework of the default theme for better accessibility and easier maintenance and customisability (most of the theming now happens in CSS). This merge has been completed this week, and although there are still a few rough edges, it's mostly done. We'll try to fix most of these rough edges soonish, then start a stabilisation branch towards 5.0, so more experimental work can start again on trunk. For the impatient and the curious, there's a list of new features on the fusionforge.org homepage, and the site is now running code from trunk. Of course, we're eager to get testers for that, which is why I prepared snapshot packages. They are currently stuck in NEW on their way to the official Debian experimental repository due to the renaming of the source package and the introduction of plenty of new binary packages, but they can already be obtained from my unofficial repository at people.debian.org. The packages are built for Debian unstable, but they seem to run just fine on Lenny if you grab mediawiki from backports.org (only required for the Mediawiki plugin, of course), and libnusoap-php and php-htmlpurifier from Debian testing (they don't drag any extra dependencies). I'll end this note by reminding people of the announcement I did three months ago: as of this week, Debian Etch is no longer officially supported security-wise, and so neither is GForge 4.5. As far as I know, I was the last person doing that, and my incentives have gone away on the day Etch ceased to be supported, since it was also the day the Adullact forge finally migrated from Etch with GForge 4.5 to Lenny with FusionForge 4.8. If you're still using 4.5, well… I think you should be aware of that. That more or less wraps it up for now. The next announcement is likely to be about a release candidate… [Less]
Posted about 13 years ago
I normally don't relay security announces for GForge or FusionForge on this blog, but I will make an exception this time: Alain Peyrat found several places in the code with insufficient input sanitizing, which can cause cross-site scripting ... [More] vulnerabilities (CVE-2009-3303). It's been fixed in the 4.7 and 4.8 branches as well as the trunk of FusionForge (and in Debian Sid and Squeeze), and updated Debian packages for GForge 4.5 and 4.7rc2 have been released for users of the Etch and Lenny distributions. The reason I make an exception for announcing this here is to remind people that I appear to be the only one maintaining code for GForge 4.5. I do that for two reasons: first, because I'm the maintainer of the package in Debian, and Debian Etch has GForge 4.5, and Etch is supported for security fixes; second, because I also admin/maintain an instance for a client of mine, so I need to backport the fixes anyway, and making them public is no bother. Both of these reasons are going to vanish sometime in the not too distant future: security support for Etch will end in February, 2010, and I hope to have migrated my client's forge to FusionForge 4.8 by then too. A direct consequence is that I will probably stop maintenance for GForge 4.5 in the coming months (at least I'll stop doing it in my free time). So if you're still using GForge 4.5, you should really consider upgrading to something supported, either GForge AS (free download from the GForge Group) or FusionForge (free as in Free Software). Both have an upgrade path. Obviously I think FusionForge is a better choice, but my position is probably biased. [Less]
Posted almost 14 years ago
Executive summary To avoid confusion with the proprietary versions of GForge (known as GForge Advanced Server, GForge Express Edition and GForge Community Edition), the free/libre/opensource codebase will from now on be separately maintained under ... [More] the name FusionForge by the main developers of the free GForge 4.x codebase. Since this is mostly a renaming, the migration path for existing users will be smooth. Longer version, with details After the initial forking from the Sourceforge codebase, the development of GForge has long been hosted, and many enhancements directly developed, by the GForge Group (GForge, LLC), with regular contributions from outsiders. The results of these evolutions were public and free, subject to the GNU GPL. In parallel, the GForge Group wrote a proprietary re-implementation of GForge, which it sold under the name "GForge Advanced Server", or "GForge AS" for short. This re-implementation added some features for "the enterprise", but was not contributed wholesale to the GForge codebase under a free license. Although some of the features were contributed to the public, the GForge Group concentrated its efforts on its (proprietary software) business model, with more versions appearing, such as "GForge Express Edition" and more recently "GForge Community Edition". As a result, it became increasingly harder for the public to know which version was which without doing extensive research (indeed, some users mistakenly installed one version instead of the other). A consequence was that the free software codebase suffered from a loss in visibility, which lowered its momentum to the point that there haven't been any moderately important releases since the (currently stable) 4.5.x series was announced in late 2005. So, in order to clarify things, avoid further confusion, and regain some of the lost momentum, it was decided by a group of leading contributors that the free software version of the GForge codebase would from now on be developed under the FusionForge name, and its development would be hosted on FusionForge.org. So is this a fork? Well, we don't know yet. It could arguably be called one, since we're taking the code and running away with it under a new name. However, we believe it's not a fork unless both roads continue their own way (more of a oddly-shaped bend). What happens to the GForge codebase developed by the GForge Group at gforge.org remains to be seen, although for the sake of our users we will backport security fixes to the gforge.org Subversion repository (at least for the 4.5.x series and the unreleased 4.6 and 4.7 pre-series) for some time. The bulk of the development will move on to FusionForge and the repositories at FusionForge.org, though, and users are encouraged to migrate at their own pace. Since we're basically continuing the evolution rather than starting from scratch, the migration path should be rather smooth. So why the FusionForge name? Because there were actually lots of locally-patched versions of GForge (and Sourceforge), and we felt it was a waste of resources that should be fixed. It seems many people and organisations took these codebases at some point in time and evolved them for their own needs. Sadly, many of the changes were not contributed back or even published, so lots of efforts were duplicated. Fortunately, many of the people managing these locally-patched forges are now realising that "out-of-tree" patches and features require quite some manpower to maintain. Some formal inter-project discussion is already taking place, and we hope to achieve actual merging of most of the interesting features that have been developed here and there into a common base that can be reused locally with minimal changes. We'd like to "un-fork" as much as possible. We also expect that, by using standard components and tools, we'll facilitate the work of potential contributors, thereby reducing the risk of a new era of fragmentation. And who are we anyway? We're Christian Bayle, Roland Mas and Alain Peyrat, long-time contributors to GForge and responsible for over 95% of the commits over the past two years, as well as a few relative newcomers. Christian and Roland have been maintaining the Debian packaging since the "Debian-SF" era, and Alain has been focusing on code quality. The three of us have, for various reasons, a vested interest in maintaining a lively codebase in a healthy ecosystem. What are our plans? Our short-term goals, as currently planned, include: pushing a stable FusionForge release out of the door; cleaning up and auditing the database schema to ensure consistency and increased performance; merging in new plugins, in particular for new version control systems; continuing streamlining the installation process to make it more portable across distributions. Longer term goals are less well defined, but we're thinking about the following: increasing code quality by the use of modern automated tools; encouraging a lively stream of external contributions, to reduce the gap between the official version and the locally-patched ones; defining an explicit governance model and release process for the FusionForge project; as a consequence, a more frequent and predictable release schedule; increasing data portability and interoperability with other forges, to reduce lock-in for users and projects. Some of these items should be facilitated by our switch to a distributed version control system and a new coordinated workflow. Also, the Debian i18n team has been kind enough to offer to host our translation effort on their Pootle server, which means translators will have a much easier time doing their job. We hope to hear from users and contributors alike in the near future. For more information, we can be reached via our fusionforge-general mailing-list (see our lists), which is also suitable for general discussions. We can also be found on IRC (#fusionforge on the Freenode network). [Less]
Posted almost 14 years ago
Stuff happens quietly on the GForge front, but after some time we decided we're getting bored with not releasing. Since we seem to have run out of major problems in the codebase, the long-awaited GForge 4.7 release is probably round the corner. And ... [More] so, since GForge migrated from its own in-house translation system to the more conventional gettext API, I'd like to take the opportunity to issue a call for translations, knowing that potential translators won't be too disturbed by unusual tools and formats. You can grab the current state of the translations from the GForge repository browser. Or, for more long-term involvement, checkout the code through Subversion or through Bzr (my gateway branch is available from bzr.debian.org. Current statistics are as follows: bg.po: 382 translated messages, 174 fuzzy translations, 1813 untranslated messages. ca.po: 1592 translated messages, 281 fuzzy translations, 496 untranslated messages. de.po: 1627 translated messages, 272 fuzzy translations, 470 untranslated messages. el.po: 0 translated messages, 2369 untranslated messages. eo.po: 0 translated messages, 2369 untranslated messages. es.po: 1600 translated messages, 236 fuzzy translations, 533 untranslated messages. eu.po: 1392 translated messages, 272 fuzzy translations, 705 untranslated messages. fr.po: 2368 translated messages, 1 untranslated message. he.po: 0 translated messages, 2369 untranslated messages. id.po: 0 translated messages, 2369 untranslated messages. it.po: 1781 translated messages, 303 fuzzy translations, 285 untranslated messages. ja.po: 246 translated messages, 118 fuzzy translations, 2005 untranslated messages. ko.po: 1292 translated messages, 264 fuzzy translations, 813 untranslated messages. la.po: 0 translated messages, 2369 untranslated messages. nb.po: 0 translated messages, 2369 untranslated messages. nl.po: 1621 translated messages, 287 fuzzy translations, 461 untranslated messages. pl.po: 0 translated messages, 2369 untranslated messages. pt_BR.po: 1292 translated messages, 262 fuzzy translations, 815 untranslated messages. pt.po: 0 translated messages, 2369 untranslated messages. ru.po: 302 translated messages, 142 fuzzy translations, 1925 untranslated messages. sv.po: 1289 translated messages, 261 fuzzy translations, 819 untranslated messages. th.po: 0 translated messages, 2369 untranslated messages. zh_CN.po: 1691 translated messages, 300 fuzzy translations, 378 untranslated messages. zh_TW.po: 1664 translated messages, 289 fuzzy translations, 416 untranslated messages. Results as patches to our patch tracker or the gforge-devel ML please. (Note to Debian-related readers: this translation work will be directly useful on Alioth when we upgrade it.) [Less]
Posted about 14 years ago by Timothy Perdue
An updated VMWare image of the 4.6 codebase has been posted for download on gforge.org. See the README.txt inside for details.http://gforge.org/frs/gforge-46rc2-centos5-vmware.zip
Posted over 14 years ago by Timothy Perdue
Christian Bayle has posted 4.7beta installer, which you can download from the homepage of gforge.org - testing and feedback is needed to resolve bugs and issues.
Posted over 14 years ago by Timothy Perdue
GForge 4.6rc1 is posted and has simple installation backported from GForge AS. If you are on a current centos, redhat, debian or fedora, it should be relatively trivial to install this version.Download here:http://gforge.org/frs/?group_id=1
Posted almost 15 years ago
Quick status update: not much happened due to a variety of reasons, but there is still some progress to report. The most important piece of news is that the Mediawiki plugin should be on its way to Debian sid by the time you read this, as the new ... [More] gforge-plugin-mediawiki binary package (it'll have to go through NEW, but that seems to be rather fast these days). Testing and reporting and bugfixing are most welcome, of course. I also went through a round of cleanups in the packaging. No more Lintian overrides, far fewer Lintian errors and warnings, and some fixes for PostgreSQL 8.3 compatibility. [Less]
Posted almost 15 years ago
First, and most important: while researching a functional bug for a client, I found a rather important security problem in GForge. All versions (starting from 3.1) are vulnerable to an SQL injection problem due to missing input sanitisation. Debian ... [More] packages have already been fixed and released, and the patches have been committed to the upstream Subversion repository, so non-Debian users are encouraged to grab the patches from there. For instance, the patches for the 4.5.* branch can be obtained from the ViewVC page. For reference, the CVE ID for this problem is CVE-2008-0173. Secondly, there's a new "gforge" tag on this blog, to filter posts that relate to GForge. I mainly created it in response to the existence of a feed aggregator focusing on forges and variants, but you can also subscribe to it directly if you only want to hear about Gforge and not about my other Free Software activities. I'll also use it to announce security patches like this one. [Less]
Posted almost 15 years ago
I'm on a roll... Gettext transition is fully done now (old functions have even been removed). French translation 100% complete! Woo! Packages now use ucf. So there. Installation process streamlined: if you just want the web interface, you'll only ... [More] need to aptitude install gforge-web-apache2, and the only interactions it'll require are to type the admin password (twice) and to accept (or integrate by hand) a change in the PostgreSQL config file. It even works on Debian GNU/kFreeBSD! Plans for the near future include continuing to clean up upstream code and maintainer scripts, making sure the installation process is as simple as possible (even for other subpackages), splitting out a few plugins into their own packages. And the big placeholders-in-prepared-SQL-queries audit I mentioned last time, but it may happen progressively rather than in one big go. [Less]