Planet Forge

While working hard on the new features of the upcoming version of Codendi, we took the time to rewrite the codendi.org homepage.

Do you remember the old and soporific homepage? Remember:

Quite dull, isn’t it? Lots of text, no white spaces, no visual guidances…
Well, what is fun with Codendi is that nearly all is customizable. Adjust few settings and you are ready to give some love to your users!

Codendi starter wants mainly three things: 1) download the application 2) Read The Friendly Manual 3) contribute. Now take a look at the new home page:

With some colors, some icons and big download buttons don’t you think that it is much better? Facilitating the access to downloads, documentation or participation tools is the love we had to give to our community.

Hope you will have fun with this new homepage. If you are not yet a member of Codendi Community, join now the others!

Oh.. And we’re social also: please join our network and follow us on twitter!

Once you’ve completed Step #3 and clarified the requirements for all the Product Backlog items targeted for your Sprint, the next step is to plan the Sprint in detail…

Sprint Planning Workshop (Part 2)
The first part of the Sprint Planning Workshop (in the last step of this series) was focused on clarifying the requirements for the selected Product Backlog. The second part of the Sprint Planning Workshop is focused on breaking the requirements into tasks and estimating the hours required to complete them.
Although Part 2 of the workshop can follow straight on from the first part, it is sometimes helpful for there to be a short gap between the two meetings; maybe 1 day. This allows time to clarify any outstanding questions arising from part 1 of the workshop before proceeding with the next step.
Make sure the meeting is attended by all team members.
The Product Owner and any customer, user or business representatives need not attend this part (part 2) of the Sprint Planning workshop, as it’s likely to be more technical in nature and is more about the team working out how the selected backlog items will be delivered. However, they should be welcome to attend if they wish, which may help their understanding of what’s involved to deliver the features, and may help if any further clarification is required as the tasks are discussed and estimated.

Set the Sprint Budget
First of all, calculate the team’s Sprint Budget. This is the available number of hours the team has to work on the Sprint. Start by multiplying the available hours in the Sprint Duration by the number of full-time people in the Sprint. Then, make any reasonable deductions for time that team members will not be able to spend working on the Sprint. Deduct holidays, any known meetings, any time likely to be spent working on other projects, etc.

Break Requirements into Tasks
Go through each Product Backlog item selected for the Sprint. Break the requirements into tasks.
Tasks may include the traditional steps in a development lifecycle (although limited to the feature in question, not the entire product). For instance: Design, Development, Unit Testing, System Testing, UAT (User Acceptance Testing), Documentation, etc.
Remember, agile software development methods do not exclude these steps. Agile methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.
Each of these tasks, especially development, may be broken down further. Maybe to a component level detailing each of the individual elements of the software architecture that will be required to deliver the feature of the product.

Include all tasks necessary to make the Product Backlog item 100% complete – i.e. potentially shippable – within the Sprint. Agree as a team on your definition of done, so everyone is aware what will have to be completed and included in the estimates.
State tasks as deliverables, if at all possible. Deliverables are more measurable than tasks. Instead of describing what you’re going to do, describe what you’re going to deliver.

Estimate Tasks in Hours
Keep tasks small. Estimate all tasks in hours. Estimate each task as a team.
Ask everyone what they think, in order to identify missed tasks, or to identify simpler solutions.
Ideally task estimates should be no more than 1 day. If an estimate is much larger than this, the requirements should be broken down further so the tasks are smaller. Although this can be difficult, it will get easier with practice. Keeping tasks small enough to estimate at less than 1 day has some specific benefits.
Firstly, breaking tasks down into very small chunks means they are easier to estimate. The accuracy of your estimating will be improved as a result. Secondly, tasks less than 1 day are more measurable in the daily Scrum (stand-up meeting). 1 day tasks are either done or they are not.

Commit to the Sprint Backlog
Add up all the task estimates for the selected Product Backlog.
If they are significantly over the team’s Sprint Budget, reduce the number of Product Backlog items selected for the Sprint. Remember the Product Backlog was in priority order, so if possible it should be the lower item(s) on the backlog that are removed from the Sprint.
The remaining list of estimated Tasks – those tasks needed to complete the selected Product Backlog within the Sprint - is your Sprint Backlog. The team should commit to delivering the Sprint Backlog.

Identify Stretch Tasks
Sometimes teams under-commit or over-estimate. Stranger things have happened!
Always include some additional scope in your Sprint Backlog, over and above what you think can be achieved. This is important in order to have something ready if the team delivers early, as the Sprint should ideally remain a fixed length.
Clearly identify these items as Stretch Tasks. The Product Owner should never expect Stretch Tasks to be reached. No-one should ever be beaten up if Stretch Tasks are never reached. And if you do manage to complete any Stretch Tasks, this should be cause for celebration!

Next…
So now you’ve got your backlog in order, estimated your backlog, clarified your requirements, and planned your sprint. Now you’re ready for step 5 – Create a collaborative workspace…

Extract from Kelly Waters’ blog

The step 3 is to plan your Sprint.

Sprint Planning Workshop
Call a Sprint Planning meeting. Make sure the meeting is attended by the whole team. Include all roles. Business Analysts if you have them. Testers if you have them. ALL Developers on the Scrum team for the product. And very importantly the Product Owner.
The first thing you must do (in your first Sprint Planning meeting) is decide on your Sprint duration. This decision should be taken as a team.

Decide Your Sprint Duration
This is an important decision. Scrum suggests 30 days. It might be right. But this is one point that seems to be widely adapted by agile teams practicing Scrum.
The optimum Sprint duration depends on many factors. A development team’s ‘cycle time’ is a direct reflection of the maturity of their processes. A team with immature processes will find the intensity of Scrum and the overhead of Sprint Planning, Testing, Deployment and Review quite onerous for a short Sprint cycle. Whereas teams with very mature processes (for example automated testing, automated deployment, and teams who’ve become very quick at Sprint Planning), a short cycle might be very comfortable.
The range is between 1 week and 1 month. 1 week is probably the shortest that will ever be practical, although if you really master agile practices, why not ship each new feature when it’s ready?. 1 month should certainly be the longest.

For fast-moving products or markets, such as web-based products - where there is central deployment and no rollout or user training - 1 month seems like a lifetime! For example Codendi team works with 2 week Sprints.

Keep Sprint Duration Consistent
Whatever Sprint duration you choose to go for, keep it consistent.
This, in fact, is more important than the length itself. Because it’s this consistency that allows you to get into a rythm. It’s this consistency that makes your process very repeatable. And therefore helps you to get into your stride as a team. And it’s this consistency that allows you to start understanding how many Product Backlog points you can typically do in a Sprint.

Once you’ve decided, you can now set up a Sprint Planning Workshop as a recurring appointment before every Sprint.

Select Target Backlog for Sprint
Now you’ve decided on your Sprint duration. Next you must decide on the goal for the Sprint…
Looking at the top section of the Product Backlog, what would seem to be a reasonable goal to set for the Sprint? Can you express an objective that sums up the goal for the next Sprint, or at least pick a section of items/features from the top of the Product Backlog that the team thinks can be achieved in the Sprint duration?

Select your target backlog for the Sprint. Make this decision as a team.
Include a bit more than you think can be achieved. It’s important to prepare more items during planning in case the team finishes early. These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed. These are the things you will only do if the Sprint goes better than you expected.
In future Sprints, you will be able to use your Scrum team’s previous Velocity to help with this decision. Velocity is the number of Product Backlog Points delivered in a Sprint. This tends to fluctuate wildly early on when adopting Scrum. But it will settle down as the team get into a rythm, and in future provide you with a reasonable norm to base your target backlog on.

Clarify Sprint Requirements
Take each item on the Product Backlog. It’s important to go through them methodically, one item at a time…
The Product Owner presents each item and explains how he/she sees it working from a functional perspective.
The whole team discusses the item in detail. The whole team asks questions about the feature in order to establish what it should do and how it should work.
The outcomes of this discussion should be captured on a whiteboard or flipchart, or someone could write notes on a laptop as the discussion progresses.
You can use whatever form of writing requirements you want to. But the important principle in Scrum, and in any agile development methodology, is that you write requirements feature by feature, just before they are developed.
Write requirements in a way that is lightweight and visual. Agile requirements should be barely sufficient. The fact the features will be developed and tested within the next few weeks, and by the team that were present, makes this possible.

Consider writing ‘User Stories’, a concept from XP (extreme programming). It’s beyond the scope of this article to explain user stories in any detail. But the basic concept is to write features using this construct: As a [type of user], I want to [do whatever], so I can [achieve what goal].

Extract from Kelly Waters’ blog

If you’ve completed step 1, congratulations! Because it’s the biggest step. If you haven’t completed step 1, you must not go any further until you have. So here’s Step #2: How to estimate your Product Backlog…

High Level Estimates

You need to provide some high-level initial estimates, in order to get an idea of the size of your product backlog items.
This is helpful because it helps to inform the decision about priorities. And whether or not the features are likely to be worthwhile. And from a management point of view, gives a perspective of how big the team ought to be, commercials permitting.

But as yet, you don’t know much about the items on the backlog. You don’t know exactly what the features are meant to do. You don’t know what tasks are needed to complete them. And you don’t really know how you will implement them.
So you have to do a very high level, top down, indicative estimate.

Estimate Product Backlog in Points

The answer: Estimate your product backlog in points. Not in units of time. Estimate your product backlog in points. So we’re not asking the team ‘how long will it take?’. We’re asking ‘how big is it?’

Use a Points System

So what scale should you use for your points system?
For the sake of simplicity, when using numbers for indicating size, use the range 1-21. Certainly for bug fixes and enhancements on products in the BAU (Business As Usual) cycle, this should give you sufficient a range.
The key here is about relativity.

A backlog item describes a feature. Maybe, for example, it’s a report. You’ve done similar reports before, but it does have some complexity in the underlying data, so you decide to call this a 3. Next on the backlog is another report. You size this one relative to the other one. Is it bigger or smaller. Clearly 21 is a lot bigger. 2 is a bit smaller. And so on.

To make sure the scale works for you, start by picking what you think is the smallest thing on the backlog. Give this a 1. Then find the thing you think is the biggest thing on the backlog. Give this a 21.
When you get further down the backlog, you’ll get to a point where the items are really rather fuzzy. And rather low priority. In fact you not sure you’ll ever get to them in your lifetime. Please don’t feel you have to size the entire backlog. Size enough of the items to see you through the foreseeable future. Remember it’s already been put in priority order. So make sure you work from the top.

Estimate as a Team

Size your backlog as a team. Each team member writes their estimate on a card, and everyone shows their answer at the same time. It helps to ensure less experienced members of the team are equally engaged and are not over-influenced by more experienced team members. It also helps less experienced estimators to learn from others. And it helps to avoid stronger, more vocal characters having too over-bearing an influence on the result.
From this exercise, negotiate the size of each backlog item as a team.

Review Priorities
Once you’ve sized up the backlog - or enough of it - ask the Product Owner to have another quick look at priorities. Maybe now they can see the relative size of the features they’ve asked for, they might change their view of priorities. ‘Wow, if that’s a 21, I’d rather have the other stuff first’, or ‘if that’s only a 2, let’s get it in the next release’. If any priorities are changed, simply move the item’s position in the order of the backlog.

Extract from Kelly Water’s blog

This is not only the 1st step. It’s the most important step.

Align with Business
Firstly, before you do anything else, you must align your development team with the business.

If you’re part of a business unit, that might be natural and straightforward. If you’re a central development organisation serving multiple business units, developing multiple products, it might be harder. Initially, make sure you have at least 1 person dedicated to a product, application or product range where you will start implementing Scrum.

You can share a team split across multiple products. But it’s a little harder and therefore is a slightly more advanced technique. If possible, it would be ideal to avoid this situation in your first implementation of Scrum, if you can.

Start with BAU

Secondly, although you can use Scrum on projects to good effect, you should start with BAU (business-as-usual) rather than on big projects. This will keep things simple while you and the team get used to the basics.

So you’ve decided on a product where you will start using Scrum. You have at least 1 person who will be dedicated to that product (or product range). To keep things simple at first, you have selected a product that is in the BAU cycle of bug fixing and enhancements.

Find a Willing Product Owner

The next key step is to nominate a Product Owner. You must find 1 Product Owner. 1 person who will be responsible for prioritising work on the product. 1 person who knows what is required of the product. 1 person that is a good communicator and able to convey requirements. 1 person who is committed to the success of the product, such that they are willing and able to dedicated a reasonable amount of time to its development.

If, for whatever reasons, this step is a problem for you, DO NOT PASS GO.

If you can’t complete this step, your product development is likely to be fraught with issues. Whether or not you implement Scrum. Unless you can take the above steps, it’s quite possible you will be faced with a barrage of requests, no clear view of priorities, a lack of clarity about requirements, lots of noise and complaints, and being pulled from pillar to post. The consequences? You don’t deliver and/or fail to meet expectations. Everyone is miserable. And somehow it’s all your fault! Unfortunately, this is all too common a situation for development teams everywhere. This must be solved before you proceed. This is a critical success factor for your team.

Act as ScrumMaster

So now you are organised. You’re aligned. You have 1 product, application or product range. You have at least 1 person dedicated to the product (Scrum Team). You have 1 Product Owner. And you, by virtue of the fact that you’re reading this information about implementing Scrum, I will assume are probably the ScrumMaster.

As ScrumMaster, you are responsible for supporting the Scrum Team, coaching and guiding them through this process, and removing any impediments blocking their progress.

Create the Product Backlog

Now you must create the Product Backlog.
The Product Backlog, in its simplest form, is a list of things that people want to be done to the product, in priority order.

Anyone can add anything to the Product Backlog. Anyone. The Scrum process, and agile development principles generally, are collaborative and inclusive. There is no longer any need to say no.

Only the Product Owner can prioritise the Product Backlog.

The Product Backlog can contain anything relating to the product that is : bugs. Enhancements, whole projects, issues, risks…

Having said that, items on the Product Backlog should ideally be expressed in business terms that are of some value to the user (or customer, or business).

Functional requirements should be expressed as features. Non-functional requirements can be put on the Backlog too, for instance ‘the product needs to be faster’, ‘we need to ensure the product is secure’, ‘we need to get off the old platform’, ‘there’s a high risk of downtime due to a single point of failure’. These might not be features, as such, but they are completely justified as items on the Product Backlog.

Prioritise the Backlog

The Product Owner prioritises the Product Backlog. He doens’t categorise the priorities 1, 2, 3 or anything like that. The priority is determined simply by the order of the list. The Product Owner puts the Product Backlog in priority order.

Things at the bottom of the list may be way off and may or may not ever get done. Things down the bottom are likely to be fuzzy and ill-defined. Don’t waste time defining things you may never get to, or not get to for some time. If something is a bad idea, the Product Owner should explain to whoever requested it why they are removing it from the Backlog. However, if something’s not such a bad idea, although never likely to be done, just put it in its rightfully low place on the Backlog and explain to the requester where it fits with priorities.

Extract from Kelly Water’s blog

Agile Software Development is one of the big buzzwords of the software development industry. But what exactly is agile development?

Agile development is a different way of managing software development projects. Principles of Agile Software Development, and how it fundamentally differs from a more traditional waterfall approach to software development, are as follows:

-Active user involvement is imperative
-The team must be empowered to make decisions
-Requirements evolve but the timescale is fixed
-Capture requirements at a high level; lightweight & visual
-Develop small, incremental releases and iterate
-Focus on frequent delivery of products
-Complete each feature before moving on to the next
-Apply the 80/20 rule
-Testing is integrated throughout the project lifecycle – test early and often
-A collaborative & cooperative approach between all stakeholders is essential

Extract from Kelly Water’s blog

With this article in 10 steps, you’ll understand how to concretely implement Scrum methodology with your team.
After reminding hte principles of agile development , you’ll find 10 guidelines steps for an easily deployment. Each step is developped in a dedicated article.

Share with us the questions you may have during your implementation and we’ll try to find a solution together !

- Step 1: Get your backlog in order!
- Step 2: How to estimate your product backlog
- Step 3: Sprint Planning/clarify requirements
- Step 4: Sprint Planning/estimate tasks
- Step 5: Create a collaborative workspace
- Step 6: Sprint!
- Step 7: Stand up and be counted
- Step 8: Track progress with a daily burndown chart
- Step 9: Finish when you said you would
- Step 10: Review, reflect, repeat…

Thanks to Kelly Waters who gives us these advices on her blog.

This is the third part of the report from the recent RMLL/LSM 2010 “Development” technical track (see links to previous parts at the bottom of this post)

This part deals with the forges afternoon that took place on the 7th, co-authored with my colleague Madhumita Dhar (who’s also working on the COCLICO project).

The first forge to be presented by Sylvain Beucler was Savane, which is the software that runs the FSF’s forge Savannah. He spoke about the previous and future road-map of the Savane project. Breaking away from its legacy PHP code (sourcing from the old libre Sourceforge codebase in PHP), Savane is going in for a complete code rewrite. This is quite a bold decision and awaits a lot of work for everyone involved. However it also allows the choice for newer tools (Django), languages (Python), practices, and should provide a more modern, easy-to-wield forge at the end of the day. Main novelty should be in a new model of forge that would be decentralized (following recent trends ala git, and guidelines about freedom in the Cloud by Moglen and others), but I’ll blog on that topic later.

The second presentation was that of fusionforge, by Roland Mas. Like Savane, Fusionforge’s ancestry also started as a fork of the old Sourceforge. The path followed by them in recent times, interestingly however is quite different from Savane’s plans. Instead of building a new fusionforge, they are trying to make the current one better, providing more features and upgrades, through code clean-up and smooth refactoring. As Fusionforge has a good user-base (often as old heavily patched GForge 4.x deployments), the effort is also more to merge in the plugins/patches developed by its users and bring about more contributions (hence the fusion term). A considerable amount has aleady been done, with more on the way. It was also mentioned that as part of efforts conducted in the COCLICO project, there’s now some converging code (plugins, for instance) between Codendi and FusionForge to try and reduce implementation efforts (Codendi is another of the cousins of Savane and FusionForge forked-off from the Sourceforge base).
Beyond efforts on FusionForge, together with other COCLICO project participants, Roland and me initiated the PlanetForge initiative, that seeks for more discussion, interoperability and other experience exchange among forge implementers and users. It was discussed during the Q&A session, and we tried to clarify that the goal is not to make other forges merge to FusionForge (even if different forks of the same PHP codebase could benefit from merging together). The goal of PlanetForge is to create an interest community, so that each FLOSS forge project can continue to live its own life, but that, if possible, all can better share information, APIs specs and other interoperability means. In short, be different, while still interoperable to each-other.

The next presentation was about Launchpad, by Jonathan Lange. It was a general presentation, explaining how Lanchpad came to be developed, the current priorities, motivations of the people who are behind launchpad, its different features, and so on. There was some discussion afterwards on whether the goals of openness seeked by LaunchPad authors can be compatible with the technical difficulties in setting up LaunchPad instances for one’s own use.

The last presentation of the afternoon was on How to choose a forge for your needs by Joseph Roumier. A good talk outlining the why and how of the methodology used by his team at CETIC, to go about selecting a forge, for their specific needs. Any guesses for the winning forge ? You’ll have to watch the video, or read the slides.

Previous parts :

• (1/4) Report on programming languages and techniques in Development session of RMLL/LSM 2010 (1/4)
• (2/4)Report on ALM, QA and industrialization methods and tools presented in “development” track at RMLL 2010 (2/4)

Next parts:

• (4/4) Final part of the report on the Development track at RMLL/LSM 2010 (4/4)

A new paper of ours was just published. If you’re curious about all that Semantic Web and Linked Data hype and how it would impact forges and other software development tools, and the link with Open Source development platforms, then, read this :

Weaving a Semantic Web Across OSS Repositories: Unleashing a New Potential for Academia and Practice
(DOI: 10.4018/jossp.2010040103)
Authors: Olivier Berger (Institut Telecom, France); Valentin Vlasceanu (Institut Telecom, France); Christian Bac (Institut Telecom, France); Quang Vu Dang (Institut Telecom, France); Stéphane Lauriere (Mandriva, France)
in International Journal of Open Source Software & Processes (IJOSSP) Volume: 2, Issue: 2 (2010), Pages: 29-40 pp.

Here’s the abstract:

Several public repositories and archives of “facts” about libre software projects, maintained either by open source communities or by research communities, have been flourishing over the Web in recent years. These have enabled new analysis and support for new quality assurance tasks.
This paper presents some complementary existing tools, projects and models proposed both by OSS actors or research initiatives that are likely to lead to useful future developments in terms of study of the FLOSS phenomenon, and also to the very practitioners in the FLOSS development projects.
A goal of the research conducted within the HELIOS project is to address bugs traceability issues. In this regard, the authors investigate the potential of using Semantic Web technologies in navigating between many different bugtracker systems scattered all over the open source ecosystem.
By using Semantic Web techniques, it is possible to interconnect the databases containing data about open-source software projects development, which enables OSS partakers to identify resources, annotate them, and further interlink those using dedicated properties and collectively designing a distributed semantic graph.

Keywords : RDF, forge, archive, bug, semantic, semantic Web, ontology, database, repository of repositories,
interoperability, bugtracker, OSLC-CM, Debian.

The journal is published as closed content on paid access, but you may ask us, should you need to read a draft version.

This is an extended version of an earlier position paper presented at WOPDASD 2009.

This work was conducted in the frame of the “System@tic Paris-Region” cluster (http://www.systematic-paris-region.org/), with funding of the Paris Region council.

A new paper of ours was just published. If you’re curious about all that Semantic Web and Linked Data hype and how it would impact forges and other software development tools, and the link with Open Source development platforms, then, read this :

Weaving a Semantic Web Across OSS Repositories: Unleashing a New Potential for Academia and Practice
(DOI: 10.4018/jossp.2010040103)
Authors: Olivier Berger (Institut Telecom, France); Valentin Vlasceanu (Institut Telecom, France); Christian Bac (Institut Telecom, France); Quang Vu Dang (Institut Telecom, France); Stéphane Lauriere (Mandriva, France)
in International Journal of Open Source Software & Processes (IJOSSP) Volume: 2, Issue: 2 (2010), Pages: 29-40 pp.

Here’s the abstract:

Several public repositories and archives of “facts” about libre software projects, maintained either by open source communities or by research communities, have been flourishing over the Web in recent years. These have enabled new analysis and support for new quality assurance tasks.
This paper presents some complementary existing tools, projects and models proposed both by OSS actors or research initiatives that are likely to lead to useful future developments in terms of study of the FLOSS phenomenon, and also to the very practitioners in the FLOSS development projects.
A goal of the research conducted within the HELIOS project is to address bugs traceability issues. In this regard, the authors investigate the potential of using Semantic Web technologies in navigating between many different bugtracker systems scattered all over the open source ecosystem.
By using Semantic Web techniques, it is possible to interconnect the databases containing data about open-source software projects development, which enables OSS partakers to identify resources, annotate them, and further interlink those using dedicated properties and collectively designing a distributed semantic graph.

Keywords : RDF, forge, archive, bug, semantic, semantic Web, ontology, database, repository of repositories,
interoperability, bugtracker, OSLC-CM, Debian.

The journal is published as closed content on paid access, but you may ask us, should you need to read a draft version.

This is an extended version of an earlier position paper presented at WOPDASD 2009.

This work was conducted in the frame of the “System@tic Paris-Region” cluster (http://www.systematic-paris-region.org/), with funding of the Paris Region council.

Q: What is the first step in implementing a requirements strategy?
A: A move to either introduce a requirements strategy where none currently exist or implement a different requirements strategy requires careful attention and planning to change management. As a first step it is critical to create a sense of need and urgency throughout the organization that will be affected. People know the difference between a real need and the next “silver bullet”. Establish real need in the minds of everyone involved, but don’t overlook capturing their hearts as well. Use both statistics & metrics and anecdotes to create a compelling case for change, and involve 20% of your organization in facilitating the change. A core group of knowledgeable and motivated individuals can facilitate change more rapidly than a single leader from a soap box. Finally, include in this opening salvo the training necessary to educate people on requirements development and management. [...]

Q: Who should be involved in defining and managing requirements?
A: The people who are going to use the software built from the requirements. That first sentence cuts to the chase, if you don’t have people who will use the software involved in the requirements process then the software will not be fit for the intended business purpose. However, there are multiple skill sets required to create software requirements that are usable themselves. [...]

This is an extract from an article published on Dr Dobb.

As a VP of product development , M.Witt deals with requirements every day. He recently took time to talk with Dr. Dobb’s editor in chief Jon Erickson.

Read the whole article

Yesterday night I found out that Sourceforge made available a new beta forge. You can browse the projects created so far in the new beta using the URL http://sourceforge.net/p/, to have a look at a test project go to http://sourceforge.net/p/fancypants/home/.

I also created a project to see what the new features are. At a glance you will notice that the layout is entirely different and simpler, the “old” sourceforge’s pages were offering too much information. Once you create the project you can add new resources to it, git, bts, wiki and so on .. nothing new under the sun at this point, but I’m pretty sure new features are coming soon. I’ve read in the Mark Ramm’s blog some interesting info:

• “And we are committed to making this the most open forge possible. We’re committed, to open processes, open code, and perhaps most importantly open data.” Encouraging sentence
• “data should be portable (every project gets their own database, which they can take with them if they want)”. I like this, if you want to be the best forge platform you shouldn’t obly people to stay, you must convince them to come
• “open source community ought to be able to extend and enhance the tools they need”

In any case, after a couple of minutes in the new forge I have some questions:

• Shouldn’t forges be more people oriented? I do love the way github does it
• Will be possible to integrate third party services (bugzilla or mediawiki for instance) in remote?
• Will be possible to import data from third party services? (for instance import a remote svn to git or mantis bugs to the sf’s bts)
• Are they going to integrate the forge with the ohloh’s results?
• Are they improving the search engine? I didn’t manage to find a person using its real name in the “old” sourceforge’s forge
• Some of the links in the beta redirects you to the “old” forge, I guess they will replace this with the new features slowly.

Passing new software to production is always funny and stressful. Good luck to the sourceforge’s team

Some interesting links:

• A peek at a new Sourceforge.net
• Adobe Announces Open-Source Collaboration with Sourceforge

The first impression in both sites is that they are really sexy, not too much information in the front page and a beautiful and simple design. Below you can find a few notes I made with the remarkable features (or lacks) of both platforms.

Github

Features:

• It is not libre software
• It offers Subversion and GIT repositories
• BTS available, it is very simple. Maybe too much!
• Team support if you sign up as an organization
• You can create a web home page in 30 seconds, there is an automatic generator that uses the information you have provided to create the project and some extra fields. http://sanacl.github.com/rsstotwitter/
• No mailing lists available
• No forums available
• If you want more than a private repo, you have to pay for it
• Project list sorted by different filters: Interesting, Popular Forked, Popular Watched, Recent, Random
• Advanced search form
• 312,000 coders and over 967,000 repositories

User experience:

It doesn’t support OpenID, I had to create a new account (boooring process). Once I had my account already created I started a project importing software from a Subversion repository hosted in sourceforge, the import was really smooth, I did it in a couple of clicks. After everything was passed to GIT it even sends you suggestions like “We couldn’t find a README for this repository, we strongly recommend adding one”

The use dashboard is really sexy, it shows you activity of the people you are following (http://github.com/sanacl), you also can “watch” different projects and developers, so the final product is really a social network for developers. There are more interesting features like the service hooks or the graphs which show the activity around the GIT repo, my favourite graph is the punchcard.

Gitorious

• It’s libre software (AGPLv3) http://gitorious.org/gitorious
• It offers just GIT repositories
• OpenID support, since I started to use this common service I’m happier.
• No BTS available
• Team support
• No Home Page available
• No mailing lists available
• No forums available
• The projects list is not very user friendly. It jsut offers a huge list of projects without categories, filters .. ( http://gitorious.org/projects ).
• I did not manage to find information about the number of users and projects

User experience:

The account creation was fast as it supports OpenID. I created a project in less than five minutes time but when I was looking for the bts I found out that there is no bts available in this platform. The dashboard is similar to the one offered by Github but as it happens with the software repositories, it’s a bit difficult to look for people. You can also “watch” repositories but AFAIK you can’t follow the entire activity of a developer with a mouse click. There is no advanced search form, so if you need to look for a user like “Germán Póo-Caamaño” is better to know its nickname (gpoo) because you won’t find him with his real name.

I had no time to test one of the basic differences between Github and Gitoriuos, the team support. The theory says that this feature helps teams of developers to collaborate sharing repositories and projects. One of the biggest teams I found is the Qt developers team, so have a look and find out yourself

No, it’s not just half the answer. I think we’re much farther down the way than that ☺ while there are still improvements planned, under development, and to come, we’ve gone a long ways from 4.5 based Evolvis platform releases.

I have just upgraded all tarent-internal instances of Evolvis, as well as the public evolvis.org forge, to a new version of the FusionForge based EvolvisForge as well as MediaWiki and its extensions.

There are several new extensions, almost all of them enabled by default. You can see a tech demo of these at https://evolvis.org/plugins/mediawiki/wiki/evolvis/index.php/PluginDemo (which will automatically show you an English- or German language version depending on your web browser’s preferences). The extensions are:

• Math
• Cite
• Collection
• CreateBox
• Footnote
• GraphViz
• ImageMap
• InputBox
• LanguageSelector
• NewestPages
• News
• PageCSS
• ParserFunctions
• Polyglot
• RSS_Reader
• SpecialCite
• SyntaxHighlight_GeSHi

The MediaWiki extensions are “driven” (configured) by the forge semi-automatically, for example RSS_Reader uses a per-project (forge group) cache directory instead of disabling the cache (which needed to be done for the Debian package, since the default installation does not have the luxury of a directory writable for the Apache user). The configuration closely matches the “old-style” (JH) Wiki integration that has been done for Evolvis 4.5 previously.

Further changes include a fair number of bugfixes to the code, theme, wiki, extensions (fed upstream), and XHTML compliance. We know there are still enough bugs to keep us busy for a while, but you might notice some improvements; others are hidden but shorten the Apache error_log noticeably ☺

To further summarise from the developer/package management system changelog the (non-bugfix) changes from the last version include:

• reduced space requirements by using the xz compressor instead of gzip for nightly Subversion backups
• give forge (group/project and site) admins more permissions in the Wiki by default
• Konqueror users have clickable sftp:// links in the places where SFTP/manual file upload can be used
• displaying filenames of uploaded files, including rules for them, has been improved
• there are now two automatic mailing lists (for newly created groups/projects): unixname-commits (where every member with commit rights will be added automatically) and unixname-discuss (where every member will be added automatically); of course there’s still the option to unsubscribe or, for non-members, to subscribe (a new Mailman integration is being worked on)
• Mailman list administrator passwords can now be (re-)set from the forge (by group/project or site admins); be careful to tell your co-admins the new password though…
• new values for PM (Tasks) status fields
• the ability to copy a task to another subproject
• customisable display for the Tasks area

Notable bugfixes:

• the SCM URLs now always use the correct hostname
• help window pop-ups are working again
• Evolvis can now almost fully be used with PHP 5.3 on Debian unstable (although we are still formally targetting Debian Lenny (with select backports and custom packages) specifically)
• font sizes (in the forge and the wiki) are finally consistent
• slight performance improvements

The time tracking area in Tasks has been disabled, since there is a company-internal tool doing the same, with an Evolvis integration being developed.

We hope you enjoy the latest installment of the Evolvis platform!

— Thorsten Glaser, for the tarent Evolvis task forge, FusionForge and Mediawiki

Another month, another update, but nothing spectacular to be announced in FusionForge-world. We're still working on finishing the transition to the new configuration system, we're testing the migration to a simpler and more flexible set of Apache configuration files, and work is in progress on the RPM packaging. And so on.

Possibly the most newsworthy item is the FusionForge presence at next month's Libre Software Meeting in Bordeaux (the “RMLL” in French). I'll do a FusionForge, one year and a half later talk summarising the status and progress of FusionForge, and there'll also be a *forge devroom where we'll mingle with people interested in all kinds of software forges. Come see us if you're around!

Reposting from : Open Source OSLC-CM implementations in PHP posted on Helios project’s blog at SF.net :

Steve Speicher at IBM/Rational has blogged about OSLC reference implementations and test suites.

He’s been kind to link to our implementation, which uses Zend framework in PHP, and will provide an Open Source OSLC-CM V1 server component for the Open Source Mantis bugtracker (and later for FusionForge trackers too).

I hope people can learn how OSLC-CM V1 works, by testing with a Mantis 1.2 installation plus our server add-on, and by looking at our server’s code (and maybe, then decide to use it in production too, of course).

…

More at https://sourceforge.net/apps/wordpress/heliosplatform/2010/06/17/open-source-oslc-cm-implementations-in-php/

During the forecoming Libre Software Meeting 2010 (aka Rencontres Mondiales du Logiciel Libre) to be held from July 6th to 11th in Bordeaux (France), the “Development” technical track will host 27 interesting talks covering various aspects of software development with and/or for libre software. Among the topics covered, here’s the list of talk titles :

On development around PHP:

• SOAP and RESTful webservices with Symfony (Hugo Hamon)
• PHP development industrialization (Jean-Marc Fontaine)
• Listen to your PHP code (Gabriele Santini)
• PHP code audits (Damien Seguy)

On build and compilation tools:

• Bee Build management tool (Michel Casabianca)
• Extending the GCC compiler with MELT to suit your needs (Basile Starynkevitch)

On industrialisation, ALM and agile methods:

• Java development Industrialization using a technical base (Stephane Traumat)
• Industrialization & agility : the HELIOS project (Laurent Laudinet)
• Agile development with IceScrum (Vincent Barrier)

On bugtracking (english track):

• Peer to peer issue tracking with SD and Prophet (Jesse Vincent)
• Client to deal with great amount of bug for Launchpad: BugHugger (Didier Roche)

On software forges (english track):

• A new Savane (Sylvain Beucler)
• FusionForge, one year and a half later (Roland Mas)
• The Launchpad collaboration platform (Jonathan Lange)
• Choosing a software forge (Joseph Roumier)

On programming languages (english track):

• Go: A new systems programming language (Uriel)
• Perl 5.12 (Jesse Vincent)
• How I learned to Stop Worrying and Love Static Typing (Alexander Heussner)
• Quick introduction to Ruby 1.9 (Bruno Michel)

On development techniques:

• NoSql databases access in python (Youenn Boussard)
• Introduction to libre “fulltext” technology (Robert Viseur)
• Accelerated development with Quickly (Didier Roche)

and also several other aspects of libre software projects and distributions:

• How to make applications accessible? (Samuel Thibault)
• The translation of KDE into french (Ludovic Grossard)
• The road to GNOME 3 (Vincent Untz)
• The illustrated guide to your first contribution to openSUSE (Vincent Untz)
• PLF, the story of a third-party repository like no other for Mandriva (Michael Scherer)

There should be plenty of oportunities to learn and discover interesting tools, techniques or methods. We’re looking forward to welcoming you in Bordeaux. And as usual, LSM is free entrance, and organized by volunteers, so join and enjoy.

With EvolvisForge 4.8.3+evolvis20, we have a new configuration system for Apache 2 (being prepared for merging into FusionForge) which greatly simplifies things.

The most common tasks can now be easily solved:

• /etc/gforge/templates/httpd.ssl0.inc: uncomment two lines, and all forge vhosts redirect to https unconditionally
• /etc/gforge/templates/httpd.auth.forge.inc: uncomment a bunch of lines, and you get HTTP Basic Auth with PAM backend accessing nss_pgsql2, which means you must login with your forge username and password to display the site
• /etc/gforge/templates/httpd.auth.projects.inc: copy the same lines here, and the project homepages (*.forge vhosts) are protected in the same manner
• /etc/gforge/httpd.d/*: change 02namevhost, 06maindirhttp, 20list, 40virtualhost if you want not *:80 and *:443 vhosts but per-IPv4-address vhosts
• /etc/gforge/gforge.conf: insert lines like 「sys_sslcrt=/etc/ssl/my.cer」, 「sys_sslkey=/etc/ssl/private/my.key」, 「sys_ssl_apache_extra_cmd=SSLCertificateChainFile /etc/ssl/chain.pem」 to configure HTTPS properly and easily

Of course, there’s more to that: If you have more vhosts, just 「Include /etc/gforge/httpd.security.inc」 to disable a potential security hole / information leak, 「Include /etc/gforge/httpd.log.inc」 to log into the same files, 「Include /etc/gforge/httpd.ssl0.inc」 (SSL off) and 「Include /etc/gforge/httpd.ssl1.inc」 (SSL on) to use the same SSL configuration as the forge. The latter is especially important if you have more than one 〈VirtualHost *:443〉 container, as Apache 2 uses the configuration from the ASCIIbetically first one.

I was able to completely switch from the old, hand-edited configuration to a generated one with little, if any, changes on all our installations now. Some legacy or useful vhosts have been split out, for example a redirect for the old-style Wiki URIs, the Maven 2 repository vhosts, and Alfresco/Domisol (which was already separate but now got split port-80/443 configuration and the above-mentioned Include directives).

Furthermore, eMails from forge users to the FOO-commits@ mailing lists are always allowed by default for newly created lists, and users added to a group with SVN commit rights will be automatically subscribed to that list. We now issue the Forge Identification Header and display the version on the webpage. There was, of course, your usual round of bugfixes and infrastructure improvements, including preparations for more things to come (so stay tuned).

Roland will, as usual, take the best out of EvolvisForge and put it into FusionForge (et vice versa).

There’s also news on the not-so-forge front of Evolvis: our Hudson installations talk Jabber now, and the integration is becoming more tight. We can drive both old-style wikis and gforge-plugin-mediawiki at the same time. We’ve begun adding a bunch of mediawiki plugins (more to follow as needed); if there are people packaging those for Debian already, cooperation is desired.

Until 12th of June, the “Fairtrade Software” booth at LinuxTag 2010 in Berlin, Germany, will present Evolvis and FusionForge to the public. Visit us in Hall 7.2a, Booth 123, and check out the other exciting tarent projects!

 Codendi 4.2 beta version is released. This is an early access from the final Codendi 4.2 Edition that will be fully tested and secured and soon available.

With this beta version, Codendi provides a new generation of trackers, one of the most important tool of the platform on which are based all the other tools. This is the major new feature of Codendi 4.2. Codendi team worked hard to build a new tracker engine providing from now significant enhancements and new functionalities and allowing lots of future developments.

The trackers of the platform had already strong capabilities as linking all the artifacts of a project to each others allowing users to immediately access work items, bugs, source code, documents and other artifacts at any step of the project’s lifecycle.
Codendi 4.2 beta version goes further and provides now a workflow for each tracker. It is now possible to define artifact state transitions with associated permissions. The 4.2 beta tracker engine offers new tracker templates and the import/export of tracker structure in XML format to boost open architecture.

For improving project monitoring and productivity, you can now post results or reports of your customized tracker queries everywhere in your project or personal workspace. You can interactively build up reports by adding, moving and resizing columns. You can also add and remove query filters interactively and replay previous complex queries very quickly. Moreover, the new user-friendly interface makes work easier and faster.

A GIT plugin has been added. This distributed version control system offers performance and efficient storage. It allows committing offline then pushing, branching and merging are faster and easier. Git enables multiple local branches that can be entirely independent of each other. Git enables to link a repository to several other remote ones which can be modified locally as independent branches. Each remote branch can be a feature you can experiment and finally decide to merge or discard.

Codendi final 4.2 Edition will contain bug fixing and a new SOAP interface to give the possibility to plug any other tool to the platform.

You are kindly welcome to download the Codendi 4.2 Beta version and share your feedback on the community website http://www.codendi.org/

We’ve been working on modeling bug reports properties for quite a long time, but never managed to stabilize an ontology specification. Better late than never, here’s our first proposed draft and our request for comments :

More details in the helios project’s blog :
http://sourceforge.net/apps/wordpress/heliosplatform/2010/06/04/first-draft-of-helios_bt-bug-ontology-request-for-comment/

The project of the month for may 2010 is Jappix. This is a very new project developped on CodingTeam.net since april 2010!

According to the project leader, Jappix is a Jabber web-client that aims at becoming the web equivalent of Gajim. It means that loads of XMPP XEP will be supported, and the client will probably become a "mini" social network, entirely based on the XMPP protocole, with the help of PubSub.

The graphical aspect is also very important to the Jappix team as they want the non-profit Jappix project to be as good as other commercial web-app. According to them, the user has to feel good while using it: “ The Jabber network needs good clients, so that we can do it and convert everyone to Jabber. Let's decentralize the instant messenging ! ”

And now, a few questions asked to the project leader!

• How did you know CodingTeam?
  
  I know Codingteam thanks to Edouard, who posted a comment on my weblog, that told me he was using CodingTeam.net since a few time and it was pretty good for his projects (in fact, they were shared faster). At the really beginning, I wanted to use Launchpad.net from Canonical, but I saw that it wasn't as good as I expected. Here came CodingTeam.net !
   
• What CodingTeam brings in your project development?
  
  CodingTeam brings us a better organisation, mostly with the bugs reporting tool, that we use mainly as a ToDo list (because I report all the functionalities that I'd like to code for the next versions with that tool).
  
  On the one hand, CodingTeam.net brings us a simple hosting platform for our project, with a great SVN repository and package hosting, with the principal advandage that is to get a quick view of the total number of downloads, with the popularity of our project on the platform. The OpenForge API is also great, because we use it to retrieve data on one of our external website.
  
  On the other hand, the work of the translators was really simplified thanks to CodingTeam, because they are able to start translating from a simple web interface, and they do not need to contact us anymore to send any translated strings file ! That's simple, direct, and powerful.
  
  There are loads of things that CodingTeam has which make me love it (the XMPP functionnalities and so on). It make us work even faster and easier, together.
   
• What would you see in CodingTeam in the future?
  
  Well, I think that, in a first, some tools like the translation engine might be improved to allow anonymous users translating the project that they want to. Then, I really think that opening the forge to other repository protocols (principally Git), because some developers can't bear Subversion...
  
  Allowing project managers to add external Jabber rooms or external repositories would be great too. Maybe that on some CodingTeam modules, the performances should be increased too: the page generation can be very slow by using a particular tool and very fast with some other tools.
   
• Since you use CodingTeam, did you became rich and sexy?
  
  Well, I got lots of donations (74€) for the project (I don't know if it's thanks to the "donate" link on CodingTeam.net or the one on my weblog), but the main thing is that it allowed me to code even faster and better.
   

Thanks to Valérian who answered to my questions! Feel free to take a look at Jappix!

The usual semi-regular bits of news from the FusionForge project. We continue being quite active, with several hundred commits each month. The momentum doesn't seem to stop even after the 5.0 release last month. A large part of the activity stems from the Coclico project, which has several work-packages related to convergence of code across forges (mostly between FusionForge and Codendi). This convergence comes in three flavours:

• some new features are developed in common for both forges; as an example, the Mailman and ForumML plugins recently committed can now run unmodified in FusionForge and in Codendi (or at least that's the goal);
• some features existing only on the Codendi side are ported across to FusionForge; this includes the Codendi “widgets” system, which allow drag-and-drop customization of some of the web pages, and the Hudson plugin;
• finally, some of the core code is rewritten so that a common API and abstract data model can be used by higher-level pieces of code; the configuration system has been almost completely converted to a simple API, and the role-based access control system has also been rewritten into a clean model that extends both FusionForge's previous RBAC system and Codendi's, so each forge will provide new features for access control (the immediate gain for FusionForge is the ability to grant different permissions to anonymous visitors and to visitors that are logged in even if not members of the current project).

All in all, a fairly busy period for FusionForge. The current trunk is evolving rather fast, with some long-overdue rewrites being underway. Interesting times.

I just installed EvolvisForge 4.8.3+evolvis12 (after quite some bugfixing) on evolvis.org and the last remaining internal instance.

This means that tarent is no longer running GForge 4.5 so let’s celebrate!

You’re hereby cordially invited to check out the public Evolvis and what makes it so good (FusionForge based) and then even better (our hard work ☺). This is the latest and greatest, but still work in progress, we have a lot of further improvements planned, so stay tuned!

Maintenance release, bugfixes and translations only

The project of the month for april 2010 is Kinovea. This project is developped on CodingTeam.net since september 2008!

Kinovea is a video analysis tool for sport coaches and athletes. The main focus is to enable performance analysis through a straightforward interface. The most important functions (aside frame by frame playback) are video-drawing and side by side comparison.

The project started as a small freeware in 2004, then underwent a full rewrite starting in 2006, with the first open source version available in 2008. The project is also used by 2D/3D animators to comment on each others works.

Kinovea was rewarded in 2009: it was the third project in the Multimedia category of Les Trophées du Libre.

And now, a few questions asked to the project leader!

• How did you know CodingTeam?
  
  I honestly don't remember how I stumbled upon CodingTeam, it probably was on Veni Vidi Libri wiki (a website to help Open Source software authors with licensing and organising). What I do remember is that I was attracted by the human-sized structure and clean design. The fact that the forge is open was also a strong point. It suddenly made me realise that most other forges weren't quite coherent in their approach.
   
• What CodingTeam brings in your project development?
  
  We are mostly using the subversion repository facility, its web interface, and the RSS feed of code changes.
   
• What would you see in CodingTeam in the future?
  
  I think one area that could be worth exploring is to give the administrator of a project more access to the underlying data of his project. For example, the wiki pages (including history) could be made downloadable on demand as a single archive, to provide an extra backup mechanism.
  
  I think there are already a whole lot of interesting features, probably more than one can dream of. As a matter of fact, it might be interesting to give project admins the ability to hide/show tabs to better match the tools they actually use.
  
  That said, I'm looking forward Mercurial support, I know it's in the works :-)
   
• Since you use CodingTeam, did you became rich and sexy?
  
  Definitely. Each time I use CodingTeam, I gain one extra point of sexiness. Now I need to figure out how to fix the sexy, sexy bugs I write :-)
   

Thanks to Joan who answered to my questions! Feel free to take a look at Kinovea!

Fourteen months after the renaming of the Free/Open Source code of GForge 4.x to the new “FusionForge” name, we're pleased to announce version 5.0. As mentioned in the release notes, this is still an incremental step over version 4.8 rather than a revolution, but the changes are important enough, and numerous enough, that we felt it justified to bump the major version number.

Major improvements, beyond a host of bugfixes, include:

• a rewrite of the version control integration (with support for Bazaar, Darcs, Git and Mercurial in addition to the “traditional” CVS and Subversion);
• a much better integration of Mediawiki (one wiki, with its own set of permissions, per project);
• a cleaner database layer, more robust against SQL injections;
• configurable display for the trackers;
• more powerful tracker engine, with configurable workflows;
• a rework of the default theme, with better accessibility.

FusionForge 5.0 now also includes new plugins that were previously only “floating around” (or completely private):

• projectlabels gives a simple way of adding bits of HTML onto project description pages, so the forge admin can, for instance, highlight a “project of the month”;
• extratabs allows a project to define new tabs in its pages, pointing at external resources;
• globalsearch is a first step in the “federation of forges” concept, whereby a project search can be conducted on several forges at once;
• contribtracker allows a forge to prominently display major contributors to projects, to give them visibility beyond the simple commit logs.

These plugins, as well as a large part of the improvements in the trackers and the rewritten Mediawiki plugin, are a direct consequence of the “upstreaming” of work having been done in private instances of forges. We're happy to note that this goal of ours (to merge local patches into the central repository when it makes sense) seems to be working well. For the record, this 5.0 release includes work and plugins that were reintegrated from sources such as Alcatel-Lucent, Adullact and AdaCore.

This release is also the first to have had the benefit of automated testing during the whole cycle. Coverage isn't 100 % yet, but the existing unit tests and functional tests help us be confident in the quality of the release. We'll keep adding more tests as time passes, of course.

Looking back at the initial goals stated when the project started, we seem to be on the right track:

• stable release pushed out: check (this is the third one, not counting minor releases);
• new plugins merged: check;
• automated testing: check;
• external contributions merged: check;
• explicit governance model and release process: sort-of (there's still a cabal, but it's partially documented).

We still need to work on the database schema and the cross-distro part, as well as cross-forge interoperability. The good news is that work is happening on these fronts already. And with almost 2500 commits, we truly seem to have accomplished at least one of the (implicit) goals: to bring development back to a healthy state. And we're far from being out of ideas for the future, so there's a lot of good stuff still cooking!

Here's another quick update on the status of FusionForge.

We released version 4.8.3. Nothing earth-shattering, but a collection of bugfixes that had accumulated on the 4.8 branch. If you're running a patched version, you might want to merge.

We also published the second release candidate for 5.0. It's not final yet (there have been a few commits on that branch since then), but we're running out of known bugs. We're currently down to zero open bugs targeting 5.0, so the actual release is probably going to happen in a matter of days. 5.0rc2 is currently available in Debian experimental for those who want to test it, and the final 5.0 will be uploaded to unstable, and hopefully migrate to Squeeze in due time.

Stay tuned…

Here are some cool statistics about CodingTeam.net usage (generated on 28^th march 2010). There are currently 304 projects registered on CodingTeam.net.

Top categories.

• Network (76 projects)
• Other (50 projects)
• Game (49 projects)
• Programming (40 projects)
• System administration (14 projects)

User involvement.

• Number of users: 1,276

• Users who own one or more project: 249 (19.5%)
• Users without any project: 1,027 (80.5%)

• Users involved in one or more project: 283 (22.2%)
• Users without any project involvement: 993 (77.8%)

Miscellaneous.

• Number of posts in the forums: 2,436
• Number of bugs reported: 1,097
• Number of strings to translate: 335
• Number of translated strings: 1,492
• Number of news: 386
• Number of downloads: 495

The fact is that a lot of users on CodingTeam.net are somewhat inactive. But the few users that are really involved seem to be huge workers (we have more than 3,200 commits since the 0.9 release (all past commits aren't counted)).

Each time I release a new version of CodingTeam, a lot of users come to CodingTeam.net to see how it works. CodingTeam.net not being a test setup may be the reason for a large part of these 77.8% inactive users: They register, see their project rejected, and stop here. Maybe it would be a good solution to create a CodingTeam demo, opened to all, allowing everyone to test, to see and to make their own advice without installing anything. Statistics are cool, interpreting them is harder.

And, last but not least, as I'm very busy this month, there won't be a Project of the Month entry for march 2010.

FusionForge 5.0 is still an incremental step over 4.8, but many changes have been made, some of which may require caution when upgrading. In particular, the rewriting of the version control subsystem created the possibility for many new VCS tools to be integrated, and indeed several new plugins were implemented (Arch, Bazaar, Darcs, Git and Mercurial). To avoid crowding the chroot, all repositories are now hosted under a two-level subdirectory structure. For instance, where you had a CVS repositories stored under /var/lib/gforge/chroot/cvsroot/<project>, you'll now have it under .../chroot/scmrepos/cvs/<project>. As a consequence, you need to move the repositories by hand and/or add symlinks. Previously existing symlinks will also have to be updated, as well as previously existing working copies obtained by users. Also, the Mediawiki plugin was rewritten to allow for each project to get their own independent wiki. The wiki for project foo-bar is now stored in the plugin_mediakiki_foo_bar in the same database as the rest of the forge. This means the data should be migrated from the existing database to this new location. Depending on your setup and the amount of data involved, it might make sense to either cut and paste by hand or dump the tables and reload them in the new schema. On the internal side of things, access to the database has been converted from the db_query() abstraction layer to the db_query_params() one. This means SQL queries are no longer built as strings with unwieldy and fragile escaping code, while ensuring no data coming from the user can be used for SQL injection attacks. The db_query() function, while deprecated, is still present for the benefit of out-of-tree code that might use it. It might be removed at some point in the future, so maintainers of local plugins or enhancements are encouraged to migrate their code to db_query_params(). For really complex queries that need to be built dynamically, there's also a db_query_qpa() abstraction, with a db_construct_qpa() method to manipulate "QPA" (query+params array) objects. On a more visible note, the default theme has been reworked to increase the accessibility of the web pages; this rewrite also brings better maintainability, easier customisation by CSS and more conformant XHTML.

I’m happy. I just was able to deploy a new version with many improvements on almost all of our systems (save the two which are not yet on 4.8 but stuck on 4.5 codebase).

For example, Roland has provided code to set the roles’ default permissions in a new forum, tasks or tracker subproject to some (sane) default value, instead of Read – now that they’re suddenly honoured, the bug (of them not being set to e.g. Tech) surprised many people.

I’ve written a CAPTCHA for user self-registration, in the hope of fooling automated login bots to fight spam accounts like we see at evolvis.org quite often these days (maybe spammers have special bot codes for *forge?).

The automated creation of ~user/.forward to enable mail forwarding for «user»@«forge» the same way «user»@users.«forge» is already handled now also works well. Other nifty things include bug fixes and more features in our theme (which should not be considered public) and the mediawiki plugin (allowing better control over importing, editing the Sidebar, logos, etc) and better XHTML/CSS compliance and browser compatibility.

Admins will love this: one can now set the password of any user if one is a Site Admin! (Before, this involved quite some database fiddling after calling md5(1) and encrypt(1) manually.)

The only sad things I see are that we cannot yet upgrade all instances we run to gforge-plugin-mediawiki, so they keep running the old-style separate wikis, which run on the same database though, preventing it from being upgraded from PostgreSQL 8.1 to 8.3 (due to the age of the mediawiki engine being used), and that our internal forge and the public one, evolvis.org, cannot yet be upgraded (especially as I’ll be on vacation RSN).

Still, we hope our cow-orkers enjoy the new release.

On the other track, we’re already running towards a stable 5.0 release, which will rock. One of my colleagues is helping with translating the strings into German upstream, and the branch is created; the code is being stabilised now and short of a release (also, thanks to the speedy help of the Debian FTP masters, with a detailed and correct debian/copyright file and a DFSG free distfile). Some tarent/evolvis extensions have found their way in there already; FusionForge 5.1 will have more, we guess.

Keep up the great work, FusionForge people!

FAQ: When will FusionForge 5.0 be released? ⇒ As soon as it’s ready. Faster if you help.

EvolvisForge will migrate to a 5.0-based code some time after, taking care of possible regressions and merging our changes, some of which will then wander into FusionForge trunk, hopefully ☺

FusionForge-4.8.3: * Maintenance release, security and bugfixes.

We have received a visitor from DERI last week (PhD student Aftab Iqbal) who’s researching integration of facts about software development tools into Linked Data in order to provide interesting “semantic mashups” of data into IDEs like Eclipse (see his slides). Quite interesting is the choice of ontologies and the results integrated in an Eclipse plugin made available to developers.

This approach is quite similar to the one we practice in the core of the Helios platform (still under development) to integrate data coming from different FLOSS ALM tools in order to create dashboards offering a consolidated view of software (maintenance) process.
Maybe the difference is that Helios does this internally inside a “self-contained” platform whereas the potential of LD2SD presented by Aftab is to do the same on the Web of Linked Data.

Also, in Helios, there are other contributions made for the Mandriva distribution (with links with projects like Scribo and Nepomuk to which Mandriva is also participating) in the form of the doc4.mandriva.org, in order to aggregate, this time, not facts at the “project” level, but for a meta-project (a GNU/Linux distribution) that are quite interesting. See Stéphane Laurière’s slides for details.

We’re also experimenting in the frame of the COCLICO project on producing RDFa data about software development projects hosted in FusionForge instances. (see our progress tracked through this FusionForge feature request). First candidates are project’s DOAP profiles and developer’s FOAF ones, and lots of SIOC to glue it all, and of course other informations relating to a Forge ontology that we’re proposing in COCLICO.

With recent announcements that Mylyn is investing a lot in OSLC, and OSLC being based on RDF, and the advent of the Semantic Desktop starting to emerge (in KDE mainly) on top of Nepomuk, this brings great promises for a great Semantic future.

We have received a visitor from DERI last week (PhD student Aftab Iqbal) who’s researching integration of facts about software development tools into Linked Data in order to provide interesting “semantic mashups” of data into IDEs like Eclipse (see his slides). Quite interesting is the choice of ontologies and the results integrated in an Eclipse plugin made available to developers.

This approach is quite similar to the one we practice in the core of the Helios platform (still under development) to integrate data coming from different FLOSS ALM tools in order to create dashboards offering a consolidated view of software (maintenance) process.
Maybe the difference is that Helios does this internally inside a “self-contained” platform whereas the potential of LD2SD presented by Aftab is to do the same on the Web of Linked Data.

Also, in Helios, there are other contributions made for the Mandriva distribution (with links with projects like Scribo and Nepomuk to which Mandriva is also participating) in the form of the doc4.mandriva.org, in order to aggregate, this time, not facts at the “project” level, but for a meta-project (a GNU/Linux distribution) that are quite interesting. See Stéphane Laurière’s slides for details.

We’re also experimenting in the frame of the COCLICO project on producing RDFa data about software development projects hosted in FusionForge instances. (see our progress tracked through this FusionForge feature request). First candidates are project’s DOAP profiles and developer’s FOAF ones, and lots of SIOC to glue it all, and of course other informations relating to a Forge ontology that we’re proposing in COCLICO.

With recent announcements that Mylyn is investing a lot in OSLC, and OSLC being based on RDF, and the advent of the Semantic Desktop starting to emerge (in KDE mainly) on top of Nepomuk, this brings great promises for a great Semantic future.

During the last couple of months some interesting things have happened in my research group (libresoft.es) related with software metrics and its application to collaborative environments. One of our dearest data mining project (FLOSSMetrics) has achieved a great added value in terms of procedures to get data from libre software projects and some of its small features have been applied OSOR.eu, the biggest collaborative environment we maintain. With the background we have in this topic (see the links below) we are in a great position to contribute with something interesting in this area to the libre software community so .. there we go.

Our first task is to polish up the tools we developed for FLOSSMetrics, our team have some ideas about how to improve the heart of the analysis (a tool called retrieval system .. so far!). At the same time they design the new platform I’ll start creating a prototype which will be our template for its application to the first forge: fusionforge, which is the new libre release of GForge. As always, the design is the most important part because we want/need to obtain a standalone product with a wide variety of plugins. Indeed we need to emphasize that our aim must be obtaining/offering a “product“, only one product with many many small applications. This point of view would be new for us (it is not very common in research projects) and I’m pretty sure that’s the way we can improve the final quality.

One metrics product to rule them all!

Some interesting links:

• Melquiades – analysis for ekiga
• Metrics in osor.eu for the Sextante project
• Metrics in osor.eu for the whole platform

It took us a while, but we’ll be participating at Plänet Forge soon as well. We, that is the Evolvis team at tarent GmbH:

• Thorsten Glaser (that’s me), a sysadmin at tarent and an Evolvis developer
• Sven Frommeyer, an apprentice sysadmin at tarent
• Stefan Walenda, our project manager
• … and potentially others

To clean up the nomenclature…

• Evolvis is the platform consisting of EvolvisForge and others, such as a Continuum or Hudson build server, an Alfresco DMS, a MediaWiki, …
• EvolvisForge shall be the name of the customised installation (not fork) of FusionForge (formerly gforge-*.deb) that is used by Evolvis
• evolvis.org is the public platform where tarent GmbH is presenting their open-sourced projects
• There are other Evolvis installations at *.tarent.de domains, which are private.

EvolvisForge customisations mostly consist of: take a stable FusionForge version plus bugfixes, sometimes backports (such as the FF 5.0 MediaWiki integration), change some defaults, and add Evolvis branding such as our theme. Also, some integration with the other Evolvis components, Univention/LDAP, etc.

This is a welcoming posting, so I better keep it short. We’ve been in Issy-les-Moulineaux (I hope I spelt that correctly) breaking up the French cabal, but they’re all nice people. Let’s try and improve all the forges!

Le livrable de la tâche 2 du WP5 est disponible sur le site du projet Coclico/Onglet Fichiers. Ce livrable comprend une archive Eclispe Ganymede Plugin RCP + Mylyn + code source du Plugin Codendi. A noter qu'il y a une version plus récente d'Eclipse qui est sortie : Galileo, mais nous ne l'avons pas utilisé parce que la version du plugin Codendi n'est pas encore dispo pour Galileo. Si vous avez des remarques n'hésitez pas.

Codendi offers a new service, Codendi SaaS.

In order to manage and follow the projects on the Codendi platform without having to manage the installation, maintenance or reliability aspects, or the environment security, Codendi allows its customers to benefit from a Codendi platform based on an external server.

Indeed, Codendi SaaS is hosted by Xerox, and is managed by an experimented team in charge of the application, leaning on a robust and secured infrastructure.

The support is carried out by our development and support teams, in order to facilitate the use of the solution to the Codendi SaaS members, wherever they are connecting to.

Codendi SaaS is quickly useful, allows a good scalability and interoperability between the actors of the project. Those actors can work in the same company, or can be customers, providers or partners.

SupInfo has selected this year Codendi Saas to help its students to achieve the internship projects they have to realize. This service allows them to share the project with the concerned companies, and to benefit from the latest releases and versions of Codendi.

SaaS, for “Software as a service”, is a service which consists in hosting an application on its own server for its customer use.

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 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…

The project of the month is an interesting project using the CodingTeam software forge. Each month, I'll pick up another project that looks attractive and speak about it on this blog. Thus, the community gets a place to be known. So if you use CodingTeam (either CodingTeam.net or your own forge) your project can appear here! By the way, if you think that it would be captivating to present your project here, let me know!

The project of the month for february 2010 is Bechamail. And it becomes the first project of the month!

Bechamail is lead by Robert Sebille on CodingTeam.net since november 2007! He works on this project since 2005 for his association with help and feedbacks from the other members of it.

Bechamail is a French-speaking project written in PHP. It's an e-mail addresses manager. Concretely, it helps the sysadmin by providing an user oriented tool to easily configure e-mail addresses for one or more domain names. It fits to MTA and MDA configuration.

This project has been developed in an associative context as Robert is one of the fouding members of Cassiopea. The goal of this association is to heavily connect associative virtual networks and to help people to understand new technologies. Cassiopea provides internet services such as implementation or development of websites, mailing lists, domain names, e-mail addresses, trainings… to other Belgian associations.

Bechamail is born in 2005 because, at the start of this associative project, whenever it was necessary to create, modify or delete an alias or an e-mail box, they had to intervene on the server. It was inevitable to automate the process and allow members to manage their e-mails easily.

Bechamail is successfully used at Cassiopea and also at Banlieues, an association that focuses on the disadvantaged public. Those who want to try Bechamail can test the demo!

And now, a few questions asked to the project leader!

• How did you know CodingTeam?
  
  By searching the web for forges lists (but I don't remember where). Functionnalities suited me and it was in French and English. It looked good to me to support a sofware forge available in French. There were not many.
   
• What CodingTeam brings in your project development?
  
  Usual functionnalities of a software forge of course, like the essential SVN. Once you start to use CodingTeam, it's so practical, how to do without? ;). I remember a day, there was once a technical issue on the the server side, I really appreciated to be able to discuss it on the chatroom and the CodingTeam reactivity!
   
• What would you see in CodingTeam in the future?
  
  I was going to say the dashboard, but it's already done ;), great! Then, e-mail report when someone answers to a bug or a feature request. Otherwise, I have to think regularly to consult the bug tracker or the RSS feed, and I don't always think about it, especially if I am busy with another project for a few months. That's why e-mail notifications would be useful for me, because I could see them even if I'm working elsewhere. I read the discussion here. The solution to choose to receive or not notifications seems good to me.
   
• Since you use CodingTeam, did you became rich and sexy?
  
  Rich with money? Not so. On the other side, I found a lot of fortunes on CodingTeam.net ;). Sexy? I was already sexy before, in my point of view. ;)
   

Thanks to Robert who answered to my questions! Feel free to take a look at Bechamail!

You work on developing a software forge, you’re an admin for a software forge, or a project administrator.

Join us and discuss (in english) forge matters on discussions@planetforge.org, to try and improve communication, sharing, reuse and interoperability among various hosting platforms, and collaborative development tools.

You may prefer joining the PlanetForge RSS aggregator if you blog about forges (feel free to add it to your preferred RSS reader).

As part of COCLICO, we’re working on an exchange format for forges, that should help dump, restore, export and import from different software forges.

There are various use cases for this, like moving a project from one forge to another, but also as backup/restore feature for forge admins. More about the rationale here.

We’d like this format to be a standard some day, so it should have good properties so that it’s generic enough and at the same time easy to adopt. Thus it would be relatively easy to contribute new exporters or importers to an framework (for which we’ll implement basic core tools), while having a long-lasting format that can still be used in the future.

A lot of work ahead of us, and this is just a short notice in case you’re interested and you’d like to know more

Stay tuned, and if interested, join discussions@planetforge.org to discuss this topic.

P.S.: yes, it’s a rebirth of CoopX, somehow (see the coopx tag in my blog for more details)

The INRIA (the French national institute for research in computer science and control) in Grenoble has animated on 12th January a seminar about the methodologies and experiences of the open source based developments.

This meeting, organized by the business intelligence Club IN Tech and GRILOG association (“Grenoble Isère Logiciel”, i.e. Grenoble Isère Software), was the occasion for the different actors, industrialists and researchers, to have a technological and information exchange.

During this conference, a demonstration session has allowed to present open source applications and products, and to discuss the development team organization, the features used, or the technology transfer among others.

Nicolas Guérin, our technical manager, has presented Codendi and its evolution : from the forge created inside the Xerox research center in order to gather all the required tools of the software development to a natural passage to an ALM tool.

Actually, the proprietary ALM solutions are generally complex, split and expensive. The approach proposed by the modern forge developers allows a natural integration of the ALM tools, as :

• the project standardization thanks to the patterns
• the possibility of parameter setting following the chosen methods (Scrum or other Agile methods, CMMI or quality)
• Or even the traceability of the requirements, tests, documents or taskswhich can be linked together.

Besides, the open source development opens up possibilities to integrate and adapt other tools to increase and diversify the features as Subversion, Git, CVS for versioning, Hudson for continuous integration, or Salomé TMF for test plan management.

The open source process makes easier the use of protocols and open standards as HTTP, XMPP, SOAP or LDAP.

Finally, it improves the contributions and the co-development model because it creates discussions with the users; so that the extensions developed were enough generic to be integrated into the application. So, all users benefit from it.

In fine, the open source is determinedly directed to the consumer, because of durability and search of innovation, and requires in return an investment in talents.

And you, what is your experience about the open source use? Share your opinions on this blog.

Mardi 12 janvier se tenait à l’INRIA (institut de recherche en informatique et en automatisme) près de Grenoble une après-midi de réflexion autour des méthodologies et des expériences de développement basées sur le logiciel libre.
Cette rencontre, organisées par Le club de veille technologique IN’Tech et l’association GRILOG (Grenoble Isère Logiciel), a été l’occasion d’échanger sur les retours d’expérience des différents acteurs présents, qu’ils soient dans le monde de l’industrie ou dans celui de la recherche.
Le cycle de conférence a été entrecoupé d’une séance de démonstration de produits et d’applications issus de l’open source, durant lequel un échange notamment sur l’organisation des équipes de développement, des fonctionnalités utilisées et du transfert de développement a pu être abordé.

Nicolas Guérin, responsable technique de Codendi, a ainsi présenté Codendi et son évolution : de la forge logicielle créée au sein de Xerox dans le but de rassembler les outils nécessaires pour le développement collaboratif à un passage naturel vers un outil d’ALM (Application Lifecycle Management).

En effet, les solutions ALM propriétaires sont en général complexes, morcelées et coûteuses. L’approche proposée par les forges modernes permet une intégration naturelle des outils ALM, comme par exemple pour :
- la standardisation des projets à l’aide de modèles,
- la possibilité de paramétrages en fonction des méthodes de gestion choisies (Scrum ou autres méthodes Agile, CMMI ou approche qualité),
- ou encore la traçabilité des exigences, tests, documents ou tâches qui peuvent être liés entre eux.

Par ailleurs, le développement open source ouvre la possibilité d’intégrer et d’adapter d’autres outils open source pour élargir le spectre des fonctionnalités telles que Subversion, Git, CVS en gestion de version, Hudson en intégration continue ou Salomé TMF en gestion de plans de test.
L’open source facilite l’utilisation de protocoles et standards ouverts comme HTTP, XMPP, SOAP ou LDAP.
Enfin, il améliore la contributions et modèle de co-développement car il engendre des discussions avec l’utilisateur afin que les extensions développées soient suffisamment génériques pour être intégrées à l’application; ainsi, tous les utilisateurs en bénéficient.

In fine, l’open source est résolument orienté vers le consommateur en terme de durabilité et de recherche d’innovation et requiert en échange un investissement dans les talents.

Et vous quelle est votre expérience d’utilisation de l’open source ? Faites-nous part de vos réflexions sur ce blog.

The Helios project is gradually going more open, as we start releasing and committing in the open into a SF.net project (heliosplatform).

Among the tools offered by SF.net we will use a blog (wordpress), the wiki (mediawiki) and the SVN, for a start.

The project’s SVN repo will be populated with all components we have developed, as we progressively switch our SVN hosting. The first piece we have committed is the Mantis OSLC REST server module.

It's time to start this blog with an interesting subject: online translation inside CodingTeam. This post is a full introduction to this new feature in the CodingTeam software forge.

As it stands in the release notes for the 0.9.2:

CodingTeam 0.9.2 reintroduces the gettext-based online translation system. It was already in our forge up to the 0.42 but this had disappeared with the full-rewrite of the 0.9. Now, you can easily translate your software online with CodingTeam! The process is simple: you upload a gettext translation model (a .pot file) and then users can translate all your strings in their language. If you already have a gettext translation file (a .po), you can upload it to automatically translate all the strings in the database. When you want to get the translated strings in order to release your software, just export the translation file for all available languages and it's done! And by the way, to prepare the next release, you will import your new .pot file, which will cause the automatical update of your strings database (deleted strings will be deactivated).

This feature is very new and we release it early to get feebacks on this implementation, in order to make it better and better with the time. But here it is, you can now translate your softwares with CodingTeam!

Thus I write this step-by-step howto in order to fully explain this feature, its use and operation to the CodingTeam users and more generally to anyone who may be interested.

Before starting, it is necessary to mention some important points. First, CodingTeam is a software forge, that means that you can do everything to develop your software in one place with varied tools from bugs tracker to source code management. This software can be used, if you have a free software (as in freedom) project, on the CodingTeam.net website!

The method used to implement internationalization (also known as i18n) inside the CodingTeam software forge is based on gettext. It's the GNU library for internationalization and localization. gettext is somewhat a de facto standard to develop multilingual programs. The use of this library is very simple. Programmers put their strings in the gettext function (commonly aliased _). Then, they run xgettext that generates a .pot file wich is a template (it means that this file contains the list of translatable strings extracted from the sources). Afterwards, the translator derives a .po file from this template with msginit or msgmerge and the translation is made in this file. He just send it back to the developer who uses msgfmt to generate a .mo file wich is a binary. These binary files will be used by the program.

With CodingTeam, all the translation work can be made online. The fact is that a lot of people are unwilling to use gettext. Therefore in the context of free software, an easy-to-use appliance can only increase the number of translators who will contribute to your project! And, in an enterprise, it's just necessary to save time.

First step: upload a .pot file.

Just click on the "Administration" link to enter the panel and select your base language.

If you're going to import a template of translatable strings of your programs currently written in English, thus your base lang is English. Just import this file and you're done, strings are now ready to be translated.

English is now hidden in the list of the internationalization homepage. This is because you won't translate strings that are already translated!

Second step: upload a .po file.

Now, you can import an existing translation files if you have it. Just fill this form and this language will be updated.

It's useful in order to maintain on a CodingTeam forge the translation that you've already started elsewhere. The .po import is designed for that and for prehistoric animals that still contribute to translation without using online interfaces.

Third step: translate a string.

The third step is the most interesting of all. Here is the translation string view:

You can see the string that you have to translate and the current proposed translation. If you are registered on the forge, you can add your own proposition (and tag it as translation, correction or reformulation). You can also see where this string is located in the sources (file and line number), this kind of information can be very useful to understand the meaning of a sentence taken out of context.

And below you have the revision history for this translation. Indeed, CodingTeam's internationalization system works as a sum of suggestions, the last one is the translation that ends up being used. Thus, to limit abuse, administrators can delete any suggestions.

When someone contribute to translations, this work is shown in the project's timeline (and therefore in the dashboards). You can also get (through this timeline's entry) a summary of all translation work made in a day by all translaters on all languages.

Fourth step: export a .po file.

Once translation work is finished, you can export the translated .po files. You will just have to compile .mo files from them.

Well done!

Well, you know everything you should know about CodingTeam's online translation system!

But, as I said in the release notes, this feature is very new. It lacks a lot of functionality and can be improved by the time. Some of the needed (and planned!) things to make this internationalization system better are:

• linking the source code repository and the internationalization system (update on commit, build and commit translation files…)
• handling plural forms

If you have another great idea, feel free to write it here!

Richard Matthew Stallman defines the free software by those 3 words :

Liberty, Equality, Fraternity (In french in the text: “Liberté, Égalité, Fraternité” which is the national motto of France). Present in Grenoble on Thursday, January 19th, without paper and in a fluent French, he presented the philosophy and the issue of the free software. Notice that Stallman is the free software father, founder of the GNU project and an outstanding evangelist of his philosophy. Evangelist is the right word:

he doesn’t hesitate to caricature his personality wearing monastic scapular and halo to close his show.

Therefore, during around two hours, Richard Stallman gave us his famous three words definition of the free software, defined the 4 fundamental freedoms (freedom to use the software, freedom to study the source code, freedom to redistribute copies, freedom to improve the program), explained how the proprietary software (sorry, user-subjugating

software!) are evil and addressed related issues like GNU/Linux, Hadopi or the free software at school. At the end, Richard Stallman presented himself as Saint IGNUcius and the guru accepted to answer the public questions.

Codendi, as a free software, had to be present at this talk. A reminder of the fundamentals by such a man of principles could not be a bad thing and allows us to strengthen our vision of the software evolution.

Have you participated to the conference? What are your thoughts about it?

PS: You can find some videos of his talk (FR) on the web.

Ces trois mots définissent la notion de logiciel libre selon Richard Matthew Stallman. Présent à Grenoble jeudi dernier, sans notes et dans un français tout à fait correct, il a présenté à son auditoire la philosophie et les enjeux du logiciel libre. Il faut rappeler que Stallman est le père du logiciel libre, fondateur du projet GNU et évangeliste hors pair de sa philosophie. Évangéliste est le mot : il n’hésite pas à caricaturer sa personnalité en enfilant toge et auréole pour clôturer son show.

Ainsi, pendant près de deux heures, Richard Stallman nous a présenté sa fameuse définition en trois mots du logiciel libre, a défini les 4 libertés fondamentales (liberté d’utiliser le logiciel, liberté d’étudier le code source, liberté de distribuer et liberté de contribuer), a expliqué en quoi les logiciels propriétaires (pardon, privateurs !) sont le mal et a abordé différents thèmes liés comme GNU/Linux, Hadopi ou encore le logiciel libre à l’école. Enfin après la présentation de Saint IGNUcius, le gourou a bien voulu répondre aux questions du public.

Codendi, en tant que lociciel libre, se devait d’être présent à ce discours. Une piqure de rappel par un homme de principe sur les fondamentaux ne fait pas de mal et permet de prendre du recul et d’asseoir la vision à long terme du chemin que doit garder la solution.

Avez-vous participé à la conférence ? Qu’en avez-vous pensé ?

PS: Pour ceux qui ont trouvé une bonne excuse pour ne pas y aller, on peut trouver des diffusions vidéos de son discours sur le net.

Le projet COCLICO invite les développeurs et utilisateurs de FusionForge à se retrouver à Issy les Moulineaux (France) le 3 février 2010 pour une journée destinée au travail technique sur ce logiciel.

Pour plus de détails veuillez vous référer à l’annonce en anglais : FusionForge developers/users meeting coming up, notamment pour les détails sur le contact des organisateurs.

OSLC-CM V1 is a proposed standard for REST APIs of bugtrackers, and in our seek for more interoperability in the bugtracker space, we’ve been very interested in it.

OSLC-CM is quite young and only so far implemented in proprietary tools (although elaborated in an open way) on the server side, and as we believe in FLOSS, we’ve started trying to implement basics of server side plugins for a few bugtrackers.
In addition to a demo server that’s simulating the behaviour of a bugtracker, we have started implementing a Mantis plugin and FusionForge and Codendi trackers add-ons (all PHP and based on Zend framework, see this project on picoforge). All are very basic, but we hope they will be the basis for future OSLC-CM compatible servers in these tools.

At the same time we’ve been experimenting with the code already published in Mylyn to support OSLC-CM on the client side. Not everything is public yet in Mylyn, as the elements that have been developped for some connectors of Tasktop to the proprietary tools are being ported to the open source code of Mylyn.
We have thus been able to use the Junit tests classes of Mylyn and tweak them in a way to connect to an instance of the demo server for Mantis (including handling some Basic auth), and be able to retrieve the first bugs descriptions

Now that this works, we’ll try and add some Java code (maybe reusing Mylyn client libs) to doc4 (being developped as part of Helios) in order to start linking doc4 and Mantis so that this can be used in the Helios platform. This may involve mixing code of XWiki and Mylyn… hmmm… well, we’ll see.

Next steps may be also to try and implement a connector in Python that might be used in tools like bts-link.

Then whichever Python or Java client libraries we have, will allow us to use them inside FetchBugs4.me to connect and harvest bugs of OSLC-CM compliant bugtrackers eventually.

Lots of interesting developments ahead. Stay tuned.

OSLC-CM V1 is a proposed standard for REST APIs of bugtrackers, and in our seek for more interoperability in the bugtracker space, we’ve been very interested in it.

OSLC-CM is quite young and only so far implemented in proprietary tools (although elaborated in an open way) on the server side, and as we believe in FLOSS, we’ve started trying to implement basics of server side plugins for a few bugtrackers.
In addition to a demo server that’s simulating the behaviour of a bugtracker, we have started implementing a Mantis plugin and FusionForge and Codendi trackers add-ons (all PHP and based on Zend framework, see this project on picoforge). All are very basic, but we hope they will be the basis for future OSLC-CM compatible servers in these tools.

At the same time we’ve been experimenting with the code already published in Mylyn to support OSLC-CM on the client side. Not everything is public yet in Mylyn, as the elements that have been developped for some connectors of Tasktop to the proprietary tools are being ported to the open source code of Mylyn.
We have thus been able to use the Junit tests classes of Mylyn and tweak them in a way to connect to an instance of the demo server for Mantis (including handling some Basic auth), and be able to retrieve the first bugs descriptions

Now that this works, we’ll try and add some Java code (maybe reusing Mylyn client libs) to doc4 (being developped as part of Helios) in order to start linking doc4 and Mantis so that this can be used in the Helios platform. This may involve mixing code of XWiki and Mylyn… hmmm… well, we’ll see.

Next steps may be also to try and implement a connector in Python that might be used in tools like bts-link.

Then whichever Python or Java client libraries we have, will allow us to use them inside FetchBugs4.me to connect and harvest bugs of OSLC-CM compliant bugtrackers eventually.

Lots of interesting developments ahead. Stay tuned.

News is slow this month on the FusionForge development front. We're all busy gathering all the things that we want to go into the next release, but there's no big news from the code. However, there is something of interest.

You may have heard about the Coclico project, which is an initiative aiming at collaboration and convergence between several forge engines, most notably FusionForge, Codendi and Novaforge. That project was started last October, and it holds regular meetings with its members. The next meeting is scheduled for the 2nd of February in Paris, and we thought we could host an open meeting on the 3rd for non-Coclico members, a bit like the forge meeting we had last year (which is when FusionForge was officially born), but with an emphasis on what Coclico did so far. Since most of the FusionForge hackers are in Western Europe, and several are in Paris (especially if we add those who go to Paris for the Coclico meeting), we thought it would also be a good opportunity to gather for a technical and social meeting.

It seems the Coclico open session didn't generate much interest this time (at least, it hasn't so far), so I proposed to hijack the room for this FusionForge meeting, and I didn't hear any objections. I have several themes I'd like to discuss with people, and possibly start implementing during that day:

• database maintenance and schema: unification of the upgrade scripts (including for plugins), cleanup of obsolete stuff, addition of missing constraints, and so on;
• configuration system: my initial prototype didn't raise many objections (at least in its scope), now what to do with the next steps?
• packaging and installation system: what needs to be done to keep the three ways of installation (manual, *.deb, *.rpm) in sync with as little work as possible?
• permissions system: clarification of what happens currently, ideas for evolution;
• plugins and interaction with external software: do we lack stuff that would make this easier?
• roadmap, long-term plans, this sort of things;
• other things that users may want to discuss with hackers?
• possibly drink a beer or two;

…and so on. These are in no way specific to FusionForge, and in fact I think it would be great if hackers/users of other forges were present, because we could benefit a great deal from their experience and plans. But if we find ourselves amongst FF people only, I think these would be good to discuss, possibly write some code for, and go home with a clearer picture of where our efforts should focus in the near future.

I'd therefore like to invite interested people to mark the 3rd of February on their agendas. The meeting will take place in Issy-les-Moulineaux (near Paris, within reach of the tube). If you're interested, please get in touch with us (#FusionForge on the FreeNode IRC network, or the fusionforge-general mailing-list), so we can have a rough estimate of how many people to expect. The meeting room is provided by France Télécom, and they're probably going to need numbers if not names. Further details will be announced when known.

Alright, here is the first post on the CodingTeam blog!

To celebrate this new release (and this new year), I open this blog. This will not contain releases notes, there is already the project news for that. So, let me explain the goal of this blog. It's intended to be a place for the CodingTeam community (formed by users and administrators) to get news about the project and where they will be able to participate in the future of the project, by writing their advices on the posts. This will also be a place where people will find informations and news about the project.

This blog will be updated monthly with subjects related to CodingTeam or the software forges in general, so you don't have to know everything about CodingTeam in order to read this blog. This blog will also speak about projects that use CodingTeam, in a "Project of the Month" category. By the way, if you are using CodingTeam for your project(s), feel free to contact me!

The releases notes of the new 0.9.2 release can be found here and you can download it here.

Thus, the appointment is made! See you soon.

L’année 2009 a été riche en évènements pour Codendi :

- la création de notre site communautaire Codendi.org en juin donne accès à chacun au code source de  Codendi Labs, afin que tous puissent contribuer au développement de Codendi et échanger sur son utilisation. Elle accompagne la sortie de Codendi 4.0 et ses nouvelles fonctionnalités :

• l’intégration continue avec Hudson,
• le système automatique de références croisées,
• les tableaux de bords projets/personnels,
• l’extension du système de permissions.

- la mise en place du projet Coclico en partenariat avec d’autres acteurs tels l’INRIA, Bull, Orange Labs qui a démarré le 1er octobre. Il vise à renforcer la dynamique autour des plates-formes de forges, indispensables pour le développement collaboratif de logiciels, et notamment en permettant un échange de réflexion sur les différentes forges et une optimisation des fonctionnalités pour une utilisation industrielle et de meilleure qualité.

- Notre rencontre au sein de l’Agile Tour avec d’autres acteurs pour échanger sur les pratiques optimales en termes de méthodes agiles, et comprendre comment développer au mieux Codendi pour faciliter son utilisation dans le cadre d’application de ces méthodes.

- La certification de nos 2 collègues, Nicolas Terray en PHP avec la Certification Zend PHP 5, et Marc Nazarian ScrumMaster en méthode Agile de type Scrum démontre l’intérêt de nos équipes pour se perfectionner dans des domaines de développement de projets logiciels, ce qui contribue à la qualité du niveau de support et de développement de l’équipe Codendi.

Grâce à ces évènements, notre équipe est toujours au plus près de vos besoins pour vous apporter des services adaptés d’installation, de formation, de maintenance et de support via Codendi Pro.

Nous poursuivrons en 2010 cette recherche de qualité de services en renforçant notre partenariat initié fin 2008 avec SupInfo dans l’accompagnement des étudiants à la gestion de projets, en proposant une nouvelle offre hébergée, et avec la version Codendi 4.2 prévue pour le printemps 2010 notamment.

D’ici là, je vous souhaite de bonnes fêtes de fin d’année, en vous remerciant de nous suivre dans l’aventure qui voit grandir Codendi chaque jour…

Pour mon premier billet sur ce blog, je voulais vous raconter une petite histoire qui est arrivée il y a quelques semaines, lors de notre dernière itération.

Il était une fois …

Quand nous avons décidé de réécrire le moteur des trackers, nous avons voulu essayer le Test Driven Development (TDD, ou Développement Piloté par les Tests en français).

Nous appliquons Scrum dans l’équipe depuis pas mal de temps. Bien que le TDD ne soit pas obligatoire dans Scrum (il est plutôt conseillé dans la méthodologie XP), il n’est bien sûr pas interdit !

Depuis la dernière version de Codendi, l’intégration continue avec Hudson est proposée et intégré dans la plateforme.

Nous avions donc déjà toutes nos branches de support et de développement sous intégration continue (voir la copie d’écran).

On se lance !

Tout était donc prêt pour commencer notre expérience du TDD. Nous avons choisi de faire du TDD en pair-programming, parce que c’était quelque chose d’assez nouveau pour nous. On faisait donc d’une pierre deux coups : essayer le TDD et essayer le pair-programming en même temps.

Au départ notre objectif était double :

• faire émerger le design par les tests

• avoir des tests unitaires.

Nous ne savions alors pas que ces quelques graines semées allaient nous donner une aussi bonne récolte !

+106 %

Tout d’abord, nous avons augmenté le nombre de tests de manière significative, ce qui est une bonne chose pour les clients, mais également pour l’équipe de développement. Notre logiciel devient de plus en plus robuste !

Nous avons augmenté les tests de +106% (de 197 tests au départ sur les trackers à 407 aujourd’hui) et ce n’est pas fini !

L’essayer, c’est l’adopter !

Deuxièmement, c’était plutôt amusant ! Et nous avons constaté avec surprise que ça a donné envie aux autres membres de l’équipe d’essayer. Ainsi le TDD a rapidement été adopté par l’équipe qui travaille sur le workflow, et celle qui travaille sur Git (un système de gestion de code source décentralisé).

Mais il y a un autre bénéfice que nous n’avions pas vu venir : cela a renforcé l’esprit d’équipe. Les gens étaient vraiment contents de travailler ensemble, et tout le monde se sentait concerné par les tests unitaires, et par la bonne santé du build Hudson.

On continue dans la bonne direction

Nous alloons donc continuer nos efforts dans ce sens, et faire de la prochaine version 4.2 un succes.

Et vous, avez-vous des histoires similaires concernant le TDD, le pair-programming ou d’autres pratiques agiles ?

Si oui, n’hésitez à les partager avec nous !

For my first post on this blog, I’m going to tell you a short story that happened a few weeks ago, during our last iteration.

Once upon a time…

When we decided to rewrite our tracker engine, we experimented Test Driven Development (TDD). TDD is not a required practice in Scrum, but it is not forbidden at all!

Since the last Codendi release, continuous integration with Hudson has been integrated in our platform.

We already had all our support and development branches under continuous integration (see screenshot).

Let’s start!

So everything was set up for a great Test Driven Development experience! We chose to try TDD with pair-programming, because it was quite a new thing for us, so we had two birds with one stone: two people experiencing TDD and pair-programming in the meantime. At the beginning, there was two identified goals:

• see the design emerge from the tests

• have unit tests

What we did not know at this time, was that our small seed would generate amazing benefits!

+106 %

First of all, we increase dramatically the number of tests of the platform, which is a really good news for both customers and development team. The software becomes gradually more robust.

We increase the number of tests by +106% (from initially 197 tests on trackers up to 407), and it is not finished!

Try it, adopt it!

Moreover, it was fun! And surprisingly, it incited other team members to try it. So TDD spread to the team that was working on workflow, and the one working on distributed version control Git.

Another thing we did not see coming was that it strengthened the team spirit. People were really happy to work together, and everyone was concerned about the unit tests, and the Hudson build.

Keep up the good job

So we will definitely keep going that way, and make our next release 4.2 a great success.

And you, do you have similar stories with TDD, pair-programming or agile practices?

We’re working on implementing a demo/test server for the OSLC-CM V1 protocol, in order to help test client tools.

We’ve released (under a BSD license) a first 0.1 preliminary version that only supports GET queries, that’ll lead the way to an expected complete demo server of OSLC-CM V1 when the 1.0 version will be finished.

At the moment, it will only provide a minimal REST implementation of a PHP server using zend, and will produce JSON or XML/RDF views of fictionnal bugs contructed out of contents of a CSV file.

More details may be found at : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/, whereas the code is in the Download page there.

FusionForge-4.8.2: * Maintenance release, security and bugfixes.

From Monday 30^th November, it’s Fedwa who backs up the marketing activity for a few months. Indeed, Manon has a more personal project to achieve as she’s awaiting a happy event for the beginning of next year. She hands over to Fedwa who will animate notably the website and other internet tools. Of course you can get in touch with her for any questions or remarks about Codendi and if you want to share news about open-source: fedwa.jebbor@codendi.com

 

« Hello to everybody. Thanks for welcoming me and see you soon to share our experience about open-source and Codendi.» Fedwa

 

« See you soon… » Manon

A partir de Lundi 30 Novembre , c’est Fedwa qui va reprendre l’activité marketing pour quelques mois. En effet, Manon a un projet plus personnel à accomplir puisqu’elle attend un heureux événement prévu pour début d’année prochaine. Elle passe le relais à Fedwa qui va poursuivre notamment l’animation du site web et des outils internet. Bien entendu, vous pouvez prendre contact avec elle pour toutes questions ou remarques concernant Codendi ou si vous souhaitez partager une actualité sur l’open-source : fedwa.jebbor@codendi.com

 « Bonjour à tous. Merci de m’accueillir et à très vite pour partager notre expérience autour de l’open-source et Codendi.» Fedwa

 

« Je vous retrouve bientôt… » Manon

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 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.