Re: [libreoffice-users] Re: How to handle regressions

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.Foote@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+unsubscribe@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