On 07/10/2020 08:55, Romain Manni-Bucau wrote: > Hi JB, > > Think one key point for this ambition is to be able to ensure releases > don't depend on a single man (whatever his quality is ;)). > Checking on apache index it seems around 3-4 PMC are active (I can be wrong > since I don't follow the list accurately from very long so happy if it is > more), what about having planned (each two months?) releases and rotating > in the PMC for the releases?
Another thing is that coming up with a template timeline of what the release looks like would be nice. For OpenDaylight we have 6 months release cadence, which is planned out here: https://docs.opendaylight.org/en/latest/release-process/release-schedule.html. The accuracy of releases depend, but I think we have a decent success rate. Obviously Karaf is much smaller in terms of codebase and number of independent repositories, so something more nimble might make sense. For individual projects (such as YANG Tools, etc.) we are doing something more light-weight and predictable: - major release every 6 months, has to happen to meet "Release Integrated Deadline" in the above plan - minor releases occur periodically in between, roughly every 3-4 weeks, irrespective of content -- even if it means just realigning upstream dependency versions - artifact staging and release is very much automated We also support up to 3 concurrent streams with increasing bar for backports. For the oldest release a patch needs to be quite a critical fix, or have an extremely good risk/benefit ration to land. Release-to-EOL for a particular major release is 18 months. To make all of this work, there are a few things that have to happen: - target issues to a release realistically, keep list of deliverables short - assign issues only when they are actively being worked on - re-eval issue targets periodically, it is fair for an issue to not have a fix-by release - resist the urge fit 'just this little bit' into a release :) Hope this helps in the ideas department :) Regards, Robert
