On Thu, Oct 13, 2016 at 1:15 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Wed, 12 Oct 2016 19:37:20 -0700, Gary Gregory wrote: > >> On Oct 12, 2016 4:17 PM, "Gilles" <gil...@harfang.homelinux.org> wrote: >> >>> >>> On Wed, 12 Oct 2016 15:44:26 -0700, Gary Gregory wrote: >>> >>>> >>>> On Oct 12, 2016 3:34 PM, "Gilles" <gil...@harfang.homelinux.org> wrote: >>>> >>>>> >>>>> >>>>> On Wed, 12 Oct 2016 22:48:49 +0200, Emmanuel Bourg wrote: >>>>> >>>>>> >>>>>> >>>>>> Le 12/10/2016 à 18:45, Gilles a écrit : >>>>>> >>>>>> So, what you say in substance is that you'd rather _wait_ for >>>>>>> someone to come by who will want to work with you on 3.x, rather >>>>>>> than continue with people, here and now, a work (CM4) that >>>>>>> started more than 3 years ago. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> To be clear, I have no plan to maintain CM 3. I applied a small bug >>>>>> fix >>>>>> to CM 4, I just thought it would be nice to backport it if ever a new >>>>>> >>>>> CM >> >>> 3 release is required. That's all. >>>>>> >>>>> >>>>> >>>>> >>>>> That backport served as an example that could lead to a broader >>>>> reflection on the future of a project and the "community" around >>>>> it; but you ignored it, again, by expressly cutting that part of >>>>> my message. >>>>> >>>>> >>>>> I'm doing open source mostly for fun, my motivation is to help and make >>>>>> something useful to others, and if a fixed CM 3 makes someone happy, >>>>>> then so am I. >>>>>> >>>>> >>>>> >>>>> >>>>> I am sad that those one-shots gives the false impression that >>>>> CM3 (or CM4) is alive. >>>>> >>>>> Some people here could have the project to maintain CM3; even >>>>> if I'd prefer that they would work on CM4, they are of course >>>>> free to decide where they want to contribute. >>>>> >>>>> However, I find it extremely uneasy that there is no roadmap >>>>> whatsoever; only criticism of what I proposed. >>>>> >>>>> Is that fix worth a CM 3.7 release? >>>>> If not, and nobody works towards a release, what did the >>>>> reporter actually gain? >>>>> >>>> >>>> >>>> Sometimes, a user just wants a bug fix in an easy to apply release. The >>>> liveliness of the project switches state as soon as the fix is >>>> delivered. >>>> Release notes can warn that new features are only happening on the >>>> master >>>> branch. If I get a bug fix I am happy ;-) >>>> >>> >>> >>> This is all fine, in "theory". But: >>> * Who is going to _make_ a release for each applied patch? >>> >> >> Speaking here only about 3.x... >> >> Whomever feels like it! :-) We do not have ownership as you well know. I >> do >> not have a need for a patch today and I do not foresee needing one, but I >> would certainly not be shy about cutting an RC if I needed one. >> > > Even if he wished to do it, the reporter and patch provider could > not do it (unless he is a committer already). > > Will you grant the privilege on the basis of one patch? I should have been clearer, sorry. I meant to say that it is up to a Commons committer (which means an Apache Committer really) to step up and do the release. The PMC still gets to VOTE of course, so it makes sense to discuss fixes and releases on the ML to see what would put -1's in the path of a release once an RM steps forward, this is no different than another component. > > > * Why this fix and not the other ones reported on JIRA? >>> >> >> It's up to the volunteer that steps up, with reasonable feedback from this >> peanut gallery :-) >> > > PMC members do not ask for feedback. > They do as they wish. > Usually, that's fine. > But in the case of a project that is in a bad situation like > CM (I call "bad", the shift from "bug report is handled within > hours" to "unmaintained"), it's not. > > * If a release should be considered only after all reported >>> issues have been examined, who is going to do that work? >>> >> >> See above. >> > > Well, the above is a non-answer. > > No "privileged" developer is likely to spend his time doing > point releases. > What's a "privileged" developer? In the past I've cur releases for selfish needs: I need it at work or for a personal project. I've also cut them just because it bugs me to see fixes pending in changes.xml and no reason not to push them out. It's also a matter of time. Gary So there should be a roadmap such as "new point release every > 6 months, containing whatever has been fixed". > > Otherwise, why would a contributor be motivated to provide a > patch? > > >>> Where is the roadmap? >>> >> >> We do not need a roadmap for 3.x fixes IMO. >> > > I do not agree; I gave the reason above. > > For 4.x, the answer is the same as it has always been, we discuss on the >> ML. How else would it happen? At an Apache conference or meetup I >> suppose... >> > > I've discussed a lot on the ML. > I've proposed things, and there has been no alternative (I do not > call letting the code rot, an alternative). > > Don't you think that having maintained CM alone during 6 months > (from December to May) and, my stopping doing that have resulted > in nobody else doing it, is enough proof that the development > model is not good for this situation (big code, no team), and > that the "community" and PMC should support a radical change? > > If not, it means that fairly soon, people will search for > alternative projects that are well maintained. > > People who read this and have a certain competing project in > mind that has this property should say clearly that they in > fact support _that_ alternative. > All PMC members should indicate where they stand. > > > Gilles > > > >> Gary >> >>> >>> Gilles >>> >>> >>> >>>> Gary >>>> >>>>> >>>>> >>>>> What is the added value of this project if there is no >>>>> decision to move forward? >>>>> As I indicated a few months ago, the code sits there; and >>>>> the more time passes, the less it will attract new >>>>> contributors. >>>>> >>>>> >>>>> Gilles >>>>> >>>>> >>>>> >>>>>> Emmanuel Bourg >>>>>> >>>>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
