Saturday, June 18, 2016, 9:41:19 AM, Jacopo Cappellato wrote: > I agree that it is the right time to discuss graduation. > In my opinion the incubation process for Freemarker has been successful and > for this reason I will vote +1 for the graduation. > As anticipated when we initially discussed the incubation, one critical > aspect of the Freemarker project was its small committer's base; under this > aspect the incubation process didn't do any magic and frankly speaking I > was not expecting it to happen. > However, as mentioned by Daniel and Sergio, the project is mature but there > are plans for the future that will keep the community busy, not just > maintaining the old code. > This community has still to find a more effective way to attract new > committers but this should not be a blocker to become a top level project @ > ASF.
And for the record, I think that requires some substantial modernization/cleanup, which I have called FreeMarker 3 as it drops backward compatibility. There are many things where FreeMarker 2 can be evolved further without breaking backward compatibility, but making the project more attractive is also timely, and the resources are scarce, so I think we can't have both. > It is however important to verify that we will have, even after graduation, > a PMC group capable of casting at least 3 positive votes on releases. Is it customary for PPMC members of the poddling to be also in the PMC of the graduated project? If so, can any of you express his intent regarding that? What are the risks of failing the graduation vote? BTW, something that I can do to help it, to document some project-specific rules, and a step-by-step release tutorial. -- Thanks, Daniel Dekany > Jacopo > > On Tue, Jun 14, 2016 at 1:55 PM, Sergio Fernández <[email protected]> wrote: > >> Hi Daniel, >> >> On Mon, Jun 13, 2016 at 9:18 PM, Daniel Dekany <[email protected]> >> wrote: >> >> > I think we can start some discussion about that even now. Or at least >> > I will tell what do I think about the state of the project. >> > >> >> Great step. Thanks. >> >> The main problem is the number of active developers, which is 1, me. >> > >> >> I'm aware... >> >> https://github.com/apache/incubator-freemarker/graphs/contributors?from=2015-07-01&type=c >> >> >> > What if I'm hit by a truck tomorrow? We can hope that if there's a bug >> > that concerns many, then someone will eventually fix it. After all the >> > owner (ASF) won't be gone, the release infrastructure is there, etc. >> > But as far as non-bugfix development goes, it's certain that things >> > would stop. Some may say that that's OK for a project that's >> > backward-compatibility-locked for 12 years now (the 2.x line is >> > actually 14 years old). >> >> >> Well, I'd say that's critical, but the community of a project is more than >> the developers who code. And the Freemarker community is much bigger than >> what you could think. >> >> For instance if you consider my personal case: I volunteered for mentor >> because I knew the project for so long. I even code some extensions ( >> http://marmotta.apache.org/ldpath/template.html). Definitively I used >> Freemarker much more in the past than currently, but Web development has >> changed a lot, moving more stuff to the frontend (10 years ago we didn't >> have AngularJS). >> >> So I'd say there are many people like me out there, using every day >> solutions based on Freemarker. People who are not that close to the source >> base, but familiar enough to be able to jump in at any time a provide a >> patch. >> >> >> >> > But of course that's just slow death if a >> > project can't counter its old design problems and can't evolve to >> > tackle new problems anymore. So indeed 2.x should switch to >> > maintenance eventually (but ATM there are still things that can be >> > done in 2.x), but only to give place for 3.x. Anyway, how to catch >> > long standing developers? I don't think that 2.x have a real chance >> > for that, because of all the legacy code burden piled up. (Some Apache >> > projects have many paid contributors, but I think FM isn't the kind of >> > project that can have that, so it's important that the developers want >> > to fiddle with it for free.) So the 3.x jump will be necessary, and >> > then, maybe, we can have a developer base growth (template engines >> > isn't hot topic anymore, so I just mean having a few developers >> > around). But 3.x is far away (if it will happen at all), and we can't >> > hang around in the incubator forever. >> >> >> Well, we can consider 2.3.x feature-complete, and 2.3.25-incubating a >> maintenance release. The world has change a lot in template business in >> these 14 years. But I'm pretty sure FreeMarker has its place there, and 3.x >> could bring some many great ideas that may attract potential new >> contributors. And that's what I see as future of this project. >> >> >> > So, do you believe there's any chance to graduate with the current >> > developer base? >> > >> >> Definitively that has been always the major issue with this podling. >> Honestly I'm not sure. But following with all my argumentation that the >> community is much bigger that what shows the development team, I'd say >> could be at least discussed with the IPMC. >> >> Looking forward to hear every body else's opinions. >> >> Cheers, >> >> -- >> Sergio Fernández >> Partner Technology Manager >> Redlink GmbH >> m: +43 6602747925 >> e: [email protected] >> w: http://redlink.co >>
