Jacopo, Thank you for the elaborate reply.
Hopefully the survey Sharan has put together, will provide the insights about what OFBiz version are being used at the moment. But, if to many of the current active community members fill in the survey as well, we might expect to see a lot of the same answers that renders the survey useless. E.g. when a multitude of contributors of HWM fill out the questionnaire, we can expect that they all will state (with negligible variances) the same versions that they support for HWM customers. If we do get the response we want, namely feedback of a large and diverse population of the users (I don't know whether we can validate this), decisions need to be taken with regards to our release and maintenance strategy. And the questions you circumvented in your posting, need to be addressed. 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 8:02 PM, Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> wrote: > > 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 > >> > >> > >> > >
