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

Reply via email to