Hi all, I'm going to call for a vote to release several modules to fix the issues that have been found with the last release. I think it is good to leave things in a tidy state before moving it to the attic branch so that downstream project aren't forced to move to forks right away.
Cheers, Reto On Wed, 20 Apr 2016, at 15:22, Reto Gmür wrote: > On Mon, 18 Apr 2016, at 17:41, Stian Soiland-Reyes wrote: > > +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) > > +1 for keeping things in a separate branch of our repo. > > Cheers, > Reto > > > > > > > > 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
