Success Bot Says
- mordred on #openstack-sdks: “Finished the shade transition to pure REST away from client libs” [0]
- Tell us yours in OpenStack IRC channels using the command “#success <comment>”
[0] – http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2017-12-04.log.html
Community Summaries
- TC report 50 [0]
- POST /api-sig/news [1]
- Release countdown [2]
- Technical Committee Status Update [3]
- Resource Providers Update 45 [4]
Switching to Longer Development Cycles
Our self-imposed rhythm no longer matches our natural pace. Our elections, feature freezes feel like they’re around the corner, and due to that, we’re losing time from them, as multiple people have stated. The pace was designed around more people contributing full time to OpenStack, but lately, we have composite jobs, or were participating in multiple communities (which is great!).
It means:
- One OpenStack coordinated release per year.
- Maintain one stable branch per year.
- Elect PTLs once a year.
- One set of community goals per year.
- One PTG per year.
Any project that still wants to release often can use the cycle-with-intermediary release model [0]. At a minimum, we’ll release once a year. Teams can choose to revive midcycle if they need to meet more than the one PTG each year. We’ll have more time for community-wide goals, so we will have more time to complete or even set more ambitious goals.
This doesn’t simplify upgrades. While upgrading every year is incrementally better than being forced to upgrade every 6 months. The real solution is better support for skipping releases.
It also doesn’t give us LTS. The cost of maintaining branches is not really due to the number of them in parallel, it’s due to the age of the oldest one. The real solution here is being discussed by the (still forming) LTS SIG. Extending stability periods is per-project at this point, and the proposal has yet to address a coordinated stability period.
We’re doing a year because of the way the events are organized. It’s suggested to start for the Rocky release and have the single PTG in 2018 in Dublin. The release team is opening the discussion to the community, and the TC will give a final decision.
Various cons were expressed, like this causing a rush to get in code at the end of a release to avoid having to wait an entire year. Projects are also forced to do compatibility support for versioned APIs, config files, etc since projects would be unable to drop compatibility in an intermediate release. Projects like Grenade will have to support the cases of some projects doing intermediate releases, and those doing yearly.
For the people that spend 20% of their time contributing to OpenStack, it has been voiced that it takes time to get a feature merged and the current cycle makes it impossible. This longer development cycle could help with allowing more time for those people. Various people expressed that we should be looking at the root cause of helping our part-time contributors, as the length of the cycle is unlikely the cause. People who can only contribute 20% of their time are also likely to deal with rebase conflicts, instead of focusing on their code.
Having a year could also impose having intermediate releases so specifications that can have multiple times a year to be approved. If that’s the idea, however, then it’s causing stress on the core team by having to match these precise schedules, in which the proposal was aiming to ease. It was a concern that this more solves the problem of giving more opportunities to people to get their spec/new feature considered.
This topic has also been brought up by various times in the past. Someone noted Daniel Berrange’s thread [1]
Zuul Dashboard Available
In addition to the Zuul dashboard [0] showing the “Status”, there are additional tabs added. “Jobs” page shows a list of all jobs in the system and their descriptions. The “Builds” page lists the most recent runs. You can query pipeline, job, and project.
Security SIG
Following previous mailing list discussions [0], the Security Project will be changing into a Special Interest Group (SIG). SIGs have shown to be a good match for the activity the group does around a topic or practice that spans around the community of developers, operators, and users. The group will continue to manage and care for the Security Guide, OSSNs, Bandit, Thread Reviews, Syntribos as well as encourage and incubate new security projects. The group will continue to work with the VMT and will keep a Sec-core group for launchpad that can work with the embargoes issues.
Cycle Highlights Reminder
As we get closer to Queens-3 and our final RCs, a reminder is given about the new ‘cycle-highlights’ that has been added to deliverable info. Background of why this was added, some PTLs were being pinged multiple times every release cycle by various people like journalists, product manager and other to compile the same information. To mitigate that, we have a way to capture highlights as part of the release. This will give basic information, but not as a complete marketing message.
This is done in the openstack/releases repository in the deliverables/queens/$PROJECT.yaml file formatted like so:
cycle-highlights:
– Introduced new service to use the unsed host to mine bitcoin.
We have three different places that document activities for three different audiences:
Commit messages: Developer documentation
Release notes: End-user and deployer documentation
Cycle highlights: Journalists, product manager, and others.
Community Goals For Rocky
Some questions to ask ourselves: What common challenges do we have, and who is willing to drive that community-wide goal (aka champion).
A champion is someone who drives a goal but doesn’t commit to writing code necessarily. The champion will communicate with project PTLs about the goal, and make the liaison if needed.
The list of ideas for community-wide goals is collected on this etherpad [0]. Propose some ideas now!
Leave a Reply