2018-08-16 Drupal 8 Committer Meeting [#2993877]

In attendance

@cilefen
@xjm
@Dries
@Gábor Hojtsy
@effulgentsia
@webchick
other?

Additional release manager(s)

@Cilefen plans to step down as release manager. We need to look for a replacement.
Probably best to do a public call to canvas widely for the position. Gets rid of “in network” effect. Though this risks getting candidates that publicly declare their self-nomination and aren’t found suitable, and is quite intimidating for some people.
Suggestion to post public call for “project manager” committer role descriptions #2974016: Add "committer team facilitator" and "core initiative facilitator" roles to core governance, as well as release manager.
Dries to reach out to a candidate with a general request about being a provisional committer, and let them say where they sees themselves on the team.
Dries to also draft a blog post, though we should continue brainstorming candidates internally as well.
@cilefen to stay on for titular / emergency stand-in until replacement is found.
Another piece of communication that could help: “What do the committer roles do?” that’s shorter than the long governance document, to help people self-identify as good for certain roles.
Specific things we’re looking for in a release manager:
- Cautious by default
- Demonstrated skill assessing risks and potential impacts of proposed changes
- Monitoring after releases for regressions and evaluating incoming reports
- Experience/interest in triaging issues for severity, risk, allowed changes, etc.
- Adherence to schedules and interest/participation in future planning
- Interest in provisional security team involvement
- Familiarity/interest in the Drupal issue priority definitions https://www.drupal.org/core/issue-priority , D8 allowed changes https://www.drupal.org/core/d8-allowed-changes , BC https://www.drupal.org/core/d8-bc-policy and deprecation https://www.drupal.org/core/deprecation policies, etc. (These are totally things we all learn and get better at over time, but someone who finds these policies soul-crushing probably would not be very happy as a release manager.) ;)

Drupal 7 EOL

- Driesnote going to talk about Drupal 9, and questions will naturally creep up about Drupal EOL as a result of this.
- Lots of organizations will need at least 2 years to move off Drupal 7.

When/how can we make a decision about this?
We need to be ready to schedule Drupal 9 release date within a 6-month window in order to say "this is the date"
If we declare a date today of "September 1 2021" what happens if we don't ship Drupal 9 by September 2020? We would extend the date.
We need security team buy-in either way, so that's probably the first step.
We want to EOL Drupal 7 a year after Drupal 9 comes out, and 9 won't come out any sooner than 2020. So we'll EOL 6-12 months after that.
Precedent already with Drupal 6, extending security coverage an extra 3 months.
Drupal 7 has automated test coverage, so can (ideally) extend for longer.

Summary:

We don't want to EOL Drupal 7 before Drupal 9 is released.
First, need to figure out when we're going to release Drupal 9.
For now, the most realistic release date for Drupal 9 seems to be in 2020.
We are aiming to EOL Drupal 7 a year after that. (which means early 2021 or longer)
This requires buy-in of the security team. [who???]
D7 has test coverage that D6 did not, so extending security support is less risky.
Also need to help onboard D7 committers onto security team, and are involved in the security team process to help reduce burden.

Action items:

Dries to check in with Pol about onboarding process
xjm: Talk about inviting Pol to participate provisionally in D7 core security?
xjm: Post pointer to the sec. team list, and let people know we need their feedback on Drupal 7 EOL (as well as proposal)
webchick/xjm: Have initial "in-person" meeting at Midwest Developer Summit w/ security team members to cover initial feedback from list.
xjm/mlhess: Add to Sec Team agenda for Drupal Europe meeting

Security Extended Coverage

Jess documenting phases in the process
Phase 1 done (?)
Phase 2 done (buy-in from Drupal 8 committers and the Drupal Security Team)
Phase 3 done (beta-testing backports of security advisories to the 8.4.x branch after its official EOL)
Phase 4 in progress (Drupal telling you your site is insecure)
Phase 5 in progress (design how to present information to users)
Phase 6 not started (contrib semver best practices)
Two things need committer feedback on:
Phase 4 and 5 implementation
Backporting Phase 4 and 5 work to 8.5. (somewhat disruptive)
Timeline for completion?
Hoping to have changes in 8.6.0 (2-3 weeks) but no designs for them yet, so only minimal fixes possible. [at risk]
8.6 => 8.7 cycle core is creating releases, Drupal notifying you about them, implementing contrib semver.