On 6 Feb 2001, Marcus Sundberg wrote:
> [EMAIL PROTECTED] (Christoph Egger) writes:
>
> > 4 February
> > - Added ML
>
> Seems they have at least added the possibility to view an entire thread
> in their list-archive, so you will not have to walk over my dead body
> to put any mailing lists at Sourceforge... Still there's no point in
> having a link to zero mailing lists.
The reason of that decision is:
http://sourceforge.net/docman/display_doc.php?doc_id=772&group_id=1
> > and CVS to SF by Andy
>
> As long as the CVS repository doesn't even exist it's just confusing
> to have a link to it.
Well, _we_ have to set up a tarball containing our sources at
first. Then we can import it.
Jon and some others want to clean up the directory-tree. He said:
-----------------------------------------------
Yeah. If/when we move our CVS to SourceForge, the libggi2d
directory should be dropped. Actually, maybe we should use such a
CVS move to reorganize our whole CVS tree, which is now over three
years old and filled with cruft and deleted directories. We could
split GGI/GII, KGIcon, and each extension library off into their own
separate SF projects, to reduce the size of snapshots and such. I
already did this for LibGGI3D once upon a time....
-----------------------------------------------
We are going to do this:
---------------------------------------------------
> SF supports a module-concept. Just think of KGI-0.9: It has three
> modules: kgi-0.9, tools and html. We should do so for each
> extension as well as create a new task at SF for each extension.
exactly. It's basically about releases. I would think that as long as
there is a lot of interdependency the different parts should stay in
the same project. However, they could become separate modules in cvs,
as well as separate packages for releases.
---------------------------------------------------
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
