[Savannah-dev] Re: Savannah development at CERN (+please introduce version tagging)

[Derek FEICHTINGER]

Hello, Mathieu

thanks for your prompt reply

> CVS and patches:
>
>         As said previously, we are open to any suggestions. I did not
>         know that the lack of tags was creating such troubles to
>         you. We have nothing against tagging frequently the CVS,
>         despite the fact that the need was not so obvious to us
>         currently.
>
>         As you seem to be working a lot on the Software, it may even
>         be more appropriate to grant you CVS write directly.
>
>         Tell us.

sorry, Mathieu. We were not aware that this information had not been passed on 
to you. We had talked this over with Jaime in Febuary and we had thought that 
he had communicated it to you (we even had defined a list of items and data 
base additions and Jaime set up an agreement).

Jaime also told us, that we would be sent forms, in which we should declare in 
written form to put all our extensions under the GPL before giving us access 
to your CVS. We have been waiting for these documents since Febuary 
(shouldn't it be enough for me to put the usual GPL header in my code in 
order to place it under this license? Did all of you have to sign up in this 
way to contribute code?). We would very much have liked to directly commit 
our stuff. It's a pity, because now Frederik and I will be moving on to other 
projects (we had not been hired for this) while another colleague will take 
over the CERN Savannah installation. But as I said, we would very much like 
to commit our stuff back.

The tagging (and maybe also the creation of development branches) might be a 
good thing, because one may not want to include experimental stuff in the 
active version, and as I understand it, your active version is currently 
synchronized from the CVS head. With a development branch departing from the 
production version tagged main branch you can easily commit bug fixes to the 
production branch, while having a separate area for development efforts (this 
is how we usually organize our projects).

This way you, the GNU server administrators, have full control over which 
things really make it into your active version without us other developers 
endangering the functionality of your service (what works for us on our 
RedHat 7.3 based installations may not work on debian).

>         We would like to have a clean database before adding new
>         fields, and we know that new fields would be required (propose
>         us which one you want).

Thanks for the offer (actually our suggestions also had been in the draft that 
we prepared with Jaime. It seems to have been lost). After the feedback of 
the last few months from our users we even have further additions. Maybe it's 
best to post them here on the mailing list, so everybody can put forth his 
ideas. We will prepare a list of our suggestions together with explanations.

>
>         I think that we should keep at any cost a common database.

Yes. This was also one of our major aims. Also a change of the data base 
should not be done frequently. It would be much better to have some 
discussion with everybody now, and then do it in one step. There may be other 
installations with requirements we are not aware of and they should be heard. 
Scripts to migrate the current DB structure to the new structure could be 
provided, so existing installations need not worry about the conversion. But 
we have a lot of pressure from our users to include the required 
functionality soon.

>
>         Obviously, the mailing-list software support in Savannah
>         should be modular. That way, it should be able to work with
>         both mailman and majordomo.

I agree. 

We think GNU Savannah is a good system and it would be wonderful to see more 
installations to insure that there will be a continued interest in it.

Cheers,
Derek




> Derek FEICHTINGER <address@hidden> a tapoté :
> > Hi,
> >
> > at  CERN we have been using GNU Savannah with quite some success and I
> > notice from emails to our site that also other institutes visiting our
> > site are getting very interested in the software.
> >
> > Since the structure here at CERN demanded some special solutions we were
> > forced to adapt Savannah to our circumstances. As mentioned on previous
> > occasions we would like to donate them back (or find together some other
> > solutions) but since the current Savannah CVS repository utilizes no
> > versioning scheme (no CVS tags) this is rather difficult. Without tags it
> > is also difficult to provide patches because you always have to refer to
> > a running target. Because we could not afford the time to continually
> > update to the current GNU Savannah CVS and constantly reimplement our
> > extensions, we were forced to branch off.
> > (Note: The last sync with GNU we did on January 17th 2003)
> >
> > People from the other institutes are now starting to ask for our version.
> > I think it would be sad to split the development effort off the Savannah
> > community in that way, so we would like to make another effort in
> > commiting our stuff back.
> >
> > Our current extensions are:
> >
> > - PAM based user authentication (which fits in with the AFS
> > authentication system)
> > - simpler user management system: Users can sign up for a project and get
> > for that project a pending status. The project manager is then notified
> > and can decide to make them active users by picking the names from list
> > boxes. - possibility for project admins to do user management through
> > submitting a batch file (this is very useful for signing up lots of
> > people to a project. The current Savannah interface requires the admin to
> > type all the names). - The CVS address is now a per project property,
> > because many of our hosted projects already had an own CVS with own
> > implementations of access restrictions. We did not want to force our
> > customers to use our central repository.
> > - Mailing lists in our version needed to work with majordomo instead of
> >   GNU mailman (we would have liked to use Mailman but the CERN mailing
> > lists are based on majordomo).
> > - Some enhancements to the FAQ system, but the solution still not fully
> > satisfactory (Still, each project now can store the FAQ in its download
> > area, and specify the order in which the items are listed.)
> > - we fixed many minor bugs which caused problems when the installation
> >   was not located in the root directory of the webserver.
> >
> > On the CERN Savannah server there are now 57 projects, and we receive a
> > lot of feature requests. In order to implement some features we will need
> > to add fields to the data base tables and this will branch our version
> > even further off the GNU CVS head version. Before we do this we would
> > really like to make another effort of deciding together with you, the GNU
> > Savannah community, whether there is a possibility in doing some
> > development together.
> >
> > Regards,
> > Frederik Orellana and Derek Feichtinger
> >
> > --
> > Dr. Derek Feichtinger                   Tel:   +41 22 767 26 98
> > LCG/SPI Group                           email: address@hidden
> > CERN                                   
> > http://people.web.psi.ch/feichtinger CH-1211 Genève 23
> >
> > _______________________________________________
> > Savannah-dev mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/savannah-dev

-- 
Dr. Derek Feichtinger                   Tel:   +41 22 767 26 98
LCG/SPI Group                           email: address@hidden
CERN                                    http://people.web.psi.ch/feichtinger
CH-1211 Genève 23