LyX 2.4.0

Daniel xracoonx at gmx.de
Mon Dec 20 08:37:20 UTC 2021


On 2021-12-19 17:18, Richard Kimberly Heck wrote:
> On 12/18/21 08:21, Daniel wrote:
>> On 2021-12-14 10:45, Daniel wrote:
>>> On 14/12/2021 10:34, Richard Kimberly Heck wrote:
>>>> On 12/12/21 08:55, 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
>>>>>
>>>>> 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. I guess it was communicated on some internal list.)
>>>>
>>>> It appears that JMarc's recent changes have introduced some serious 
>>>> bugs. Unsurprisingly. So there is probably some leeway for these 
>>>> patches. I'll also try to have a look.
>>>>
>>>> If you have the time, it would be really helpful to re-target bugs 
>>>> that clearly are NOT format changes. Those can definitely wait until 
>>>> 2.4.1.
>>>>
>>>> Riki
>>>
>>> It is a bit more complicated, I think. There are non-format changes 
>>> that are (arguably) improvements on new features introduced in 
>>> 2.4.0dev. Wouldn't it be odd to introduce such new features without 
>>> the improvements in the first place?
>>>
>>> One concrete example are the new drop-down buttons called 
>>> "DynamicMenu" [sic]. Currently, they aren't customizable but one of 
>>> my patches makes them customizable.
>>>
>>> Daniel
>>>
>>
>> Down to 16 bugs. Does that seem manageable for you?
>>
>> 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
>>
>> Otherwise, I can try to take a look again.
> 
> I'll have a look this week. We still have a bit of time, as JMarc's big 
> patch gets tested.
> 
> Riki

Thanks! However, now I remembered another reason for my unease with 
pushing some enhancement down the line. Sometimes I got comments that a 
feature is too much of a change for a minor version despite it not being 
a format change.

I guess normally that is a good reason to consider such a change in a 
mayor version then. However, since this mayor version seems somewhat 
special, will there be some relaxing about introducing such new features 
in minor versions?

Daniel





More information about the lyx-devel mailing list