On Mon, Dec 13, 2021 at 07:59:10AM +0100, Daniel wrote: > 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.
That all makes sense. Thanks, Daniel! Scott
signature.asc
Description: PGP signature
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
