Den ons 20 nov. 2024 kl 18:15 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:
> So I'd say we have consensus on moving to the Python implementation -
> several +1 and no-one objecting. And since this is far from core code and
> it can easily be reverted I don't see a problem at all.
>
I've
Nathan Hartman wrote on Wed, 20 Nov 2024 21:17 +00:00:
> I notice that you write: tools/backport/*.py rather than
> tools/dist/*.py or tools/dist/backport/*.py. If that's intentional, I
> like this idea. Currently, tools/dist contains a mix of tools for
> managing backports and release management;
Daniel Sahlberg wrote on Wed, 20 Nov 2024 17:56 +00:00:
> There was two minor issues which I fixed in r1921977-r1921978. The tests
> now PASS for both Perl and Python versions.
Nice, thanks!
Might want to update README.backport lines 55:63 now, since the "not the same
language" comment is no long
Nathan Hartman wrote on Wed, 20 Nov 2024 21:21 +00:00:
> On Wed, Nov 20, 2024 at 12:16 PM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>> Den ons 20 nov. 2024 kl 14:50 skrev Daniel Shahaf >> B. Would more maintainers use the interactive functions if they [the
>>> interactive functions] w
One more quick thought...
On Wed, Nov 20, 2024 at 12:16 PM Daniel Sahlberg <
daniel.l.sahlb...@gmail.com> wrote:
> Den ons 20 nov. 2024 kl 14:50 skrev Daniel Shahaf >:
>
>> Daniel Sahlberg wrote on Mon, 18 Nov 2024 08:52 +00:00:
>
> (snip)
> B. Would more maintainers use the interactive functio
On Wed, Nov 20, 2024 at 9:22 AM Daniel Shahaf wrote:
>
> Nathan Hartman wrote on Tue, 19 Nov 2024 16:00 +00:00:
> > Looking through the backports stuff in tools/dist, currently it's a
> > little bit messy. I wonder if things can be simplified with a minimal
> > amount of effort.
> >
> > What if we
Den ons 20 nov. 2024 kl 18:15 skrev Daniel Sahlberg <
daniel.l.sahlb...@gmail.com>:
> Missed [backports_tests_p[yl].py], but I'm looking now. It did't work with
> Py3, but I changed a few things in r1921976. It seems a bunch of tests fail
> right now, don't know if it XFails() but isn't marked pro
Den ons 20 nov. 2024 kl 14:50 skrev Daniel Shahaf :
> Daniel Sahlberg wrote on Mon, 18 Nov 2024 08:52 +00:00:
> > backport.pl is a heavy user of "given ... when ..." and given that these
> > constructs will be removed[1] when Perl 5.42 is released (pun intended),
> we
> > need to take some action.
Nathan Hartman wrote on Tue, 19 Nov 2024 16:00 +00:00:
> Looking through the backports stuff in tools/dist, currently it's a
> little bit messy. I wonder if things can be simplified with a minimal
> amount of effort.
>
> What if we had just one script, actually called backport.py, with
> subcommand
Daniel Sahlberg wrote on Mon, 18 Nov 2024 08:52 +00:00:
> backport.pl is a heavy user of "given ... when ..." and given that these
> constructs will be removed[1] when Perl 5.42 is released (pun intended), we
> need to take some action. I'm guessing we have about one year before
> hitting a brick w
On Mon, Nov 18, 2024 at 3:52 AM Daniel Sahlberg
wrote:
>
> Hi,
>
> Regarding scripts in tools/dist:
>
> backport.pl is a heavy user of "given ... when ..." and given that these
> constructs will be removed[1] when Perl 5.42 is released (pun intended), we
> need to take some action. I'm guessing
On Mon, Nov 18, 2024 at 10:05 AM Stefan Sperling wrote:
>
> On Mon, Nov 18, 2024 at 09:52:31AM +0100, Daniel Sahlberg wrote:
> > I'm leaning towards the second option. The interactive features are nice
> > but I usually don't use them so I wouldn't mind loosing them - I think the
> > advantage of
On Mon, Nov 18, 2024 at 09:52:31AM +0100, Daniel Sahlberg wrote:
> I'm leaning towards the second option. The interactive features are nice
> but I usually don't use them so I wouldn't mind loosing them - I think the
> advantage of a more widely used language is more important.
>
> Thought and com
13 matches
Mail list logo
