Github anyone?

[Bruno Postle]

Sourceforge is still down.
Github is the obvious alternative, though if we want to keep on using mercurial, then bitbucket is very reliable in my experience.

--
Bruno

[Stefan Peter]

Hi list

On 18.07.2015 14:26, Bruno Postle wrote:
> Sourceforge is still down.

Additionally, they seem to abuse the trust invested in them, see for example
http://arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/

> Github is the obvious alternative, though if we want to keep on using mercurial, then bitbucket is very reliable in my experience.
>

I'd love to see hugin using git, but this is for the developers to decide.

In any case, a move away from SF would need quite some work, there are
quite some hugin related links pointing to SF. And we would have to make
sure that SF does not judge hugin to be an abandoned project and starts
to deliver crapware infested hugin installers to whoever follows an
outdated link to the SF hugin account.

As a side note, I recently started using gitlab and I really like it.

With kind regards

Stefan Peter


--
Any technology that does not appear magical is insufficiently advanced.
~ Gregory Benford

[Andreas Metzler]

Stefan Peter <s_p...@swissonline.ch> wrote:
[...]

> I'd love to see hugin using git, but this is for the developers to decide.

> In any case, a move away from SF would need quite some work, there are
> quite some hugin related links pointing to SF. And we would have to make
> sure that SF does not judge hugin to be an abandoned project and starts
> to deliver crapware infested hugin installers to whoever follows an
> outdated link to the SF hugin account.

> As a side note, I recently started using gitlab and I really like it.

[...]

If hugin switched from HG to GIT using launchpad as repository hoster
would be the natural choice since the bugtracker is already there.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[Yuval Levy]

+1 to move the codebase away from SF.

On 15-07-18 11:32 AM, Andreas Metzler wrote:
> If hugin switched from HG to GIT using launchpad as repository hoster
> would be the natural choice since the bugtracker is already there.

Have I missed something? I thought launchpad was using Bazaar.

I am agnostic between Launchpad, Github, Gitlab, Bitbucket. All of them
good enough and definitely better than SF. SF is still useful as
website host / binary distribution platform / general backup.

On 15-07-18 10:16 AM, Stefan Peter wrote:
> Additionally, they seem to abuse the trust invested in them

It's a never-ending story, with their increasingly abusive monetization
attempts that cripple every HTML interface they "customize" and every
email they send. Enough is enough.

> In any case, a move away from SF would need quite some work

<https://import.github.com/new> looks easy (but we'd have to wait for SF
to be back up to test it).

Hg-attached developers can keep using Hg tools with a simple extension:
* <http://hg-git.github.io/>
* <https://github.com/schacon/hg-git>

The difficulty is to implement some sort of synchronization of the
codebase back to SF, to keep the Hg instance on SF as a live backup, at
least during a transition period.

Moving the bug tracker would be a lot of work, and out of topic for now.
Launchpad is still doing well.

> make sure that SF does not judge hugin to be an abandoned project
> and starts to deliver crapware infested hugin installers to whoever
> follows an outdated link to the SF hugin account.

Volunteer builders can keep feeding download/installers into SF. We
need to keep "gardening" that place to avoid weed creeping up.

To really protect against SF's crapware, I would suggest a trademark
registration in the US (home to SF), so that if they play dirty we can
threaten them with a trademark infringement lawsuit.

Having had the pleasure of running the migration of Hugin from SVN to Hg
five years ago, I have the experience. At the moment I have no time,
but I may have some time available in the first or second week of August
to test a move and report back for a decision by the community.

Yuv

[Stefan Peter]

Hi Yuval, All

On 18.07.2015 17:45, Yuval Levy wrote:
>
>> In any case, a move away from SF would need quite some work
>
> <https://import.github.com/new> looks easy (but we'd have to wait for SF
> to be back up to test it).

I am quite sure we can handle the developer side of things, but what
about all the "download binary release of hugin from here <SF download
link>" type of references that are out in the wild? This is out of our
control and we would need a permanent redirect support on the urls from
SF in order to move them off SF. And I doubt that SF will play ball for
this.

We may have to do a slow move away from SF, offering and promoting our
new download locations for quite some time before abandoning SF
completely, if ever.

>
> Hg-attached developers can keep using Hg tools with a simple extension:
> * <http://hg-git.github.io/>
> * <https://github.com/schacon/hg-git>

I'd really prefer a complete switch over to git in favor of promoting a
crutch that most probably will neither be completely hg not completely
git. As I said before, the developers have to decide on this.

> The difficulty is to implement some sort of synchronization of the
> codebase back to SF, to keep the Hg instance on SF as a live backup, at
> least during a transition period.

I would like to prevent a split head scenario where part of the
development works with git out of whatever service we may choose and
other developers still working with SF hg. When moving away from SF, the
hg repository there should be deleted (or replaced with a pointer.txt
redirecting to the new git/whatever location of the hugin repository),

> Moving the bug tracker would be a lot of work, and out of topic for now.
> Launchpad is still doing well.

Let us keeping that then. Did we ever really use the SF bug tracker?

>> make sure that SF does not judge hugin to be an abandoned project
>> and starts to deliver crapware infested hugin installers to whoever
>> follows an outdated link to the SF hugin account.
>
> Volunteer builders can keep feeding download/installers into SF. We
> need to keep "gardening" that place to avoid weed creeping up.

Or populate the SF download areas with redirect messages to whatever new
service we may chose. BTW, who has admin privileges for the hugin
project on SF?

> To really protect against SF's crapware, I would suggest a trademark
> registration in the US (home to SF), so that if they play dirty we can
> threaten them with a trademark infringement lawsuit.

I am not a lawyer, but wouldn't we need a legal corps for that?

> Having had the pleasure of running the migration of Hugin from SVN to Hg
> five years ago, I have the experience. At the moment I have no time,
> but I may have some time available in the first or second week of August
> to test a move and report back for a decision by the community.

I'd say, let's wait for the developers to speak up until you commit your
free time to a project like this.

[Andreas Metzler]

Yuval Levy <goo...@levy.ch> wrote:
> +1 to move the codebase away from SF.

> On 15-07-18 11:32 AM, Andreas Metzler wrote:
>> If hugin switched from HG to GIT using launchpad as repository hoster
>> would be the natural choice since the bugtracker is already there.

> Have I missed something? I thought launchpad was using Bazaar.

[...]

Hello,

It looks loke Ubuntu might be moving to GIT, they have recently added
GIT support to lauchpad.

http://lwn.net/Articles/649198/
http://blog.launchpad.net/general/launchpad-news-april-june-2015
https://help.launchpad.net/Code/Git

[T. Modes]

What's the advantage of switching to git?

E.g. switching to github would mean:
1.) Manage also the premissions on github.
2.) Then also manage the issue tracker and pull requests on github.

Doing the switch requires "only" a limited time effort, but keep it alive takes more time.
And our resources are limited (I see who's active on our tracker and who's helping with current release).

[Bruno Postle]

On Mon 20-Jul-2015 at 08:43 -0700, Thomas Modes wrote:
>
>What's the advantage of switching to git?

There is no real technical advantage switching from mercurial to
git, but Sourceforge still isn't back up and I'm not sure that
it has much future even when they do get it going again.

>E.g. switching to github would mean:
>1.) Manage also the premissions on github.
>2.) Then also manage the issue tracker and pull requests on github.

We already have the tracker on Launchpad, it would make a lot of
sense to move the source to Launchpad - but this means switching to
git.

(I was going to build Hugin rc2 fedora snapshots now that I finally
have a solid enblend build, but my HG tree is three weeks out of
date)

--
Bruno

[Bruno Postle]

On Mon 20-Jul-2015 at 23:01 +0100, Bruno Postle wrote:
>
> my (Hugin) HG tree is three weeks out of date)

I do have a full Panotools::Script tree, which I have put here for
now: https://bitbucket.org/brunopostle/panotools-script

I have a complete enblend repo too, I can put this up temporarily if
anyone wants it.

--
Bruno

[T. Modes]

Hi Bruno,

Am Dienstag, 21. Juli 2015 00:01:55 UTC+2 schrieb Bruno Postle:

We already have the tracker on Launchpad, it would make a lot of
sense to move the source to Launchpad - but this means switching to
git.

I did a first test. A git repository of Hugin can found now at launchpad. For details see https://code.launchpad.net/hugin
Maybe it needs some more polishing (volunteer welcome), but for now it's a working start point, I hope.

(I was going to build Hugin rc2 fedora snapshots now that I finally
have a solid enblend build, but my HG tree is three weeks out of
date)

I wanted to publish a rc3 at the last weekend because of bug https://bugs.launchpad.net/hugin/+bug/1474580
Now with a working repository again I will wait until confirmation that the bug fix does not break compilation. Then rc3 can be released.

Thomas

[Bruno Postle]

On Tue 21-Jul-2015 at 11:13 -0700, Thomas Modes wrote:
>
>I did a first test. A git repository of Hugin can found now at launchpad.
>For details see https://code.launchpad.net/hugin
>Maybe it needs some more polishing (volunteer welcome), but for now it's a
>working start point, I hope.

Ok, will need some advice here from git experts, I can clone this
repository like so:

git clone https://git.launchpad.net/~hugin-devs/hugin

..but get this error when trying to do anything:

fatal: bad default revision 'HEAD'

Then this seems to give me the current 2015 branch:

git checkout branch_2015.0

Separately, cmake fails due to a missing rev.txt file. I'll attach
a patch that fixes CMakeLists.txt to create the rev.txt file from
git instead of hg (for some reason I can't push to the new git
repository).

--
Bruno

[T. Modes]

Hi Bruno,

Am Dienstag, 21. Juli 2015 22:30:52 UTC+2 schrieb Bruno Postle:

..but get this error when trying to do anything:

  fatal: bad default revision 'HEAD'

Not sure about this. Maybe I forgot something in the conversion. Help by an advanced git user would be helpful.

Separately, cmake fails due to a missing rev.txt file.  I'll attach
a patch that fixes CMakeLists.txt to create the rev.txt file from
git instead of hg

Thanks for the patch (I'm using locally a mercurial repository and push to the git repository with the hg-git extension. So I forgot this issue.)
I committed a slightly modified version (the mercurial part is still in).
 

(for some reason I can't push to the new git
repository).

According to https://help.launchpad.net/Code/Git push is only allowed about ssh protocol.
For setting up your key see instructions here https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair

Thomas

[Bruno Postle]

On Tue 21-Jul-2015 at 13:57 -0700, Thomas Modes wrote:
>Am Dienstag, 21. Juli 2015 22:30:52 UTC+2 schrieb Bruno Postle:
>
>> fatal: bad default revision 'HEAD'
>
>Not sure about this. Maybe I forgot something in the conversion. Help by an
>advanced git user would be helpful.

I don't get it now from a fresh ssh clone, so appears to be fixed by
your first commit.

>Separately, cmake fails due to a missing rev.txt file.

>> a patch that fixes CMakeLists.txt to create the rev.txt file from
>> git instead of hg
>
>Thanks for the patch (I'm using locally a mercurial repository and push to
>the git repository with the hg-git extension. So I forgot this issue.)
>I committed a slightly modified version (the mercurial part is still in).

I 'cherry-picked' this for the 2015.0 branch and pushed to
launchpad, permissions seem to be ok with ssh. Building some 2015.0
rpms now.

--
Bruno

[Terry Duell]

On Wed, 22 Jul 2015 06:57:49 +1000, T. Modes <Thomas...@gmx.de> wrote:

> Hi Bruno,
>
> Am Dienstag, 21. Juli 2015 22:30:52 UTC+2 schrieb Bruno Postle:
>
> ..but get this error when trying to do anything:
>>
>> fatal: bad default revision 'HEAD'
>
>
> Not sure about this. Maybe I forgot something in the conversion. Help by
> an
> advanced git user would be helpful.
>
> Separately, cmake fails due to a missing rev.txt file. I'll attach
>> a patch that fixes CMakeLists.txt to create the rev.txt file from
>> git instead of hg
>
>
> Thanks for the patch (I'm using locally a mercurial repository and push
> to
> the git repository with the hg-git extension. So I forgot this issue.)
> I committed a slightly modified version (the mercurial part is still in).
>

I just tried "cmake .. && make package_source", using my normal procedure
and the bz2 archive is 280MB due to the .git dir (283MB) being included,
so the CmakeLists.txt does need a bit more tweaking for use with git.

I think it is a pity we haven't been able to find a suitable location to
keep using mercurial, it does seem that git imposes an additional
management overhead and hard to see the benefits for this project...but
that's just my two bob's worth, or probably more to the point "...two
cents".

Cheers,
--
Regards,
Terry Duell

[cspiel]

Bruno,

        I shall only talk for the Enblend/Enfuse project, which is
hosted on SourceForge just like Hugin.  Actually, we are using two of
their services:
    1. Source-code management with Mercurial.
    2. File hosting for the release tar-balls.

Some time ago we abandoned the SF Bug Tracker Service and moved it to
LaunchPad.


1. Mercurial vs Git

1.1.  Let's see who contributes to the project by analyzing the commit
log!  The last 500 entries have been by the following official
developers.  The second column tells the number of commits per
person.
    Chris        345
    Thomas        77
    Kornel        39
    Mikolaj       30
    Bruno          4
    Yuval          1
For those who want to do the math themselves: Ten patches of mine are
pending and four are by external contributors.

Having submitted twice as many changes than all others combined, I'd
like to express my preference for Mercurial as source-code management
system.

1.2.  In the course of coaching the Vigra guys with their GSoC 2014
student project on parallelization, I worked with GitHub.  So I am
able judge both sides from my own experience and not just based on
some fluffy concept papers.

Mercurial gives me the best balance between
  * assisting me to avoid mistakes,
  * giving me a helping hand when necessary and
  * getting the hell out of me way most of the time.
In direct comparison to Git I particularly value the seamless
integration of patch stacks ("queues" in Mercurial lingo) and the
_lack_ of a Staging Area, which are intermingled preferences.


2. SourceForge "Files Area", i.e. Package Distribution

        We serve our Stable Branch packages as source and pre-compiled
for a measly O/S through SF.

Neither Enblend nor Enfuse are pieces of software you desperately need
in case of an imminent heart attack or to ensure National Security &
Happiness.  I don't have to be particularly objective to find
Enblend/Enfuse 24x7-availability of the source code packages
_unimportant_.
  * Nobody in the Enblend/Enfuse team earns money from timely shipped
    contributions.
  * We do not have a business, ergo we don't have competitors to
    outpace.
  * If someone can't download Enblend and therefore turns to Veranda
    (or whatever freaky Dutch names they give them), this is no
    problem, its freedom of choice of Free Software.
General, public availability of the source code packages is
acknowledged, though.

IMO, the SF Files Area sucks as much as the rest of their homegrown
stuff, but I use it rarely enough, namely only when releasing a new
version, that I can tolerate the clumsy handling.

We could quite easily move away from this distibution channel as soon
as we find a replacement, be it BitBucket or some other service.


As a final note: Who guarantees that any free-of-charge or other
provider will give us a superior operations base for developing
Enblend/Enfuse in the next say ten years?  Is the grass always better
blended/fused on the other side especially when we take into account
the migration expenses, which amount mostly to developer-time we could
use for writing code?


/Chris

[Bruno Postle]

On 22 July 2015 at 09:10, cspiel wrote:
>
> I shall only talk for the Enblend/Enfuse project, which is
> hosted on SourceForge just like Hugin. Actually, we are using two of
> their services:
> 1. Source-code management with Mercurial.
> 2. File hosting for the release tar-balls.

It's not about git vs. mercurial, they are pretty much equivalent,
Sourceforge has been down for nearly a week and may not have much of a
future: http://sourceforge.net/p/enblend/code/

Combine this with the recent revelation that they insert malware into
Windows installers, now seems like a good time to be looking at
alternatives:

- bitbucket works well and allows you to continue with Mercurial.
- launchpad is already set up with developer permissions as we use the
bug-tracker, but means switching to git.

BTW, it's reassuring to see the Hugin repository has every commit
since 2003, i.e. we have migrated from cvs to svn to hg to git without
losing anything.

--
Bruno

[Stefan Peter]

Hi list

Am 22.07.2015 um 14:51 schrieb 'Bruno Postle' via hugin and other free
panoramic software:

> BTW, it's reassuring to see the Hugin repository has every commit
> since 2003, i.e. we have migrated from cvs to svn to hg to git without
> losing anything.

I assume that the absence of most branches is intentional. On the other
hand, all tags are present???

Additionally, the logs for the master contain log entries from the
2015.0 branch?

I have created my own git repository from the hg repo I used fro the
nightly builds. It is available at
https://bitbucket.org/stefanpeter/temphugin/overview
and does not show these problems. It was created using fast-export from
git://repo.or.cz/fast-export.git

BTW, fast-export reports
Error: repository has at least one unnamed head: hg r5913

so I had to use --force --hgtags)

[T. Modes]

Am Mittwoch, 22. Juli 2015 15:54:05 UTC+2 schrieb Stefan Peter:

I assume that the absence of most branches is intentional. On the other
hand, all tags are present???

Additionally, the logs for the master contain log entries from the
2015.0 branch?

BTW, fast-export reports
Error: repository has at least one unnamed head: hg r5913

with all the problems I tempted to remove the git repository again.
I think we should do more tests before doing the switch. The first test was not fully successfully.

I has somebody objections against the removal of the git repo?

Thomas

[Stefan Peter]

Hi list

On 22.07.2015 19:39, T. Modes wrote:
>
> with all the problems I tempted to remove the git repository again.
> I think we should do more tests before doing the switch. The first test
> was not fully successfully.
>
> I has somebody objections against the removal of the git repo?
>

I have reworked the hugins-nightly scripts to work from git. They
produced today (see
https://launchpad.net/~hugin/+archive/ubuntu/nightly
)

Of course, I can revert these changes, no problem.

However, we are really far into a release atm and we need a working
repository as a way for builders to download sources now. And a way we
can distribute binary packages for those poor souls not being able to
rely on OS inherent download repositories for binaries (I'm looking at
you, windows ... ;) ).

Sourceforge has hinted towards a complete restoration of their functions
for mid of this week, but here it is Wednesday evening and still
mercurial is not working.

I say we need an alternative plan, at least for the source repository.
And because switching the source version control system at this time in
the release process seem a large risk to me, I propose to find another
hosting provider for the mercurial hugin repo.

If all hell breaks loose, I hereby offer to host it on one of my private
servers for a _limited_ amount of time.

We will take care for the binaries once the have been created. And I
hope we can discuss and test the move from mercurial to git at ease
after the release of hugin 2015.0.0. Because I'm convinced that in the
long run, git will displace all other SCMs.

What do *you* think?

Cheers

[Andreas Metzler]

Stefan Peter <s_p...@swissonline.ch> wrote:
[...]

> I say we need an alternative plan, at least for the source repository.
> And because switching the source version control system at this time in
> the release process seem a large risk to me, I propose to find another
> hosting provider for the mercurial hugin repo.

> If all hell breaks loose, I hereby offer to host it on one of my private
> servers for a _limited_ amount of time.

Hello,

it might be unnecessary, the latest sf update
<http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-722/>
said that HG should be back today (July 23). It is not done yet,
though.

cu Andreas

[Stefan Peter]

On 23.07.2015 21:15, Andreas Metzler wrote:
> Stefan Peter <s_p...@swissonline.ch> wrote:
> [...]

>> If all hell breaks loose, I hereby offer to host it on one of my private
>> servers for a _limited_ amount of time.
>
> Hello,
>
> it might be unnecessary, the latest sf update
> <http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-722/>
> said that HG should be back today (July 23). It is not done yet,
> though.

I still get

$ hg pull
abort: error: Connection refused

However, I still hope that SF will get the mercurial repositories back
up until the end of this week. The question is, what shall we do if they
do not?

[Terry Duell]

On Fri, 24 Jul 2015 06:27:52 +1000, Stefan Peter <s_p...@swissonline.ch>
wrote:

> On 23.07.2015 21:15, Andreas Metzler wrote:
>> Stefan Peter <s_p...@swissonline.ch> wrote:
>> [...]
>>> If all hell breaks loose, I hereby offer to host it on one of my
>>> private
>>> servers for a _limited_ amount of time.
>>
>> Hello,
>>
>> it might be unnecessary, the latest sf update
>> <http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-722/>
>> said that HG should be back today (July 23). It is not done yet,
>> though.
>
> I still get
>
> $ hg pull
> abort: error: Connection refused
>
> However, I still hope that SF will get the mercurial repositories back
> up until the end of this week. The question is, what shall we do if they
> do not?
>

'hg pull' now working on both hugin and enblend sourceforge repos.