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