Re: [Savannah-hackers] Savane news

[Sylvain Beucler]

I guess I can publish the news item and continue to filter bug requests  
at project savannah.

The current installation is indeed the CERN branch plus a number of  
changes in and out of the repository, permanent or temporary.

However, Paul just sent a status report with, among others, the  
following:
* Started initial discussions regarding the database structure of the
 current Savannah installation and the effort that will be required
 to transition from those structures to the ones used in GForge.

I though Savane would be better for upgrading Savannah, since it is  
made by the same people, who know Savannah's architecture, and who are  
willing to make a product that fits the needs (see below).

Besides, managing dual websites (sv.[non]gnu) and other GNU-specific  
features may require local changes to GForge, which will lead to the  
current situation: working with a codebase, with contains bugs that are  
already fixed, but that we cannot update because it would break our  
changes.

What are the points in using GForge instead?

--
Sylvain


Vincent Caron wrote:
> Sylvain Beucler wrote:
> > I saw a news item from Mathieu for project 'savannah' about the new   
> > location of project 'Savane'. Do you think we should put it on the  
> > main  page? Maybe it would make people stop reporting Savane bugs at  
> > the  'savannah' project.
>
>   The trick is that from a CVS point of view, the trunk of Savane is  
> the famous DEV_2003-09-05_CERN branch from Savannah, as if this  
> branch had been merged back to the trunk before the security overhaul  
> from Paul & Jim (start of December 2003).
>
>   In other words, what's installed on Savannah is out of sync, and it  
> might generate reports on bugs already fixed in Savane.
>
>   I'd like to check precisely what's missing in Savane in order it  
> could run Savannah as it is of today. As far as I know, the only non  
> backward compatible move on Savannah is the per-group chrooting  
> model. On Gna, we have chrooted services and kept the backend  
> compatibility. We could start to work on this, reconciliating both  
> security models.