On Sep 22, 2014, at 6:42 PM, Pierre Smits <pierre.sm...@gmail.com> wrote:
> Jacopo, > > Your first suggestion is a bit cumbersome. If an issue affects multiple > versions and it is not fixed in all versions, why not simply keep it open > as long as the release branch it affects is in the maintenance cycle? I have to provide a "technical" response; I apologize but without this information you can't appreciate my proposal. The reason is that if we not close the ticket, it will not appear in the release notes of the releases of the branches where it has been backported. > > Your second suggestion is ambiguous. > Which part of the community are you referring to with respect to decreased > interest? > What if the installed versions amongst our user base is significant > different than you expect? We can suggest the users what to use, but it is > down to migration costs and added value of the newer version how customers > decide. Of course we always appreciate when a bug fix is backported to all the active release branches. Unfortunately we can't impose this rule to the committers (that are already donating hours of their free time to the community) or to the contributors (that are already donating their contributions). I am not saying this is good or bad... it is just the reality of every open source project that is not backed up by a company. A release branch can only stay active if there are interested parties helping it to stay alive, by reporting bugs, contributing patches, testing patches and backporting patches from the trunk. This is actually not different from the work done on new features in the trunk: people interested in them (committers or not) contribute code because they either need it or simply for the greater good of the project. My proposal is an attempt to try to address the situation when very few contributors are backporting patches to an old(ish) release branch: a vote in the community would be a warning message saying that the branch is currently not well maintained; this would give a chance to users that can help (either companies with a development team or individuals with technical skills) to step in and become more involved in the project; on the other hand, if not enough people show up at least the users will know that they have to migrate to a newer release or live with the current (dying) branch. Jacopo > > And what if there is enough interest among the non-committing contributors > to continue to support a release branch, while none of the committers is > willing to? Is the PMC going to invite these non-committing contributors to > be committers as well? > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Mon, Sep 22, 2014 at 3:51 PM, Jacopo Cappellato < > jacopo.cappell...@hotwaxmedia.com> wrote: > >> Some ideas to manage this workflow in a better way: >> >> * if a bug that affects an old release branch is not backported, when we >> resolve the ticket we create a new one that is linked to the original and >> has the field "affected releases" set the affected old branch; this will be >> a placeholder for the ones willing to maintain the old branch >> * about the end of life of release branches: when we perceive a decreasing >> interest from the community to backport to an old release, we could run a >> vote to decide if the community is ok to anticipate the end of life of a >> release branch; the ones that vote to keep the branch alive could offer to >> help in the backporting process >> >> Jacopo >> >> >>
