clisp-devel

sourceforge miseries

[Bruno H. <br...@cl...>]

mercurial access to sourceforge is highly unreliable these days again:

$ hg in
comparing with ssh://ha...@hg.../p/clisp/clisp
^Cinterrupted!
$ hg in
remote: abort: there is no Mercurial repository here (.hg not found)!
abort: no suitable response from remote hg!
$ hg in
comparing with ssh://ha...@hg.../p/clisp/clisp
searching for changes
no changes found
$ hg push
pushing to ssh://ha...@hg.../p/clisp/clisp
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: abort: Transport endpoint is not connected
remote: transaction abort!
remote: rollback failed - please run hg recover
abort: unexpected response: empty string

And no report at https://twitter.com/sfnet_ops.

This is not the first time the hg server at sourceforge is acting miserably.

To me, this increases the priority of moving the source code repository
away from sourceforge.

We can consider the following options:

  a) Move it to savannah.gnu.org (yes, savannah supports hg, see
     http://hg.savannah.gnu.org/hgweb/?sort=lastchange ),

  b) Convert it to git and move it to savannah.gnu.org.

  c) Convert it to git and move it to gitlab.com.

Discussion:

- Advantage of a): Less work, can be realized in a short time frame.

- Advantage of b), c): Reduce the entry barrier for young developers
  (they all know how to use git, but hardly anyone uses mercurial).

Bruno

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

I wrote:
> This is not the first time the hg server at sourceforge is acting miserably.

And it's not just hg. Looking at the pending support requests [1] there are
several similar ones for 6 days:
  - Svn does not work again
  - svn is awfully slow since the upgrade to the new server backend
  - issues accessing https:/​/​svn.code.sf.net/​p/​gexperts/​code/​trunk
  - Svn unreliable
  - svn commits very very slow
  - svn commit fails
  - git push broken ?
  - Gateway timeout
  - Is there some problem with speed of commits?
  - Gateway Time-out
  - Is the Git service down?
  - Error on SVN checkout: 504 Gateway Time-out (https:/​/​svn.code.sf.net)
  - Subversion SVN Not Working Properly - Commits Timeout - Project Page is Broken
  - unable to use svn merge anymore, very slow svn access

And I can't get a shell to sourceforge, to execute the "hg recover" command:

  $ ssh -t ha...@sh... create

  Waiting for your shell to start.
  queued... 
  The shell did not start -- aborting.

  Connection to shell.sourceforge.net closed.


Bruno

[1] https://sourceforge.net/p/forge/site-support/search/?q=status%3A%28unread+pending+assigned%29

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

I wrote:

> And I can't get a shell to sourceforge, to execute the "hg recover" command:
> 
>   $ ssh -t ha...@sh... create
> 
>   Waiting for your shell to start.
>   queued... 
>   The shell did not start -- aborting.
> 
>   Connection to shell.sourceforge.net closed.

The documented way to get a backup [1] failed:

  $ rsync -av hg.code.sf.net::p/clisp/clisp .
  receiving incremental file list
  rsync: connection unexpectedly closed (8 bytes received so far) [Receiver]
  rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]

But I could get a backup this way:

  $ ssh ha...@sh... tar -C /home/hg/p/clisp -cf - clisp > clisp-hg.tar

With this, I'm ready to move the repository.

Bruno

[1] https://sourceforge.net/p/forge/documentation/Mercurial/

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

>   $ ssh -t ha...@sh... create
> 
>   Waiting for your shell to start.
>   queued... 
>   The shell did not start -- aborting.
> 
>   Connection to shell.sourceforge.net closed.

Now I got a shell working, and I see that 'hg' on the server is of version
2.6.2, from 2012. Since then, there have been 6 CVEs with code execution in
hg. [1][2]

With that shell, I could do the "hg recover". But please, don't "hg push"
anything until further notice!

Bruno

[1] https://www.cvedetails.com/product/14386/Mercurial-Mercurial.html?vendor_id=8291
[2] https://www.cvedetails.com/vulnerability-list/vendor_id-8291/Mercurial.html

Re: sourceforge miseries

[Jean L. <bu...@gn...>]

Hello,

I must say that not convenient and on the other
side also good, as it could at least be hosted on
GNU.

Gitlab while way better than Sourceforge is
commercial and there is again dependency with
people and future company changes. Who knows who
is going to be taken over by whom and what changes
are to come.

FSF is for free software and it is a foundation,
and has really no commercial tensions. It provides
Mercurial and it provides git.

I am voting (without voting rights) that it is
hosted on GNU servers for better marketing of
CLISP and without any advertising. CLISP is
popular part of GNU system as well.

And process may be done gradually, first mercurial
transfer to GNU servers, then gradually git if
that is deemed to be the best for developers.

On Mon, Apr 09, 2018 at 11:32:46AM +0200, Bruno Haible wrote:
> And no report at https://twitter.com/sfnet_ops.
> 
> This is not the first time the hg server at sourceforge is acting miserably.
> 
> To me, this increases the priority of moving the source code repository
> away from sourceforge.
> 
> We can consider the following options:
> 
>   a) Move it to savannah.gnu.org (yes, savannah supports hg, see
>      http://hg.savannah.gnu.org/hgweb/?sort=lastchange ),
> 
>   b) Convert it to git and move it to savannah.gnu.org.
> 
>   c) Convert it to git and move it to gitlab.com.
> 
> Discussion:
> 
> - Advantage of a): Less work, can be realized in a short time frame.
> 
> - Advantage of b), c): Reduce the entry barrier for young developers
>   (they all know how to use git, but hardly anyone uses mercurial).

-- 
Jean Louis

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

Hello Jean-Louis,

Thanks for your input. I appreciate it.

> CLISP is popular part of GNU system as well.
> 
> And process may be done gradually, first mercurial
> transfer to GNU servers, then gradually git if
> that is deemed to be the best for developers.

Noted.

Bruno

Re: sourceforge miseries

[Sam S. <sd...@gn...>]

Hi Bruno,

I moved from cons.org to SF 18 years ago based on similar hardships.
I understand your frustration ;-(

Now that git has clearly won against mercurial, I think any repo move
should include switching to git - no reason to stick with obsolete tech.

>   b) Convert it to git and move it to savannah.gnu.org.
>   c) Convert it to git and move it to gitlab.com.

why not d) github.com?

savannah has had its fair share of failures - security breaches,
hardware faults week-long down times - over the 15 years that we used
it.

just like SF was "all the rage" in 2000 and quite reliable back then, it
seems that github is the most feature-full and reliable source host.

unless ideology is at stake, I see no reason to use savannah.

another question is timing.
I suggest not making a move until 2.50 is released and GSoC is over.
The combination of repo move, release and GSoC may be too much.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://www.dhimmitude.org
http://thereligionofpeace.com http://no2bds.org https://jihadwatch.org
Takeoffs are optional.  Landings are mandatory.

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

Hi Sam,

> I moved from cons.org to SF 18 years ago based on similar hardships.
> I understand your frustration ;-(

Thanks for the condolences.

> Now that git has clearly won against mercurial, I think any repo move
> should include switching to git - no reason to stick with obsolete tech.
> 
> >   b) Convert it to git and move it to savannah.gnu.org.
> >   c) Convert it to git and move it to gitlab.com.
> 
> why not d) github.com?

Github.com has a tendency of establishing a closed universe:
  - You can "fork" a github repo, but on github only.
  - Users can hide their email address; then the only way to contact
    a developer is through an "issue" on github. No way to contact them
    of you are not a github user. No way to write a private email.
  - Issue threads on github cannot be moved to another platform.

With Gitlab, on the other hand, I'm being told that they change the UI
every couple of weeks, adding new powerful features quite frequently.
So far they are not "closed": You can have your main repo (in git)
elsewhere, a mirror repo at gitlab, and run your continuous integration
tests at Gitlab.

> savannah has had its fair share of failures - security breaches,
> hardware faults week-long down times - over the 15 years that we used
> it.

Yes, especially around 2007/2008 there were week-long downtimes. This has
improved a lot since then: In my 5 years of active contributions with GNU
projects since 2009, I haven't encountered an incident worth remembering.

> seems that github is the most feature-full and reliable source host.

I think that both Gitlab and savannah have a good reliability too.
There was one known issue with Gitlab last year [1]; they surely have learned.

> unless ideology is at stake, I see no reason to use savannah.

My reason to use savannah is that it's continuously working fine,
and a familiar environment (same bug trackers as for GNU libffcall,
for example).

10 years ago, when GNU was under firm control of RMS, I would have
disliked to move to savannah as well. Nowadays, the control of GNU is
distributed across several people, who don't show a dictatorship
behaviour.

> another question is timing.
> I suggest not making a move until 2.50 is released and GSoC is over.
> The combination of repo move, release and GSoC may be too much.

I definitely intend to do the move ASAP, that is, before 2.50.
The two won't overlap.

So, my proposal is: Move the hg repository to savannah today (or ASAP),
so that we can continue to work on 2.50 and the GSoc students will not
be interrupted in their work.

The repository conversion for libffcall (from CVS) took me 2 days of work;
I therefore estimate that the clisp repository conversion to git will
take 2-4 days of work too.

Like Jean-Louis says, this can be done after moving off sourceforge.

Bruno

[1] https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

Re: sourceforge miseries

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-04-09 22:49:22 +0200]:
>
>> At any rate, do you also want to move the bug tracker? mailing list?
>
> Not at the moment.
>
> For the mailing lists, such a move can be considered later.
> Advertisements in a mail footer are silly.
>
> For the bug tracker, sourceforge is currently OK (now that we have
> learned how to use ``` ... ``` and `...`).

Note that such a change is fairly expensive - our sources and docs are
littered with bug tracker and mailing list URLs.

When they upgraded the bugtracker, it was a matter of a relatively easy
- but time consuming - editing to fix that.
When gmane http access went down, I had to jump though some ugly hoops
to fix the links (see clisp/emacs/misc.el)

I shudder at the thought of what lays ahead ;-)

>> Yeah, but that bug tracker sucks big time.
>> Even SF is better.
>
> The rich text functionality in savannah's tracker is a bit poor, yes. On
> the other hand, I like the categorization / sorting interface.

gitlab/github uses tags, which is more flexible, I think.

Note that savannah is based on an early version of sourceforge (warts
and all).

During the SF bugtracker upgrade they renamed "category" to "milestone"
instead of tag, with pretty funny results.

>> I am not too familiar with gitlab, but its tracker appears to be more
>> modern.
>
> Surely everything Gitlab has is modern. The worry I have with Gitlab
> is whether it will remain easy-to-use and easy-to-administrate 10
> years from now.

We used SF or 18 years.
I am sure that in 10 years we will have to switch no matter what we
chose now (https://thetyee.ca/Views/2004/03/24/Planning_Six_Centuries_Ahead/).

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://www.memritv.org http://iris.org.il https://jihadwatch.org
The paperless office will become a reality soon after the paperless toilet.

Re: sourceforge miseries

[Reini U. <rei...@gm...>]

I already have a nice git mirror on GitHub, if you need that for conversion.

Sam Steingold <sd...@gn...> schrieb am Mo., 9. Apr. 2018, 23:07:

> Hi Bruno,
>
> > * Bruno Haible <oe...@py...t> [2018-04-09 22:49:22 +0200]:
> >
> >> At any rate, do you also want to move the bug tracker? mailing list?
> >
> > Not at the moment.
> >
> > For the mailing lists, such a move can be considered later.
> > Advertisements in a mail footer are silly.
> >
> > For the bug tracker, sourceforge is currently OK (now that we have
> > learned how to use ``` ... ``` and `...`).
>
> Note that such a change is fairly expensive - our sources and docs are
> littered with bug tracker and mailing list URLs.
>
> When they upgraded the bugtracker, it was a matter of a relatively easy
> - but time consuming - editing to fix that.
> When gmane http access went down, I had to jump though some ugly hoops
> to fix the links (see clisp/emacs/misc.el)
>
> I shudder at the thought of what lays ahead ;-)
>
> >> Yeah, but that bug tracker sucks big time.
> >> Even SF is better.
> >
> > The rich text functionality in savannah's tracker is a bit poor, yes. On
> > the other hand, I like the categorization / sorting interface.
>
> gitlab/github uses tags, which is more flexible, I think.
>
> Note that savannah is based on an early version of sourceforge (warts
> and all).
>
> During the SF bugtracker upgrade they renamed "category" to "milestone"
> instead of tag, with pretty funny results.
>
> >> I am not too familiar with gitlab, but its tracker appears to be more
> >> modern.
> >
> > Surely everything Gitlab has is modern. The worry I have with Gitlab
> > is whether it will remain easy-to-use and easy-to-administrate 10
> > years from now.
>
> We used SF or 18 years.
> I am sure that in 10 years we will have to switch no matter what we
> chose now (
> https://thetyee.ca/Views/2004/03/24/Planning_Six_Centuries_Ahead/).
>
> Thanks.
>
> --
> Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
> http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
> http://www.memritv.org http://iris.org.il https://jihadwatch.org
> The paperless office will become a reality soon after the paperless toilet.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> clisp-devel mailing list
> cli...@li...
> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>

Re: sourceforge miseries

[Jean L. <bu...@gn...>]

On Mon, Apr 09, 2018 at 07:34:54PM +0200, Bruno Haible wrote:
> With Gitlab, on the other hand, I'm being told that they change the UI
> every couple of weeks, adding new powerful features quite frequently.
> So far they are not "closed": You can have your main repo (in git)
> elsewhere, a mirror repo at gitlab, and run your continuous integration
> tests at Gitlab.

There is no reason at all today to relay on
hosting of third party, and if to relay on them,
then why not use GNU servers.

I think with FSF there is no problem to ask them
to give you hosted server for yourself or money
for that. Installing self-hosted Gitlab is matter
of 10 minutes. Just make it how you wish it.

FSF is there to support GNU project, CLISP is part
of it. FSF are people and if money is needed I
will give money that you host it somewhere on free
software, just avoid the github, gitlab.com hosted
and sourceforge.

(gitlab.com hosted is not same as self-hosted
gitlab software)

Host it yourself with gitlab software (free
software edition) or on Gnu servers or elsewhere,
that access to it is totally free and without
non-free Javascript as well.

> 10 years ago, when GNU was under firm control of RMS, I would have
> disliked to move to savannah as well. Nowadays, the control of GNU is
> distributed across several people, who don't show a dictatorship
> behaviour.

Buahaha, was it so? I think he never maintained
any servers himself. The only dictatorship on GNU
is to host free software and support free
software, and everything else may be
discussed with staff at FSF. 

> So, my proposal is: Move the hg repository to savannah today (or ASAP),
> so that we can continue to work on 2.50 and the GSoc students will not
> be interrupted in their work.

That is great news. I welcome that.

Please also include CLISP mailing list into
http://lists.gnu.org that we can get it nicely
archived and accessible, with people and their
names and emails, and here are examples of good
team work:
http://lists.gnu.org/archive/html/emacs-orgmode/

The GNU Guix distribution issues are totally
managed by using mailing list for example.

I am sure that moving CLISP to GNU and to those
mailing lists with GNU is going to get new people
and contributors to CLISP.

I may contribute to CLISP so that we can translate
it to Swahili as well, and then the whole
documentation, and then to present it to
universities in Kenya and Tanzania.

-- 
Jean Louis

Re: sourceforge miseries

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-04-09 19:34:54 +0200]:
>
> With Gitlab, on the other hand, I'm being told that they change the UI
> every couple of weeks, adding new powerful features quite frequently.
> So far they are not "closed": You can have your main repo (in git)
> elsewhere, a mirror repo at gitlab, and run your continuous integration
> tests at Gitlab.

That's how it was with SourceForge 15-20 years ago,
and Savannah started as a clone of SourceForge.
Let's see how long it will take GitLab to close up.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net https://ffii.org
http://think-israel.org https://jihadwatch.org http://no2bds.org
Be sure brain is in gear before engaging mouth.

Re: sourceforge miseries

[Sébastien V. <seb...@de...>]

On Mon, Apr 09, 2018 at 07:34:54PM +0200, Bruno Haible wrote:

> > seems that github is the most feature-full and reliable source host.
> 
> I think that both Gitlab and savannah have a good reliability too.
> There was one known issue with Gitlab last year [1]; they surely have learned.

FWIW, Gitlab has a significant advantage over Savannah: it implements “pull
requests” (similarly to Github), which greatly facilitates contributions.

Also note that a number of free software projects have recently moved to Gitlab
(creating their own instance of the service):

- Debian: http://salsa.debian.org/
- GNOME: https://gitlab.gnome.org/
- the Common Lisp foundation: http://gitlab.common-lisp.net/

OTOH, Savannah has the advantage of being under the direct control of the FSF.
It may offer a greater security for a small project that does not have the
ressources to create its own Gitlab instance.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

Sébastien Villemot wrote:
> FWIW, Gitlab has a significant advantage over Savannah: it implements “pull
> requests” (similarly to Github), which greatly facilitates contributions.
> 
> Also note that a number of free software projects have recently moved to Gitlab
> (creating their own instance of the service):
> 
> - Debian: http://salsa.debian.org/
> - GNOME: https://gitlab.gnome.org/
> - the Common Lisp foundation: http://gitlab.common-lisp.net/

Interesting. This would suggest that it would be useful if GNU had its own
Gitlab instance as well.

There was some discussion about it, two years ago [1].

Regarding clisp, I would prefer a hosting at savannah to a hosting on
gitlab.common-lisp.net.

Bruno

[1] https://lists.gnu.org/archive/html/savannah-hackers-public/2016-02/msg00000.html

Re: sourceforge miseries

[Sam S. <sd...@gn...>]

> * Sébastien Villemot <fro...@qr...t> [2018-04-09 23:29:17 +0200]:
>
> FWIW, Gitlab has a significant advantage over Savannah: it implements “pull
> requests” (similarly to Github), which greatly facilitates contributions.

+1

Note that PRs can be merges as "squashed".
I.e., the contributor makes many changes in response to maintainers'
comments and then the whole PR is pulled as a single git commit.
This makes it much easier to understand history and faster to bisect it.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://jij.org
http://thereligionofpeace.com http://mideasttruth.com http://think-israel.org
Yeah, yeah, I love cats too... wanna trade recipes?

Re: sourceforge miseries

[Jean L. <bu...@gn...>]

On Mon, Apr 09, 2018 at 12:27:59PM -0400, Sam Steingold wrote:
> Hi Bruno,
> 
> I moved from cons.org to SF 18 years ago based on similar hardships.
> I understand your frustration ;-(
> 
> Now that git has clearly won against mercurial, I think any repo move
> should include switching to git - no reason to stick with obsolete tech.
> 
> >   b) Convert it to git and move it to savannah.gnu.org.
> >   c) Convert it to git and move it to gitlab.com.
> 
> why not d) github.com?

and why not simply fire up your own Gitlab
instance on DigitalOcean.com?

I mean how hard is that one?

There are many reasons against github.com:

- CLISP is free software, hosted on non-free
  software, makes no sense for free software
  supporters. Github is not free software. Gitlab
  is. Install Gitlab for you yourself, easy. 

- Decentralization. What is the point of Internet
  if you need to depend on github? Why not have
  your own server. If money is needed I can
  donate. Gitlab is self-hosted.
 
- Github runs non-free software on their website,
  so why push users into running non-free software
  (Javascript) to get free software, make no
  sense. 

I would also say that plethora of mailing lists
are hosted with GNU.org http://lists.gnu.org/ and
that CLISP mailing list would be great there, as
one can download all archives down and there is
web interface to browse there. And all mail can be
converted into it easily.

Jean

Re: sourceforge miseries

[Sam S. <sd...@gn...>]

> * Jean Louis <ohtf@tah.fhccbeg> [2018-04-10 00:25:06 +0200]:
>
> I would also say that plethora of mailing lists
> are hosted with GNU.org http://lists.gnu.org/ and
> that CLISP mailing list would be great there, as
> one can download all archives down and there is
> web interface to browse there. And all mail can be
> converted into it easily.

I am afraid that they will censor our mailing lists by prohibiting
discussions of software which they deem "non-free".
E.g., if someone uses, say, Matlab of Netica interface to CLISP, they
might demand that each mention of Matlab is accompanied with a political
statement promoting the Octave alternative.

If you look at the emacs-devel mailing list, every mention of "linux" is
met with a diatribe that it should be called "gnu/linux" instead.

I did not toe the party line back in the USSR,
I will not do it here in the US.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net
http://no2bds.org http://iris.org.il http://honestreporting.com
Experience comes with debts.

Re: sourceforge miseries

[Jean L. <bu...@gn...>]

On Mon, Apr 09, 2018 at 06:41:58PM -0400, Sam Steingold wrote:
> > * Jean Louis <ohtf@tah.fhccbeg> [2018-04-10 00:25:06 +0200]:
> >
> > I would also say that plethora of mailing lists
> > are hosted with GNU.org http://lists.gnu.org/ and
> > that CLISP mailing list would be great there, as
> > one can download all archives down and there is
> > web interface to browse there. And all mail can be
> > converted into it easily.
> 
> I am afraid that they will censor our mailing lists by prohibiting
> discussions of software which they deem "non-free".
> E.g., if someone uses, say, Matlab of Netica interface to CLISP, they
> might demand that each mention of Matlab is accompanied with a political
> statement promoting the Octave alternative.
> 
> If you look at the emacs-devel mailing list, every mention of "linux" is
> met with a diatribe that it should be called "gnu/linux" instead.
> 
> I did not toe the party line back in the USSR,
> I will not do it here in the US.

That is not true Sam. Sorry, why have such wrong
perception. Yes there are these and those groups,
but this is your group, and you can get mailing
list and mention Matlab and Linux as you wish. It
really does not matter.

In fact, if you refer to operating system as Linux
it is deceptive in itself... ;-) It should be
mentioned as GNU/Linux or GNU with kernel
Linux. Unless it is not GNU, for example it may be
Android.

Jean

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

Jean Louis wrote:
> and why not simply fire up your own Gitlab
> instance on DigitalOcean.com?

Managing IT infrastructure has some costs. It's not
only installing the software, it's assuring response to
issues, installing security upgrades, assuring backups,
assuring continuation in case of personal bankrupcy or death,
and so on.
  - If a single person does it, chances are high that it won't
    last long. This was our first experience with cons.org.
  - If a small group of people does it (like GNU or common-lisp.net),
    we have to follow the rules of that group.
  - If a large company, such as gitlab.com, does it, it is most
    cost-effective, but we are at the mercy of developments of this
    company. This was our experience with sourceforge.

Bruno

Re: sourceforge miseries

[Jean L. <bu...@gn...>]

On Tue, Apr 10, 2018 at 01:08:42AM +0200, Bruno Haible wrote:
> Jean Louis wrote:
> > and why not simply fire up your own Gitlab
> > instance on DigitalOcean.com?
> 
> Managing IT infrastructure has some costs. It's not
> only installing the software, it's assuring response to
> issues, installing security upgrades, assuring backups,
> assuring continuation in case of personal bankrupcy or death,
> and so on.
>   - If a single person does it, chances are high that it won't
>     last long. This was our first experience with cons.org.
>   - If a small group of people does it (like GNU or common-lisp.net),
>     we have to follow the rules of that group.
>   - If a large company, such as gitlab.com, does it, it is most
>     cost-effective, but we are at the mercy of developments of this
>     company. This was our experience with
> sourceforge.

Yes sure there is cost, I just don't see it as
significant myself.

Most updates can be done automatically. Most VPS
servers are running on Debian. I would prefer
running on a fully free software distribution, but
I do not know the provider.

Debian GNU/Linux based VPS or dedicated server can
be fully automatically updated and be running for
years without problems.

Backup assurance is also a simple script to make
multiple backups worldwide.

I would do following steps:

1) Establish a mailing list for CLISP and
CLISP-DEV on lists.gnu.org

2) Gradually convert from hg to git to Savannah

3) Update the official clisp.org website, so that
it points to correct sources.

4) Use the CNAME for git pull, so that it becomes
git.clisp.org and have clisp.org under your (CLISP
team) control

5) If anything is wrong with Savannah in future,
you still have the CNAME git.clisp.org and you
may move it to any provider and users will not
even know it.

6) Keep the mailing list from (1) on GNU as it is
reliable, browsable, usable, easily accessible,
and easy to copy. It will bring new contributors. 

-- 
Jean Louis

Re: sourceforge miseries

[Sam S. <sd...@gn...>]

Hi Bruno,

> * Bruno Haible <oe...@py...t> [2018-04-09 19:34:54 +0200]:
>
> My reason to use savannah is that it's continuously working fine, and
> a familiar environment (same bug trackers as for GNU libffcall, for
> example).

Yeah, but that bug tracker sucks big time.
Even SF is better.
I am not too familiar with gitlab, but its tracker appears to be more
modern.

> So, my proposal is: Move the hg repository to savannah today (or
> ASAP), so that we can continue to work on 2.50 and the GSoc students
> will not be interrupted in their work.

Does savannah or SF support repo synchronization?
(push to either and the other one automatically gets the patch)
Note also that SF might recover soon...

At any rate, do you also want to move the bug tracker? mailing list?

> The repository conversion for libffcall (from CVS) took me 2 days of
> work; I therefore estimate that the clisp repository conversion to git
> will take 2-4 days of work too.

CVS->hg is, I think, a bigger hassle than hg->git.

Thanks.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://think-israel.org
http://memri.org http://camera.org http://iris.org.il http://jij.org
"Sustainability" without "population growth control" is hypocrisy.

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

Hi Sam,

> Does savannah or SF support repo synchronization?
> (push to either and the other one automatically gets the patch)

For the git side, yes.
1) It is possible to install server-side git hooks on savannah
   (although it may require help from Jim Meyering or the site admins
   to do so).
2) There is a coreutils git mirror on github, and it is very up-to-date.

For the hg side, I don't know.

Note that for continuous integration, you don't need repo synchronization:
it is sufficient to do "git pull" / "hg pull --update" once a day.

> At any rate, do you also want to move the bug tracker? mailing list?

Not at the moment.

For the mailing lists, such a move can be considered later. Advertisements
in a mail footer are silly.

For the bug tracker, sourceforge is currently OK (now that we have
learned how to use ``` ... ``` and `...`).

> Yeah, but that bug tracker sucks big time.
> Even SF is better.

The rich text functionality in savannah's tracker is a bit poor, yes. On
the other hand, I like the categorization / sorting interface.

> I am not too familiar with gitlab, but its tracker appears to be more
> modern.

Surely everything Gitlab has is modern. The worry I have with Gitlab is
whether it will remain easy-to-use and easy-to-administrate 10 years from now.

Bruno

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

> > Does savannah or SF support repo synchronization?
> > (push to either and the other one automatically gets the patch)
> 
> For the git side, yes.
> 1) It is possible to install server-side git hooks on savannah
>    (although it may require help from Jim Meyering or the site admins
>    to do so).
> 2) There is a coreutils git mirror on github, and it is very up-to-date.

On the other hand, this request was rejected:
https://savannah.gnu.org/support/index.php?108889

Bruno

Re: sourceforge miseries

[Sam S. <sd...@gn...>]

> * Bruno Haible <oe...@py...t> [2018-04-10 00:29:58 +0200]:
>
>> > Does savannah or SF support repo synchronization?
>> > (push to either and the other one automatically gets the patch)
>> 
>> For the git side, yes.
>> 1) It is possible to install server-side git hooks on savannah
>>    (although it may require help from Jim Meyering or the site admins
>>    to do so).
>> 2) There is a coreutils git mirror on github, and it is very up-to-date.
>
> On the other hand, this request was rejected:
> https://savannah.gnu.org/support/index.php?108889

strong argument for gitlab against savannah.

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il
http://americancensorship.org http://camera.org http://thereligionofpeace.com
Two magic words will open almost all doors for you: "pull" and "push".

Re: sourceforge miseries

[Bruno H. <br...@cl...>]

Sam Steingold wrote:
> I am afraid that they will censor our mailing lists by prohibiting
> discussions of software which they deem "non-free".
> E.g., if someone uses, say, Matlab of Netica interface to CLISP, they
> might demand that each mention of Matlab is accompanied with a political
> statement promoting the Octave alternative.

They will not censor the mailing list, but they might very well have requests
regarding the source code. See [1][2].

> I did not toe the party line back in the USSR,
> I will not do it here in the US.

+1.

Bruno

[1] https://savannah.gnu.org/register/requirements.php
[2] http://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly/