Should using trunk be restricted to request or invitation?

[Thaddy]

Should using trunk be restricted to on request or invitation only?

I see, to my regret, that there are a lot of questions on the forum that can only be answered properly when the user actually knows what version is used and what to expect.

There are many more open source projects, including compilers, where access to the core development is closed for that reason.

I have all the time in the world, but: I am completely fed up by silly questions and silly assumptions, and those assumptions also include me, myself and I (As PascalDragon will confirm).

So, what do you all think?
- Restrict
- Keep everything open

My heart says 2, but my brains say 1.
(question initiated by the silly discussion about InOut ( a var) and Out(which should not be assumed to be initialized ) as well as generic class declarations)

[Bogen85]

I understand what you are saying and I could argue both sides of what you are presenting.

I use trunk and while I do admit some of my posts and replies may be irrational or nonsensical at times, I try to not bog down the forum with trunk related issues.

I've filed many bug reports against trunk (both fpc and lazarus). Most are taken seriously and the issues corrected and resolved. Not all are resolved, but I have no expectation they will be resolved in a timely manner.

Only a few have been rejected. And yeah, there may have been one or two I should not have filed and should have done better research before filed.

I mainly use trunk. And yes, I know anything can happen. And I know any workarounds might be broken later the same day that I make that workaround. So far that has been the exception, not the rule. For me trunk has been very stable, but not all programmers have the same expectations and willingness to file bug reports and find workarounds when something does not work as they would like or expect it to work

[wp]

Should using trunk be restricted to on request or invitation only?

You are saying that "normal" users should not be allowed to use trunk? What a non-sense!

[Bogen85]

Trunk users should be updating every time they are developing with it.

If they are building their own code several times day, they should be updating from trunk at least once a day, if not multiple times a day.

If one needs to file a bug report against trunk they need to update and try again before submitting the issue. EDIT: This should be mandatory in my opinion...
EDIT: Well, maybe not mandatory, but recommended, unless one wants to dig into what changed since last time they updated. In other words, you are using a build from last year and found a bug, you should update before trying now.

If someone has open issues they filed they should every few weeks or months update and check again to see if the problem is still present or now has different symptoms.

Those who use trunk should be willing and able to do all the above. EDIT: a weak should, I'm not going to say must, but they need to understand using trunk will be very difficult otherwise.

Even though I could argue both ways on this, I don't think restricting read only access to trunk is a good idea, especially for developers who understand the risks but are depending on trunk only features (yes, that could change forcing one to have to rework their code).

[marcov]

Since (1) bothers somebody with administration, while the problems of (2) are shared with the wider community, (1) is undesirable since it creates a maintenance bottleneck that is much worse than the problem.

So this is a pretty pointless proposal IMHO

Aside from the fact that I can't really imagine anybody in core to be in favour of (1).

In short: the forum regulars need to solve their own  @$@!%Q#%$ problems, not try to move the burden to core or forum admin. (and I represent both)

[Bart]

If one needs to file a bug report against trunk they need to update and try again before submitting the issue. EDIT: This should be mandatory in my opinion...

OK, the bug is in file X, I know what is wrong.
I can see that file X (or the code in question) has not been touched since I updated trunk and built it.
And yet, you want to make it mandatory for me to update and build again?
Even though it will be absolutely certain, that this will not change the outcome?
That's a bit insane (granted, not as insane as Thaddy's proposal, but that's to be expected...).

Bart

[Bogen85]

If one needs to file a bug report against trunk they need to update and try again before submitting the issue. EDIT: This should be mandatory in my opinion...

OK, the bug is in file X, I know what is wrong.
I can see that file X (or the code in question) has not been touched since I updated trunk and built it.
And yet, you want to make it mandatory for me to update and build again?
Even though it will be absolutely certain, that this will not change the outcome?
That's a bit insane (granted, not as insane as Thaddy's proposal, but that's to be expected...).

Bart

Agreed. Mandatory is a bit extreme. But if you filing something today with an FPC built last summer, checking git to see what files have changed might take longer than just running a script to update where you have a new build ready to use in a few minutes.

EDIT: OK, few minutes on a fast machine (using make -j to use all threads), but FPC does not take all that long to rebuild compared to gcc or clang or something else similar.

[BrunoK]

That's a bit insane (granted, not as insane as Thaddy's proposal, but that's to be expected...).

Bart

Hi hi

[BrunoK]

EDIT: OK, few minutes on a fast machine (using make -j to use all threads), but FPC does not take all that long to rebuild compared to gcc or clang or something else similar.

Has been around 3-4 mins with reasonably newer processors for the past >~ seven years in  various versions.

[marcov]

EDIT: OK, few minutes on a fast machine (using make -j to use all threads), but FPC does not take all that long to rebuild compared to gcc or clang or something else similar.

Has been around 3-4 mins with reasonably newer processors for the past >~ seven years in  various versions.

I happen to test FPC build times today on my two workstations today:

_ on windows_ (slow):

Ivy Bridge i7-3770 (9 years old)___   2:40
Ryzen 5700X  (one generation older than  "newest")  1:27

The Ivy bridge build may have been more tuned than the ryzen build by specifying a higher core count to clean than to build. (since cleaning is mostly blocked on I/O, the number of cores can be > physical)

[BrunoK]

Make command ?

Does it include clean ?

[marcov]

Yes, times include clean and installation. My build script, save as .cmd

Code: [Select]

@echo off
rem A simple build script for Windows. 2018 version; switching between 32-bit and 64-bit
rem nicer output due to stdout capturing.

rem uncomment OS, en select if CPU has avx 1 or 2. rem Both host and target. 
rem I have ivy bridge, skylake and Ryzen machines, roughly avx1 vs avx2.
rem so that's why I model it that way. For the few runs I still do on older machines, I manually change the script.

rem set OS=win64
set OS=win32
set AVX=1

rem CROSSOPTS64 is only added if 64-bit, to allow setting SIMD fpu option only for 64-bit.

if %AVX% equ 1 goto:ivy
rem Ryzen 5 2600/5600x or Skylake i5 or later Ryzen  4800h laptop
set CPUOPTS=-O2  -Opcoreavx2 -Cpcoreavx2
set CPUOPTS64=-Cfavx2
set CORES=5
set /a CLEANCORES=%CORES% + (%CORES% / 2)
echo %CLEANCORES%

goto donecpuopts

:ivy
rem Ivy Bridge i7-3770
set CPUOPTS=-O2 
rem -Opcoreavx -Cpcoreavx
rem set CPUOPTS64=-Cfavx
set CORES=5
set /a CLEANCORES=%CORES% + (%CORES% / 2)
echo %CLEANCORES%

:donecpuopts

rem  ----   decode OS to cpu and compiler name.

set OS_TARGET=%OS%
if "%OS%"=="win32" goto:win32
if "%OS%"=="win64" goto:win64
echo Unknown OS: %OS%
exit /b
:contosok

rem A bit of a mess. A mix of configurable settings and variables mostly dependent on detected variables.

set BASEDRV=c:
set SRCDIR=%BASEDRV%\repo\fpcgit
set PPCNAME=ppc%COMPSUFFIX%.exe
set FPCSTART=c:\fpc\3.2.2\bin\i386-win32\ppc386.exe
rem set FPCSTART=c:\pp32rel\bin\i386-win32\ppc386.exe


rem %SRCDIR%/utils/fpcm/  for cross? x32->x64 ?

set LOGDIR=%BASEDRV%\repo
set INSTALLDIR=%BASEDRV%\pp%BITS%
set DESTCOMPILER=%SRCDIR%/compiler/%PPCNAME%
set CROSSOPTS=

rem small FPC script to replace unix "time"
set DUMPTIME=c:\usr\dumptime.exe

if "%BITS%"=="64" set CROSSOPTS= OS_TARGET=win64 CPU_TARGET=x86_64

set OPTS=   -gw2 -godwarfsets -gl     
set COMMONOPTS= COPYTREE=echo OPT="%OPTS% "  NOWPOCYCLE=1 OVERRIDEVERSIONCHECK=1

rem use only if starting compiler does not
set NEWOPT= %CPUOPTS%

rem === invariant part ===

cd /d %SRCDIR%

for /f %%i in ('%FPCSTART% -iV') do set STARTINGVERSION=%%i
for /f %%i in ('%FPCSTART% -iTO') do set STARTINGOS=%%i
for /f %%i in ('%FPCSTART% -iTP') do set STARTINGARCH=%%i

echo Starting compiler %STARTINGVERSION% on %STARTINGARCH%-%STARTINGOS%

rem a small fpc program that dumps time, as substitute for *nix time

if exist %DUMPTIME% (
%DUMPTIME% set %temp%\stdbuild%BITS%.txt
)

echo Cleaning with %CLEANCORES% cores
make -j %CLEANCORES% RELEASE=0 %CROSSOPTS% distclean FPMAKEOPT="-T %CLEANCORES%" %COMMONOPTS% FPC=%FPCSTART% NEWOPT="%NEWOPT%"  ALLOW_WARNINGS=1 1> %LOGDIR%\cleanlog%BITS%.txt 2>&1

echo building %CPU_TARGET%-%OS%  with %CORES% cores
make -j %CORES% RELEASE=0 %CROSSOPTS% all FPMAKEOPT="-T %CORES%" %COMMONOPTS% FPC=%FPCSTART% NEWOPT="%NEWOPT%"  ALLOW_WARNINGS=1 1> %LOGDIR%\buildlog%BITS%.txt 2>&1

IF %ERRORLEVEL% EQU 0 GOTO:buildOK
echo build failed, skipping installation
exit /b

:buildOK
for /f %%i in ('%DESTCOMPILER% -iV') do set DESTVERSION=%%i
for /f %%i in ('%DESTCOMPILER% -iTO') do set DESTOS=%%i
for /f %%i in ('%DESTCOMPILER% -iTP') do set DESTARCH=%%i
echo Generated compiler %DESTVERSION% on %DESTARCH%-%DESTOS%

set FPCMAKENEW=%SRCDIR%/utils/fpcm/bin/%STARTINGARCH%-%STARTINGOS%

REM separate install step for crossversion purposes (and under Unix sudo) FPCMAKENEW required for crossbuilding.

echo installing
make install %COMMONOPTS% %CROSSOPTS% INSTALL_PREFIX=%INSTALLDIR%  FPC=%DESTCOMPILER% FPCMAKENEW=%FPCMAKENEW%/fpcmake.exe 1> %LOGDIR%\installlog%BITS%.txt   2>&1

rem otherwise %%i is parsed when if block is parsed and misses content changes inbetween
setlocal EnableDelayedExpansion

if exist %DUMPTIME% (
for /f "delims=#" %%i in ('%DUMPTIME% get %temp%\stdbuild%BITS%.txt') do set THETIME=%%i
echo Ok, building and installing took !THETIME!
)

IF %ERRORLEVEL% EQU 0 GOTO:theend

echo install failed!
exit /b

:win32
set BITS=32
set COMPSUFFIX=386
set CPU_TARGET=i386
goto:contosok

:win64
set BITS=64
set COMPSUFFIX=x64
set CPU_TARGET=x86_64
set CPUOPTS=%CPUOPTS% %CPUOPTS64%
goto:contosok

:theend

I assume fpcdeluxe uses something similar.

[DonAlfredo]

Yes. But deluxe also sets FPCDIR to prevent the Makefile from picking up wrong units with the same FPC version.
Edit. When building Lazarus.

[marcov]

Yes. But deluxe also sets FPCDIR to prevent the Makefile from picking up wrong units with the same FPC version.
Edit. When building Lazarus.

Do you differentiate between cores for cleaning and building ?

[DonAlfredo]

Nop. Cleaning and native building multi cores. Cross-building always single-core.