On 8/29/06, Frank Buss <[EMAIL PROTECTED]> wrote:
> Justin Heyes-Jones wrote:
>
> > The advantages are the obvious reliablity (both uptime and speed) of
> > google infrastructure. (I've noticed a lot of downtime and slowness on
> > sourceforge.) The bug (or issue) tracking is very simple, very
> > visible, and easy to use.
>
> Sourceforge has sometimes problems, but most of the time it works. But I
> don't care, where the repository is, and you may be right that Google is
> more reliable.
>
> > Downsides are that there is no release mechanism for easy download.
> > Casual users may be put off by having to use subversion to get a
> > release. Yet theres nothing stopping us putting an automatically
> > zipped up release in the subversion database which can then be linked
> > to in their web site.
>
> I don't like the idea of storing release packages in SVN. But we could still
> use the Sourceforge file release system (with the worldwide mirrors it
> should be reliable) and the SVN-repository of Google. So if there are more
> people who thinks it is a good idea to move to Google, feel free to commit
> all files to the Google repository, then delete all files from the
> repository at Sourceforge and add a new readme file, that says that the
> current repository is at Google now.
>
> The Google system looks very spartanic (in contrast to Sourceforge, which
> looks very bloated), maybe we should suggest to Google to add a file release
> system?
>

OK let's do it then. Over the next couple of days I'll set up a google
project and move over the subversion database. As you say there is no
reason why we shouldn't continue to use sourceforge for releases.

I think it would be useful to add bugs and ideas for new features to
the google projects issues database; it's very easy to use.

Justin
_______________________________________________
application-builder mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/application-builder

Reply via email to