Hi Ross! maybe my mail previous sounds a little poor so please excuse me, it wasn't my intention. I admit my Lab ignorance in therms of story/policies, anyway not being in the PMC I was just trying to give my 0.02 cents ideas. Thanks *a lot* anyway for the exhausting explanation (and for the time you had to spend to reply!) :) All the best, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, May 31, 2011 at 6:04 PM, Ross Gardler <[email protected]> wrote: > On 31/05/2011 16:39, Simone Tripodi wrote: >> >> (PRE: take the following strictly as my personal consideration) >> >> Hi again guys, >> following Christian questions, I think that giving more karma to Lab, >> allowing releases, would benefit the whole Apache ecosystem. I mean: >> apache-extras is AFAIK open also to non ASF committers, Lab is not. >> That's the main difference. > > There are sound legal reasons why releases are not allowed. In short > allowing releases means that the overhead on the PMC is vastly increased and > thus labs would not scale. > > However, this thread is about labs not having momentum - scaling is not a > problem right now. Maybe we got the balance wrong. > > There are many differences between extras and labs. Extras is supposed to be > a place to host real software with real users and non-ASF developers. Labs > is a place for experimentation either alone or with fellow ASF committers > without the overhead of running a real open source project, such as having > to manage write access, collect CLAs or do legal due-diligence on releases. > > Labs was not created as a hosting platform for full projects. Nor was it > created as a away to circumvent the processes that make ASF projects > valuable to users (i.e. they are legally sound). > > I wonder if this thread is losing sight of what labs should be? I wonder if > there is an appetite for something that is not labs? Something that can make > releases, but still enhance visibility for ASF committers (although with > only 100 people ever having posted to this list I'm not sure labs ever > achieved that). > >> We can still continue follow the community/general consensus way, >> since the Lab owner can propose an RC, then the PMC could vote for >> success/failure. Users can reuse that components at their own risk, >> since it is a lab component. Lab releases could be marked as >> apache-foo-X.Y-lab (like we do for -incubating) > > Approving a release is much more than just voting. If you ever vote +1 for a > release without doing due diligence on it please stop doing that - now. > Doing so undermines the whole purpose of the ASF from the perspective of our > users. The vote for a release indicates that the software can be released > *legally* as an Apache Licensed product and thus safely used. > > Speaking entirely personally, I would resign from this PMC if that role > included an expectation to do due diligence on releases. I (and I would > guess) many others don't have the time for this on random experimental > projects that don't pique our personal interest. > >> The side effect could be an extreme proliferation of Labs :( > > And the scaling problems that come with that.... > > The current rules were put in place for a reason. If we want to change those > rules then we need to figure out how to handle the possible results. > > Ross > >> Do you think that would be an evaluable option? >> Many thanks in advance, all the best!!! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Tue, May 31, 2011 at 5:26 PM, Ross Gardler<[email protected]> wrote: >>> >>> On 31/05/2011 16:13, Christian Grobmeier wrote: >>>>>> >>>>>> I'm more than pleased to tell you my little story :) When I started my >>>>>> Lab, I just joined the Cocoon PMC, I was a fresh Apache committer, and >>>>>> didn't have many contacts here at ASF, so the only chance I had to >>>>>> give Amber enough visibility and catch someone else's interest, to >>>>>> build a community around it, was via Lab. And it worked because it >>>>>> became an Incubator, without looking for initial developers, but they >>>>>> asked me if I was interested on it. >>>>> >>>>> Thanks for that insight. This is something that labs gives but not an >>>>> external hosting location. Not even apache-extras at this point. >>>>> >>>>> So, it would be a shame to kill off labs if we didn't replace it with >>>>> this >>>>> in some way. >>>> >>>> Please answer me two questions: >>>> >>>> 1) I would like to create a Struts2 plugin. It is probably just one or >>>> two classes and if the Struts people like it, it will probably not >>>> stay there for too long. Is this a case for the incubator? >>> >>> This sounds like a case for the struts project. If they don't want it >>> then >>> apache-extras.org is the right home for it (perhaps as a Struts PMC >>> sponsored struts-plugins project). >>> >>>> 2) If the Struts people don't like it, it might happen that I create a >>>> jar package of it and put it for download on my homepage. No Apache >>>> naming in it, except the package names. Is it ok or not? >>> >>> Well it's open source so you can do that, yes. But why would you? >>> >>> If you want to make a release for people to use it then I imagine you >>> would >>> want them to get the source and maybe even fix a bug. In which case you >>> can't do that in a lab. So again, apache-extras.org is the right home. >>> >>>> If the answer to 1) is yes, I was afraid before all the voting before >>>> the lab creation. >>>> If the answer to 2) is yes, then I like Labs much more then before. >>> >>> Labs is a place for experimentation, not a place for developing software >>> that is intended to be used. Your use case sounds more like software for >>> use >>> than an experiment. >>> >>> Ross >>> >>>> >>>> Cheers >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> -- >>> [email protected] >>> @rgardler >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > -- > [email protected] > @rgardler > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
