Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Than you *very* much for the excellent and detailed explanation.

That clears up a lot of things for me about the process.


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

Thanks again for taking the time to explain this so clearly.

On 10/3/2014 8:26 PM, V Stuart Foote <> 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

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

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.


View this message in context:
Sent from the Users mailing list archive at

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.