> That brings us to the question of the project's future. We added Mick > to the PMC and he's come forward with some ideas for a Tiles 3. At > this point I'm ready to report to the board that the Tiles PMC does > not wish to disband. Do we have general agreement on that? >
Yes. Things are still slow but there's still movement. I'm still somewhat curious about the whole attic process when i see other apache projects (commons, jakarta, Turbine, etc) being in similar categories of /inactivity/ but otherwise still very useful projects to have "alive". I understand the Apache focus' on ongoing development but the move to Attic gives users not acquainted with the truth a bad impression of the project. Of course not having enough members to provide answers to the user's mailing list is a clear sign of a project to be disbanded. But Antonio continues to be amazing at providing answers, both informative and abrupt as each is required. I hope we don't loose you here Antonio. > > Regarding the PMC chair, it's generally thought to be a good idea to > > rotate the chair. Now is probably a good time to do that. Would anyone > > else be interested in taking that over? > > Tiles made its time and was good, thanks to its server-centric > architecture that helped slow clients work fine. This is the era of > single-page applications, servers are simply JSON (or similar) providers. > I am not leaving yes since I can still help answering questions about > building, architecture, etc. Once the first release of Tiles 3 is born, I > think I can leave the team. I'm of a slightly different opinion here. First of all i see Tiles as a project largely fulfilling its niche so i agree future development is largely limited. I can compare this to many of Apache's older projects too, eg commons. I can also see that it's not currently one of Apache's new exciting projects so we won't see new developers flocking to contribute. I do see Tiles usage in modern development still as applicable as its always been. I don't believe that's it's a shift from server-centric architecture to single-page applications, but rather an evolution to a richer eco-system. Pages within a website will continue to exist (think of the sitemap), and json/xml providers will be layered on top. The thing is even these providers still require to finally produce html and in a website (where the composite pattern gives advantages in providing common design) why isn't tiles also providing its templating abilities out to the client? For example the Autotag implementations only support server-side templating today. Shouldn't it be possible to generate javascript files so that the client can perform the rendering... And so here your templating becomes holistic, the design re-usable, and the choice of when to use server-side and client-side templating freed up. It becomes less about technologies and more about the needs of performance and user experience. > > About Mick, can a freshly-elected PMC member be a PMC chair? If yes, I have > > no objections for him. > > There's nothing wrong with that, but I'd hate for Mick to have such a > steep Apache culture learning curve right off the bat. My preference then is if you can maintain the chair for a little longer Greg. I'm aware you time is limited, but if you still have time for the minimal requirements for this position (ofc i'll help wherever/whenever possible), i'd rather have you as the apache mentor here for a while more. ~mck -- “Some men give up their designs when they have almost reached the goal; While others, on the contrary, obtain a victory by exerting, at the last moment, more vigorous efforts than ever before.” - Herodotus | http://semb.wever.org | http://sesat.no | | http://tech.finn.no | Java XSS Filter |
signature.asc
Description: This is a digitally signed message part
