Radical Clerezza Spring Cleaning

[Reto Gmür <re...@apache.org>]

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)

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). For the other components I think many of them
would be better off if managed outside apache by their respective core
developers. 

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.

* 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. 

What do you think?

Cheers,
Reto

Re: Radical Clerezza Spring Cleaning

[Reto Gmür <re...@apache.org>]

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 <to...@gmail.com>
> > wrote:
> > > hi Reto,
> > >
> > >
> > > Il giorno gio 7 apr 2016 alle ore 20:52 Reto Gmür <re...@apache.org> 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

Re: Radical Clerezza Spring Cleaning

[Reto Gmür <re...@apache.org>]

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 <to...@gmail.com>
> wrote:
> > hi Reto,
> >
> >
> > Il giorno gio 7 apr 2016 alle ore 20:52 Reto Gmür <re...@apache.org> 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

Re: Radical Clerezza Spring Cleaning

[Stian Soiland-Reyes <st...@apache.org>]

+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 <to...@gmail.com> wrote:
> hi Reto,
>
>
> Il giorno gio 7 apr 2016 alle ore 20:52 Reto Gmür <re...@apache.org> 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

Re: Radical Clerezza Spring Cleaning

[Tommaso Teofili <to...@gmail.com>]

hi Reto,


Il giorno gio 7 apr 2016 alle ore 20:52 Reto Gmür <re...@apache.org> 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
>