Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
Since there is no stated end date to this vote: Please let it (or it's replacement) run until at least March 4th. Oleg will be working through a mail backlog that week-end. If this vote thread should be replaced next week, I will not be able to re-cast my vote until the week-end of March 10/11. > [X] Jakarta should sponsor (which effectively states we like to see the code > end up here) > [ ] Jakarta shouldn't sponsor (which effectively means it will end up TLP) > [X] commons as a component > [ ] httpcomponents as a component > [ ] subproject directly under Jakarta > [ ] integrate / merge code into project xxx (please replace x) (so not a > subcomponent of a project!) > [ ] I am willing to mentor (you need to be on the Incubator PMC / Member of > the ASF) > [ ] I want to get involved in coding > [X] No interest in getting involved. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
On 2/24/07, Martin van den Bemt <[EMAIL PROTECTED]> wrote: >> >> Let's keep this statement your personal opinion on the fact that it is >> not >> relevant. I still like to >> know the opinion of others. > > > If you want opinions, don't use a vote to collect them. This is a vote > thread, not an opinion thread. Votes within the ASF are for decision > making, > not opinion polls. Jakarta is well known, in a negative way, for being > overly vote-happy, so we should be doing our best to confine our use of > voting to things that really need to be voted on. That includes neither > opinion polls or consensus building. > > My statement was that the final destination of a project is not relevant > for > a vote on whether or not it should be accepted into the incubator. I > consider that to be a simple fact about the way the incubator works, not an > opinion. > The difference of opinion here is that you see this as a vote about incubating ssl, which is simply not our call. Not true. There are two basic requirements for entry into incubation: a Champion and a Sponsor. Once both are found, the project is accepted. That's it. So by stepping up and being a Sponsor, the Jakarta PMC could play a pivotal role in the incubation of this SSL project, because without a Sponsor, incubation is not going to happen, and once it has one, and a Champion, entry into incubation is a done deal. We can vote however on accepting ssl into Jakarta, which has the consequence that Jakarta is going to be actively involved as a champion / sponsor role to have the Incubator accept ssl. Those things are not quite as connected as you make them out to be. Yes, we could decide that Jakarta would be happy to have the SSL project land here after incubation. But that does not imply any particular involvement in the incubation process, and in the absence of a decision to be the project's Sponsor, it is meaningless. So the real decision to be made is whether or not the Jakarta PMC is willing to step up and be the Sponsor for the SSL project. That basically means two things: 1) Do we believe that this project would make a worthy addition to the ASF? This is regardless of where it might land after incubation. 2) Would we be willing to accept the project as part of Jakarta once incubation is completed successfully? Note that #2 says that we are _willing_ to accept it, and makes no statement about whether the project will, in fact, end up as part of Jakarta, or go somewhere else. So let's restart the vote (again - sorry) and make it very clear that we are voting to be the Sponsor of the SSL project, and thus voting on whether it should enter into incubation or not. Say if the target is commons, we probably should have commons-ssl end up in the website of commons, have Julius participate on the commons website, instead of having separate lists, separate website and a separate PPMC and learning the commons way is pretty hard when you are actually not integrated into the commons community to begin with. We are talking about around 20 classes here and 1 new committer (afaik). What makes this case special compared to eg webwork (came across this while wading through the incubator archives to find similar scenario's) ? Maybe it's just a different definition of the meaning of full incubation. Things I want see solved during incubation here is (assuming commons is the target) : - IP clearance (paperwork is done by the way) - It contains crypto, so we probably need some legal advice on this (currently a discussion on legal btw) - Making sure Julius is here to stay (so preventing a new dead commons project) - Getting enough support in commons, so it's not a one man project Commons is not the issue here. Building a community around the code, within the ASF, is the issue. Without that, incubation will fail. This is, IMHO, the single most important criterion for any ASF project. - Everything takes place on the commons mailinglists (user and dev) - Release votes needs to be the same as any other commons component, with the addition of an extra incubator vote. - Reuse of commons infrastructure, probably with the exception of svn (eg incubator svn and have separate permissions, with the whole of jakarta being able to work there) Agreed on these last three, with the proviso that they apply to whatever environment the project might land in after successful incubation, be it Jakarta or elsewhere. -- Martin Cooper Thoughts welcome... Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Jakarta Wiki] Update of "JakartaBoardReport-current" by JochenWiedmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta Wiki" for change notification. The following page has been changed by JochenWiedmann: http://wiki.apache.org/jakarta/JakartaBoardReport-current -- === Releases === - A list of the released versions/distributions in this month. + * 13 February 2007 - Commons Fileupload 1.2 Released === Community changes === @@ -61, +61 @@ ''Email'' ''!FileUpload'' + + The release 1.2 of Commons Fileupload 1.2 introduces a new streaming API, which allows to use the library with arbitrarily large files and an extremely low memory profile. ''IO'' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Accept not yet commons ssl project WAS : Re: [Vote] Where should "not-yet-commons-ssl" go?
>> >> Let's keep this statement your personal opinion on the fact that it is >> not >> relevant. I still like to >> know the opinion of others. > > > If you want opinions, don't use a vote to collect them. This is a vote > thread, not an opinion thread. Votes within the ASF are for decision > making, > not opinion polls. Jakarta is well known, in a negative way, for being > overly vote-happy, so we should be doing our best to confine our use of > voting to things that really need to be voted on. That includes neither > opinion polls or consensus building. > > My statement was that the final destination of a project is not relevant > for > a vote on whether or not it should be accepted into the incubator. I > consider that to be a simple fact about the way the incubator works, not an > opinion. > The difference of opinion here is that you see this as a vote about incubating ssl, which is simply not our call. We can vote however on accepting ssl into Jakarta, which has the consequence that Jakarta is going to be actively involved as a champion / sponsor role to have the Incubator accept ssl. Say if the target is commons, we probably should have commons-ssl end up in the website of commons, have Julius participate on the commons website, instead of having separate lists, separate website and a separate PPMC and learning the commons way is pretty hard when you are actually not integrated into the commons community to begin with. We are talking about around 20 classes here and 1 new committer (afaik). What makes this case special compared to eg webwork (came across this while wading through the incubator archives to find similar scenario's) ? Maybe it's just a different definition of the meaning of full incubation. Things I want see solved during incubation here is (assuming commons is the target) : - IP clearance (paperwork is done by the way) - It contains crypto, so we probably need some legal advice on this (currently a discussion on legal btw) - Making sure Julius is here to stay (so preventing a new dead commons project) - Getting enough support in commons, so it's not a one man project - Everything takes place on the commons mailinglists (user and dev) - Release votes needs to be the same as any other commons component, with the addition of an extra incubator vote. - Reuse of commons infrastructure, probably with the exception of svn (eg incubator svn and have separate permissions, with the whole of jakarta being able to work there) Thoughts welcome... Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
