SecureDrop release cycle


After 0.4 is released the goal is to release every six weeks. Today I browsed the tentative roadmap for the upcoming releases and realized it would be better to set priorities.

It’s very difficult to commit to meet an deadline and a set of changes / features. Instead we could have priorities set to issues so an outsider looking at the list of issues knows what is important for the next release. This requires some maintenance of course: it is meaningless to have an issue to the highest priority during multiple releases :slight_smile:

It could go like this:

  • at the beginning of the six weeks cycle all issues that need attention are set to high prioirity, all others are set to a lower priority (even those that previously were set to high priority (to avoid clutter)
  • whenever an issue is resolved, it is set to the next milestone a posteriori
  • X days (one week ?) before the deadline the release/XXX branch is cut and we move to QA (it does not matter if an issue is missing, we have a timeboxed release cycle, not a feature bound release cycle, we can’t have both)

An important aspect (from an external contributor perspective) is that this model scales horizontally. People do not fight for what will be scheduled for the next release, trying to convince the owner of the roadmap. Instead, some work is done by whoever is available and if the quality of the work is good enough to be merged, it will be in the next release. I could expand on how important that is for large features such as i18n/l10n but it’s probably obvious to everyone :wink:

What do you think ?

Having priority-based labeling would be extremely helpful to the development team in triaging issues, especially as we move to a regular release schedule. I still see value in the milestone bucket, however, so that there’s a bit of visibility into what will change in the upcoming release.

Do you see a conflict between the concept of milestones and priority-based labeling? It may be too much overhead to first label based on priority, and second group subsets of the high-priority into milestone buckets.

Conceptualizing the changeset in the forthcoming release as determined more by time than by a must-have list of features is certainly going to be valuable in keeping the releases reliable and on-time, so I’m willing to explore that direction more.

Not really a conflict but redundancy, in the best case scenario (i.e. when all milestoned / high priority issues are resolved on time).

In reality issues with milestones will inevitably need to be postponed. And since this will be a frustrating experience, a kind of failure to deliver, it will create a tension, an incentive to push the release back a few days (or more).

Another undesirable side effect of setting issues for a given milestone is that it makes it more difficult to work with a community with diverse interests. For instance there should be a regular (even if small) flow of commits merged toward i18n, starting right after 0.4. There currently is one PR pending and dozens of commits in the pipe.

This is a typical case where the core team has the luxury of choosing between implementing a major feature (meaning set milestones, strategy, allocate resources etc.) or trusting community members to do the right thing, incrementally. I would not dare presume which way it’s going to be :wink: My point is that a set of timeboxed objectives makes it more difficult to blend that kind of external contribution.

Great points all around! The development roadmap is intended to provide some transparency as to what FPF staff see as the important priorities for the project in the next few releases, it’s definitely not intended to be set in stone or anything like that. We’re happy to merge work outside of the roadmap as it’s done if it’s in line with the goals of the project (where the best way to determine this is to make an issue, ask for comment on an existing issue, or ask in Gitter) and does not introduce a significant maintenance burden or particularly tricky deployment issues.

I also agree with your points @dachary re: setting issue priorities. I’m in favor of a timeboxed release schedule: we get through as much of the backlog as we can starting with the “must do” high priority issues first, and then release on time with as much as we have managed to get done (making sure that we leave aside sufficient time for QA as you note).

So after the 0.4 release, let’s have an open meeting with FPF staff and contributors and prioritize the backlog for the 0.4.1 release together. We’ve laid out in the 0.4.1 milestone on GitHub the issues that we [FPF staff] think are important. If contributors and SecureDrop users see something as being important to get in SecureDrop ASAP then we can add them to the backlog in the 0.4.1 milestone during the meeting and prioritize from there.

Here’s a poll to determine a time for the SecureDrop 0.4.1 planning meeting:

1 Like