Hi Robert, Thanks for the update and details. It’s helpful.
Once Karaf 4.3.0 will be out, I will prepare a release guide draft to both describe release process and define the schedule. Currently, the Karaf "calendar" is on the website download page. But we can also have a dedicated page to be more "visible". Thanks ! Regards JB > Le 7 oct. 2020 à 11:15, Robert Varga <n...@hq.sk> a écrit : > > 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
