Daily Archives: Tuesday, October 15, 2013

  • Italy’s Emilia-Romagna region to save €2 mn. with OpenOffice

    Steve WoodsOpen Source, Open Standards, Politics, Tech

    Flag of Emilia-RomagnaThe administration of the Italy’s Emilia-Romagna region will switch to the open source OpenOffice productivity suite, Joinup reports. It thus hopes to save some €2 mn. euro on the licences that it would have spent for updating the ubiquitous MS Office suite. To prepare the migration, a three-month pilot involving 300 workstations has started at the region’s Directorate-General for Agriculture; all other regional departments will switch over to OpenOffice by the end of 2014. The region employs some 3,545 office staff.

    screenshot of OpenOffice splash screen

    The region is currently using a ten year-old version of MS Office. Instead of spending €2 mn. to upgrade 3,200 proprietary licences that are due to expire next year, the province decided to switch to OpenOffice which “offers basically the same functionality”.

    The region has set aside a budget of €220,000 for the switch to OpenOffice; this budget includes a staff training element.

  • Freeze date and Freeze Policy for Debian Jessie announced

    Steve WoodsLinux, Open Source, Tech

    Debian logoThe next version (8.0) of Debian GNU/Linux, codenamed Jessie, will be released in the first half of 2015. Debian’s developers have now announced the freeze date and freeze policy for Debian Jessie. An extract of the announcement (entitled “Bits from the Release Team (Jessie freeze info)”) is reproduced below.

    We are happy to announce that we will freeze Jessie at 23:59 UTC on the 5th of November 2014. To avoid any confusion around exactly how we will freeze, we have prepared a draft of the Jessie Freeze Policy in advance

    FREEZE POLICY

    Notable changes to the policy include:

    • Well-defined stages in the freeze policy at certain dates.
      • After 3 months of freeze, we will no longer allow remove packages to re-enter testing
      • We only accept fixes for important bugs in the first month.
      • etc.
    • Proactive automated removals 3 months into the freeze.
      • Note that bug-free packages will be removed if they (build-)depend on a RC-buggy, non-key package.
      • Also note the interval of 7 days between each removal run.
    • Inclusion of “do” and “don’t” guidelines for uploads and unblock bugs.
    • Currently, we are undecided whether to maintain “carte blanche” freeze exceptions at the start of the freeze. For now, exceptions are *not* included in the freeze policy (i.e. do *not* rely on them). This means that changes have to migrate to testing *before* the freeze date if they are to be included in the release.
      • *If* such exceptions are added, they will *not* apply for packages where migration would change the “upstream” version.
      • Native packages are at a disadvantage here, since all uploads of native packages are considered a new “upstream” version.
      • It should go without saying, but “urgency” abuse is not an acceptable way of getting your latest changes into the release.
      • It should also go without saying that embedding a new upstream release in a patch just to get a such “carte blanche” exception is also considered abuse.

      As noted we are dealing with a draft, so there may be changes to the actual freeze policy. Should we change the policy in a substantial way, this will be included in subsequent “bits”.