LyX 2.4.0

[Daniel]

On 2021-12-12 15:18, Scott Kostyshak wrote:
> On Sun, Dec 12, 2021 at 02:55:51PM +0100, Daniel wrote:
>> On 2021-12-10 06:52, Richard Kimberly Heck wrote:
>>> On 12/9/21 03:00, Daniel wrote:
>>>> On 2021-12-07 23:04, Richard Kimberly Heck wrote:
>>>>> On 12/6/21 22:00, Daniel wrote:
>>>>>> On 2021-12-06 22:58, Richard Kimberly Heck wrote:
>>>>>>>> Do you mean by "safe enough to include" that they
>>>>>>>> should be more or less done? For example, there were
>>>>>>>> a couple of tickets where you said that you take a
>>>>>>>> look at while there were things that needed to be
>>>>>>>> done still. I take it that this is not going to
>>>>>>>> happen, right?
>>>>>>>
>>>>>>> Safe as in: Not likely to cause bugs we need to solve
>>>>>>> before the release. Once we hit beta, we are in
>>>>>>> bug-fixing mode, and the fewer the better.
>>>>>>>
>>>>>>> Riki
>>>>>>
>>>>>> Okay. (Though it is not what I have expected beta to be. I
>>>>>> would have thought that software in beta is actually
>>>>>> "likely" to have bug rather than unlikely. I would have
>>>>>> thought the latter is release candidate.)
>>>>>
>>>>> Well, we know beta will have bugs---indeed, we know of some
>>>>> already---but the idea is that we do our best not to create new
>>>>> bugs at that point. New features bring new bugs. That's why beta
>>>>> release goes with feature freeze.
>>>>>
>>>>> That said, at the moment we're talking about what will make it
>>>>> into beta, so some risk is all right.
>>>>>
>>>>> Riki
>>>>
>>>> I have to do the tickets one by one. Should I post them here (with
>>>> reference) on the list, create a (temporary) meta bug with the list
>>>> of tickets, or just ping you on the tickets themselves?
>>>
>>> Maybe assemble a list of them, and then post it here. I'll see it, I hope!
>>>
>>> You could also add a 'triage' keyword to the bugs themselves. I've used
>>> that for this kind of purpose.
>>>
>>> Riki
>>
>> Here is a list of enhancements with milestone 2.4.0 and patches. I guess it
>> is worthwhile to go though them anyway and either apply or re-target them:
>>
>> https://www.lyx.org/trac/query?status=accepted&status=assigned&status=new&status=reopened&description=~&reporter=~&summary=~&milestone=2.4.0&keywords=~patch&type=enhancement&col=id&col=summary&col=keywords&col=reporter&col=status&col=type&col=severity&desc=1&order=id
> 
> Thanks, Daniel. I will try to find time to take a look at one or two of
> those next week.
> 
>> I will not manage to do more than give you this list. Maybe you just ask me
>> if something is unclear that seems more efficient since you will look at
>> them carefully anyway? I could also give more info on them but that is as
>> much as I can do for this weekend. (Maybe I missed the road map but some
>> warning would have been helpful a bit in advance.
> 
> This release cycle is a bit crazy due to unusual circumstances. At this
> point I think the idea for 2.4.0 is to "get it out" without being as
> careful or methodical as we usually are. That is just my opinion though.
> 
> That said, I can understand your frustration since you've put in so much
> work and you have not gotten timely reviews and it would be a shame not
> to see a lot of your work in 2.4.0. All I can say is "thank you"
> sincerely for your work and "I'm sorry" for not helping with reviewing
> your patches.
> 
>> I guess it was
>> communicated on some internal list.)
> 
> Nothing on the internal list. The internal list is rarely used and
> certainly not for release-related issues.
> 
> Scott
Thanks. That is all fine. No worries!

As far as I understand how it works with LyX development currently is 
that people work more or less on their own on things they have a rather 
good grip of with only minor reviews (because of 
time/priorities/interest). I often have quite unfinished patches, 
especially when it comes to new features because of my limited 
programming knowledge (e.g. I never got my head around creating lyx2lyx 
when a file format change is involved even though people keep telling me 
how easy it is) and because I don't want to spend too much time on 
something people might not like or that I will have to do partly again 
because someone else's patch interferes (and I am not particularly good 
with git either). So, my expectations concerning my patches are 
naturally low (though I sometimes get carried away if I like something).

All I wanted to do is explain why things are as they are from my side 
and lower the risk a bit that a feature patch that might actually be a 
good idea for 2.4.0 gets just overlooked.

Daniel