[En-Nut-Discussion] SF's anonymous CVS problem

[Theodore A. Roth]

On Fri, 17 Oct 2003, Harald Kipp wrote:

>
> >Would the developer(s)/contributor(s) kindly like to make & export a weekly
> >"test-release" for those of us who can't get the latest full CVS nut to
> >the EtherNUT
> >web site?
>
> As far as I understood, SF got serious problems with their
> server loads and moving the anonymous access to different
> mirror sites.

I'd say that's bit of an understatement. ;-)

For the avarice project, I've set up a cron job running on sf which
does a daily checkout from anon-cvs, tarballs it up and makes it
available via the download area. I think this still has the anon-cvs
lag, but it side-steps the problems with anon-cvs being in-accessible.

I can make my script available if desired.

A better improvement would be to move the cron job to my local system,
do a clean checkout as a developer, filter the CVS/Root files to
look like an anon checkout, then tarball and scp back to sf.

>
> Today I'd prefer http://savannah.gnu.org/, but this would
> require some extra work and there are more important tasks
> to be done.

They have their own problems on savannah since they are all
volunteers, but so far they've been very responsive when I've had
problems.

>
> I'll try to create regular snapshots. But currently I'm
> the only maintainer of the repository and very short in
> time. As the project is growing, I'd like to extend the
> Sourceforge developer access to the CVS repository.
> However, I must admit, that I'm already struggling with
> the complicated system and would need some help to set
> this up.
>
> One additional comment: I do not know the number of
> people using Nut/OS, but it increased a lot within this
> year. In order to avoid breaking existing systems, it is
> important to move forward very conservative. Also, many
> contributers do not have access to the ImageCraft Compiler
> and ignore certain porting issues, e.g. PSTR(). Therefore
> my company is prepared to be the final approval instance
> for official releases.

You might want to try something like they do with gcc/binutils/gdb.
All maintainers have "commit after approval" for any file in cvs.
Maintainers of specific areas/files can commit without approval (e.g.
I can only do this for the avr-tdep.c file in gdb). In all cases,
committed patches _must_ be posted to the *-patches mailing lists,
either for approval if needed or after a commit.

I'm not trying to say the GNU folk's way is the "one true way", I'm
just using it as an example since I'm familiar with it. There's a lot
of ways you can handle this. As long as you codify the "rules of
conduct" up front, things should go fairly smoothly. If someone breaks
the rules, it's easy enough to revert a patch and either warn them or
take away commit access. I think everyone would agree that Harald
would retain ultimate veto power since he (mostly) started all this,
has been so kind to share and knows the system very well.

Ted Roth