commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [DISCUSS] Mission Statement for Commons...
Date Sun, 06 Oct 2013 21:01:25 GMT
Of the various tasks that are part of keeping Commons going:  making
releases, pushing to the website, etc., I feel like there are maybe a
couple of people who feel confident to do each task, and they're probably
not the same people for each task.  I think it could be helpful to
establish a list of what items there are that routinely need doing, and who
knows how to do them *and is willing to help others understand a given
process.*  Making releases seems to be a big pain point--can we identify
what the problems are and improve or fix them?  Is there any of us who
feels super-comfortable with releasing?  Maybe that person could help e.g.
me over IRC next time I want to cut a release.  Hopefully then I'll be more
comfortable and can try to help the next person.  Similarly, I suspect that
some of us are now doing Commons dev using git-svn, and I have the feeling
it would be easier to merge github pull requests using git--is there anyone
willing and able to help me if I run into trouble experimenting with this?

I do think that more than one component has had the wind taken out of its
sails by too much "back seat driving":  anyone, committer or not, should
feel free to voice his opinion on any design decision, but that needs to be
tempered with a respect for the process of do-ocracy.  If you're not
willing to actually step up and do the work, and can't convince
someone-who-is that your concern is important enough that they *want* to
take care of it, don't be surprised when it doesn't get done.  At this
point we'd be better off releasing imperfect code.  Bad code and good
communities, as they say... don't most of us begin participating in OSS
because we're using a library that's *almost good enough* if we could just
get that one bugfix or feature that we want so badly we write it ourselves?
 Our obsession with perfection may be killing us in two ways:  one, we
don't release anything, and two, if we ever did, it would be so perfect
there'd be nothing for a newcomer to contribute!  ;)

Matt


On Sun, Oct 6, 2013 at 3:37 PM, Jean-Louis MONTEIRO <jeanouii@gmail.com>wrote:

> +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