On Fri, Jul 28, 2023 at 10:21:50AM +0200, Pavel Sanda wrote: > > On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: > > I was going to write separately about format freeze. Is there anything > > anyone really wants to get in before we do that? > > Not me. > > > I'd like to add the BufferParam needed for #10049 even though I don't have > > Your call, though reading through the bug it seems to me that at this stage > even the concept is not entirely clear and thus the tentative changes to > BufferParams might be wrong/void in the end... > > > >Yuriy/Riki? #12814 - nesting in Outliner; there is a patch, but needs > > >either clarification or review > > > > I've posted a comment there. I think the patch is right. > > Ok, I'll comit then. > > > >Juergen/Enrico? #12831 - Udi proposes changing order how we output LaTeX > > >font options. Has a patch which looks legit to me, but I would like someone > > >to look over and give +1 > > > > It looks sensible to me, but I don't know that stuff well. > > Will wait for other comments. > > > >#12577 - complex code to improve source editor within LyX; only JMarc tried > > >to understand and failed; anyone wants to engage? > > > > This is too big for 2.4.0. I've retargeted to 2.4.1. But I'm not really sure > > about it. I'll have a look at it between now and then. > > For this particular case I think the question whether we *want* feature. In > other > words do we want to guarantee support and bugfixing the code we don't > understand > ourselves? :) > > > There is more generic question here though. I see that you flagged bunch of > bugs with *finished* patches (e.g. #12797) as for 2.4.1/2 and I would argue > that it's better to commit them now for the following reasons: > > - even if we release RC1 today we still have months for the testing because > there is no way translations can not be done in two weeks or so > > - if the bugs should bite us, better they bite us now. Ppl are more ready to > accept breakage with 2.4.0(/RC) than in later phases. > > > > >We need to freeze, then remerge strings and notify translators. I can > > >handle > > >the review of layouttranslation for 2.4. Riki, do you have preference when > > >to proceed? Before RC release or after? Remerge should be committed by > > >you, > > >otherwise we'll spend megabytes in large commits due to different outputs > > >of > > >different polib versions (tested). > > > > What did we do last time? Scott, do you remember? I guess my instinct would > > be to get translations into RC1, since that's one thing we'd want to have > > checked.
I don't have a specific memory, other than asking for help regarding the translations. > I don't think it matters that much, we just need to agree on something. > > The advantage having translations in RC1 is that it really looks like > release candidate. The disadvantage is you have to wait considerable time > for its release. I went through updating cs.po and it took me long weeks > to get through it in a lowkey speed. I think month waiting time is bare > minimum, not counting it's midsummer and ppl are on vacation. > > Another thing is that there would be advantage of having some release > just after you declare string freeze. Translators who can't compile LyX > on their own can actually look on the string/feature in the program, > because sometimes it's hard to translate if you don't see the context > of its use... > > Considering all above my suggestion would be to commit all bugs with > finished patches, declare freezes, get one quick release out (it can > be still beta5 not RC, if you prefer) and then wait for translations/ > feedback for last changes... The only showstopper for that is IMHO > to get #12576 done. I like the idea of getting a pre-release out right after file format freeze, and similar to Pavel I don't think the name is important (beta vs RC). Scott
signature.asc
Description: PGP signature
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
