Than you *very* much for the excellent and detailed explanation. That clears up a lot of things for me about the process.
Follow-up... In the bug UI, is there an easy way to get a list of bugs that have been patched/fixed in master, that a user like me could browse, and pick certain ones that I could then test and if confirmed fixed, could request be back-ported (if they haven't been already)? I would be very happy to participate in this manner, but honestly, the bug UI is a bit daunting, so anything that makes this easier for non devs would be very welcome for technically inclined non-devs like yours truly. Thanks again for taking the time to explain this so clearly. On 10/3/2014 8:26 PM, V Stuart Foote <vstuart.fo...@utsa.edu> wrote: > @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: users+unsubscr...@global.libreoffice.org 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
