> That particular patch is confusing as it's claiming to be about giving > developers control, but it's changing a file in the release scripts to > take the control away from the app developers... the exact opposite of > your opening paragraph.
> I'm probably understanding it wrong, but then so are others. I read that criticism in the MR discussion, too, and I didn't get it. Here's how I understood the patch and its aims: 1. We have some apps being released by teams/individuals, and some apps that rely on release-team 2. Jonathan wishes to promote the former as a culture because $positive_reasons and $current_trends 3. He believes this requires relevant files to live with the project repository, because it's what the teams generally care to work on - on the face of it, this seems sensible: if you want people to care you move stuff into their area of care 4. Yet we need things to keep working even while we refactor, so the release-team tooling needs to be able to update things in the repositories because of the apps that rely on release-team 5. This sequence of steps therefore starts with this patch Here's what's missing from the conversation: - Consensus-building on $positive_reasons and $current_trends (aka "change management is difficult") - Roadmap planning and roadmap visibility, so intermediary steps make sense in context - Agreeing on implementation strategies and best practices that achieve technical goals, afford flexibility across the range of different things different projects want to do, and so on This particular MR discussion failed largely because we were not collectively ready for a productive one, because the necessary leg work didn't happen. It's a classic case of trouble when initially docking an open source contribution, the good old "you sent your patch to lkml too late and should have asked for input earlier", but part of the responsibility also lies with everyone in the community who saw it elect this goal and didn't (a) spend some time thinking about it and preparing themselves for the discussion and (b) doesn't welcome it when it comes. Best regards, Eike Hein - KDE e.V. vice president, treasurer
