Bug Hunting Session
Bug 70667 - Notify libreoffice user list of API changes and motivate user to test extensions on dailies/beta
Summary: Notify libreoffice user list of API changes and motivate user to test extensi...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: difficultyBeginner, easyHack, skillScript
Depends on:
Blocks:
 
Reported: 2013-10-20 13:11 UTC by Björn Michaelsen
Modified: 2019-02-24 03:05 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Michaelsen 2013-10-20 13:11:46 UTC
When LibreOffice developers do adjustments to the UNO API (which is done carefully) they will mark the commit with the words "API CHANGE" so it can be marked in the release notes. Here are some examples:

 http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=API+CHANGE

It would be nice to create a git hook that triggers on these commits and sends a mail to the libreoffice user list at users@global.libreoffice.org:
- showing the body of the commit message
- a link to the commit for reference
- and kindly asking user to test if their extensions and scripts still work with the changes made by running a daily build from http://dev-builds.libreoffice.org/daily/ or alpha/beta releases of upcoming major versions.

The earlier a change gets notified, the easier it is to fix regressions or for extensions: to update to the extension to for the new major release on time. As a sideeffect this might give us more coverage and testing of daily builds, which hardly is a bad thing.
Comment 1 Björn Michaelsen 2013-10-20 13:13:27 UTC
AFAIK current git hooks can be found at:

 http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/git-hooks/core.git/hooks/update
Comment 2 Markus Mohrhard 2013-10-20 13:32:44 UTC
We also have the other option of integrating it into out other notifying scripts.

We already have a number of scripts running for each commit. Adding one more is easy. They can be found at http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/tree/ciabot
The new script would need to be plugged into run-libreoffice-ciabot.pl:79
Comment 3 Cor Nouws 2013-10-20 19:00:46 UTC
Hi,


In general a big plus, but ..

> It would be nice to create a git hook that triggers on these commits and
> sends a mail to the libreoffice user list at users@global.libreoffice.org:
> [...]

could this lead to a flood of mails with API changes to the users list, I mean more then a few a day?
I doubt if that is OK.
Comment 4 Björn Michaelsen 2013-10-20 21:02:37 UTC
@Cor: No, see the link:

 http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=API+CHANGE

shows its far less: around 2 per week on average, although some will come in bursts of 3-4 ....
Comment 5 Björn Michaelsen 2013-10-21 09:12:59 UTC
FWIW, an alternative would be to have the notification in regular intervalls (e.g. two weeks) and than collect what API changes have been done since the last notification (a bit like the gerrit digest mailer with a longer intervall). But TBH, I would like to leave the details to the implementer ...
Comment 6 Cor Nouws 2013-10-21 21:16:09 UTC
(In reply to comment #4)

> shows its far less: around 2 per week on average, although some will come in
> bursts of 3-4 ....

Fine. Incidental 'bursts' of that size won't be a problem of course.
Comment 7 tim 2013-10-28 16:30:39 UTC
Please bear in mind it isn't just fairly technical developers of 'extensions' that can be affected.  End-users with application developments of their own can also be affected. 

The details of many of the commit messages are incomprehensible to such as myself.  However, I well understand that changing a data type in a form control could affect my code.

I do understand it's difficult to please everyone, but I'm just trying to clarify some of the characteristics of your potential audience.
Comment 8 Björn Michaelsen 2013-10-28 18:27:35 UTC
(In reply to comment #7)
> Please bear in mind it isn't just fairly technical developers of
> 'extensions' that can be affected.  End-users with application developments
> of their own can also be affected. 
> 
> The details of many of the commit messages are incomprehensible to such as
> myself.  However, I well understand that changing a data type in a form
> control could affect my code.

The Good Thing is: You dont need to completely understand the commit message to test a daily build. Actually its a Good Thing if the tester isnt _too_ confident in "completely understanding" the commit message, as it can lead to the reader thinking: "ah, this cant possibly break my stuff, so Im not testing ..." (see also: http://www.youtube.com/watch?v=4XpnKHJAok8&feature=player_detailpage#t=1399s ). This is not what we want for three reasons:
- if the reader tests the change, he/she is not only testing the specific scenario, but also other stuff
- if the reader is confident in understanding the message, but misunderstands, there is less testing, which is not what we want
- the the reader is confident and understands the message right, the message might still be wrong or incomplete. Again, testing would help the case here.
Comment 9 Robinson Tryon (qubit) 2015-12-14 06:49:43 UTC Comment hidden (obsolete)
Comment 10 Robinson Tryon (qubit) 2016-02-18 14:52:18 UTC Comment hidden (obsolete)