Re: my pTLP view
On Sun, Jan 25, 2015 at 4:01 PM, Dave Fisher wrote: > > On Jan 25, 2015, at 1:22 PM, Benson Margulies wrote: > > > On Sun, Jan 25, 2015 at 3:53 PM, Bertrand Delacretaz > > wrote: > >> On Fri, Jan 23, 2015 at 8:58 PM, Greg Stein wrote: > >>> ...They are reporting to the Board. We know what inactivity looks > like. So we > >>> ask the PMC to fix it, or we shut them down > >> > >> I know how that works, it's just that with your pTLP proposal the > >> podling is "at the mercy" of their mentors - if the Incubator PMC > >> disappears it might be hard for them to recruit initial or new > >> mentors. Not a blocker for me, just an observation. > > > > I want to be clear about the hypothetical here. I think it is, "The > > board establishes a PMC containing some people whom it knows and > > trusts, and there is a larger community of some other people whom it > > would like to get to know and trust. (Or, even, the board included > > some of the second group in the PMC at the outset.) Before the second > > group merges with the first group, the first group loses motivation > > and disappears." > > > > It seems to me that this is not likely. To me, at least, signing up to > > be a PMC member is a much clearer commitment than signing up as a > > mentor, and, while I might be distracted for a month here and there, > > I'm not going to just wander away. I think I'd be pretty much typical > > (in this one tiny respect) of anyone that the board for a new PMC. To > > get into the pickle Bertrand is musing about, more than one of the > > group has to wander off, so that the remainder are not available to > > help recruit some successors from the general membership. > Very well-stated, and very clear, Benson. Thanks. Yes... that matches my own thoughts precisely. The "failure mode" based around absent PMC members is very unlikely. But carry it a bit further: one of those is the VP. An Officer of the Foundation. If that person disappears, it is quickly obvious, so we don't need to worry about this case (easily noted and fixed). If the other members of the PMC disappear ... well, that VP can *still* appoint people onto the PMC, to get the roster back up to (3) active people who can +1 releases, and can acknowledge that the commits/direction of the project comport with the PMC and the Foundation. [ for those not aware: yes, the VP can unilaterally add people to the PMC; no need to have 3 actives; so a reboot is always possible if a VP is around ] > > +1. > > I think that in this pTLP proposal there are no IPMC Mentors. These are > not needed. Why? The Apache Members are coming in as the PMC. This is a > much more serious commitment than being a Mentor. The pTLP is not an IPMC > entity. > In the model that I have proposed: correct. This is simply another TLP which the Board has mandated the "probationary/provisional" label upon. Even the "requirement" for only ASF Members is a suggestion. A community can arrive with any initial list of PMC members, but speaking with my Director hat: no, the initial list should be small, greybearded, and well-known. They can make an argument for one or two others, I'd think, so the "rule" is more like advice on how to get the Board to approve it :-) While we don't like BDFL's or tech leads at the ASF, many incoming projects have individuals that fit into such a role. I'd expect that person to get onto the initial PMC list. But I would never approve without (3) or more ASF Members on the list. > Incubator life cycle for a pTLP. > - Proposal to be a pTLP. > - IPMC recommendation to the Board as a possible fit to be a pTLP. > Sure. Or a community can directly approach the Board. However, the Board is really bad about engaging a community in discussion, so the approach kind of needs to be packaged with a high chance of approval (since back/forth won't happen). That generally means an individual Director would work with the community to put the proposal together (based on their impression of what the Board would accept, and their own part in discussions during the Board meeting to make it happen). > Board life cycle for a pTLP. > - Board accepts - they can accept no matter what the IPMC opines. > - Board manages it like a TLP. Appoints Board Shepherd, etc. Not the > IPMC's responsibility any longer. > - Board decides when the probationary period is over and the little "p" is > removed. > Yessir. Cheers, -g
Re: my pTLP view
On Sun, Jan 25, 2015 at 11:01 PM, Dave Fisher wrote: > ...The Apache Members are coming in as the PMC. This is a much more > serious commitment than being a Mentor. The pTLP is not an > IPMC entity Ok, I agree that if those PMC members take that as seriously as you think there shouldn't be any problems. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: my pTLP view
On Mon, Jan 26, 2015 at 1:13 AM, Bertrand Delacretaz wrote: > On Sun, Jan 25, 2015 at 11:01 PM, Dave Fisher wrote: >> ...The Apache Members are coming in as the PMC. This is a much more >> serious commitment than being a Mentor. The pTLP is not an >> IPMC entity > > Ok, I agree that if those PMC members take that as seriously as you > think there shouldn't be any problems. I'm skeptical. Having ASF Members swear that they "really really mean it" doesn't transform them into core developers overnight. The project is still being overseen by outsiders with limited investment. The same flawed incentive structure which afflicts the Incubator persists. Should work or life changes force these ASF Members to make hard choices, the pTLP is still a volunteer effort that they didn't start on their own and may not be getting paid to work on -- and it will be prioritized appropriately. As a result, I would expect attrition at roughly the same rates as Incubator Mentors. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: my pTLP view
Yes, formal votes for all decisions has been my *universal* experience on all projects I have participated in at Apache. It's like there are two (or more) different foundations, culturally. Thanks for the consideration. On Sun, Jan 25, 2015 at 12:40 PM, Branko Čibej wrote: > On 25.01.2015 21:07, Andrew Purtell wrote: > > I'm not arguing with you Greg (smile), honestly, Subversion sounds like a > > very laid back place to participate. It's different in Bigtop, HBase, > > Phoenix, Whirr (of historical note), and Hadoop (secondhand observation), > > Hive (secondhand observation), ZooKeeper (secondhand observation) and > > others. Formal votes are called on releases, committerships, PMC > elevation, > > branch merges (with even additional hurdles by bylaw), and are most > > definitely talled. > > Sigh ... well, all I can really add here is that the projects you > mention might benefit from a bit of therapy to cure their control-freak > reflex. > > The reason why communities should reach consensus through public > discussion is that, when instead you have a formal vote every time > someone gets an itch, you're likely to end up with some very nasty > behind-the-scenes vote swapping. Of course I'm not accusing anyone of > doing that ... though, sadly, I've heard rumours. > > Suffice it to say that what you describe is not the ASF Way. > > -- Brane > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: my pTLP view
TL;DR I think this is a good idea. I thought long and hard about this during the weekend and I’ve changed my mind about this; I’ll spare you my handwringing thought processes. Some things that I personally would like to see: - do away w/ the pTLP name, just make it a regular TLP - ComDev should be charged w/ augmenting their maturity model with “profiles” which can be applied to such TLPs, e.g. - committers==PMC - codebase going through IP clearance - PMC considers TLP properly diverse - PMC considers TLP properly active - item 2 is too strict Regards, Alan > On Jan 23, 2015, at 5:42 AM, Greg Stein wrote: > > Roman kicked off a query about "next steps", with links to several wiki > pages on possibilities. The "IncubatorV2" page which describes a > "probationary TLP" is nothing like I have thought about. > > In my mind, a pTLP looks *exactly* like any other PMC. They report directly > to the Board, they have infrastructure like any other project (eg. > FOO.apache.org). But they have two significant differences: > > 1. probationary text is prominent, much like we require "incubating" to be > prominent in various locations/messages for podlings > > 2. the initial PMC is comprised of only ASF Members. committers can be > chosen however the community decides. but the *project* is reviewed by > people with (hopefully/theoretically) experience with the Foundation and > its views on communities > > That's it. By creating a PMC that understands what is needed, then they can > groom new PMC members, and use the standard process for adding them to the > PMC. The Board doesn't care about committership, so the pTLP can do > whatever it wants in that regard. > > The Board might not accept a pTLP resolution because it wants more > greybeards on there, to help the community. Removing the "probationary" > label, is up to the pTLP to request, and the Board to approve. It is > usually pretty obvious when a community has reached that point, if you are > talking about active ASF/PMC Members. But the Board would apply its own > level of trust. > > There is a big element here, which didn't exist 12 years ago: the Board's > ability to review many projects. Before the Incubator, there weren't that > many projects. The Directors didn't have a lot of experience with a lot of > breadth. Nowadays, we review the work of *dozens* of projects every month. > If one is a pTLP instead of a regular TLP? Not a big deal. They have some > operational restrictions, but the report should be showing us a typical > Apache community. > > The other aspect is IP clearance and management, which also didn't exist a > dozen years ago (and the Incubator was basically started in response to > some IP problems). We have a much better understanding there. Today, we > have the Incubator performing that, but no reason we can't have pTLPs > managing that process. We file "forms" about clearance with the Incubator, > but really: that should be filed $somehow defined by the VP of Legal > Affairs (and *that* position/process didn't exist until years after the > Incubator was established). > > TLPs are a recognition of a community. We can create probationary > communities, supported by ComDev, Legal, other communities, and reviewed by > the Board. > > Speaking as a Director of the ASF, if a Resolution arrived on the Board's > Agenda to create such a pTLP, then I would be supportive. The pTLP > construct is independent of the Apache Incubator. Anybody is free to define > how they want to approach it, and then ask the Board if they are willing to > try it. > > Cheers, > -g
IPMC/Incubator/Metors reform: where do we go from here
Hi! I think it would be fair to say that in the past month or so we've had a healthy amount of discussion around where to go next with IPMC/Incubator/Metors reform. A diverse set of view points has emerged that helped clarify things a great deal (at least for me it did!). This is all goodness. What seems to be missing at this point, though, is coming up with a set of actionable steps and moving forward. Here's what I would like to propose: lets decouple IPMC/Incubator/Metors reform from a *complimentary* plan of pTLPs. It is clear that no drastic change is in the cards for Incubator for the next 6 months. Whatever we do on that side of things has to be very measured and incremental. And regardless of whether IPMC gets reformed of stays exactly the same, running a pTLP experiment and evaluating that as an eventual alternative to IPMC seems pretty non-controversial to me. Personally, I'm much more enthusiastic about pTLPs becoming THE way of how new projects get added to the foundation. This is what I'm going to focus all of my personal energy in the coming months, hoping to demonstrate pTLP to not only be a viable, but a superior alternative to bringing new projects into the foundation. Although I can NOT offer my time to champion a more incremental approach to evolving the classic Incubator, I think it is of paramount importance that somebody do it. It would be a great thing if whoever becomes a new Chair can get this done. My only observation here is that despite our efforts to evolve 3 of the wikified proposals, the way they stand right now is not actionable within the charter of a careful, incremental approach to improving IPMC. Or to put it another way: there are still dealbreakers (btw, thanks to those who took time to provide that feedback on the wiki!) and hence should any of these proposal come to a vote -- I don't think they can reach a consensus in their current form. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling Name Searches
One option would be to get the company involved to donate the trademark, if you check with trademarks@a.o then I am pretty sure that has happened in the past and they can likely guide you on procedures for this Your wording implies that perhaps this isn't an option in this particular podlings case? Rob On 25/01/2015 06:45, "Branko Čibej" wrote: >On 25.01.2015 14:08, John D. Ament wrote: >> All, >> >> If a podling had its name and codebase donated from a company, which had >> already secured rights to the name, > >The term "secured rights" is a bit misleading. Even if they have a >registered trademark, that's no guarantee that it doesn't infringe on >anything, especially in a different jurisdiction. > >> what is required in the podling name search? > >IMO, same as always. There's no reason for the ASF to implicitly trust >corporate lawyers. We should always look for names that are globally >unambiguous. > >-- Brane > > >- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] Solicitation for IPMC Chair nomination
Hi! after making sure that there's still an Incubator to be managed for the next 6-12 months, I'd like to open up a discussion thread on soliciting nominations for the next IPMC Chair. Feel free to self-nominate or nominate folks who you know. Provide a summary of your 'program' or not. At this point, we want as much feedback and discussion as possible. The VOTE thread will come in a few weeks. Things to keep in mind while thinking about nominating yourself or others: 1. This is a 6-12 months commitment that, based on my personal experience, would require you to allocate 7-10 hours per week. 2. This is a rotating Chair and you would be expected to start a similar thread in 12 months. 3. From where I sit, the most important job for the new Chair for the next few months would be to help shape the incremental, actionable plan for improving the mentoring situation in the Incubator. 4. The situation around 'professional student' podlings is not improving nearly quick enough (4 years without a single release? really?). Anybody who has actionable ideas on how to improve it would get my support. Now, to get the ball rolling, here are the two folks I'd like to suggest as future IPMC Chairs: * Ted Dunning * Henry Saputra In my view, both have demonstrated an exceptional understanding of the 'Apache Way', dedication to mentoring podlings they are responsible for and enthusiasm around bringing new communities into the ASF family. On top of that, both have exercised a remarkable skill in conducting public discussions and driving towards consensus. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Solicitation for IPMC Chair nomination
> On Jan 26, 2015, at 10:45 AM, Roman Shaposhnik wrote: > > Hi! > > after making sure that there's still an Incubator > to be managed for the next 6-12 months, I'd like > to open up a discussion thread on soliciting > nominations for the next IPMC Chair. > > Feel free to self-nominate or nominate folks who > you know. Provide a summary of your 'program' > or not. At this point, we want as much feedback > and discussion as possible. The VOTE thread will > come in a few weeks. > > Things to keep in mind while thinking about nominating > yourself or others: > 1. This is a 6-12 months commitment that, based on my >personal experience, would require you to allocate 7-10 >hours per week. > >2. This is a rotating Chair and you would be expected to >start a similar thread in 12 months. FYI, this is a tradition, not a rule; albeit a very good tradition. >3. From where I sit, the most important job for the new >Chair for the next few months would be to help shape >the incremental, actionable plan for improving the >mentoring situation in the Incubator. > >4. The situation around 'professional student' podlings >is not improving nearly quick enough (4 years without >a single release? really?). Anybody who has actionable >ideas on how to improve it would get my support. > > Now, to get the ball rolling, here are the two folks I'd > like to suggest as future IPMC Chairs: >* Ted Dunning >* Henry Saputra > In my view, both have demonstrated an exceptional > understanding of the 'Apache Way', dedication to > mentoring podlings they are responsible for and enthusiasm > around bringing new communities into the ASF family. > On top of that, both have exercised a remarkable skill > in conducting public discussions and driving towards > consensus. > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Solicitation for IPMC Chair nomination
On Mon, Jan 26, 2015 at 10:49 AM, Alan D. Cabrera wrote: >> Things to keep in mind while thinking about nominating >> yourself or others: >> 1. This is a 6-12 months commitment that, based on my >>personal experience, would require you to allocate 7-10 >>hours per week. >> >>2. This is a rotating Chair and you would be expected to >>start a similar thread in 12 months. > > FYI, this is a tradition, not a rule; albeit a very good tradition. True, but FWIW: anybody NOT firmly sharing this expectation will fail to receive support of a few IPMC members (including yours truly). Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Solicitation for IPMC Chair nomination
> On Jan 26, 2015, at 10:57 AM, Roman Shaposhnik wrote: > > On Mon, Jan 26, 2015 at 10:49 AM, Alan D. Cabrera > wrote: >>> Things to keep in mind while thinking about nominating >>> yourself or others: >>> 1. This is a 6-12 months commitment that, based on my >>> personal experience, would require you to allocate 7-10 >>> hours per week. >>> >>> 2. This is a rotating Chair and you would be expected to >>> start a similar thread in 12 months. >> >> FYI, this is a tradition, not a rule; albeit a very good tradition. > > True, but FWIW: anybody NOT firmly sharing this > expectation will fail to receive support of a few IPMC > members (including yours truly). And me as well! :) Regards, Alan - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IPMC/Incubator/Metors reform: where do we go from here
+1; this is a pragmatic proposal. -C On Mon, Jan 26, 2015 at 10:25 AM, Roman Shaposhnik wrote: > Hi! > > I think it would be fair to say that in the > past month or so we've had a healthy amount > of discussion around where to go next with > IPMC/Incubator/Metors reform. A diverse > set of view points has emerged that helped > clarify things a great deal (at least for me it did!). > > This is all goodness. What seems to be missing > at this point, though, is coming up with a set of > actionable steps and moving forward. > > Here's what I would like to propose: lets decouple > IPMC/Incubator/Metors reform from a *complimentary* > plan of pTLPs. It is clear that no drastic change is > in the cards for Incubator for the next 6 months. Whatever > we do on that side of things has to be very measured and > incremental. And regardless of whether IPMC gets reformed > of stays exactly the same, running a pTLP experiment and > evaluating that as an eventual alternative to IPMC seems > pretty non-controversial to me. > > Personally, I'm much more enthusiastic about pTLPs > becoming THE way of how new projects get added to > the foundation. This is what I'm going to focus all of > my personal energy in the coming months, hoping to > demonstrate pTLP to not only be a viable, but a superior > alternative to bringing new projects into the foundation. > > Although I can NOT offer my time to champion a more > incremental approach to evolving the classic Incubator, > I think it is of paramount importance that somebody > do it. It would be a great thing if whoever becomes a new > Chair can get this done. My only observation here is that > despite our efforts to evolve 3 of the wikified proposals, > the way they stand right now is not actionable within the > charter of a careful, incremental approach to improving IPMC. > Or to put it another way: there are still dealbreakers (btw, > thanks to those who took time to provide that feedback > on the wiki!) and hence should any of these proposal > come to a vote -- I don't think they can reach a consensus > in their current form. > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[QUESTION] Importing a project from GitHub
Dear Incubator, (if this isn’t the right list to ask this, please direct be to the correct place). The CouchDB community was approached by the lead developer of https://github.com/dscape/nano to have the project become apart of Apache CouchDB. The community has voiced some interest in pursuing this. There has not been a vote on this yet, though, this is just to clear any preliminary concerns. Is there a precedent for importing GitHub projects to the ASF? In particular, how do we handle the GitHub-usual main-dev-team + lots of drive-by-contrbutors without a clear copyright assignment step in place? While the lead developer and copyright holder as per the projects README.md has made the most significant contributions (412 commits / 41,036++ / 39,540--), some of the other contributors have not-insignificant (double negative alert!) contributions (17 commits / 613++ / 53--, e.g., see https://github.com/dscape/nano/graphs/contributors for details). As per ASF requirements, is the lead developer in a position to donate the project as a whole to the ASF? Which, if any, of the other contributors will have to co-sign the donation? Or put their contributions under an ICLA of their own? Or what other things need to be done? FWIW, the second most prolific contributor expressed interest in moving to the ASF with the project, all legalities covered. The rest are pretty much inactive at this point, or have only made insignificant contributions, that were clearly meant to be included in the main project. * * * My understanding is that getting the main contributors / active maintainers to do a software grant and/or ICLA will do the trick, as minor contributions that were meant to be included in the project (as per regular ASF contributions guidelines), don’t need the legal red tape. That said, where do we make the cut off for significant contributions? In the given project, my gut feeling says contributors #1 and #2 (https://github.com/dscape/nano/graphs/contributors) will cover what we need, but I’d like to get confirmation on this before proceeding. Assume all the other bits (license, dependencies, community vote) would be sorted. Does the above sound reasonable or am I way off on any point? Thank you for your advice! Best Jan -- signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [DISCUSS] Solicitation for IPMC Chair nomination
+1 for Ted Dunning. Ted has passion for the Incubator's mission. He is an excellent consensus builder, with the right mix of patience and advocacy. He can get the job done while sending judicious amounts of email, which is important in keeping traffic on general@incubator under control. He is politically adept and tough enough to handle the challenges of interfacing with the Board and with outside organizations. If he will take the job, the Incubator would be lucky to have him. FWIW, I don't have the expectation that Ted or any other Chair will *lead* reform -- Apache Chairs are not executives. But if Ted chooses to be be an active moderator, I have faith that he will do as well as anyone could in guiding consensus for whatever bottom-up proposals emerge. Marvin Humphrey On Mon, Jan 26, 2015 at 10:45 AM, Roman Shaposhnik wrote: > Hi! > > after making sure that there's still an Incubator > to be managed for the next 6-12 months, I'd like > to open up a discussion thread on soliciting > nominations for the next IPMC Chair. > > Feel free to self-nominate or nominate folks who > you know. Provide a summary of your 'program' > or not. At this point, we want as much feedback > and discussion as possible. The VOTE thread will > come in a few weeks. > > Things to keep in mind while thinking about nominating > yourself or others: >1. This is a 6-12 months commitment that, based on my > personal experience, would require you to allocate 7-10 > hours per week. > > 2. This is a rotating Chair and you would be expected to > start a similar thread in 12 months. > > 3. From where I sit, the most important job for the new > Chair for the next few months would be to help shape > the incremental, actionable plan for improving the > mentoring situation in the Incubator. > > 4. The situation around 'professional student' podlings > is not improving nearly quick enough (4 years without > a single release? really?). Anybody who has actionable > ideas on how to improve it would get my support. > > Now, to get the ball rolling, here are the two folks I'd > like to suggest as future IPMC Chairs: > * Ted Dunning > * Henry Saputra > In my view, both have demonstrated an exceptional > understanding of the 'Apache Way', dedication to > mentoring podlings they are responsible for and enthusiasm > around bringing new communities into the ASF family. > On top of that, both have exercised a remarkable skill > in conducting public discussions and driving towards > consensus. > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: my pTLP view
I can see how it could work for some new communities, but I don’t think it will work for all. I would imagine some potential podlings don’t have well-established communities. They might just be a few folks with a good idea and looking to recruit lots of new folks for the initial committers list. In such a case, it sort of makes sense for there to be an option, if enough ASF members want to be on that initial committers list not to mentor, but to be real committers, for the board to bypass incubation and establish a pTLP. For Flex, we did not have an established community of developers coming in with the code. But I don’t know that we could have recruited enough ASF members to be committers. Flex was different enough to not be closely related to any other Apache project. Folks were interested in seeing if Flex could be a viable Apache project, but I don’t think any existing ASF members have actually become Flex committers. I think I’ve processed new accounts for each of our committers. So would that mean that some future Flex would just not come to Apache? On 1/26/15, 10:09 AM, "Alan D. Cabrera" wrote: >TL;DR I think this is a good idea. > >I thought long and hard about this during the weekend and I’ve changed my >mind about this; I’ll spare you my handwringing thought processes. Some >things that I personally would like to see: > >- do away w/ the pTLP name, just make it a regular TLP >- ComDev should be charged w/ augmenting their maturity model with >“profiles” which can be applied to such TLPs, e.g. >- committers==PMC >- codebase going through IP clearance >- PMC considers TLP properly diverse >- PMC considers TLP properly active >- item 2 is too strict > > >Regards, >Alan > > >> On Jan 23, 2015, at 5:42 AM, Greg Stein wrote: >> >> Roman kicked off a query about "next steps", with links to several wiki >> pages on possibilities. The "IncubatorV2" page which describes a >> "probationary TLP" is nothing like I have thought about. >> >> In my mind, a pTLP looks *exactly* like any other PMC. They report >>directly >> to the Board, they have infrastructure like any other project (eg. >> FOO.apache.org). But they have two significant differences: >> >> 1. probationary text is prominent, much like we require "incubating" to >>be >> prominent in various locations/messages for podlings >> >> 2. the initial PMC is comprised of only ASF Members. committers can be >> chosen however the community decides. but the *project* is reviewed by >> people with (hopefully/theoretically) experience with the Foundation and >> its views on communities >> >> That's it. By creating a PMC that understands what is needed, then they >>can >> groom new PMC members, and use the standard process for adding them to >>the >> PMC. The Board doesn't care about committership, so the pTLP can do >> whatever it wants in that regard. >> >> The Board might not accept a pTLP resolution because it wants more >> greybeards on there, to help the community. Removing the "probationary" >> label, is up to the pTLP to request, and the Board to approve. It is >> usually pretty obvious when a community has reached that point, if you >>are >> talking about active ASF/PMC Members. But the Board would apply its own >> level of trust. >> >> There is a big element here, which didn't exist 12 years ago: the >>Board's >> ability to review many projects. Before the Incubator, there weren't >>that >> many projects. The Directors didn't have a lot of experience with a lot >>of >> breadth. Nowadays, we review the work of *dozens* of projects every >>month. >> If one is a pTLP instead of a regular TLP? Not a big deal. They have >>some >> operational restrictions, but the report should be showing us a typical >> Apache community. >> >> The other aspect is IP clearance and management, which also didn't >>exist a >> dozen years ago (and the Incubator was basically started in response to >> some IP problems). We have a much better understanding there. Today, we >> have the Incubator performing that, but no reason we can't have pTLPs >> managing that process. We file "forms" about clearance with the >>Incubator, >> but really: that should be filed $somehow defined by the VP of Legal >> Affairs (and *that* position/process didn't exist until years after the >> Incubator was established). >> >> TLPs are a recognition of a community. We can create probationary >> communities, supported by ComDev, Legal, other communities, and >>reviewed by >> the Board. >> >> Speaking as a Director of the ASF, if a Resolution arrived on the >>Board's >> Agenda to create such a pTLP, then I would be supportive. The pTLP >> construct is independent of the Apache Incubator. Anybody is free to >>define >> how they want to approach it, and then ask the Board if they are >>willing to >> try it. >> >> Cheers, >> -g > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For
RE: my pTLP view
It's an *option* not the only route. Working for some but not others is just fine. Ross -Original Message- From: Alex Harui [mailto:aha...@adobe.com] Sent: Monday, January 26, 2015 11:23 AM To: general@incubator.apache.org Cc: Chris Mattmann; Jim Jagielski Subject: Re: my pTLP view I can see how it could work for some new communities, but I don’t think it will work for all. I would imagine some potential podlings don’t have well-established communities. They might just be a few folks with a good idea and looking to recruit lots of new folks for the initial committers list. In such a case, it sort of makes sense for there to be an option, if enough ASF members want to be on that initial committers list not to mentor, but to be real committers, for the board to bypass incubation and establish a pTLP. For Flex, we did not have an established community of developers coming in with the code. But I don’t know that we could have recruited enough ASF members to be committers. Flex was different enough to not be closely related to any other Apache project. Folks were interested in seeing if Flex could be a viable Apache project, but I don’t think any existing ASF members have actually become Flex committers. I think I’ve processed new accounts for each of our committers. So would that mean that some future Flex would just not come to Apache? On 1/26/15, 10:09 AM, "Alan D. Cabrera" wrote: >TL;DR I think this is a good idea. > >I thought long and hard about this during the weekend and I’ve changed >my mind about this; I’ll spare you my handwringing thought processes. >Some things that I personally would like to see: > >- do away w/ the pTLP name, just make it a regular TLP >- ComDev should be charged w/ augmenting their maturity model with >“profiles” which can be applied to such TLPs, e.g. >- committers==PMC >- codebase going through IP clearance >- PMC considers TLP properly diverse >- PMC considers TLP properly active >- item 2 is too strict > > >Regards, >Alan > > >> On Jan 23, 2015, at 5:42 AM, Greg Stein wrote: >> >> Roman kicked off a query about "next steps", with links to several >> wiki pages on possibilities. The "IncubatorV2" page which describes a >> "probationary TLP" is nothing like I have thought about. >> >> In my mind, a pTLP looks *exactly* like any other PMC. They report >>directly to the Board, they have infrastructure like any other >>project (eg. >> FOO.apache.org). But they have two significant differences: >> >> 1. probationary text is prominent, much like we require "incubating" >>to be prominent in various locations/messages for podlings >> >> 2. the initial PMC is comprised of only ASF Members. committers can >> be chosen however the community decides. but the *project* is >> reviewed by people with (hopefully/theoretically) experience with the >> Foundation and its views on communities >> >> That's it. By creating a PMC that understands what is needed, then >>they can groom new PMC members, and use the standard process for >>adding them to the PMC. The Board doesn't care about committership, >>so the pTLP can do whatever it wants in that regard. >> >> The Board might not accept a pTLP resolution because it wants more >>greybeards on there, to help the community. Removing the "probationary" >> label, is up to the pTLP to request, and the Board to approve. It is >>usually pretty obvious when a community has reached that point, if you >>are talking about active ASF/PMC Members. But the Board would apply >>its own level of trust. >> >> There is a big element here, which didn't exist 12 years ago: the >>Board's ability to review many projects. Before the Incubator, there >>weren't that many projects. The Directors didn't have a lot of >>experience with a lot of breadth. Nowadays, we review the work of >>*dozens* of projects every month. >> If one is a pTLP instead of a regular TLP? Not a big deal. They have >>some operational restrictions, but the report should be showing us a >>typical Apache community. >> >> The other aspect is IP clearance and management, which also didn't >>exist a dozen years ago (and the Incubator was basically started in >>response to some IP problems). We have a much better understanding >>there. Today, we have the Incubator performing that, but no reason we >>can't have pTLPs managing that process. We file "forms" about >>clearance with the Incubator, but really: that should be filed >>$somehow defined by the VP of Legal Affairs (and *that* >>position/process didn't exist until years after the Incubator was >>established). >> >> TLPs are a recognition of a community. We can create probationary >>communities, supported by ComDev, Legal, other communities, and >>reviewed by the Board. >> >> Speaking as a Director of the ASF, if a Resolution arrived on the >>Board's Agenda to create such a pTLP, then I would be supportive. The >>pTLP construct i
Re: [VOTE] Recommend retirement for NPanday poddling
+1 [sadly] On Wed, Jan 21, 2015 at 02:13PM, Roman Shaposhnik wrote: > This is a vote on recommending a retirement option > for the NPanday poddling. > > It comes on the hills of the general consensus of > the NPanday community and its mentors that > retirement is the only viable path at this point: > http://markmail.org/thread/litmh5wmwbclrk6n > http://s.apache.org/Efn > > NPanday entered incubator on 13th of August 2010: >http://incubator.apache.org/projects/npanday.html > Up until 2012 the poddling was doing reasonably well, > producing two releases and adding mentors and > committers. Starting from 2012 the community started > to dwindle and no further releases were produced. > Starting from 2014 the poddling really struggled to > regain vitality despite of numerous attempts to help > by Brett Porter and Konstantin Boudnik. The most > visible attempt was in July/August 2014 and resulted in > a spur of JIRA and ML activity, but couldn't be sustained > without direct involvement of Brett and Konstantin: > https://wiki.apache.org/incubator/August2014 > Starting from September the poddling was back to > the usual levels: > http://mail-archives.apache.org/mod_mbox/incubator-npanday-dev/ > http://mail-archives.apache.org/mod_mbox/incubator-npanday-commits/ > http://mail-archives.apache.org/mod_mbox/incubator-npanday-users/ > while missing Incubator reports: > https://wiki.apache.org/incubator/November2014 > https://wiki.apache.org/incubator/December2014 > and having absolutely 0 commits coming into the repository. > It now appears that that all of the PPMC has been disengaged > and the user community for the project is pretty much non existent. > > IPMC has been monitoring the situation all throughout 2014: >http://markmail.org/message/3sbwfpedosyqzqhn >http://markmail.org/message/c2fbokolyujki3gl >http://markmail.org/thread/3ttavmqnq5s6pe74 >http://markmail.org/message/bxelz5ati2hofe4y > and at this point it feels like the most production option would > be to recommend retirement of the poddling. Should > the VOTE pass, Konstantin and myself are volunteering > to take care of the poddling retirement mechanics. > > Vote will run for at least 72 hours (to 1/26/14, noon PST). > > [ ] +1 Recommend retiring NPanday poddling from the Incubator. > [ ] +/-0 Don't care, but... > [ ] -1 Don't recommend retiring NPanday poddling from the Incubator because > ... > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [QUESTION] Importing a project from GitHub
I think your assumption is fairly reasonable. The iithmus test would be; What if any contributions outside the sign-off ones, turn out to be not "clean"? Is it reasonable to remove such patch and do a rewrite of that section? If the answer is "yes, we can either re-write or remove that without too much impediment", then I think that is a reasonable cut-off point. Niclas On Tue, Jan 27, 2015 at 3:13 AM, Jan Lehnardt wrote: > Dear Incubator, > > (if this isn’t the right list to ask this, please direct be to the correct > place). > > The CouchDB community was approached by the lead developer of > https://github.com/dscape/nano to have the project become apart of Apache > CouchDB. The community has voiced some interest in pursuing this. There has > not been a vote on this yet, though, this is just to clear any preliminary > concerns. > > Is there a precedent for importing GitHub projects to the ASF? > > In particular, how do we handle the GitHub-usual main-dev-team + lots of > drive-by-contrbutors without a clear copyright assignment step in place? > > While the lead developer and copyright holder as per the projects > README.md has made the most significant contributions (412 commits / > 41,036++ / 39,540--), some of the other contributors have not-insignificant > (double negative alert!) contributions (17 commits / 613++ / 53--, e.g., > see https://github.com/dscape/nano/graphs/contributors for details). > > As per ASF requirements, is the lead developer in a position to donate the > project as a whole to the ASF? > > Which, if any, of the other contributors will have to co-sign the > donation? Or put their contributions under an ICLA of their own? Or what > other things need to be done? > > FWIW, the second most prolific contributor expressed interest in moving to > the ASF with the project, all legalities covered. The rest are pretty much > inactive at this point, or have only made insignificant contributions, that > were clearly meant to be included in the main project. > > * * * > > My understanding is that getting the main contributors / active > maintainers to do a software grant and/or ICLA will do the trick, as minor > contributions that were meant to be included in the project (as per regular > ASF contributions guidelines), don’t need the legal red tape. > > That said, where do we make the cut off for significant contributions? In > the given project, my gut feeling says contributors #1 and #2 ( > https://github.com/dscape/nano/graphs/contributors) will cover what we > need, but I’d like to get confirmation on this before proceeding. > > Assume all the other bits (license, dependencies, community vote) would be > sorted. > > Does the above sound reasonable or am I way off on any point? > > Thank you for your advice! > Best > Jan > -- > > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java
[VOTE] Release Apache NiFI 0.0.1-incubating
Hello The Apache NiFi (incubating) team is pleased to be calling this vote for the source release of Apache NiFi 0.0.1-incubating. With six binding (in the ppmc sense) +1 votes and no dissenting votes the PPMC has approved the vote for the release in this thread: http://s.apache.org/nifi-rc3 We now ask the IPMC to vote for this release. Since this is our first release as part of the Apache Incubator it will be slightly unique because we need to release two components. The first component is the 'nifi-nar-maven-plugin' which allows us to build 'NiFi Archives' which is part of our classloader isolation model. The second is simply 'nifi' which is the full build and application that is 'Apache NiFi (incubating)'. After this first release we expect to be releasing the 'nifi-nar-maven-plugin' very rarely. So we'll break the information sections of this vote into two parts where one is for 'nifi-nar-maven-plugin' and the other 'nifi'. For the 'nifi-nar-maven-plugin' -- The source zip, including signatures, digests, etc. can be found at: https://repository.apache.org/content/repositories/orgapachenifi-1021 The specific repository path in that staging repo is: orgapachenifi-1021/content/org/apache/nifi/nifi-nar-maven-plugin/1.0.0-incubating/ The sources.zip is called 'nifi-nar-maven-plugin-1.0.0-incubating-source-release.zip' The Git tag is nifi-nar-maven-plugin-1.0.0-incubating-RC3 The Git commit ID is 6e69d99444e22772df300cd777096dc21a7c8e35 https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=6e69d99444e22772df300cd777096dc21a7c8e35 Checksums of nar-maven-plugin-1.0.0-incubating-source-release.zip: MD5: 2681be25c32a45df07fbac59f768c5d2 SHA1: 1e6057e07c32a7a0208afdc36e7ce725bd9935e4 7 issues were closed/resolved for this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329307 Note once you have completed the verification of the 'nifi-nar-maven-plugin' you will have 'nifi-nar-maven-plugin:1.0.0-incubating' in your local repo and thus you can move on to the 'nifi' build below which depends on it. For 'nifi' - The source zip, including signatures, digests, etc. can be found at: https://repository.apache.org/content/repositories/orgapachenifi-1022 The specific repository path in that staging repo is: orgapachenifi-1022/org/apache/nifi/nifi/0.0.1-incubating/ The sources.zip is called 'nifi-0.0.1-incubating-source-release.zip' The Git tag is 'nifi-0.0.1-incubating-RC3' The Git commit ID is 3a7625920866deaab1f3973fc4db0847d054a9b5 https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;a=commit;h=3a7625920866deaab1f3973fc4db0847d054a9b5 Checksums of nifi-0.0.1-incubating-source-release.zip: MD5: f421bb67a775b9ef7e29a34c08c538c1 SHA1: a04a3914d9e5a4455c1b503785a7772ab772816c 114 issues were closed/resolved for this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12329078 The following information applies to both the 'nifi-nar-maven-plugin' and 'nifi': Release artifacts are signed with the following key: https://people.apache.org/keys/committer/joewitt.asc KEYS file available here: https://dist.apache.org/repos/dist/release/incubator/nifi/KEYS This vote will follow 'http://www.apache.org/foundation/voting.html' 'Votes on Package Releases' guidelines. The vote will be open for 72 hours. Please download the release candidate and evaluate the necessary items including checking hashes, signatures, build from source, and test. Then please vote: [ ] +1 Release this package as Apache NiFi 0.0.1-incubating [ ] +0 no opinion [ ] -1 Do not release this package because because...