Re: [fpc-other] Git & SVN

Am 25.05.2017 um 00:44 schrieb Graeme Geldenhuys: > But I get in now. You guys are set in your ways - good or bad, and currently > not willing to change. > So I'll leave it at that. Thanks. I hope I might quote you in a few weeks/months/years :) ___

Re: [fpc-other] How do you keep up with FPC discussions?

On 24/05/17 20:30, Marco van de Voort wrote: In our previous episode, nore...@z505.com said:> > How in the world do people (you) keep up with reading email lists and > not waste the entire day? Some of it's reputation. It's obviously always worth knowing Florian and Jonas's position on even

Re: [fpc-other] Git & SVN

El 24/05/2017 a las 22:07, Florian Klämpfl escribió: > > The workflow will not change. If the tool does not fit the workflow, it is > the wrong tool. Period. I'm not an apostle of Git, nevertheless, your statement is wrong. Workflows are designed according with the tools you had when you

Re: [fpc-other] How do you keep up with FPC discussions?

On Tue, 23 May 2017 21:07:05 -0500, nore...@z505.com wrote: >Maybe I'm a retard and my brain is slow, but how the f**k do you keep up >with all these emails and have any time for programming, cooking, >working, hiking, possibly a relationship with opposite sex? > Well, for one thing, skip the

Re: [fpc-other] How do you keep up with FPC discussions?

On 25/05/17 10:20, Graeme Geldenhuys wrote: On 2017-05-25 09:02, Mark Morgan Lloyd wrote:> even if most of the time he> pushes it far harder than many of us enjoy. I’m afraid it’s an occupational habit. My job as a technical consultant and developer often requires me to come up with more

Re: [fpc-other] Git & SVN

Am 25.05.2017 um 12:02 schrieb Graeme Geldenhuys: > On 2017-05-25 09:26, Florian Klämpfl wrote: >> This is at least one month of work I (and >> probably nobody else) can and want to spent. > > And some how I believe that will never happen (or be allowed) even if I (or > somebody else) decide to

Re: [fpc-other] Git & SVN

On 2017-05-25 09:26, Florian Klämpfl wrote: This is at least one month of work I (and probably nobody else) can and want to spent. And some how I believe that will never happen (or be allowed) even if I (or somebody else) decide to donate a month of our time. I fear the resistance will

Re: [fpc-other] How do you keep up with FPC discussions?

On 2017-05-25 09:02, Mark Morgan Lloyd wrote: even if most of the time he pushes it far harder than many of us enjoy. I’m afraid it’s an occupational habit. My job as a technical consultant and developer often requires me to come up with more efficient ways of doing things. Yes, inefficient

Re: [fpc-other] Git & SVN

In our previous episode, Santiago A. said: > Workflows are designed according with the tools you had when you > designed it. Sometimes you improve your workflow as you improve your > knowledge of tools. And sometimes you create new tools to improve your > workflow. > > But sometimes other people

Re: [fpc-other] How do you keep up with FPC discussions?

On Thu, 25 May 2017 05:20:11 -0400, wkitt...@windstream.net wrote: >each >of the FPC related mailing lists comes into my thunderbird and is filtered to >its own (sub)folder where the messages are read in threaded mode... it is >faster >and available to me even when i'm offline... plus i have

Re: [fpc-other] How do you keep up with FPC discussions?

On 2017-05-25 12:09, Bo Berglund wrote: But my observation is that email is not the best way of managing these things even if you *can* create some folder structure. Email clients evolve a lot and suddenly your old store of messages is not readable anymore. I've been working on and off (more

Re: [fpc-other] What makes a Compiler project (like FPC) special?

In our previous episode, Graeme Geldenhuys said: > > Yet the ?packages? and ?rtl? directories is just that - which by the way > is part of the FPC project. Yes, except some of the parts directly connected to the compiler and its features (like exceptions, RTTI etc) > And that is also where

Re: [fpc-other] What makes a Compiler project (like FPC) special?

In our previous episode, Graeme Geldenhuys said: >Just to be clear, I'm not pushing Git here - I know you guys will >not change - Florian made that very clear. Yes, boundless leaps of faith are out of the question. Git should be a tool, not a religion. >But Florian's statements

Re: [fpc-other] What makes a Compiler project (like FPC) special?

On 2017-05-25 22:04, Marco van de Voort wrote: There are no narrow interfaces that are natural seams for modularization inside the compiler. Yet the “packages” and “rtl” directories is just that - which by the way is part of the FPC project. And that is also where most commits have been

Re: [fpc-other] What makes a Compiler project (like FPC) special?

On 05/26/2017 12:16 AM, Graeme Geldenhuys wrote: On 2017-05-25 22:04, Marco van de Voort wrote: There are no narrow interfaces that are natural seams for modularization inside the compiler. Yet the “packages” and “rtl” directories is just that - which by the way is part of the FPC project.

Re: [fpc-other] What makes a Compiler project (like FPC) special?

Am 25.05.2017 um 21:29 schrieb Graeme Geldenhuys: > > So what is Florian going on about regarding workflow and Git not being able > to cope in a "compiler" > based project? He made it out as if FPC will not be workable in a Git managed > environment. I don't > see his analogy. The Linux Kernel

[fpc-other] What makes a Compiler project (like FPC) special?

This is directed at Florian primarily, but any other FPC core member is welcome to chip in. Since Florian mentioned that a compiler project is "rocket science" [not his direct words, but he hinted at that] and totally different to any other software project... It has really bugged me... Why

Re: [fpc-other] Git & SVN

Hi, Στις 2017-05-25 18:24, Dimitrios Chr. Ioannidis via fpc-other έγραψε: Hi, Στις 2017-05-25 17:34, Sven Barth via fpc-other έγραψε: < snip > a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server... Ok just setup

Re: [fpc-other] Git & SVN

Hi, Στις 2017-05-25 17:34, Sven Barth via fpc-other έγραψε: < snip > a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server... Ok just setup gogs for testbed / evaluation at https://fpc-scm.nephelae.eu/ . Anyone

Re: [fpc-other] Git & SVN

2017-05-24 14:12 GMT+02:00 Karoly Balogh (Charlie/SGR) : > > Hi, > > On Wed, 24 May 2017, Graeme Geldenhuys wrote: > > > If the Free Pascal team is ever serious about migrating to Git, I'll > > happily help out with the migration process. > > Well, I think the resistance

Re: [fpc-other] Git & SVN

2017-05-25 15:20 GMT+02:00 Karoly Balogh (Charlie/SGR) : >> Of course the biggest obstacle is the building and running of the >> testsuite. > > Well. Build breakages are daily occurence with obvious "this could have > never built" mistakes, or new packages get committed

Re: [fpc-other] Git & SVN

2017-05-25 15:34 GMT+02:00 Marco van de Voort : > In our previous episode, Sven Barth via fpc-other said: >> Of course the biggest obstacle is the building and running of the >> testsuite. > > I think running the testsuite is a waste of time and cycles for anything > outside

Re: [fpc-other] Git & SVN

In our previous episode, Florian Kl?mpfl said: > > donate a month of our time. > > Indeed, it depends on the person who does it. It requires knowledge about the > specific workflow > requirements of a compiler project. And that this is not easy is proven by > the fact that gcc as well > as

Re: [fpc-other] Git & SVN

Hi, Στις 2017-05-25 16:53, Sven Barth via fpc-other έγραψε: < snip > Maybe such a hypothesized integration system would be a bit more rigorous depending on what files were changed? E.g. full build with fullcycle plus testsuite run on Tier 1 targets if anything in compiler and rtl was changed

Re: [fpc-other] Git & SVN

On 2017-05-25 15:34, Sven Barth via fpc-other wrote: a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server... Gitolite is brilliant at directory level, file level, branch level, site level permissions, private

Re: [fpc-other] Git & SVN

Hi, Στις 2017-05-25 16:53, Sven Barth via fpc-other έγραψε: < snip > Step 1: have an official FPC trunk Git mirror on our own server with a mirror/fork of it on GitHub (were those license troubles regarding GPL and Co I mentioned some months ago solved, btw?) and accept Pull Requests on the

Re: [fpc-other] How do you keep up with FPC discussions?

On 2017-05-24 08:54, Karoly Balogh (Charlie/SGR) wrote: Hi, On Wed, 24 May 2017, Nikolay Nikolov wrote: > I'm positive that some of you are just clever A.I. bots posing as > humans.. that's where your super powers come from. You're not actually > humans.. Hahaha, you got that right! That's my

Re: [fpc-other] What makes a Compiler project (like FPC) special?

On 2017-05-25 09:18, Graeme Geldenhuys wrote: This is directed at Florian primarily, but any other FPC core member is welcome to chip in. Since Florian mentioned that a compiler project is "rocket science" [not his direct words, but he hinted at that] and totally different to any other software

Re: [fpc-other] How do you keep up with FPC discussions?

On 2017-05-25 04:20, wkitt...@windstream.net wrote: while i understand what you are saying, i always get a huge belly laugh when someone says anything about cluttering an inbox... that's just crazy when you have filters that can easily move new mail to its own folder for reading... each of the

Re: [fpc-other] What makes a Compiler project (like FPC) special?

On 05/25/2017 05:18 PM, Graeme Geldenhuys wrote: This is directed at Florian primarily, but any other FPC core member is welcome to chip in. Since Florian mentioned that a compiler project is "rocket science" [not his direct words, but he hinted at that] and totally different to any other

Re: [fpc-other] What makes a Compiler project (like FPC) special?

On 2017-05-25 19:47, Nikolay Nikolov wrote: The answer is: much higher complexity and much tighter coupling between the different components. Everything depends on everything, basically. And all of that's caused by necessity, not by bad design, because the task you're solving is very complex.