Jonas Hahnfeld writes:
> Am Dienstag, den 11.02.2020, 14:16 +0100 schrieb David Kastrup:
>> I am not sure of when and how and whether at all it might make sense
>> suggesting to GitLab that we would be a good showcase project, being
>> ancient and with significant history
Jonas Hahnfeld writes:
> Am Dienstag, den 11.02.2020, 14:27 +0100 schrieb David Kastrup:
>> 7.6 ‘tsort’: Topological sort
>> =
>>
>> [...]
>>
>> Now of course the non-linear manner of being able to update issues and
>>
ets condensed into
the somewhat hard to find LSR, and then the educational aspect goes
somewhat missing. This kind of stuff does not rise to the level where
making a package of the code makes a lot of sense either.
Just throwing this out in case somebody has an idea for such things.
--
David Kas
Karlin High writes:
> On 2/11/2020 10:03 AM, David Kastrup wrote:
>> There
>> is nothing wrong per se with the user list, but it's not indexed in a
>> manner where many of the high quality answers would be accumulated into
>> wisdom, and it is comparatively ra
Han-Wen Nienhuys writes:
> On Mon, Feb 10, 2020 at 11:48 PM David Kastrup wrote:
>
>>
>> So for longterm efficiency reasons I am planning to reimplement the
>> get_property/set_property macros and underlying data structures that map
>> to get_property_internal/se
Han-Wen Nienhuys writes:
> On Tue, Feb 11, 2020 at 10:17 PM David Kastrup wrote:
>
>> > the reason being that it is better if the source code looks like plain
>> C++,
>> > even though they might actually be macros that do advanced magic. Having
>> > norma
End of forwarded message
--
David Kastrup
Urs Liska writes:
> I just told them to copy last year's proposal, which basically links to *our*
> GSoC page.
Thanks.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like
meone still entertains a bad
conscience because of how we ended up after getting flushed out of
Google Code. Let's try leaving on our own schedule this time.
Though I do see, say, <https://codereview.appspot.com/551400043/>.
--
David Kastrup
My replies have a tendency to cause friction.
because of interaction
with some other change someone else committed previously (like removing
some unused macro/function which your patch then used).
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a s
Han-Wen Nienhuys writes:
> On Sun, Feb 16, 2020 at 5:23 PM David Kastrup wrote:
>
>> Han-Wen Nienhuys writes:
>>
>> > sorry, my mistake (another reason to move to different tooling.)
>>
>> I very strongly disagree. We don't want to move to a tooli
ionality since it is similarly useful from Scheme where it looks
decidedly more natural than using the internals.
It would appear I am not alone in considering that useful:
git blame d03a3486639de982cfb6c6c315d76039bc5a0ac5 ly/markup-init.ly
shows Nicolas Sceaux already implementing this ability independently in
2006.
--
David Kastrup
mmensurate with how long the
stable branch has diverged. Hopefully we manage to find some
combination of process and responsible persons next time around that
delivers faster.
Nevertheless, I am glad we are getting there.
--
David Kastrup
Jonas Hahnfeld writes:
> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the end
>> of this week. This leaves a few days for the translation team to catch
>> up with the cur
Jonas Hahnfeld writes:
> Am Montag, den 17.02.2020, 14:59 +0100 schrieb David Kastrup:
>
>> Yes, GUB for 2.21.0. We don't want to have another indeterminate
>> backlog on unstable releases. That means that GUB needs to get switched
>> over to Python 3.
>
>
Jean-Charles Malahieude writes:
> Le 17/02/2020 à 13:25, David Kastrup a écrit :
>> Ok, I think 2.20 is basically done and we should push it out by the
>> end
>> of this week. This leaves a few days for the translation team to catch
>> up with the current state.
>
Urs Liska writes:
> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the
>> end
>> of this week.
>
> This is really great news!
> I'm somewhat undecided whether it is a cause
:6:
all] Error 2
I'll back out the Pango related commit and retry. It is a bit of a
puzzler to me how this could have passed testing.
--
David Kastrup
David Kastrup writes:
> Hi, staging does not compile anymore.
>
> Making lily/out/keyword.o < cc
> Making lily/out/simple-spacer-scheme.o < cc
> Making lily/out/episema-engraver.o < cc
> Making lily/out/lyric-extender.o < cc
> Making lily/out/includable-lexe
James writes:
> Hello,
>
> On 18.02.2020 11:59, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> Hi, staging does not compile anymore.
>>> Making lily/out/keyword.o < cc
>>> Making lily/out/simple-spacer-scheme.o < cc
>>> Ma
est "$have_pangoft2_with_otf_feature" = yes; then
-AC_DEFINE(HAVE_PANGO16)
-AC_DEFINE(HAVE_PANGO_FT2)
AC_DEFINE(HAVE_PANGO_FT2_WITH_OTF_FEATURE)
Any reason for that?
--
David Kastrup
Han-Wen Nienhuys writes:
> On Tue, Feb 18, 2020 at 11:08 PM David Kastrup wrote:
>
>> Han-Wen Nienhuys writes:
>>
>> > This surprises me greatly. I just checked
>> > out b16c3d14f3d1f10aa919e70107e6103c67a9aa01 which is what I pushed t
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Tue, Feb 18, 2020 at 11:08 PM David Kastrup wrote:
>>
>>> Han-Wen Nienhuys writes:
>>>
>>> > This surprises me greatly. I just checked
>>> > out b16c3d14f3d1f10aa919e70107e610
>
> My system is a down-to-earth Mint 19.3.
Color me curious: why would you try building staging? The whole point
of the staging system was to avoid breakage for developers. Only patchy
processes are supposed to care about staging.
--
David Kastrup
My replies have a tendency to cause frict
Jonas Hahnfeld writes:
> Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>>
>> The procedure for a patch would be
>>
>> git apply --index .diff
>> ./autogen.sh --noconf
>> cd build
>> ../configure --enable-checking # and/or o
Lukas-Fabian Moser writes:
> Le mer. 19 févr. 2020 à 09:08, David Kastrup a écrit :
>
> Color me curious: why would you try building staging? The whole point
>> of the staging system was to avoid breakage for developers. Only patchy
>> processes are supposed
Jonas Hahnfeld writes:
> Am Mittwoch, den 19.02.2020, 09:34 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>> > > The procedure
Han-Wen Nienhuys writes:
> On Wed, Feb 19, 2020 at 10:03 AM David Kastrup wrote:
>
>>
>> > So the dependency isn't correctly satisfied and we would always run it
>> > from then on, effectively slowing down our build system. And that is
>> > why I
produces the failure. I added a fix, and verified it passes on Ubuntu
> 19.04.
>
> I pushed it to staging.
>
> There should be a cleaner way than defining PANGO_ENABLE_BACKEND, but don't
> have time to investigate now.
Could you explain the urgency warranting an immediate h
Probably simpler is calling autoconf with the option --force in
autogen.sh.
Maybe that is what we should recommend instead in the Makefile instructions.
--
David Kastrup
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Wed, Feb 19, 2020 at 9:19 AM Han-Wen Nienhuys wrote:
>>
>>>
>>>> +// Necessary for supporting pango_context_new() and
>>>> +// pango_context_set_font_map()
pkx1...@posteo.net writes:
> Hello and sorry I am late to the table on this - been a busy week for me.
>
> On 19/02/2020 08:10, Jonas Hahnfeld wrote:
>> Am Dienstag, den 18.02.2020, 14:19 +0100 schrieb David Kastrup:
>>> James <
>>> pkx1...@posteo.net
>>&
ts off to people who tackle a whole
translation rather than just a puny file.
--
David Kastrup
Federico Bruni writes:
> Il giorno gio 20 feb 2020 alle 14:06, David Kastrup ha
> scritto:
>> In unrelated news, I tried my hand at translating at least the Changes
>> file into German and am about 50% done. Anybody want to work from the
>> bottom so that we should coor
David Kastrup writes:
> Graham Percival writes:
>
>> On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
>>>
>>> Anybody actually using the "music-cause"? Inside of LilyPond, the only
>>> appearance (apart from its declaration)
David Kastrup writes:
> David Kastrup writes:
>
>> Graham Percival writes:
>>
>>> On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote:
>>>>
>>>> Anybody actually using the "music-cause"? Inside of LilyPond, t
Jonas Hahnfeld writes:
> Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
>> David Kastrup <
>> d...@gnu.org
>> > writes:
>>
>> > Han-Wen Nienhuys <
>> > hanw...@gmail.com
>> > > writes:
>> >
>>
Jonas Hahnfeld writes:
> Am Donnerstag, den 20.02.2020, 20:21 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld writes:
>>
>> > Am Mittwoch, den 19.02.2020, 17:30 +0100 schrieb David Kastrup:
>> > > David Kastrup <
>> > > d...@gnu.org
>> &
sible to manually stop a bad staging commit from
reaching master even if it would compile: once you reset staging, no
already running Patchy process will override that decision with a
version of staging that has become stale.
This kind of double care is tricky enough to warrant its own
script/logic rather than rely on someone remembering all the details.
--
David Kastrup
David Kastrup writes:
> Federico Bruni writes:
>
>> Il giorno lun 17 feb 2020 alle 22:49, Federico Bruni
>> ha scritto:
>
>>> I'm working on the italian update and I hope to be ready before
>>> Thursday night.
>>>
>>
>> Can
you come up with for CI tooling. If a full run takes
> 122 CPU minutes, we'll fall out of the free tier everywhere, and have
> to put down some serious money. (eg. travis-ci has a limit of 120
> minutes per build; the gitlab free tier is 1000 minutes/month)
So it does seem quite relevant to see how CI works out with regard to
the platform we use, and in particular how we can keep parts of the CI
on private systems if it turns out necessary for staying in free tiers.
--
David Kastrup
Han-Wen Nienhuys writes:
> On Sat, Feb 22, 2020 at 3:06 PM David Kastrup wrote:
>> > I would be interested in your feedback.
>> >
>> > For example, I think it could be used for validating the staging ->
>> > master push in the following way:
&g
Han-Wen Nienhuys writes:
> On Sat, Feb 22, 2020 at 9:54 PM David Kastrup wrote:
>> > On Sat, Feb 22, 2020 at 5:23 PM Jonas Hahnfeld wrote:
>> >> > I would be interested in your feedback.
>> >>
>> >> Not having run any of this, my immediate r
Federico Bruni writes:
> Il giorno sab 22 feb 2020 alle 19:25, David Kastrup ha
> scritto:
>> German Changes file has been added by now. Where are we with regard
>> to
>> the other translations? Federico?
>
> I'm still working on it.
> My spare tim
Han-Wen Nienhuys writes:
> On Sat, Feb 22, 2020 at 10:01 PM David Kastrup wrote:
>> >> That's oversimplifying the staging->master push process a bit which goes
>> >> to considerable pain to make sure that its own copy of staging is still
>> >> par
Han-Wen Nienhuys writes:
> On Sun, Feb 23, 2020 at 12:16 AM David Kastrup wrote:
>>
>> Yes. But if every developer tests on the same platform, we will have
>> to email back and forth with users to figure out what is going on
>> when the stuff does not blow up on our
Han-Wen Nienhuys writes:
> On Sat, Feb 22, 2020 at 11:43 PM David Kastrup wrote:
>> >> Assuming that all translations are kept at exactly the same level and
>> >> the example code is not at all adapted to the language in question in
>> >> lyrics and code
> the script needs gs 9.21 or so since newer GS versions dropped some
> essential functionality needed for processing. This sounds very
> familiar to our issues with ghostscript...)
--
David Kastrup
, but please open a tracker issue so that the idea is not lost.
Where the hardwired info currently comes from can be seen with
git grep -6 docLinks
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me addin
loiting parallel CPUs, something which we
have used since before I even started with LilyPond.
Do you start your doc building tests with a suitable CPU_COUNT ?
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me
"Phil Holmes" writes:
> - Original Message - From: "David Kastrup"
> To: "Federico Bruni"
> Cc: ; ; "Phil
> Holmes"
> Sent: Saturday, February 22, 2020 10:54 PM
> Subject: Re: 2.20.0 release coordination with translation. Ot
there is no I/O
> delay any more that you can paper over with CPU bound tasks.
I run with -j9, using 1 CPU for I/O latency and 4 CPUs for
hyperthreading. I wish there were no I/O delay any more, that would be
nice.
--
David Kastrup
page update mechanism. I just remember that we had
>> problems last time round.
>>
>> -- David Kastrup
>
>
> I think it needs to point to documentation that actually exists, since
> we won't be building for the development version. There's no reason
> not to
c_define_gsubr (Super::type_p_name_, 1, 0, 0,
> ~~~^~~~~~
> (scm_t_subr) smob_p);
>
Ah that abomination. Sorry for seeing this onl
Thomas Morley writes:
> Am So., 23. Feb. 2020 um 13:50 Uhr schrieb Thomas Morley
> :
>>
>> Am So., 23. Feb. 2020 um 13:14 Uhr schrieb David Kastrup :
>
>> > Ah that abomination. Sorry for seeing this only now. You'll need t
lots with GNU make"
> https://www.gnu.org/software/make/manual/html_node/Job-Slots.html
But that still doesn't solve the problem that the database approach of
lilypond-book does not work for running multiple lilypond-book jobs in
parallel.
--
David Kastrup
Dan Eble writes:
> On Feb 23, 2020, at 09:11, David Kastrup wrote:
>>
>>> "Sharing Job Slots with GNU make"
>>> https://www.gnu.org/software/make/manual/html_node/Job-Slots.html
>>
>> But that still doesn't solve the problem that the d
>
>
> FWIW, on my Fedora31 box, Intel® Core™ i5-4440 CPU @ 3.10GHz with 8
> Gigx of RAM, on the translation branch as of
> 5149cf967a8b9f5c01696a3bd994c5ca6f2fa473 (Fix some dead links in
> German documentation):
>
> -*- mode: compilation; default-directory: "~/GIT/Traduc/&
Jean-Charles Malahieude writes:
> Le 23/02/2020 à 16:38, David Kastrup a écrit :
>> Why wouldn't either of you be using the CPU_COUNT= ... environment
>> variable for letting lilypond-book run parallel jobs of lilypond ?
>>
>
> I forgot to mention that I&#
r realtime. It will not buy us significantly
smaller billable user time.
So its main payoff would be if we keep doing the bulk of our
test/integration work on private computers rather than virtualised CPUs.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> I tried what happens if one concats all texi/tely files together, and
>> runs lp-book on them.
>>
>> The result is 25 minutes of purely CPU bound grinding (this is with
>> Guile 2.2). Then building the r
is less harmful than aborting.
It's conceivable that this could be turned into a programming error,
namely something that should not occur but does not keep LilyPond from
taking a reasonable course of action.
--
David Kastrup
Pierre-Luc Gauthier writes:
> Hi David,
>
> Thanks for your answer.
>
> Le lun. 24 févr. 2020 à 17:25, David Kastrup a écrit :
>> -DNDEBUG
>
> Sadly, I'm not a programmer although I compile LilyPond weekly. I
> tried adding the -DNDEBUG flag in many places
want to refer to a context, use ‘@code{}’ in
the main text and ‘@rinternals{}’ in the ‘@seealso’.
--
David Kastrup
;
>>
> I know it says
>
> /usr/bin/ld: final link failed: No space left on device
> collect2: error: ld returned 1 exit status
>
> but I have plenty. I moved the build dir to a place I know I have
> plenty of space (just to be sure) and still get the same problem.
>
> Could this be some permission issue?
>
> I don't know how to get more logging here.
First, the build dir of patchy is somewhere else. Second, my
.lilypond-patchy-config contains
[runner_limits]
RLIMIT_CPU = 1000,2000
[self_limits]
RLIMIT_FSIZE = 25600
and particularly the last number (whatever it is set to on your system)
looks like it could cause trouble for you.
--
David Kastrup
more days of delay. 2.18.0 was released in December 2013. I
think we should be able to afford a few more days to have everybody
righteously proud of what we push out.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic p
support for the GNU project.
That may have affected the speed with which they are progressing with
that project.
At any rate, there is nothing wrong with trying to get more information
for arriving at a decision, so it would be great for you to figure out
what the current plans regarding project h
Pierre-Luc Gauthier writes:
> Le mar. 25 févr. 2020 à 04:54, David Kastrup a écrit :
>> ./configure CXXFLAGS=-DNDEBUG
>
> Thanks David.
> It compiles fine.
>
> Now engraving hangs at the same place but a bit differently :
>
> Calculating page and line breaks (8 p
across the finishing line?
--
David Kastrup
>From 2b318c869bb0f968b25c6287cb46e5d63c1cf7b5 Mon Sep 17 00:00:00 2001
From: David Kastrup
Date: Wed, 26 Feb 2020 02:07:27 +0100
Subject: [PATCH] Get download sizes show up correctly
This calculates download sizes as the last step of HTML generation
or verifying the downloads as being untampered. If
we put in md5sums (for example), this fixup would of course not work as
an approach and we could not allow for circular dependencies to be
broken by patchup.
--
David Kastrup
Jean-Charles Malahieude writes:
> Le 26/02/2020 à 02:18, David Kastrup a écrit :
>>
>> Anybody want to see what it takes to get this across the finishing line?
>>
>
> Just a nitpick: the sizes are in Documentation/web/manuals.itexi.
> I'll have a loo
t in not trying to evaluate the feedback they bother to
provide. Whether we are realistically in a position to make our project
adopt it is a different question, but I see no point in ignoring it.
>> Let me see if I can get more information on when they plan to bring
>> the hosting platf
Han-Wen Nienhuys writes:
> On Wed, Feb 26, 2020 at 11:06 PM David Kastrup wrote:
>
>> > There is also a bunch of verbiage about how tracking tags are evil.
>> > (lilypond.org has been running Google Analytics for 15 years or so).
>>
>> Because?
>
>
ithout size currently as far as I can tell: it should not be
too much work to reorganise size indications once I am finished, to get
more of them).
--
David Kastrup
Federico Bruni writes:
> Il giorno gio 27 feb 2020 alle 02:10, David Kastrup ha
> scritto:
>> For example, try downloading any French documentation from
>> <http://lilypond.org/doc/v2.19/Documentation/web/notation.fr.html> if
>> your browser locale is not F
the user away from Scheme rather than to it, so it
might not fit your palate.
Just take a look at what you see LilyPond doing and whether you can
think of something, then ask on the list whether it is a good idea (most
ideas will likely have problems in design or execution that list people
can advise about).
--
David Kastrup
Han-Wen Nienhuys writes:
> On Thu, Feb 27, 2020 at 4:17 PM David Kastrup wrote:
>
>> Does anybody have a better idea than that?
>
> couldn't we rename the localized downloads as
>
> notation_de.pdf
>
> and then link to them explicitly?
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> On Thu, Feb 27, 2020 at 4:17 PM David Kastrup wrote:
>>
>>> Does anybody have a better idea than that?
>>
>> couldn't we rename the localized downloads as
>>
>> notation_de.pdf
Federico Bruni writes:
> Il giorno gio 27 feb 2020 alle 16:17, David Kastrup ha
> scritto:
>> The thing is a nightmare to diagnose since our web server settings
>> tell
>> the server to serve xxx.it.extension in preference of xxx.extension if
>> your browse
o
start rolling 2.20 from Saturday noon UTC, and he has green light to
upload on Sunday noon UTC. That leaves us with some window for
release-blocking objections (other than the obvious blocker of GUB
refusing to build, of course) without wasting too much effort. Or time.
--
David Kastrup
on branch on what happens to be the stable/2.20 and
master branches at a time shortly after the release.
Different issue, so will be done without a rush. Nobody is really going
to sue us for the indentation ending up in the release. I hope.
--
David Kastrup
y than, say, 2.21.37 (assuming that we don't cut 2.22
before reaching there).
Thank you for your understanding!
--
David Kastrup
re now at the point where 2.20 _and_ 2.21 are going
to be a thing rather soon. Assuming that things like the Python3
migration don't cause more of a standstill for 2.21.0 than we imagine,
but then one can still decide to stop being disciplined until things are
fixed enough to get 2.21.0 done.
--
David Kastrup
Jean-Charles Malahieude writes:
> Le 29/02/2020 à 02:04, David Kastrup a écrit :
>> I've merged to stable/2.20. I'd say that Phil has the green light
>> to start rolling 2.20 from Saturday noon UTC, and he has green light
>> to upload on Sunday noon UTC. That
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
>> >
>> > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
>> > to be a thing rat
pond-book/out-test/suffix-texinfo.html < texi
Making input/regression/lilypond-book/out-test/tex-musicxml-file-options.tex <
lytex
Making input/regression/lilypond-book/out-test/tex-musicxml-file-options.pdf <
tex
Please check the logfile
/usr/local/tmp/lilypond/input/regression/lilypond-book/out-test/tex-musicxml-file-options.pdflatex.log
for errors
make[2]: *** [../../../make/lilypond-book-rules.make:38:
out-test/tex-musicxml-file-options.pdf] Error 1
make[1]: *** [GNUmakefile:22: local-test] Error 2
make: *** [GNUmakefile:333: test] Error 2
I think we had something like this fixed in master previously. Any idea
what I might be missing here?
--
David Kastrup
hes is so that
we can figure out at some later point of time what might have caused a
difference in workability.
Seems like we know this for this patch now.
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me ad
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 19:53 +0100 schrieb David Kastrup:
>> I am currently trying to merge translations and master. make test gives
>> me
>>
>> [...]
>> Making input/regression/lilypond-book/out-test/html-musicxml-file.html &l
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup:
>> dev/translation-merge
>>
>> Fails at make test (at least on my system).
>
> Ah, the merge re-instantiated some code for Python 2. The following
> diff fixes 'make test&#x
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup:
>> dev/translation-merge
>>
>> Fails at make test (at least on my system).
>
> Ah, the merge re-instantiated some code for Python 2. The following
> diff fixes 'make test
David Kastrup writes:
> Jonas Hahnfeld writes:
>
>> Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup:
>>> dev/translation-merge
>>>
>>> Fails at make test (at least on my system).
>>
>> Ah, the merge re-instantiated some code f
move to a different development
platform once we figure out where we are good to go.
All the best!
David
Start of forwarded message
From: David Kastrup
To: translati...@lilynet.net
Subject: [translations] Branches rededicated!
Date: Mon, 02 Mar 2020 23:
ds conceptually wrong, given that you want to use one of
> them (I didn't understand which one) for 2.20.1 - I don't think we want
> to have the Python 3 switch in there.
origin/translation-staging
--
David Kastrup
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 21:40 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup:
>> > > dev/translation-merge
&g
Jonas Hahnfeld writes:
> Am Dienstag, den 03.03.2020, 11:05 +0100 schrieb David Kastrup:
>> > Only for the final outcome. 'git bisect' will still walk into (most of)
>> > stable/2.20 which is likely not what we want it to do. I'll try to have
>>
David Kastrup writes:
> Jonas Hahnfeld writes:
>
>> Am Dienstag, den 03.03.2020, 11:05 +0100 schrieb David Kastrup:
>
>>> > Only for the final outcome. 'git bisect' will still walk into (most of)
>>> > stable/2.20 which is likely not what we w
Jonas Hahnfeld writes:
> Am Dienstag, den 03.03.2020, 11:13 +0100 schrieb Jonas Hahnfeld:
>> Am Dienstag, den 03.03.2020, 11:05 +0100 schrieb David Kastrup:
>> > Jonas Hahnfeld <
>> > hah...@hahnjo.de
>> >
>> > > writes:
>> > &g
David Kastrup writes:
> Jonas Hahnfeld writes:
>> This gives me 6 rather small merge conflicts that I could easily
>> handle, plus skipping 4681e271ab and 41a35ee2dd (that are in master
>> anyhow). The result is at dev/translation-picking.
>> Now when merging this in
Jonas Hahnfeld writes:
> Am Dienstag, den 03.03.2020, 17:10 +0100 schrieb David Kastrup:
>> David Kastrup
> Sounds good to recycle the work.
>
>> >
>> > The history is yours, the tree is mine.
>>
>> Wait, wrong branch/HEAD.
>>
>> Chec
Jonas Hahnfeld writes:
> Am Dienstag, den 03.03.2020, 17:50 +0100 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>> > Perfect. I only restored the following files from the branch to keep
>> > the Portuguese
301 - 400 of 6220 matches
Mail list logo
