@Charles, *, Tanstaafl wrote > Also, I'm confused... > > Jan-Marek in the bug comment on August 17th - well before the 'Hard code > freeze' on September 1st for 4.3.2 (released on Sept 22nd - said that > the patch would show up in the daily builds after that. > > So, I'm not complaining, I'm just asking - can someone who understands > the dev process explain why this fix did not make it into 4.3.2?
No worries, it can get a bit confusing about what commits are where and when. His "would show up in the daily builds" refereed only to master branch. To be clear, in the normal flow of things, majority of development is made by commits onto the master branch. That includes new features, or UX/UI tweaks or even patches to repair or revert regressions. The in-line field edits have been available for testing in master since the commit in August. So where it gets confusing is the master's relationship with prior releases. At present we have the 4.2 branch nearing its final bug-fix release and then EOL a month later, and the 4.3 branch with its third bug fix in the works. While commits to master can and do break things, in order to keep the code stable, patches committed to master require additional review and deliberation before being back-ported to a prior branch. As needed some work will be done directly on the older branches--but most is integrated into master first and ideally are fully tested there. Some times if dealing with an obvious regression with simple correction, the developer will put up the back-port for review immediately, but usually just one release back. At times the issue has technical dependencies and requires review and validation, and only then will the back-port be posted and again reviewed before it is committed. But occasionally the dev will simply overlook a good opportunity to resolve an issue on branches other than master--which is understandable as most developers are forward looking and framing the work to tackle the next feature or issue in queue. And that is where the user and QA community comes in, we have to stay up with the issues on the forum and in BZ and occasionally make comment regards opportunity that might otherwise be missed. For this issue--despite being on the 4.2 Most Annoying Bug list--once patched the back-port to 4.2 or to 4.3 for the in-line field editing was not pursued. In fact it was only proposed yesterday, meaning it missed 4.3.2 testing and build cycle. But when committed to the branch should make the 4.3.3 bug-fix cut. And, technically, it could still make the 4.2.7 final release, but that requires an exceptional approval by three devs or the Engineering Steering Committee. Jan-Marek G.'s proposed backport to 4.3 branch for the in-line field edits are up for code review, each of these is a separate facet of the patch needed for 4.3 (and possibly 4.2) as already implemented in master since August. https://gerrit.libreoffice.org/11779 https://gerrit.libreoffice.org/11780 https://gerrit.libreoffice.org/11781 https://gerrit.libreoffice.org/11782 If there are no technical issues, since the patch put into master in August was sound they'll likely be approved and committed in time for the next 4.3 release--but available for testing in context on "nightly" builds of the 4.3 branch once committed, i.e. they should be checked by users and QA for continued proper function. Hope that was clear enough for all. Stuart -- View this message in context: http://nabble.documentfoundation.org/How-to-handle-regressions-tp4124391p4124855.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
