commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject [ALL] Pushing out releases, one component at a time
Date Mon, 18 Mar 2013 21:43:17 GMT
Hi all,

when looking through the components and the sandbox I can see that
development activity is very different.
We have very few components that are been worked on constantly, most
notably [math].

Some components seem to be worked on, only by a few people. [configuration]
comes to mind, where Oliver Heger is pushing a redsign of the API forward.
Thomas Neidhart is working on [logging] and in the same time prepares
[collections] for a 4.0 release. Oliver and Thomas are representatives for
other people that are not mentioned here, who put a lot of effort into
individual components.

Furthermore we have some really promising APIs that have never been
released like [csv], [functor], [graph], [privilizer]. It's sad, that we
can not get those into a releasable state.

Now I was asking myself how we can improve things. For me the collaboration
with other developers always is the most fun (and the most instructive).
This is why I was trying to get involved in more components recently. I
believe if several people work together on one component at a time, overall
development speed will increase.

With this thread I want to bring up a discussion regarding medium-term
development goals for commons. It may be a good thing if could agree on
something like: "Until end of this year we want to push out collections
4.0" or just "Let us focus attention on [csv] to finally push out the first
release soon".

I know that most of us work for commons in their free time and almost
certainly want to develop on the components they are really interested in.
This is why my intention is not to create rules, like "nobody is allowed to
do commits for components other than [graph] until we have a release", but
to define a shared goal to focus resources and enhance development speed
and fun (at least for me ;-)



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