commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis MONTEIRO <jeano...@gmail.com>
Subject Re: [DISCUSS] Mission Statement for Commons...
Date Sun, 06 Oct 2013 20:37:12 GMT
+1, looks like there are plenty of examples.
Agree with Phil, how could we make things lighter or easier?

I mean to get more release out.

Jean-Louis


2013/10/6 Phil Steitz <phil.steitz@gmail.com>

>
>
> > On Oct 6, 2013, at 1:11 PM, Oliver Heger <oliver.heger@oliver-heger.de>
> wrote:
> >
> > Hi Christian,
> >
> > Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> >> James,
> >>
> >> thank you.
> >>
> >> I believe Commons is in a bad shape.
> >>
> >> Look at Commons Collections. Before 4 years somebody
> >> said Guava is more modern, he his answer seems to be widely accepted.
> >> http://stackoverflow.com/a/1444467/690771
> >> This guy said we have no generics. What did we do in the past 4 years?
> >>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
> >>
> >>
> >> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> >> we haven't managed
> >> to officially release this? The last release is from 2008.
> >>
> >> I did consider to put my JSON component to Commons. But I didn't.
> >> Reason: I really need the component
> >> and I calculated how long it would take to release it here. I thought,
> >> it's not helping me
> >> to develop it here. I simply don't have the time.
> >>
> >> I thought a long while about it.
> >>
> >> We had discussions like: do we really need Generics? It works without!
> >> Do we really drop an outdated JDK? We might have users
> >> who run JDK 1.3! And so on. Finally this led us to the situation where
> >> almost all of our users seem to have JDK 1.3 and
> >> are not interested in generics - in 2013. The users who want modern
> >> features go to Guava. We maintain legacy code. And seriously, a lot of
> >> code works without generics. This is no reason to not include them.
> >>
> >> We discuss magic strings in the sandbox. Why? We don't need to discuss
> >> that. Before we release we can simply check Sonar. Safe the time to
> >> discuss. Fix it or leave it to Sonar to report it.
> >>
> >> We seem to think perfect documentation is more valuable then quick
> >> releases. Is it?
> >>
> >> We seem to be proud of our build. I am not. It's complex. It's no fun.
> >> Releases should be do-able in a short time, maybe
> >> even automated.
> >>
> >> It is so sad that lot of good features like Collections with Generics
> >> were blocked such a long time or drowning in discussions.
> >>
> >> I agree we should support old users. But if we don't have the manpower,
> >> we can't support them. They need to accept we are moving on. We are
> >> blocked with our backwards compatible ideas and innovation is far away.
> >>
> >> When I spoke to young developers about Commons they asked me if it still
> >> exists. Nobody of them is interested in our community.
> >>
> >> For the mission statement I would wish to see things like that:
> >>
> >> Commons Components…
> >>
> >> …are released quickly and often
> >> …do use modern JDKs and support old JDKs only as long as they are
> >> supported by Oracle
> >> …we make use of modern Java features when they are available
> >> …can be easily released
> >> …can be released without having 100% perfect documentation or perfect
> >> implementations
> >> …are build by Community who wants to learn, experiment and create new
> >> features more than by Community which wants to be backwards compatible
> >> for a long time
> >> …are allowed to release major versions with api breaks as they want
> >>
> >> Cheers
> >> Christian
> > I agree with many of your points. Another example is [csv] which is
> > about to be released for ages. Here, I think, the main impediment is
> > that we try to come up with a *perfect* API because due to our rules of
> > backwards compatibility it is so difficult to correct any mistakes later.
> >
> > I still think that backwards compatibility is very important, but we
> > really should define a process which allows us to experiment with new
> APIs.
> >
> > As a suggestion to improve this situation, could we agree on an alpha
> > release process allowing us to push releases with the aim of getting
> > community feedback? Where we explicitly state that incompatible changes
> > are possible (and likely)?
> >
> > We did something similar with [collections] 4, but there were many
> > limitations (the release was not allowed to be uploaded to Maven central
> > for instance). If we did such experimental releases more often, there
> > would hopefully not be the fear of defining a broken API, and we would
> > see more releases.
>
> +1 let's agree on how to do alphas.
>
> Phil
> >
> > Oliver
> >
> >>
> >>> On 6 Oct 2013, at 20:30, James Carman wrote:
> >>>
> >>> All,
> >>>
> >>> The Apache Commons project seems to be languishing as of late and we
> >>> need some rejuvenation.  Perhaps we should try to define our mission
> >>> as a project.  What are our goals?  What do we want to accomplish?
> >>> Who are our users/customers?  What non-functional qualities do we want
> >>> our software to exhibit?  How do we want to conduct ourselves?  How
> >>> often do we want to do releases?  What else?
> >>>
> >>> Sincerely,
> >>>
> >>> James
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >> ---
> >> http://www.grobmeier.de
> >> @grobmeier
> >> GPG: 0xA5CC90DB
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
Jean-Louis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message