Feeds

Appnovation Technologies: Appnovator Spotlight: Tony Nguyen

Planet Drupal - Mon, 2017-08-14 11:03
Appnovator Spotlight: Tony Nguyen Meet Tony Nguyen, our Manager of Product R&D from Vancouver, BC. 1. Who are you? What's your story? I'm Tony Nguyen and I manage the Product Research & Development team with the osCaddie R&D being our main project. I'm originally from New Zealand and moved to Vancouver just over three years ago and have been with Appnovation for two of...
Categories: FLOSS Project Planets

Tim Retout: Jenkins milestone steps do not work yet

Planet Debian - Mon, 2017-08-14 10:57

Public Service Announcement for anyone relying on Jenkins for continuous deployment - the milestone step plugin as of version 1.3.1 will not function correctly if you could have more than two builds running at once - older builds could get deployed after newer builds.

See JENKINS-46097.

A possible workaround is to add an initial milestone at the start of the pipeline, which will then allow builds to be killed early. (Builds are only killed early once they have passed their first milestone.)

Going by the source history, I reckon this bug has been present since the milestone-step plugin was created.

Categories: FLOSS Project Planets

Free Software Directory meeting recap for August 11th, 2017

FSF Blogs - Mon, 2017-08-14 10:53

Every week free software activists from around the world come together in #fsf on irc.freenode.org to help improve the Free Software Directory. This blog recaps the work we accomplished at the Friday, August 11th, 2017 meeting.

This week we improved tens of packages, with some chosen based on the theme of encryption software, and others chosen because they had simply been waiting long enough. It wasn't all work, though, and there were wide ranging topics of conversation. adfeno discussed a limitation of federation, specifically that in order work for it to work, you need many servers with consistent uptime. We also had some first time attendees to the Directory meeting, Elon_Satoshi and kembrek, who we hope to see back next week.

Elon_Satoshi told us about their efforts to free game software. They were able to convince the developer to switch to a license that required the sharing of source code, but they weren't able to get the developer to use a free software license. The Directory meetings are always a great place to come to share insights, strategies, and programs for advancing free software.

If you would like to help update the Directory, meet with us every Friday in #fsf on irc.freenode.org from 12 p.m. to 3 p.m. EDT (16:00 to 19:00 UTC).

Categories: FLOSS Project Planets

Isovera Ideas & Insights: A Practical Guide to Configuration Management in Drupal 8

Planet Drupal - Mon, 2017-08-14 10:30
In this post we'll examine some common pitfalls developers and site owners face when learning the configuration management system in Drupal 8, as well as some practical tips and tricks to help you become a configuration management ninja.
Categories: FLOSS Project Planets

Acquia Developer Center Blog: Template Doesn’t Mean Cookie Cutter

Planet Drupal - Mon, 2017-08-14 09:11

The mere mention of website templates makes some clients bristle. Nobody likes being told they have to conform to a set of rules they feel weren’t written with them in mind. They also believe that their site will look like everyone else’s and not meet their unique needs.

Let’s start by dispelling that myth: that using templates means your site will look like everyone else’s.

Tags: acquia drupal planet
Categories: FLOSS Project Planets

Doug Hellmann: statistics — Statistical Calculations — PyMOTW 3

Planet Python - Mon, 2017-08-14 09:00
The statistics module implements many common statistical formulas for efficient calculations using Python’s various numerical types ( int , float , Decimal , and Fraction ). Read more… This post is part of the Python Module of the Week series for Python 3. See PyMOTW.com for more articles from the series.
Categories: FLOSS Project Planets

Mike Driscoll: PyDev of the Week: Brian E. Granger

Planet Python - Mon, 2017-08-14 08:30

This week we welcome Brian E. Granger (@ellisonbg) as our PyDev of the Week! Brian is an early core contributor of the IPython Notebook and now leads the Project Jupyter Notebook team. He is also an Associate Professor of Physics and Data Science at California Polytechnic State University. You can also check out what projects he is working on over at Github. Let’s take a few moments to get to know Brian better!

Can you tell us a little about yourself (hobbies, education, etc):

I am going to start with the fun stuff. Since high school I have been playing the guitar, swimming and meditating. It is hard to be disciplined, but I couldn’t survive without a regular practice of these things. Doing intellectual work, such as coding, for long periods of time (decades) is really taxing on the mind, and that spills over to the body. I truly love coding, but these other things are the biggest reason I am still coding productively at 45.

In some ways, I look like a pretty traditional academic, with a Ph.D. in theoretical physics from the University of Colorado, Boulder, followed by a postdoc and now a tenured faculty position in the Physics Department at Cal Poly San Luis Obispo.

Along the way, I started building open-source software and that has slowly overtaken my entire professional life. Fernando Pérez (IPython’s creator) and I were classmates in graduate school; I began working on IPython around 2005. Fernando remains a dear friend and the best collaborator I could ever ask for. The vision for the IPython/Jupyter notebook came out of a late night discussion over ice cream with him in 2004. It took us until 2011 to ship the original IPython Notebook. Since then my main research focus has been on Project Jupyter and other open-source tools for data science and scientific computing.

Why did you start using Python?

I first used Python as a postdoc in 2003. My first Python program used VPython to simulate and visualize traffic flow. I had written a previous version of the simulation using C++, and couldn’t believe how Python enabled me to spend more time thinking about the physics and less about the code. Within a short period of time, I couldn’t bring myself to keep working in C++ for scientific work.

What other programming languages do you know and which is your favorite?

I used Mathematica in my physics research during the 1990’s. During graduate school and as a postdoc, I worked in C++. At the time, C++ was still pretty painful. I don’t miss that, but modern C++ actually looks quite nice.

Python remains my favorite language, mainly because it is so much fun and has an amazing community.

At the same time, these days I am doing a lot of frontend development for JupyterLab in TypeScript. For a large project with many contributors, having static type checking is revolutionary. TypeScript looks a lot like Python 3’s type annotations, and I can’t wait to begin using Python with static type checking.

What projects are you working on now?

Jupyter and IPython continue to take up most of my time. On that side of things I am working hard with the rest of the JupyterLab team to get the first version of JupyterLab released this summer.

In 2016, Jake VanderPlas and I started Altair, which is a statistical visualization package for Python based on Vega/Vega-Lite from Jeff Heer’s Interactive Data Lab at the University of Washington. While I spend less time on Altair, it, along with Vega/Vega-Lite are a critical part of the overall data ecosystem we are building for Jupyter users.

Which Python libraries are your favorite (core or 3rd party)?

Wow, there are so many. Pandas brought Python to the data world. I love the API design of the libraries that Matt Rocklin has built (Dask, multipledispatch, toolz). In spite of healthy competition from all the new JavaScript based visualization libraries, Matplotlib remains indispensable.

Where do you see Python going as a programming language?

It won’t be long before we are all writing statically type-checked Python 3 code

Categories: FLOSS Project Planets

Michal Čihař: New projects on Hosted Weblate

Planet Debian - Mon, 2017-08-14 06:00

Hosted Weblate provides also free hosting for free software projects. The hosting requests queue was over one month long, so it's time to process it and include new project.

This time, the newly hosted projects include:

If you want to support this effort, please donate to Weblate, especially recurring donations are welcome to make this service alive. You can do them on Liberapay or Bountysource.

Filed under: Debian English SUSE Weblate

Categories: FLOSS Project Planets

Introducing QtMqtt

Planet KDE - Mon, 2017-08-14 03:35

Recently, we talked about how we’re broadening our offering towards the automation sector. In case you missed it, you can find all relevant information here as well as read our blog post here.

One of the biggest challenges in starting an automation project is to build a suitable communication stack. MQTT has received more and more popularity over the last years for managing telemetry data (i.e. collecting data from sensors, health status of devices etc.). This is why we are now extending our portfolio to further help and simplify the development workflow.

What is MQTT

MQTT describes itself as follows:

It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.”

Using a publisher-subscriber methodology puts the routing responsibility towards the server (or in this context called “message broker”), which all clients connect to. Multiple levels of service quality can be specified to guarantee message delivery.

The connection itself usually builds on top of a TCP connection. However, it can use any ordered, lossless and bi-directional communication method.

How QtMqtt Fits Into the Picture

QtMqtt is a client implementation, which can be used for creating devices to send, but also to monitor solutions for receiving and managing data. QtMqtt does not focus on the broker side.

One important item to mention is that we aim to have QtMqtt fully specification compliant compared to other solutions. This implies support for

  • Protocol level 3.1 and 3.1.1 (prominently known/referred as 4)
  • All QoS levels
  • Wildcards
  • Authentication
  • SSL connections
  • Last Will support

Let ‘s dig a bit deeper and discuss how you actually use QtMqtt in your project.

Publishing data:

QMqttClient publisher;
publisher.setHostname(“some.brokerlocation.com”);
publisher.setPort(1883);
publisher.connectToHost();

publisher.publish(“sensor_1/dataset/foo”, “values”, qosLevel);

Receiving data:
QMqttClient subscriber;
subscriber.setHostname(“some.brokerlocation.com”);
subscriber.setPort(1883);
subscriber.connectToHost();
. . .
QSharedPointer<QMqttSubscription> sub = subscriber.subscribe(“sensor_1/#”, qosLevel);
connect(sub.data(), &QMqttSubscription::messageReceived, [&](QMqttMessage msg) {
qDebug() << “New Message:” << msg.payload();
});

Security

It is crucial for any automation solution today to make sure that all communication is secure and safe. QtMqtt provides two means to achieve this:

  1. Authentication via username and password when a connection is established.
  2. Using SSL/TLS sockets as connection channel.

For the latter case, we can utilize QSslSocket as provided by Qt Network. As a convenience, QMqttClient has another member called connectToHostEncrypted() which behaves similar to QSslSocket‘s argument list.

Extending QtMqtt

While MQTT is mostly used via TCP, it isn’t hardwired to it. QtMqtt allows you to specify additional transport methods, which are based on either QIODevice or QAbstractSocket. This implies that you can create your own transport and pass it over to QMqttClient before establishing a connection.

One concrete example is to use MQTT over websockets, for which Qt provides a separate module. QWebsocket is not based on QAbstractSocket due to different means of sending and receiving data. However, the specification is very clear on how MQTT data has to be pushed via websocket (send as binary data, must fit one datagram, etc.). Hence, a convenience class can be implemented. The specific showcase can be found in the examples of the QtMqtt module.

If you found this post interesting, feel free to get in touch with us and get access to a prerelease version.

The post Introducing QtMqtt appeared first on Qt Blog.

Categories: FLOSS Project Planets

Bryan Pendleton: Windows Update: 1, Fallout 4: 0

Planet Apache - Mon, 2017-08-14 00:37

I was starting to get interested in Fallout 4, which seems like a fairly interesting game.

But, I just got Windows 10 Creators Update installed.

Which, you might think, would be a good thing!

Unfortunately, it seems to have been the kiss of death for Fallout 4.

This is not the first bad experience I've had with the Fallout games. Fallout New Vegas was totally unplayable on my machine, as well.

When will I learn?

Categories: FLOSS Project Planets

Moshe Weitzman: Devel Releases 1.0 for Drupal 8.

Planet Drupal - Sun, 2017-08-13 20:00

With pride and pleasure, the Devel maintainers have released 1.0 for Drupal 8. Even at the ripe age of 14, Devel is an active, popular, and nimble project. Devel has been downloaded 3.5M times, and 200,000 sites currently report Devel as an enabled project. Devel’s whole codebase was deeply improved in this release. A few highlights are below, with annotated screenshots and gifs below each section. Please upgrade and report your success or failure using the new features!

Categories: FLOSS Project Planets

Aaron Morton: Limiting Nodetool Parallel Threads

Planet Apache - Sun, 2017-08-13 20:00

A handy feature was silently added to Apache Cassandra’s nodetool just over a year ago. The feature added was the -j (jobs) option. This little gem controls the number of compaction threads to use when running either a scrub, cleanup, or upgradesstables. The option was added to nodetool via CASSANDRA-11179 to version 3.5. It has been back ported to Apache Cassandra versions 2.1.14, 2.2.6, and 3.5.

If unspecified, nodetool will use 2 compaction threads. When this value is set to 0 all available compaction threads are used to perform the operation. Note that the total number of available compaction threads is controlled by the concurrent_compactors property in the cassandra.yaml configuration file. Examples of how it can be used are as follows.

$ nodetool scrub -j 3 $ nodetool cleanup -j 1 $ nodetool upgradesstables -j 1

The option is most useful in situations where disk space is scarce and a limited number of threads for the operation need to be used to avoid disk exhaustion.

Categories: FLOSS Project Planets

Justin Mason: Links for 2017-08-13

Planet Apache - Sun, 2017-08-13 19:58
Categories: FLOSS Project Planets

Sandipan Dey: Dogs vs. Cats: Image Classification with Deep Learning using TensorFlow in Python

Planet Python - Sun, 2017-08-13 18:28
The problem Given a set of labeled images of  cats and dogs, a  machine learning model  is to be learnt and later it is to be used to classify a set of new images as cats or dogs. This problem appeared in a Kaggle competition and the images are taken from this kaggle dataset. The original dataset … Continue reading Dogs vs. Cats: Image Classification with Deep Learning using TensorFlow in Python
Categories: FLOSS Project Planets

Dirk Eddelbuettel: RProtoBuf 0.4.10

Planet Debian - Sun, 2017-08-13 18:08

RProtoBuf provides R bindings for the Google Protocol Buffers ("ProtoBuf") data encoding and serialization library used and released by Google, and deployed fairly widely in numerous projects as a language and operating-system agnostic protocol.

A new releases RProtoBuf 0.4.10 just appeared on CRAN. It is a maintenance releases replacing one leftover errorenous use of package= in .Call with the correct PACKAGE= (as requsted by CRAN). It also integrates a small robustification in the deserializer when encountering invalide objects; this was both reported and fixed by Jeffrey Shen.

Changes in RProtoBuf version 0.4.10 (2017-08-13)
  • More careful operation in deserializer checking for a valid class attribute (Jeffrey Shen in #29 fixing #28)

  • At the request of CRAN, correct one .Call() argument to PACKAGE=; update routine registration accordingly

CRANberries also provides a diff to the previous release. The RProtoBuf page has an older package vignette, a 'quick' overview vignette, a unit test summary vignette, and the pre-print for the JSS paper. Questions, comments etc should go to the GitHub issue tracker off the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Categories: FLOSS Project Planets

Lars Wirzenius: Retiring Obnam

Planet Debian - Sun, 2017-08-13 14:49

This is a difficult announcement to write. The summary is if you use Obnam you should switch to another backup program in the coming months.

The first commit to Obnam's current code base is this:

commit 7eaf5a44534ffa7f9c0b9a4e9ee98d312f2fcb14 Author: Lars Wirzenius <liw@iki.fi> Date: Wed Sep 6 18:35:52 2006 +0300 Initial commit.

It's followed by over 5200 more commits until the latest one, which is from yesterday. The NEWS file contains 58 releases. There are 20761 lines of Python, 15384 words in the English language manual, with translations in German and French. The yarn test suite, which is a kind of a manual, is another 13382 words in English and pseudo-English. That's a fair bit of code and prose. Not all of it mine, I've had help from some wonderful people. But most of it mine.

I wrote all of that because backups were fun. It was pleasing to use my own program to guarantee the safety of my own data. The technical challenges of implmenting the kind of backup program I wanted were interesting, and solving interesting problems is a big part of why I am a programmer.

Obnam has a kind user base. It's not a large user base: the Debian "popularity contest" service estimates it at around 500. But it's a user base that is kind and has treated me well. I have tried to reciprocate.

Unfortunately, I have not had fun while developing Obnam for some time now. This has changed. A few years ago, I lived in Manchester, UK, and commuted by train to work. It was a short train ride, about 15 minutes. At times I would sit on the floor with my laptop on my knees, writing code or the manual. Back then Obnam was a lot of fun. I was excited, and enthusiastic.

In the past two years or so, I've not been able to feel that excitement again. My native language, Finnish, has an expression describing unpleasant tasks: something is as much fun as drinking tar. That describes Obnam in recent years for me.

Obnam has not turned out well, from a maintainability point of view. It seems that every time I try to fix something, I break something else. Usuaully what breaks is speed or memory use: Obnam gets slower or starts using even more memory.

For several years now I've been working on a new repository format for Obnam, code names GREEN ALBATROSS. It was meant to solve Obnam's problems as far as extensibility, performance, and resource use were concerned. It seems to have failed.

I'm afraid I've had enough. I'm going to retire Obnam as a project and as a program, and move on to doing something else, so I can feel excitement and pleasure again.

After some careful thought, I fear that the maintainability problems of Obnam can realistically only be solved by a complete rewrite from scratch, and I'm not up to doing that.

If you use Obnam, you should migrate to some other backup solution. Don't worry, you have until the end of the year. I will be around and I intend to fix any serious bugs in Obnam; in particular, security flaws. But you should start looking for a replacement sooner rather than later.

I will be asking Obnam to be removed from the Debian unstable and testing branches. The next Debian release (buster, Debian 10) won't include Obnam.

The Obnam mailing lists are kindly hosted by Daniel Silverstone, and they will remain, but later this year I will change them to be moderated. The Obnam git repository will remain. The web site will remain, but I will add a note that Obnam is no longer maintained. Other Obnam online resources may disappear.

If you would like to take over the Obnam project, and try to resolve the various issues, please contact me to discuss that.

Thank you, and may you never need to restore.

Categories: FLOSS Project Planets

Mike Gabriel: @DebConf17: Ad-hoc BoF: Debian for the Remote Desktop

Planet Debian - Sun, 2017-08-13 11:57

On Thursday at DebConf17, all people interested in using this or that Remote Desktop solution on Debian (as a server, as a client, as both) came together for a BoF.

Sharing about Usage Scenarios

Quite some time we informally shared with one another what technologies and software we use for remote access to Debian machines and what the experiences are.

The situation in Debian and on GNU/Linux in general is that many technical approaches exist, all of them have certain features and certain limitations. The composition of features and limitations finally lead the users to choosing one or another technology as his or her favourite solution.

The Debian Remote Maintainers Team

On the developers' side, Dominik George and I set up a packaging team for Remote Desktop related software in Debian. A packaging team that we invite everyone who is maintaining such software in the widest sense to join: https://qa.debian.org/developer.php?login=pkg-remote-team%40lists.alioth...

'DebianRemote' namespace on the Debian Wiki

For users of Debian, the group agreed, we need an overview page (on wiki.debian.org) that provides an entry point for Debian on the Remote Desktop. An entry point that provides user information as well as developer information.

A skeleton of this wiki page, I have just set up (thanks to Vagrant for taking some notes in Gobby during the BoF): https://wiki.debian.org/DebianRemote

However, the page still contains loads of FIXMEs, so the actual work only now really starts. Fill the template with content (and also adapt the template, if needed).

Everyone with experience and know-how about Remote Desktop on Debian systems is invited to share knowledge and improve this wiki namespace. (I will, at the earliest, start working on Arctica, X2Go and NX passages end of August, but I'll be also happy to find passages having been written down that I can review by then).

Tracking Debian Remote Issues in Debian BTS

At the BoF, also the following suggestions came up: The Remote Desktop experience on a GNU/Linux desktop or terminal server can be affected by all graphical applications available. Often it happens, that a change in this or that graphical application results in problems in remote sessions, but not so in local sessions. We agreed on filing and tagging such bugs accordingly. For new bugs, please file such bugs with the following BTS header at the top of your mail and always explain what remote desktop solution is being used when the bug appears:

Package: file Version: 1:5.19-2 Severity: important User: debian-edu@lists.debian.org Usertags: debian-edu Conclusion

Overall, I was quite happy that the BoF has been attended by so many people and to see that there is quite "a lobby" in Debian. Let's dive into the work and make Debian 10 the first Debian, that mentions the Remote Desktop in its release notes.

Let's, in fact, release Debian 10 as the first Debian with the official announcement as an operating system for the Remote Desktop (like the Fedora people did already for Fedora 20).

Categories: FLOSS Project Planets

Enrico Zini: Consensually doing things together?

Planet Debian - Sun, 2017-08-13 10:26

On 2017-08-06 I have a talk at DebConf17 in Montreal titled "Consensually doing things together?" (video). Here are the talk notes.

Abstract

At DebConf Heidelberg I talked about how Free Software has a lot to do about consensually doing things together. Is that always true, at least in Debian?

I’d like to explore what motivates one to start a project and what motivates one to keep maintaining it. What are the energy levels required to manage bits of Debian as the project keeps growing. How easy it is to say no. Whether we have roles in Debian that require irreplaceable heroes to keep them going. What could be done to make life easier for heroes, easy enough that mere mortals can help, or take their place.

Unhappy is the community that needs heroes, and unhappy is the community that needs martyrs.

I’d like to try and make sure that now, or in the very near future, Debian is not such an unhappy community.

Consensually doing things together

I gave a talk in Heidelberg.

Valhalla made stickers

Debian France distributed many of them.

There's one on my laptop.

Which reminds me of what we ought to be doing.

Of what we have a chance to do, if we play our cards right.

I'm going to talk about relationships. Consensual relationships.

Relationships in short.

Nonconsensual relationships are usually called abuse.

I like to see Debian as a relationship between multiple people.

And I'd like it to be a consensual one.

I'd like it not to be abuse.

Consent

From wikpedia:

In Canada "consent means…the voluntary agreement of the complainant to engage in sexual activity" without abuse or exploitation of "trust, power or authority", coercion or threats.[7] Consent can also be revoked at any moment.[8]»

There are 3 pillars often included in the description of sexual consent, or "the way we let others know what we're up for, be it a good-night kiss or the moments leading up to sex."

They are:

  • Knowing exactly what and how much I'm agreeing to
  • Expressing my intent to participate
  • Deciding freely and voluntarily to participate[20]

Saying "I've decided I won't do laundry anymore" when the other partner is tired, or busy doing things.

Is different than saying "I've decided I won't do laundry anymore" when the other partner has a chance to say "why? tell me more" and take part in negotiation.

Resources:

Relationships

Debian is the Universal Operating System.

Debian is made and maintained by people.

The long term health of debian is a consequence of the long term health of the relationship between Debian contributors.

Debian doesn't need to be technically perfect, it needs to be socially healthy.

Technical problems can be fixed by a healty community.

The Thomas-Kilmann Conflict Mode Instrument: source png.

Motivations

Quick poll:

  • how many of you do things in Debian because you want to?
  • how many of you do things in Debian because you have to?
  • how many of you do both?

What are your motivations to be in a relationship?

Which of those motivations are healthy/unhealthy?

  • healthy sustain the relationship
  • unhealthy may explode spectacularly at some point

"Galadriel" (noun, by Francesca Ciceri): a task you have to do otherwise Sauron takes over Middle Earth

See: http://blog.zouish.org/nonupdd/#/22/1

What motivates me to start a project or pick one up?

  • I have an idea for for something fun or useful
  • I see something broken and I have an idea how to fix it

What motivates me to keep maintaning a project?

  • Nobody else can do it
  • Nobody else can be trusted to do it
  • Nobody else who can and can be trusted to do it is doing it
  • Somebody is paying me to do it

What motivates you?

What's an example of a sustainable motivation?

  • it takes me little time?
  • it's useful for me
  • It's fun
  • It saves me time to keep something running that if it breaks when I or somebody else needs it
  • it makes me feel useful? (then if I stop, I become useless, then I can't afford to stop?)
  • Getting positive feedback (more "you're good" than "i use it") ?

Is it really all consensual in Debian?

  • what tasks are done by people motivated by guilt / motivated by Galadriel?
  • if I volunteer to help team X that is in trouble, will I get stuck doing all the work as soon as people realise things move fine again and finally feel free to step back?
Energy

Energy that thing which is measured in spoons. The metaphore comes from people suffering with chronic health issues:

"Spoons" are a visual representation used as a unit of measure used to quantify how much energy a person has throughout a given day. Each activity requires a given number of spoons, which will only be replaced as the person "recharges" through rest. A person who runs out of spoons has no choice but to rest until their spoons are replenished.

For example, in Debian, I could spend:

  • Routine task: 1 spoon
  • Context switch: 2 spoons
  • New corner case: 5 spoons
  • Well written bug report: -1 spoon
  • Interesting thread: -1 spoon
  • New flamewar: 3 spoons

What is one person capable of doing?

  • are the things that we expect a person to do the things that one person can do?
  • having a history of people who can do it anyway is no excuse: show compassion to those people, take some of their work, thank them, but don't glorify them

Have reasonable expectations, on others:

  • If someone is out of spoons, they're out of spoons; they don't get more spoons if you insist; if you insist, you probably take even more spoons from them
  • If someone needs their spoons for something else, they are entitled to
  • If someone gets out of spoons for something important, and nobody else can do it, it's not their fault but a shared responsibility

Have reasonable expectations, on yourself:

  • If you are out of spoons, you are out of spoons
  • If you need spoons for something else, use them for something else
  • If you are out of spoons for something important, and nobody else can do it, it's not your problem, it's a problem in the community

Debian is a shared responsibility

  • Don't expect few people to take care of everything
  • Leave space for more people to take responsibility for things
  • Turnover empowers
  • Humans are a renewable resource, but only if you think of them that way

When spoons are limited, what takes more energy tends not to get done

  • routine is ok
  • non-routine tends to get stuck in the mailbox waiting for a day with more free time
    • are we able to listen when tricky cases happen?
    • are we able to respond when tricky cases happen?
    • are we able to listen/respond when socially tricky cases happen?
    • are we able to listen/respond when harassment happens?
    • can we tell people raising valid issues from troublemakers?
  • in NM
    • it's easier to accept a new maintainer than to reject them
    • it's hard or impossible to make a call on a controversial candidate when one doesn't know that side of Debian
  • I'm tired, why you report a bug? I don't want to deal with your bug. Maybe you are wrong and your bug is invalid? It would be good if you were wrong and your bug was invalid.
  • even politeness goes when out of spoons because it's too much effort

As the project grows, project-wide tasks become harder

Are they still humanly achievable?

  • release team
  • DAM (amount of energy to deal with when things go wrong; only dealing with when things go spectacularly wrong?)
  • DPL (how many people candidate to this year elections?)

I don't want Debian to have positions that require hero-types to fill them

  • heroes are rare
  • heroes are hard to replace
  • heroes burn out
  • heroes can become martyrs
  • heroes can become villains
  • heroes tend to be accidents waiting to happen

Dictatorship of who has more spoons:

  • Someone who has a lot of energy can take more and more tasks out of people who have less, and slowly drive all the others away
  • Good for results, bad for the team
  • Then we have another person who is too big to fail, and another accident waiting to happen
Perfectionism

You are in a relationship that is just perfect. All your friends look up to you. You give people relationship advice. You are safe in knowing that You Are Doing It Right.

Then one day you have an argument in public.

You don't just have to deal with the argument, but also with your reputation and self-perception shattering.

One things I hate about Debian: consistent technical excellence.

I don't want to be required to always be right.

One of my favourite moments in the history of Debian is the openssl bug

Debian doesn't need to be technically perfect, it needs to be socially healthy, technical problems can be fixed.

I want to remove perfectionism from Debian: if we discover we've been wrong all the time in something important, it's not the end of Debian, it's the beginning of an improved Debian.

Too good to be true

There comes a point in most people's dating experience where one learns that when some things feel too good to be true, they might indeed be.

There are people who cannot say no:

  • you think everything is fine, and you discover they've been suffering all the time and you never had a clue

There are people who cannot take a no:

  • They depend on a constant supply of achievement or admiration to have a sense of worth, therefore have a lot of spoons to invest into getting it
  • However, when something they do is challenged, such as by pointing out a mistake one has made, or a problem with their behaviour, all hell breaks loose, beacuse they see their whole sense of worth challenged, too

Note the diversity statement: it's not a problem to have one of those (and many other) tendencies, as long as one manages to keep interacting constructively with the rest of the community

Also, it is important to be aware of these patterns, to be able to compensate for one's own tendencies. What happens when an avoidant person meets a narcissistic person, and they are both unaware of the risks?

Resources:

Note: there are problems with the way these resources are framed:

  • These topics are often very medicalised, and targeted at people who are victims of abuse and domestic violence.
  • I find them useful to develop regular expressions for pattern matching of behaviours, and I consider them dangerous if they are used for pattern matching of people.
Red flag / green flag

http://pervocracy.blogspot.ca/2012/07/green-flags.html

Ask for examples of red/green flags in Debian.

Green flags:

  • you heard someone say no
  • you had an argument with someone and the outcome was positive for both

Red flags:

  • you feel demeaned
  • you feel invalidated
Apologies / Dealing with issues

I don't see the usefulness of apologies that are about accepting blame, or making a person stop complaining.

I see apologies as opportunities to understand the problem I caused, help fix it, and possibly find ways of avoiding causing that problem again in the future.

A Better Way to Say Sorry lists a 4 step process, which is basically what we do when in bug reports already:

1, Try to understand and reproduce the exact problem the person had. 2. Try to find the cause of the issue. 3. Try to find a solution for the issue. 4. Verify with the reporter that the solution does indeed fix the issue.

This is just to say

My software ate
the files
that where in
your home directory

and which
you were probably
needing
for work

Forgive me
it was so quick to write
without tests
and it worked so well for me

(inspired by a 1934 poem by William Carlos Williams)

Don't be afraid to fail

Don't be afraid to fail or drop the ball.

I think that anything that has a label attached of "if you don't do it, nobody will", shouldn't fall on anybody's shoulders and should be shared no matter what.

Shared or dropped.

Share the responsibility for a healthy relationship

Don't expect that the more experienced mates will take care of everything.

In a project with active people counted by the thousand, it's unlikely that harassment isn't happening. Is anyone writing anti-harassment? Do we have stats? Is having an email address and a CoC giving us a false sense of security?

When you get involved in a new community, such as Debian, find out early where, if that happens, you can find support, understanding, and help to make it stop.

If you cannot find any, or if the only thing you can find is people who say "it never happens here", consider whether you really want to be in that community.

(from http://www.enricozini.org/blog/2016/debian/you-ll-thank-me-later/)

There are some nice people in the world. I mean nice people, the sort I couldn’t describe myself as. People who are friends with everyone, who are somehow never involved in any argument, who seem content to spend their time drawing pictures of bumblebees on flowers that make everyone happy.

Those people are great to have around. You want to hold onto them as much as you can.

But people only have so much tolerance for jerkiness, and really nice people often have less tolerance than the rest of us.

The trouble with not ejecting a jerk — whether their shenanigans are deliberate or incidental — is that you allow the average jerkiness of the community to rise slightly. The higher it goes, the more likely it is that those really nice people will come around less often, or stop coming around at all. That, in turn, makes the average jerkiness rise even more, which teaches the original jerk that their behavior is acceptable and makes your community more appealing to other jerks. Meanwhile, more people at the nice end of the scale are drifting away.

(from https://eev.ee/blog/2016/07/22/on-a-technicality/)

Give people freedom

If someone tries something in Debian, try to acknowledge and accept their work.

You can give feedback on what they are doing, and try not to stand in their way, unless what they are doing is actually hurting you. In that case, try to collaborate, so that you all can get what you need.

It's ok if you don't like everything that they are doing.

I personally don't care if people tell me I'm good when I do something, I perceive it a bit like "good boy" or "good dog". I rather prefer if people show an interest, say "that looks useful" or "how does it work?" or "what do you need to deploy this?"

Acknowledge that I've done something. I don't care if it's especially liked, give me the freedom to keep doing it.

Don't give me rewards, give me space and dignity.

Rather than feeding my ego, feed by freedom, and feed my possibility to create.

Categories: FLOSS Project Planets

Distribution management – how Upstream ensures Downstream keeps the Quality

Planet KDE - Sun, 2017-08-13 09:11

I read Emmanuele Bassi’s very interesting blog post about software distribution this week and thought a lot about it. Emmanuele kind of answers to a presentation by Richard Brown (from OpenSUSE fame). While I haven’t seen that presentation, I saw a similar one last year at the openSUSE conference and also talked with Richard about the topic. So I dare to think that I understand Richard’s arguments and even agree with most of them.

Nevertheless I want to share some of my thoughts on the topic from the perspective of KWin maintainership. KWin is more part of the OS stack, so distributing through means like Flatpack are not a valid option IMHO. As KWin is close to the OS, we have a very well integration with distributions. Plasma (which KWin is part of) has dedicated packager groups in most distributions, we have a direct communication channel to the distros, we know our packagers in large parts in person, etc. etc. So from the open source distribution model we are in the best category. We are better positioned than let’s say a new game which needs to be distributed.

So this is the background of this blog post. What I’m now going to do is to describe some of the issues we hit just over the last year with distributing our software through distros. What I will show are many issues which would not have been possible if we distributed it ourselves without a distro in between (for the record: this includes KDE Neon!). To make it quite clear: I do not think that it would be a good idea for KWin to be distributed outside distributions. While thinking about this topic I came up with a phrase to what we are doing: “Distribution management”.

We do lot of work to ensure that distributions don’t destroy our software. We actually manage our distributions.

Latest example: QML runtime dependency

Aleix created a new function in extra-cmake-modules to specify the QML runtime dependencies. Once it was available I immediately went through KWin sources, extracted all QML modules we use and added it to CMake, so that it’s shown when running CMake. Reference: D7273

This is a huge issue in fact. Plasma 5.10 introduced support for virtual keyboard in the lock screen. We had to add special code for handling that this runtime dependency is missing. I sent a mail to our distributions mailing list to remind distros to package and ship this dependency.

Obviously: if we distributed the software by ourselves this would not have been an issue at all. We would just bundle Qt Virtual Keyboard and be done. But as we are distributed through distributions we had to write special handling code for the case it’s missing and send out mails to remind distros to package it.

Incorrect dependencies – too many

Although we specify all required dependencies though CMake our distributions might add random other dependencies. For example KWin on Debian depended on QtWayland (both client and server), although KWin does not need the one or the other. This got fixed after I reported it.

This is of course a huge problem. A common saying about KDE is that it has too many dependencies and that you cannot install software on e.g. GNOME, because it pulls in everything and the kitchen sink. That’s of course true if distros add incorrect additional package dependencies.

Incorrect dependencies – too few

Of course the other side is also possible. One can have too few dependencies. Again the example is Debian, which did not make KWin depend on Breeze resulting in incorrect window decoration being set. That we depend on it at compile time is also following the “distribution management” as distros asked us to add all dependencies through CMake. So we did and made KWin optionally depend on Breeze. Of course such distribution management does not help if distributions don’t check the CMake output.

Also here if we distributed ourselves we would have compiled with all dependencies.

Outdated dependencies

Another very common problem is that distributions do not have the dependencies which we need and want to use. In case of KWin this especially became a problem during the Wayland port. For a very long time we had to keep Wayland compile time optional so that distributions like Slackware [1] could continue to compile KWin. When we turned it into a hard dependency we had to inform distros about it and check with them whether it’s working. Of course just because you inform distros does not mean that it will work out later on.

That we have distros with outdated dependencies is always a sore pain. Our users are never running the software which we are, never getting the same testing. We have to keep workarounds for outdated dependencies (e.g. KWin has a workaround for an XWayland issue fixed in 1.19) and that of course results in many, many bug reports we have to handle where we have to tell the users that their software is just too old.

Also we face opposition when trying to increase dependencies, resulting in distros consider dropping the software or to revert the changes.

Handling upgrades

Another reoccurring issue is handling updates. Our users are constantly running outdated software and not getting the bug fixes. E.g. Ubuntu 16.04 (LTS) ships with KWin 5.5. We currently support KWin 5.8 and 5.10. We constantly get bug reports for such old software and that’s just because it’s outdated in the distribution. Such bug reports only cause work for us and are a frustrating experience for the users. Because the only feedback they get is: “no longer maintained, please update to a current version”. Which is of course not true, because the distro does not even allow the user to upgrade.

Even when upgrading it’s a problem. We have to inform distros about how to handle the upgrade, of course that does not help, it fails nevertheless. We also never know what are allowed upgrade paths. For us it’s simple: 5.8 upgraded to 5.9, upgraded to 5.10, etc. If we would ship upgrades ourselves we could ensure that. But distros might go from 5.8 to 5.10 without upgrade to 5.9 ever. So we need to handle such situations. This was extremely challenging for me with a lock screen change in Plasma 5.10 to ensure the upgrade works correctly.

Random distro failure

An older example from Debian: during the gcc-5 transition KWin got broken and started to crash on startup without any chance to recover. This issue would of course not happen if we would have distributed KWin ourselves with all dependencies.

The experience was rather bad as users (rightfully) complained about the brokeness of KDE. I had friends asking me in person how it could be that we ship such broken software. Of course we were innocent and this was only in the distro. But still we (KDE) get the full blame for the breakage caused by the distro.

Useless bug reports

Thanks to distributions all crash reports we get are useless. The debug packages are missing and that’s pointless. Even if debug packages are installed mostly the crash point is missing. This is especially a problem with Arch as they don’t provide debug packages. In 2017 KWin got 71 bug reports which are marked as NEEDSINFO/BACKTRACE as the reported bug is pointless.

Misinformed maintainers

I don’t know how often I got asked this: should we change Qt to be compiled against OpenGL ES? Every time I was close to a heart attack as this would break all Qt applications for all NVIDIA users (at least a few years ago there was no GLES support in the NVIDIA driver). Luckily in most cases the maintainers asked (why me and not Qt?), but I remember one case where they did not ask and just rolled it out. With the expected result.

Thoughts

I could go on with examples for quite some time. But I think it should be obvious what I want to show: even for well integrated software such as KWin the distributions are not able to package and deliver correctly. As an upstream developer one has to spend quite some time on managing the distributions, so that the software is delivered in an acceptable state to the users.

Distros always claim that they provide a level of quality. Looking at the examples above I have to wonder where it is (granted there are positive exceptions like openSUSE). Distros claim they do a licensing check. That’s useful and very much needed, but is it required that openSUSE, Debian and Arch do the same check? Furthermore I personally doubt that distros can do more than a superficial check, they would never find a case where one copies code which is license incompatible.

Given the experience I have made with distros over the last decade working on KWin I am not surprised that projects are looking for better ways to distribute software. Ways where they can control the software distribution and ensure it works. Ways where their software is not degraded due to distros doing mistakes.

All that said, I do agree with Richard in most points, just don’t think it works. If everybody would use openSUSE than Richard would be right with almost all points. But the reality is that we have a bazillion of distributions doing the same work and repeating the same mistakes. Due to that I think that for software distribution Flatpack & Co. are a very valid approach to improve the overall user experience.

[1] Slackware for a long time did not have Wayland as that would need Weston and Weston depends on PAM which is only the optional fallback for no logind support, which Slackware of course does not have

Categories: FLOSS Project Planets

Mike Gabriel: @DebConf17: Work for Debian and FLOSS I got done during DebCamp and DebConf... and Beyond...

Planet Debian - Sat, 2017-08-12 20:44
People I Met and will Remember
  • Angela, my wife, I met daily on Jabber. Thanks for letting me go to this great DebConf17 conference and keeping our family up and running
  • Andreas asking people to either impersonate his wife or adoptive daughter for a photo shooting. You gave such a touching talk on Friday, together with Minh from Vietnam.
  • Holger for nagging us about stone age bugs in the Debian Blends package and the outdated software list in Debian Edu (Kernel 2.6.32 package are finally not mentioned anymore)
  • Vagrant, Foetini and Alkis for there efforts on LTSP and their success in Greece with bringing Debian into Greek schools
  • Tiago, Jerome and all the others from the local team, providing us with such great food and support. THANKS folks!!!
  • Enrico who showed my his 20 liner version of nodm aka lightdm-autologin-greeter (and also made me curious on staticsite)
  • Jonas Smedegaard for teaching me the solarized theme and loads of other things
  • Siri for being around and really having a stand for making Debian look more like a product
  • Dimitri John Ledkov for chiming in on Ayatana Indicators as next Indicators upstream for Ubuntu 18.04 LTS
  • Chrys for chiming on .desktop file proxying, meet you back in #arctica on Freenode
  • Sean for asking me daily, if my luggage had arrived (see below), as he shared the same fate during DebCamp
  • the owner of that nice shop where I bought loads of clothes while waiting for my luggage still stuck in Hamburg
  • Steven for looking into gcc compiler macros with me for nx-libs autotools conversion, also probably - luggage wise - the lightest traveller among us
  • Fabian for sharing is sadness and pain about the FLOSS non-situation in schools all over Quebec
  • Mario from New Zealand and Jos from the Netherlands chiming in on FLOSS and education on IRC after having watch my talk about Debian Edu / Skolelinux. Mario, we will soon ask you for opensourcing your teacher screen over WiFi solution...
  • Lior who thinks about bringing Debian Edu / Skolelinux to Israel. (That would be awesome!)
  • Rhonda for having time for my Debian Backports woes and probably having been quite forgiving ;-)
  • Bobby who is a font engineer during the week and (used to be) a cave explorer and mapper in his spare time
  • Ximin for providing deep insight in the key signing workflow and the caff approach to it
  • Daniel for sharing work experiences and nudging me to go with Remote Desktop stuff (out of pure personal interest *g*, of course, but still)
  • Tzfarir and Gunnar for a nice chat on the last night of DebConf
Topics I have worked on
  • Finding my luggage

    • After I had arrived at Montreal Airport, I found out that my luggage stayed in Hamburg
    • So the first 4.5 days, I was continuously busy with calling Lufthansa for package item tracking...
    • Go shopping twice, to update my plastic bag of fresh clothes...
  • MATE 1.18 in Debian

    • Finalize package builds of MATE 1.18 in Debian unstable (because of some GLib2.0 regression, thanks to Iain Lane for the prompt fix and upload)
  • Debian Edu

    • clear up src:package debian-edu regarding the task files related to Debian Pure Blends
    • this work is still in progress...
  • Debian Blends (esp. the blends-dev part of the blends src:package)

    • You can now have empty Depends: / Recommends: / Suggests: fields with the list of packages then starting in the next line.
    • It is now possible to have real Depends: fields in task files that become Depends: fields in debian/control. Packages targetting Depends: that are not in unstable get de-promoted to the Suggests: field in debian/control.
    • Tested with most available Debian Pure Blends meta-packages
    • I also pointed Daniel Pocock with his new GnuPG clean-room project towards Debian Pure Blends
  • Ring: A 'new' distributed video chat tool without mediating servers. Good concept, however, we could not get it to work on the DebConf campus.

  • Debian Design Team (which I am now a member of, I guess)

    • Dive into and out of the vision of a Debian Uniform set of packages, turning the collection of software in Debian into one thing.
    • Run my terminal applications now with the Base16 profile 'solarized-universal'. However, Debian Design will be much more than 16 colors in a console terminal.
    • Let's turn Debian into something like a potential product!
  • Debian Policy:

    • I even helped with a Debian Policy bug...
  • Skolab Groupware: Forking Kolab (v2) as a new project, named the Skolab Groupware. Instead of migrating my own mail server away from Kolab (v2), I chose continuing maintenance for it, at least for the core compoents:

  • nx-libs: Work on several PRs:

  • Weblate:

    • Become hosted by hosted Weblate for...
    • Ayatana Indicators
    • Arctica Project
    • Skolab Groupware

    Thanks to Michal Čihař for providing this fine translation service

Talks and BoFs Packages Uploaded to Debian unstable
  • mate-settings-daemon
  • mate-dock-applet
  • brisk-menu
  • mate-optimus
  • caja-actions
  • mate-common
  • mate-tweak
  • plank
  • freerdp (2x)
  • freerdp2
  • gosa-plugin-mailaddress
Packages Uploaded to Debian NEW
  • python-wither
  • lightdm-autologin-greeter
  • caja-rename

I also looked into lightdm-webkit2-greeter, but upstream is in the middle of a transition from Gtk3 to Qt5, so this has been suspended for now.

Packages Uploaded to oldstable-/stable-proposed-updates or -security
  • freerdp (1.1) (actually twice, one of them a security upload)
  • gosa-plugin-mailaddress
  • mate-themes
Other Package related Stuff
  • Prepare upload of caja-admin by asking for release tags upstream
  • Talk Clint Byrums into a fresh upload of the long not touch undistract-me package
  • Breed on different desktop layouts for Debian MATE (like in Ubuntu MATE)
  • Do quite a bit of GnuPG key signing
  • Update my consent with NM to pick up my work on collab-maint request processing again
Thanks to Everyone Making This Event Possible

A big thanks to everyone who made it possible for me to attend this event!!!

Categories: FLOSS Project Planets
Syndicate content