How about we just switch to git, Matt? Many projects have already gone that route.
On Sun, Oct 6, 2013 at 5:01 PM, Matt Benson <gudnabr...@gmail.com> wrote: > 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 <jeano...@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.ste...@gmail.com> >> >> > >> > >> > > On Oct 6, 2013, at 1:11 PM, Oliver Heger <oliver.he...@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-unsubscr...@commons.apache.org >> > >>> For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> > >> >> > >> --- >> > >> http://www.grobmeier.de >> > >> @grobmeier >> > >> GPG: 0xA5CC90DB >> > >> >> > >> --------------------------------------------------------------------- >> > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> >> -- >> Jean-Louis >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
