Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2015-02

Future of FPCUP tool

18 messages · 7 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Juha Manninen

I remember FPC developers had a plan to maintain the late Reinier's FPCUP tool. What is the situation now?
There is at least one active fork, see :
http://forum.lazarus.freepascal.org/index.php/topic,27429.msg169490.html#msg169490

"DonAlfredo" appears to have motivation to maintain it. It may be good idea to not burden the FPC developers with yet another maintenance job.
In any case there should be one place decided where the tools is located and maintained.
Otherwise there will be many competing forks soon.

Juha

Reply by email

Michael Thompson
to Juha Manninen
Juha Manninen wrote
"DonAlfredo" appears to have motivation to maintain it.

That's not how I interpreted his posts, particularly his last one which he might have posted after you sent this email...

Mike

Reply by email

Juha Manninen
to Michael Thompson
Michael Thompson wrote
That's not how I interpreted his posts, particularly his last one which he might have posted after you sent this email...

He wrote "By no means I am pushing myself as the new maintainer" which I interpreted as "I would gladly maintain it but I don't want to be pushy".

Anyway, ideas anybody? This popular and useful tool must be maintained somehow. Do FPC devels still have a plan about it?

Juha

Reply by email

Marco van de Voort
to Juha Manninen

In our previous episode, Juha Manninen said:

Show quoted text 9 lines
> That's not how I interpreted his posts, particularly his last one which he > might have posted after you sent this email... He wrote "By no means I am pushing myself as the new maintainer" which I interpreted as "I would gladly maintain it but I don't want to be pushy". Anyway, ideas anybody? This popular and useful tool must be maintained somehow. Do FPC devels still have a plan about it?

Still the same, looking into it after the 3.0 release.

Reply by email

Tomas Hajny
to Marco van de Voort
Marco van de Voort wrote 14 lines
In our previous episode, Juha Manninen said: > > That's not how I interpreted his posts, particularly his last one > which he > > might have posted after you sent this email... > > He wrote "By no means I am pushing myself as the new maintainer" which > I interpreted as "I would gladly maintain it but I don't want to be > pushy". > > Anyway, ideas anybody? This popular and useful tool must be maintained > somehow. > Do FPC devels still have a plan about it? Still the same, looking into it after the 3.0 release.

However, if there is someone else willing to take it over, it's probably fine as well, isn't it?

Tomas

Reply by email

Juha Manninen
to Tomas Hajny
Tomas Hajny wrote
However, if there is someone else willing to take it over, it's probably fine as well, isn't it?

My thoughts exactly. FPC devels have hands full of work already. It is rare that new people are interested to improve a tool, it should not be ignored.

Should it be under FPC sources? If there is a motivated maintainer from outside, can he get commit access for it?

I need a plan before FPC 3.0 gets released. If I recommend this tool for somebody, what is the URL he should download it from? If somebody comes up with an improvement, where should he send it? The obvious choice now is to fork the original.

Juha

Reply by email

Marco van de Voort
to Juha Manninen

In our previous episode, Juha Manninen said:

Show quoted text 5 lines
rare that new people are interested to improve a tool, it should not be ignored. Should it be under FPC sources? If there is a motivated maintainer from outside, can he get commit access for it?

My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to that.

Reply by email

Juha Manninen
to Marco van de Voort
Marco van de Voort wrote
My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to that.

FPCUP also has a GUI frontend. Can it be maintained there as well?

I start to think this tool should be maintained somewhere else. FPC developers are not as motivated with it as some other people are.

Should I ask if "DonAlfredo" wants to maintain it? Then just document his GitHub place here :
http://wiki.lazarus.freepascal.org/fpcup
If he does not want, then find somebody else.

Does anybody have commit access to late Reinier's BitBucket repo? https://bitbucket.org/reiniero
It should somehow indicate that FPCUP is not maintained there any more.

Juha

Reply by email

Michael Van Canneyt
to Juha Manninen
Juha Manninen wrote 5 lines
On Sat, Feb 21, 2015 at 12:17 PM, Marco van de Voort wrote: > My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to > that. FPCUP also has a GUI frontend. Can it be maintained there as well?

Yes, but a GUI cannot be built as part of a FPC release.

I start to think this tool should be maintained somewhere else. FPC developers are not as motivated with it as some other people are.

There is a difference between hosting it and maintaining it.

We can provide SVN space on the FPC webserver, alongside the FPC/Lazarus SVN repos. That doesn't necessarily mean we need to work on it, but it should make it clear that we do intend to have it maintained.

So, if there is any interest, I can set up a repo for it.

Michael.

Reply by email

Michael Van Canneyt
to Juha Manninen
Juha Manninen wrote 5 lines
On Sat, Feb 21, 2015 at 2:38 PM, Michael Van Canneyt wrote: > So, if there is any interest, I can set up a repo for it. How easily would a new maintainer get commit rights there?

You just need to ask. It is a separate repo, so that should not be a problem.

There is not a form to fill in in quadruplicate :-)

Michael.

Reply by email

Florian Klaempfl
to Marco van de Voort: In our previous episode, Juha Manninen said: My suggestion was to put it in fpcbuild,…
Marco van de Voort wrote 9 lines
In our previous episode, Juha Manninen said: > rare that new people are interested to improve a tool, it should not > be ignored. > > Should it be under FPC sources? If there is a motivated maintainer > from outside, can he get commit access for it? My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to that.

Hmmm, I thought I did. At least I think for now that we should keep it separate and see how things evolve. fpcbuild is for now a too strong commitment imo.

Reply by email

Michael Van Canneyt
to Florian Klaempfl
Florian Klaempfl wrote 14 lines
Am 21.02.2015 11:17, schrieb Marco van de Voort: > In our previous episode, Juha Manninen said: >> rare that new people are interested to improve a tool, it should not >> be ignored. >> >> Should it be under FPC sources? If there is a motivated maintainer >> from outside, can he get commit access for it? > > My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to > that. Hmmm, I thought I did. At least I think for now that we should keep it separate and see how things evolve. fpcbuild is for now a too strong commitment imo.

Indeed. As I proposed: a separate SVN repo is not a problem.

Michael.

Reply by email

Tomas Hajny
to Michael Van Canneyt
Michael Van Canneyt wrote 17 lines
On Sat, 21 Feb 2015, Florian Klaempfl wrote: > Am 21.02.2015 11:17, schrieb Marco van de Voort: >> In our previous episode, Juha Manninen said: >>> rare that new people are interested to improve a tool, it should not >>> be ignored. >>> >>> Should it be under FPC sources? If there is a motivated maintainer >>> from outside, can he get commit access for it? >> >> My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to >> that. > > Hmmm, I thought I did. At least I think for now that we should keep it > separate and see how things evolve. fpcbuild is for now a too strong > commitment imo. Indeed. As I proposed: a separate SVN repo is not a problem.

May I remind fpcprojects again? ;-)

Tomas

Reply by email

Michael Van Canneyt
to Tomas Hajny
Tomas Hajny wrote 20 lines
On Sat, February 21, 2015 15:32, Michael Van Canneyt wrote: > On Sat, 21 Feb 2015, Florian Klaempfl wrote: >> Am 21.02.2015 11:17, schrieb Marco van de Voort: >>> In our previous episode, Juha Manninen said: >>>> rare that new people are interested to improve a tool, it should not >>>> be ignored. >>>> >>>> Should it be under FPC sources? If there is a motivated maintainer >>>> from outside, can he get commit access for it? >>> >>> My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted to >>> that. >> >> Hmmm, I thought I did. At least I think for now that we should keep it >> separate and see how things evolve. fpcbuild is for now a too strong >> commitment imo. > > Indeed. As I proposed: a separate SVN repo is not a problem. May I remind fpcprojects again? ;-)

You may, but the disadvantage is:
a) the revision is shared between projects.
b) user rights management is a trifle more difficult.

Michael.

Reply by email

Tomas Hajny
to Michael Van Canneyt
Michael Van Canneyt wrote 26 lines
On Sat, 21 Feb 2015, Tomas Hajny wrote: > On Sat, February 21, 2015 15:32, Michael Van Canneyt wrote: >> On Sat, 21 Feb 2015, Florian Klaempfl wrote: >>> Am 21.02.2015 11:17, schrieb Marco van de Voort: >>>> In our previous episode, Juha Manninen said: >>>>> rare that new people are interested to improve a tool, it should not >>>>> be ignored. >>>>> >>>>> Should it be under FPC sources? If there is a motivated maintainer >>>>> from outside, can he get commit access for it? >>>> >>>> My suggestion was to put it in fpcbuild, iirc Florian hasn't reacted >>>> to >>>> that. >>> >>> Hmmm, I thought I did. At least I think for now that we should keep it >>> separate and see how things evolve. fpcbuild is for now a too strong >>> commitment imo. >> >> Indeed. As I proposed: a separate SVN repo is not a problem. > > May I remind fpcprojects again? ;-) You may, but the disadvantage is: a) the revision is shared between projects. b) user rights management is a trifle more difficult.

Alright, understood.

Tomas

Reply by email

Anthony Walter
to Tomas Hajny

I've tried fpcup a few times in the past and have always had problems with it not working as expected. I current;y maint what I think is a well formed set of scripts for mac, linux, and mac installers on githhub:

https://github.com/sysrpl/Codebot.Setup/blob/master/linux/install.fpc-3.0.linux.sh#L134-147

The scripts could easily be modified to accept branch/revisions, though I really don't think the public should be bogging down subversion servers to get source code. Instead it should be mirror in a CDN backed by storage service like Amazon S3, Google Cloud Storage, ect which provide much faster and cheaper file distribution than any subversion server could hope for.

By the way, my scripts already pull from an S3 cloudfront distribution. All I think we need is a simple script to perform regular auto copies from SVN to S3 or Google Cloud Storage and we're done.

Reply by email

Tomas Hajny
to Anthony Walter
Anthony Walter wrote 18 lines
I've tried fpcup a few times in the past and have always had problems with it not working as expected. I current;y maint what I think is a well formed set of scripts for mac, linux, and mac installers on githhub: https://github.com/sysrpl/Codebot.Setup/blob/master/linux/install.fpc-3.0.linux.sh#L134-147 The scripts could easily be modified to accept branch/revisions, though I really don't think the public should be bogging down subversion servers to get source code. Instead it should be mirror in a CDN backed by storage service like Amazon S3, Google Cloud Storage, ect which provide much faster and cheaper file distribution than any subversion server could hope for. By the way, my scripts already pull from an S3 cloudfront distribution. All I think we need is a simple script to perform regular auto copies from SVN to S3 or Google Cloud Storage and we're done.

FWIW - FPC releases are already available from CDN backed repository of SourceForge. It might be possible to make source snapshots available there as well (not tried yet), but it's questionable if it really makes sense - if someone wants to get the latest trunk version (e.g. because he was told that a fix or new feature needed for him is available in that version), he or she may not be interested in waiting for another day before the source snapshot is updated (especially if the download is automated and he might find out after downloading and building that the fix was not there in reality because either snapshot generation or CDN uploading were delayed for some reason).

Obviously, anybody is free to implement something like that, but I wouldn't promote that approach personally, especially not for people who are not interested in "making their hands dirty" with stuff like playing with SVN and thus are less likely to be able to find out reasons why something on the way wouldn't work as they expected it).

Just my 2 cents...

Tomas

Reply by email