Re: Preparing FPC 3.2.4 RC2
Warren Postma via fpc-pascal <[email protected]> Wed, 22 Apr 2026 11:30:55 -0700
| Newsgroups | gmane.comp.compilers.free-pascal.general |
|---|---|
| Message-ID | <CAPJ9avP4K247Qa5-02gKW1G7FbLNPOQCZPivUwoBTGpGBRN89A@mail.gmail.com> |
--===============5140862493030726002== Content-Type: multipart/alternative; boundary="00000000000025224f065010bc6a" --00000000000025224f065010bc6a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Inbetween "we never use branches" and "infinite branches bad" is every sane git workflow. Git flow, or something. stable, trunk, at least. On Wed, Apr 22, 2026 at 11:29=E2=80=AFAM Florian Kl=C3=A4mpfl via fpc-pasca= l < [email protected]> wrote: > > > Am 22.04.2026 um 20:01 schrieb Warren Postma via fpc-pascal < > [email protected]>: > > >As they should. It's then up to the FPC team to backport (cherry-pick) > them to a fixes branch. > > This feels weird to me for some reason, maybe that's normal in this > project, but it seems more Git-normal to not commit bugfixes straight to > trunk. Is this a holdover from the svn days when that's the only workflow > you had because svn branching was... broken? > > > No. But managing a branch for every change would basically mean thousands > of branches. This is possible for projects like linux or whatever when > there are people doing nothing else than managing branches. FPC does not > have such resources. Despite this, I think also LLVM despite having huge > support uses a cherry pick based approach to port fixes to stable branche= s. > > > > W > > On Tue, Apr 21, 2026 at 11:04=E2=80=AFPM Graeme Geldenhuys via fpc-pascal= < > [email protected]> wrote: > >> On Tuesday, 21 April 2026 00:16:46 BST Warren Postma via fpc-pascal wrot= e: >> > The currently open PRs seem to 100% target main, not 3_2_4 and >> >> As they should. It's then up to the FPC team to backport (cherry-pick) >> them to >> a fixes branch. >> >> > few seem to be cleanly even able to land on main anymore after the man= y >> > months of them sitting open, that's the trick, I think. >> >> Correct. I'll be starting this week, going through all the open MRs and >> triage/label them for the authors to action, so we can get them back up >> to >> date (or closed). >> >> Regards, >> Graeme >> >> >> >> >> >> _______________________________________________ >> fpc-pascal maillist - [email protected] >> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> > _______________________________________________ > fpc-pascal maillist - [email protected] > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > > _______________________________________________ > fpc-pascal maillist - [email protected] > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > --00000000000025224f065010bc6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Inbetween "we never use branches" and "= ;infinite branches bad" is every sane git workflow.</div><div><br></di= v><div>Git flow, or something.=C2=A0 =C2=A0 stable, trunk, at least.</div><= div><br></div></div><br><div class=3D"gmail_quote gmail_quote_container"><d= iv dir=3D"ltr" class=3D"gmail_attr">On Wed, Apr 22, 2026 at 11:29=E2=80=AFA= M Florian Kl=C3=A4mpfl via fpc-pascal <<a href=3D"mailto:fpc-pascal@list= s.freepascal.org">[email protected]</a>> wrote:<br></div><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"><div><br id=3D"m_932646899= 227624173lineBreakAtBeginningOfMessage"><div><br><blockquote type=3D"cite">= <div>Am 22.04.2026 um 20:01 schrieb Warren Postma via fpc-pascal <<a hre= f=3D"mailto:[email protected]" target=3D"_blank">fpc-pascal@l= ists.freepascal.org</a>>:</div><br><div><div dir=3D"ltr"><div><div>>A= s they should. It's then up to the FPC team to backport (cherry-pick) t= hem to=C2=A0=C2=A0a fixes branch.<span></span></div><br></div><div>This fee= ls weird to me for some reason, maybe that's normal in this project, bu= t it seems more Git-normal to not commit bugfixes straight to trunk. Is thi= s a holdover from the svn days when that's the only workflow you had be= cause svn branching was... broken?</div></div></div></blockquote><div><br><= /div>No. But managing a branch for every change would basically mean thousa= nds of branches. This is possible for projects like linux or whatever when = there are people doing nothing else than managing branches. FPC does not ha= ve such resources. Despite this, I think also LLVM despite having huge supp= ort uses a cherry pick based approach to port fixes to stable branches.<br>= <br><blockquote type=3D"cite"><div><div dir=3D"ltr"><div><br></div><div><br= ></div><div>W</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl= ass=3D"gmail_attr">On Tue, Apr 21, 2026 at 11:04=E2=80=AFPM Graeme Geldenhu= ys via fpc-pascal <<a href=3D"mailto:[email protected]" ta= rget=3D"_blank">[email protected]</a>> wrote:<br></div><bl= ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef= t:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, 21 April 2026 00= :16:46 BST Warren Postma via fpc-pascal wrote:<br> > The currently open PRs seem to 100% target main, not 3_2_4 and<br> <br> As they should. It's then up to the FPC team to backport (cherry-pick) = them to <br> a fixes branch.<br> <br> > few seem to be cleanly even able to land on main anymore after the man= y<br> > months of them sitting open, that's the trick, I think.<br> <br> Correct. I'll be starting this week, going through all the open MRs and= <br> triage/label them for the authors to action, so we can get them back up to = <br> date (or closed).<br> <br> Regards,<br> =C2=A0 Graeme<br> <br> <br> <br> <br> <br> _______________________________________________<br> fpc-pascal maillist=C2=A0 -=C2=A0 <a href=3D"mailto:[email protected]= scal.org" target=3D"_blank">[email protected]</a><br> <a href=3D"https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal= " rel=3D"noreferrer" target=3D"_blank">https://lists.freepascal.org/cgi-bin= /mailman/listinfo/fpc-pascal</a><br> </blockquote></div> _______________________________________________<br>fpc-pascal maillist =C2= =A0- =C2=A0<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a><br><a href=3D"https://lists.freepa= scal.org/cgi-bin/mailman/listinfo/fpc-pascal" target=3D"_blank">https://lis= ts.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal</a><br></div></blockq= uote></div><br></div>_______________________________________________<br> fpc-pascal maillist=C2=A0 -=C2=A0 <a href=3D"mailto:[email protected]= scal.org" target=3D"_blank">[email protected]</a><br> <a href=3D"https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal= " rel=3D"noreferrer" target=3D"_blank">https://lists.freepascal.org/cgi-bin= /mailman/listinfo/fpc-pascal</a><br> </blockquote></div> --00000000000025224f065010bc6a-- --===============5140862493030726002== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal --===============5140862493030726002==--