+1 to strip down a bit to simplify releasing/reviewing and maintenance. However I agree with Tommaso that the non-core stuff shouldn't just be scrapped, it could be kept on a separate branch so that it can be discovered by outsiders and potentially resurrected (e.g. as a new git repository).
(However I wouldn't make such a git repository - as it would not come with any releases) On 11 April 2016 at 10:23, Tommaso Teofili <[email protected]> wrote: > hi Reto, > > > Il giorno gio 7 apr 2016 alle ore 20:52 Reto Gmür <[email protected]> ha > scritto: > >> Hi all, >> >> It's spring cleaning time in the northern hemisphere! I propose a >> radical cleaning of Clerezza. >> >> I think the project source has a size that poses the following problems: >> >> - It's hard to manage >> - It's too much for potential new contributors to easily get into the >> project >> - Votes are hard as most PMC member are only familiar with a portion of >> the codebase >> - Unclear boundaries with the Stanbol project (Clerezza Authentication >> relies on Stanbol with in turn uses Clerezza) >> > > I agree. > > >> >> My proposal drop* everything but a core consisting of the following: >> >> - Everything in clerezza-rdf-core (API, utils, SPARQL backend) >> - rdf.core >> - rdf.ontologies and maven plugin to generate them >> - rdf .utils and rdf.utils.scala >> - rdf simple storage (mainly for tests) >> >> All this components should work well with and without OSGi. >> >> That's it no launchers, no shell, no platform, no permission, no email, >> no adapters to storage backends (apart from the SPARQL one), no uima, no >> parsers and no serializers (but with the parsing interface), no CRIS. >> >> The rationale is, that we all know the above core modules so we can have >> competent discussions about changes there. Also, I think its good to be >> conservative on changes to the APIs at the very core (and it doesn't >> harm to be a bit slow). > > > +1 on all the above, with a note on what "drop" means, see below. > > >> For the other components I think many of them >> would be better off if managed outside apache by their respective core >> developers. >> > > I disagree here, I think it's important to keep the stuff into Apache, and > maybe whenever it's time to release any of this additional components a > competent developer can take this up. > > >> >> Personally I like coding with the Clerezza API and use it in many of my >> projects, what I don't like is if I encounter a tiny issue in some >> marginal module I developed: if I fix it in the Clerezza code base I >> have to rely on a SNAPSHOT version (which I usually don't want) or make >> a release, now calling for a vote for some minor fixes in a module >> that's rather unimportant (except of course, for the project I'm working >> on) seems like an overkill and an unnecessary waiting time, I often end >> up working around the issue or duplicating code in my project. >> > > I partially agree: a minor fix is still a fix and if it's important for > your project it may be for others using that. I don't think 3 days of > waiting can be problematic from a timing point of view, what could be > problematic is lack of votes from PMC members, which I think is rightfully > what you're trying to address here. > > >> >> * By drop I mean to end maintaining as part of Apache Clerezza and >> removing it from our repository, this is the part to decide on this >> list. I'm personally interested in keeping alive significant portions of >> that code and I hope that others might too. >> > > I would opt to move non-core stuff to an addons branch, like many other > projects do. Removing would be bad as if someone wants to pick anything > from there and e.g. revamp it, that would require a lot of steps to be able > to release it. > > My 2 cents, > Tommaso > > >> >> What do you think? >> >> Cheers, >> Reto >> -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
