Development/Hard Hacks

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

• Wiki Home
• Development
• Design
• QA
• Events
• Documentation
• Website
• Localization
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Overview
• Reporting Bugs
• How to build
• Code Overview
• Git Commands
• Debugging
• EasyHacks
• Release Plan
• FAQ
• Developers
• Extensions
• → Open Issues

This page (may) contain content that is old and/or out of date. If you have experience in this area, please review this page for accuracy. Reason: links aren't updated since ages, maybe these bugs should be tracked by a RSS feed with a whiteboard keyword

About Hard Hacks

Introduction

This page is dedicated to collecting "Hard Hacks" for our more experienced developers to take on as soon as they go from the proposed state to the confirmed state (see process section). These hacks are meant to not last long in the "hard hack" stage, instead they are meant to quickly be assigned to a developer -- or more likely willingly accepted by a developer -- during conference calls. In most cases a hard hack should be assigned to a developer in less than a month and a patch should be committed in no longer than another month. If the list of hard hacks gets too long without developers being assigned, the process of accepting proposed hard hacks as official hard hacks stops until the back log is handled. This list is meant to be a temporary solution until we are able to correctly prioritize bugs in Bugzilla.

What is a hard hack?

Hard hacks should meet the below requirements:

1. Be relatively annoying for a significant amount of people
2. Be relatively difficult to solve and/or track down
3. Crashes/data loss are good candidates but not necessary
4. Backtraces should be done on proposed hard hacks before they become accepted hard hacks
5. Enhancement requests should NOT be on the list

Process

The process is quite simple, everyone is welcome to nominate a hard hack as a proposed hard hack by adding the Bug # as well as your name to the table below, this list will then be the basis of our bi-weekly QA discussion about hard hacks, where we then will collectively bring an appropriate number of hacks from the proposed section to the confirmed section. Please do not put bugs immediately in the accepted hard hacks table, this only makes the process messy and unreliable.

Joining QA Call

As mentioned above the QA conference call is made bi-weekly, usually on a Friday at 1400 GMT. Please join the QA mailing list where you'll receive an email bi-weekly detailing the date/time and agenda for the next meeting.

Hard Hack Lists

Current Hard Hacks

Bug # - Summary	Component	Assigned To	Comments

Proposed Hard Hacks

General

Bug # - Summary	Nominated By	Comment
tdf#36976 Add option to disable the automatic popping up of toolbars	Rainer Bielefeld 2013-02-21T16:17:24 (UTC)	Everybody who works with Draw (-Elements) always is nearby madness because of this very old (OOo 2) problem.
tdf#41436 FORMATTING: User style not transferred with copy / paste to other document	Rainer Bielefeld 2013-02-22T06:25:47 (UTC)	Well, it seems to affect only 1 user in the universe, but it makes Draw (and Impress) a toy instead of a tool.