Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
On Wed, Aug 14, 2019 at 9:47 PM Justin Mclean wrote: > > Hi > > Thanks for the idea and offer of help. > > > 1) Concurrent with the start of a release vote by a PPMC, the IPMC is > > to be notified that that vote is happening. IPMC members are > > encouraged to participate in the vote process on the PPMC list where > > it is happening. > > This has been discussed before and I’m not sure the IPMC has the bandwidth > for this. Most releases go through a couple RCs, sometime that can be more. > This would be asking the IPMC to potentially review 3x-5x the number of > releases than it normally done. > > > 3) If the PPMC vote completes before there is a call for an IPMC vote, > > the PPMC is free to make the release. > > How does fit with the requirement that 3 +1 PMC votes needed for a release? > Or is it doing away with it? Sorry for being unclear. My suggestion was that the IPMC only votes in the exceptional case where an IPMC member requests a vote. My assertion is that oversight and the opportunity to intercede when needed is sufficient. > Thanks, > Justin - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Business decisions and risk (was: [DISCUSS] IPMC votes on releases)
On Wed, Aug 14, 2019 at 1:24 AM Justin Mclean wrote: > > Hi, > > >> This is because of ASF bylaws i.e only PMC votes are binding on releases. > > > > That is not in the Bylaws. Stop making stuff up. > > That the way it’s been explained to me, several times, by experienced ASF > people, that only PMC votes are binding on releases and podlings are not > mentioned in the ASF bylaws. Bylaw wise see section 6.3. But you're right, > it would be more precise to say, it's a combination of 6.3 of the bylaws of > the ASF and the ASF's policy on voting on releases. [1] Concrete suggestion, and an offer to help. The ASF bylaws contain a lot of curiosities such as "each member of a Project Management Committee shall serve on such committee for a period of one year or until his or her successor is elected and qualified or until his or her earlier resignation or removal", and have been interpreted as the board is the one that determines membership of PMCs. Over time, that understanding has evolved, and is currently implemented as a notification requirement[2]. Perhaps something similar can be made to work here. Outline of proposed process: 1) Concurrent with the start of a release vote by a PPMC, the IPMC is to be notified that that vote is happening. IPMC members are encouraged to participate in the vote process on the PPMC list where it is happening. 2) If anybody on the IPMC calls for a IPMC vote on the release before the release occurs, then the release is blocked from happening until this vote completes. 3) If the PPMC vote completes before there is a call for an IPMC vote, the PPMC is free to make the release. If such a process were in place, then the burden on the PPMC would be normally be reduced to a single email per release. Any IPMC member could still -- for any reason -- call for a full IPMC vote, but my sense is that that rarely will happen, and when it does, it will generally be because there is a substantive issue that needs to be resolved. If something like this were adopted by the IPMC, I will offer to help update [1] to reflect that a different process applies during incubation. - Sam Ruby [1] https://www.apache.org/foundation/voting.html#ReleaseVotes [2] https://whimsy.apache.org/board/minutes/PMC_Membership_Change_Process.html - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
On Thu, Jun 27, 2019 at 7:57 AM Greg Stein wrote: > > On Thu, Jun 27, 2019 at 12:13 AM Justin Mclean > wrote: > > > > b) It listed as a TLP in Whimsy > > Whimsy is not canonical. Its label means absolutely nothing. Board > decisions are canonical. The canonical source is: https://svn.apache.org/repos/private/committers/board/committee-info.txt This source is nearly always updated via Whimsy roster tool as that keeps LDAP in sync. The sectary also uses the Whimsy agenda tool to update this information. The Whimsy roster tool also provides a convenient mechanism to query this information. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podlings, the Incubator, relationships and Apache
On Mon, Jun 24, 2019 at 12:12 PM Roman Shaposhnik wrote: > > On Sun, Jun 23, 2019 at 11:03 PM Alex Harui wrote: > > > > But, IMO, the reason the question went to VP Legal is that it doesn't > > really matter what the IPMC thinks if their "business decision" will have > > an impact on the "Legal Shield" and the insurance premiums that go with it. > > So I think the question got lost on legal-discuss. The "space of options" > > should probably be constrained by the "Legal Shield". > > Nope. That's not how any of the legal works. Legal never makes policy > -- legal always evaluates risk profiles of the policy that business > stakeholders make. > > In fact, and thin may come as a shock, legal never *blocks* anything. > Legal doesn't have veto power simply because the business decision > always trupms legal. Please interpret the following statement extremely narrowly: the Legal Affairs committee is a board committee. Read section 5.9 of the ASF bylaws. I believe that the correct way to interpret this is that the Legal Committee (and therefore, VP, Legal) is empowered to make business decisions on behalf of the ASF. This would include pulling a release or disbanding a committee. Now I'm not suggesting that you start vetoing anything. I'm just saying that should you find yourself in a position where a veto is necessary, don't question whether or not you have that authority. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
On Fri, Jun 7, 2019 at 8:57 PM Justin Mclean wrote: > > Hi, > > > 1) Is it legal to include GPL licensed software in releases? The > > answer is yes... as long as we comply with the terms of that license. > > In the case of strong copyleft licenses, that could mean that the > > podling release itself may need also be GPL licensed. > > And in cases where this has happened, it’s been ALv2 licensed, so I guess > that wouldn’t be legal. But we also allow minor stuff like this a lot of the > time e.g forgetting to add MIT license text to LICENSE. > > > 2) Is it legal to include compiled code in releases? Yes. > > But certainly against ASF policy and one of it core values. > > > 3) Is it legal to include copyright violations in releases? No. > > In most cases, where this has occurred this has been minor, like including a > cat photo, and can be easily sorted by removing or asking for permission. If > someone did come along as say you don’t have permission to do that, we’d say > we were very sorry and fix it. > > Perhaps rewording the proposal to say "serious issue typically found in > podling releases” would help? Podlings generally make some effort to try and > get things right. I think it would be a mistake to include the word serious in the proposal that you are asking for board approval. That likely will result in a 'no' response. As would any request that that board approve anything that is illegal, like distributing code without complying with the terms under which that code is licensed. There may be some wiggle room in getting the board to approve letting the incubator produce releases that are legal but may not comply with ASF policy in one or more ways, given that those deviations are documented, there exists a plan to fix those deviations, and that podling graduation is gated on the fixing of those deficiencies. > Thanks, > Justin - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [IMPORTANT] Board proposal on podling releases
On Fri, Jun 7, 2019 at 2:00 PM Craig Russell wrote: > > Hi Justin, > > As a board member, I'm not comfortable with granting a blanket exception to > policy that might put us at legal risk. > > As an IPMC member, I think that we do not want to allow podlings to release > material that might put us at legal risk. I do think that the IPMC under > today's policy has the ability to decide whether a podling release puts us at > risk and therefore should be blocked. So I am not convinced that the IPMC > needs to ask for this waiver from the board. > > My understanding as an IPMC member is that there are some items in a release > that can be allowed where they would not be in a TLP release. These things > have historically drawn -1 votes from IPMC members. > > I think there is consensus that a podling release does not have to conform in > every respect to what we expect from a TLP release. > > I think that the incubator IPMC should first flesh out (on the general@ list) > which materials in a podling release are > a) fine; > b) minor issue (file a JIRA and fix before graduation); or > c) blocker (puts the foundation at risk). > > The detail of what is minor versus what it a blocker is the most important > thing that needs clarity. As of now, I don't see consensus although I see > movement. Drilling down by taking the contents of the draft incubator report: "Serious problems, such as; including GPL licensed software, including compiled code, or copyright violations, in a release is currently seen as a reason to vote -1 on a release." Picking them off one by one: 1) Is it legal to include GPL licensed software in releases? The answer is yes... as long as we comply with the terms of that license. In the case of strong copyleft licenses, that could mean that the podling release itself may need also be GPL licensed. 2) Is it legal to include compiled code in releases? Yes. 3) Is it legal to include copyright violations in releases? No. > Craig - Sam Ruby > > On Jun 6, 2019, at 11:45 PM, Justin Mclean wrote: > > > > Hi, > > > > As suggested I’ve collated information from several threads and turned it > > into a proposal for the board. Any edits, feedback, agreement, disagreement > > etc etc is welcome. In particular it would be nice to hear some feedback > > from people who are in favour of this. > > > > Note that this is important as it probably changes the advice mentors will > > give their podlings on releases and change in a positive way how we vote on > > releases with serious issues in them. If you are a mentor or vote on > > releases please read it. Again feedback welcome. > > > > If the board agrees with the proposal I think we'll need to update the > > incubator DISCLAIMER. I’ve suggested what we might add in the proposal but > > the exact changes can to be discussed here. If the board disagrees with the > > proposal I suggest we discuss and come up with a list of serious issues > > that the IPMC recommends voting -1 vote on a release. This is just > > guidance, not rules, and there may of course be exceptions. (For instance > > you could ask VP legal for an exception as has been done in the past.) > > That way mentors and podlings have clear expectations on releases must > > contain. > > > > The proposal can be found in the draft board report. [1] > > > > Thanks, > > Justin > > > > 1. https://cwiki.apache.org/confluence/display/INCUBATOR/June2019 > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > Craig L Russell > c...@apache.org > > > - > 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: Podling releases and release policy
On Sat, Jun 1, 2019 at 7:50 PM Justin Mclean wrote: > > Hi, > > > Point me to where you are not allowed to make non-official podling releases > > that conform to Incubator policy. > > I find that hard to parse and perhaps you meant don’t conform to incubator > policy? But either way it’s not incubators policy, it’s the boards and infra > policy. Been lurking. Before I proceed, I will note that you have two members of the board and one infrastructure representative participating. Each has either explicitly or implicitly supported the idea of the incubator setting direction for podlings. Now my observation. My experience is that when a PMC comes to the board with an open ended question asking for advice, the responses are not crisp. This is by design. We are not a top down organization. No one Director is authorized to speak for the board. An approach I have found much more successful: come up with a proposal. Often times it will get approved. Some times you will be asked to make changes. And some times you will get yelled at. But one thing you will get is a crisp answer. - Sam Ruby P.S. Don't take this advice as recommending that you create a board resolution. In most cases, coming to consensus in a transparent way and informing the board in a sentence or a paragraph in the next board report that unless you hear otherwise, the Incubator will be implementing X is sufficient. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Generating + formatting the Board report from the website?
On Wed, May 22, 2019 at 10:26 AM Justin Mclean wrote: > > Hi, > > > Doesn't the new Markdown format help with that? > > I hope it will but: > a) Messy markdown with inconsistent formatting can still look good. > b) Some podlings submit at the last minutes and ignore formatting. > c) Some podlings tend to copy and paste the last report and modify and may > miss/alter the markdown. > > We’ll see what happens. > > > Most of my sloppy formatting is already fixed by the Markdown > > conversion > > I'm not sure the board will be viewing the results of the markdown but just > the raw text??? Currently the Whimsy report tool doesn’t support markdown > right? Let's back up, and ignore whimsy for the moment. Approved board minutes are published here, in text/plain format: https://www.apache.org/foundation/board/calendar.html We need to figuring out what the desired end result (currently I believe that this is spec'ed someplace as less than 80 characters per line and no wiki markup, but I forget where), and then work backwards to figure out when these changes are to be mad. It is entirely possible that all of these changes can be made without whimsy. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Generating + formatting the Board report from the website?
On Wed, May 22, 2019 at 8:28 AM Justin Mclean wrote: > > Hi, > > > - Whimsy likes 80 column linewraps. It will only rewrap the current > > report if you push the rewrap button and then commit. It doesn't ever > > wrap long URLs. > > Currently that severely breaks the incubator report so I don’t use it. Also > any edits to the incubator report in Whimsey duplicates large sections of it. > Both of these issues are known. The duplication problem was fixed by changing the incubator report to not have lines starting with dashes surrounding the TOC. There actually is special case logic, including tests, for reflowing incubator reports. Here are the tests: https://github.com/apache/whimsy/blob/master/www/board/agenda/spec/reflow_spec.rb What we haven't had is someone write down the rules for reflowing incubator reports. If that were done, you might be able to save a good fraction of that half hour a month of effort. > Thanks, > Justin - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Generating + formatting the Board report from the website?
On Wed, May 22, 2019 at 5:46 AM Justin Mclean wrote: > > Hi, > > > Do you then mean to run "fold -w 76 cat -s" on the formatted Markdown > > to prepare it for the Board report? > > Yes, as your experiment is still of use. Someone somewhere is still going to > view it in text form. > > It’s still unclear to me how Whimsy will render this, guess we find out when > we submit it? > > > That seems to work fine as the basic formatting is now clean. > > Going on precious experience I still expect to be a fair amount of hand > editing after that to fix things. It usually takes an hour of my time. Perhaps next time, save the before and after and the whimsy team can take a look at how much of it can be automated. > Thanks, > Justin - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: board report duplication
On Sat, Apr 13, 2019 at 5:54 PM Ted Dunning wrote: > > Moving to a data format that makes a stronger distinction between content > and envelope might be nice. JSON would work if content is actually quoted > (don't bet on it). A directory would probably be better because the content > of a file can't break the meta-data in the directory. Something like a real > database would be even better. This month's agenda in JSON format: https://whimsy.apache.org/board/agenda/2019-04-17.json Ideally the incubator report would not be a single blob (entry 47 this month), but would be a structure. > Let's all blame Telnet and FTP for starting this lamentable trend of mixing > text and meta-data, but it would be nice to stop reliving five decade old > problems. In this case, the text format predated the agenda tool. To date, a design constraint has been to continue to allow the text format be edited directly (and many of us still find that to be convenient at times). - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: board report duplication
On Sat, Apr 13, 2019 at 7:29 AM Shane Curcuru wrote: > > Sam Ruby wrote on 4/12/19 9:48 PM: > > On Fri, Apr 12, 2019 at 2:42 PM Sam Ruby wrote: > >> > >> 3) Somebody uses the whimsy board agenda tool to update the incubator > >> report, and it dutifully strips out the previous report (up to said > >> row of dashes) an inserts a new report. > > > > Here is the regular expression in question: > > > > https://github.com/apache/whimsy/blob/00d8c5d473beae972138e6c1b3bac2633b6ea342/www/board/agenda/views/actions/post.json.rb#L118 > > Thus, a key short term solution is to never put lines of 40 dashes in > the Incubator report, right? +1. Or at least avoid starting a line of dashes in column 1. Indent the dashes and you still have a visual separator without it looking like a report separator. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: board report duplication
On Fri, Apr 12, 2019 at 2:42 PM Sam Ruby wrote: > > 3) Somebody uses the whimsy board agenda tool to update the incubator > report, and it dutifully strips out the previous report (up to said > row of dashes) an inserts a new report. Here is the regular expression in question: https://github.com/apache/whimsy/blob/00d8c5d473beae972138e6c1b3bac2633b6ea342/www/board/agenda/views/actions/post.json.rb#L118 - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: board report duplication
On Fri, Apr 12, 2019 at 6:19 PM Justin Mclean wrote: > > Hi, > > > 3) Somebody uses the whimsy board agenda tool to update the incubator > > report, and it dutifully strips out the previous report (up to said > > row of dashes) an inserts a new report. > > It’s a bug in whimsey that cause the reports to be doubled I’ll check today > and fix in SVN if needed but the only issue shod be sign off and comment on > Spot. Careful, or I will may make whimsy reject any incubator report that contains attachment separator lines :-) > Thanks, > Justin - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: board report duplication
On Fri, Apr 12, 2019 at 12:12 PM Myrle Krantz wrote: > > Hey incubator, > > It looks like part of the incubator report was "doubled". I've deleted the > duplication, but I'd appreciate it if you'd check me to be sure I didn't > accidentally delete something that belonged. I still see duplication? TOC starting on line 2958 and 4206? The root cause for this generally is something along the lines of: 1) The agenda is a honking big file containing a bunch of attachments, separated by a row of dashes. 2) The incubator report is lengthy on its own, and contains one or more lines that look line and end of report. 3) Somebody uses the whimsy board agenda tool to update the incubator report, and it dutifully strips out the previous report (up to said row of dashes) an inserts a new report. > Best, > Myrle - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: List of Projects that went straight to Top Level Projects
On Mon, Apr 1, 2019 at 4:52 PM Dave Fisher wrote: > > > > > Pre-incubator: > > Ant, > Jakarta > > Avalon, > Jakarta > > DB, > Jakarta Thanks for the corrections! > > HTTP Server, Jakarta, Perl, PHP, TCL, XML > > > > Spun out from elsewhere: > > Archiva, > Maven ? Generally this information can be found in the establish resolution, in the paragraph that contains the word discharged. This extraction can often be automated, so I added this code. Some older resolutions don't quite follow this pattern (and some PMCs like Labs, etc aren't what we are looking for), so I hardcoded a table: https://github.com/apache/whimsy/commit/9667387e7467a98918dc3047ef32979462a92fc6 Updated results can be found here: https://whimsy.apache.org/incubator/graduated Note: this site is live in the sense that it will continue to update as new TLPs are created and projects are retired. There may occasionally be special cases to handle like the rename of Zest => Polygene. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: List of Projects that went straight to Top Level Projects
On Mon, Apr 1, 2019 at 2:28 PM Greg Stein wrote: > > On Mon, Apr 1, 2019 at 1:11 PM Julian Hyde wrote: > > > Most of the projects mentioned so far have been “internal” > > > Only because all the umbrella-derived projects haven't been mentioned. Most > of that "spin out to a TLP" was done a decade ago, so they've been omitted > from discussion. > > > > - code developed to help run the ASF. “External” projects also go > > straight-to-TLP and are more important because they have many more users > > and greater impact on the world. > > > > I recall only two "external" projects have gone straight-to-TLP: Serf, > Zest/Polygene. I'm guessing Dave, et al, will surface others, if they > exist. I would disagree with your latter statement; they went to TLP based > on oversight, rather than on userbase/impact. > > I would suggest: the 90% of straight-to-TLP have been "internal" or > "spun-out". My rough cut: Straight to TLP: Bahir, DRAT, Kibble, Orc, Serf, STeVe, Whimsy, Zest Pre-incubator: Ant, Avalon, Cocoon, DB, HTTP Server, Jakarta, Perl, PHP, TCL, XML Spun out from elsewhere: Archiva, Arrow, Avro, Axis, BookkeeperA, Camel, Continuum, Excalibur, Forrest, Gump, Hadoop, HBase, HiveMind, HTTPComponents, JAMES, JMeter, Karaf, Logging Services, Lucene, Mahout, Maven, Mina, POI, Quetzalcoatl, Royale, Santuario, Shale, Struts, Tiles, Tomcat, Turbine, Velocity, Web Services< Xalan, Xerces, XML Graphics, Yetus, Zookepper Non-code PMC: Attic, Community Development, Incubator, Labs, Public Relations - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: List of Projects that went straight to Top Level Projects
On Sun, Mar 31, 2019 at 9:53 PM Dave Fisher wrote: > > Hi Sam, > > That’s a cool table. Does your code look at the resolution tag? Doe we > possibly have some errors in podlings.xml? No, I don't currently look at the resolution tag, but that should be easy enough to add. That should take care of 3 of the 4 differences you found. I'll take a look at that tomorrow. Meanwhile: > (2) For Beehive, you don’t show it has graduated, but we have: > > sponsor="Incubator" startdate="2004-05-21" enddate="2005-07-18"> > Extensible Java application framework with an integrated > metadata-driven programming model for web services, web applications, and > resource access > https://whimsy.apache.org/board/minutes/Beehive.html The next column says 'false' indicating that the word 'incubator' was not found in the establish resolution, which makes sense as no establish resolution was found. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: List of Projects that went straight to Top Level Projects
I've gone ahead and added information from podlings.xml to this data. We have a number of entries which are in podlings.xml but don't contain incubator in their establishment resolution (Tika, Tapestry, Pig, Myfaces...) - Sam Ruby On Sun, Mar 31, 2019 at 8:08 PM Sam Ruby wrote: > > In March, I wrote a script to find establishment resolutions, and to > scan those resolutions for the word 'incubator': > > https://whimsy.apache.org/incubator/graduated#summary > > As always, the data is a bit dirty. There are a number of projects > that were created before we had establish resolutions, and some > projects like comdev -- while technically "bypassing" the incubator -- > are not the types of projects you are looking for. > > - Sam Ruby > > On Sun, Mar 31, 2019 at 7:28 AM Sharan Foga wrote: > > > > Hi All > > > > Does anyone know if there is a list of projects that bypassed incubation? > > For example - I know a couple of projects Royale and Kibble that went > > straight to TLP. Is there a list anywhere for all projects like this? > > > > Thanks > > Sharan > > > > - > > 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: List of Projects that went straight to Top Level Projects
In March, I wrote a script to find establishment resolutions, and to scan those resolutions for the word 'incubator': https://whimsy.apache.org/incubator/graduated#summary As always, the data is a bit dirty. There are a number of projects that were created before we had establish resolutions, and some projects like comdev -- while technically "bypassing" the incubator -- are not the types of projects you are looking for. - Sam Ruby On Sun, Mar 31, 2019 at 7:28 AM Sharan Foga wrote: > > Hi All > > Does anyone know if there is a list of projects that bypassed incubation? For > example - I know a couple of projects Royale and Kibble that went straight to > TLP. Is there a list anywhere for all projects like this? > > Thanks > Sharan > > - > 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: [RFC] Mentors and podling LDAP memberships
Yes, yes, not necessarily. First: " For that reason, I'd like to make a simplifying assumption: that all mentors are PPMC members, and all PPMC members are committers. " -- https://lists.apache.org/thread.html/a6ce7e3a366490f04f5c66e9434aa2b7da9a763f040262f1b12407af@%3Cgeneral.incubator.apache.org%3E As to your third question... I guess it would be possible (but weird) for somebody to want to stop as a mentor but continue as a committer (and possibly a PMC member). - Sam Ruby On Fri, Feb 22, 2019 at 8:57 AM sebb wrote: > > Are podling mentors expected to be in the LDAP owners group (i.e. on > the PPMC) and in the members group (i.e. committers)? > > This affects Whimsy: should it report discrepancies, e.g. mentors not > in the committers group? > > It also potentially affects graduation: normally at least some mentors > drop out at graduation, i.e. are not part of the initial PMC. This > would generally imply that they should also be dropped from the LDAP > owners group, and possibly the committers group as well. Is that the > case? > > - > 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: Clarifying on how to add initial PPMC members
On Mon, Dec 18, 2017 at 6:43 AM, John D. Ament <johndam...@apache.org> wrote: > Heyyy look at that, it's magic (check your email). You should be all set. > > But I should replace "requested" with "completed" to make sure people know > that it has to be done first. And as far as I know, it is a button, > however only infra and secretary can push that button. Correct. The authority required to execute that request is the same authority required to delete (or modify) any PMC or podling. > John - Sam Ruby > On Mon, Dec 18, 2017 at 6:33 AM Justin Mclean <justinmcl...@me.com> wrote: > >> Hi, >> >> > Were LDAP and DNS entries created yet? >> >> Probably not [1][2] (hey I’m impatient) but it’s a little unclear to me >> what needs to be done to sort this or why it couldn’t be automated. >> Creating a new podling should be as pushing a button IMO. >> >> Thanks, >> Justin >> >> 1. https://incubator.apache.org/guides/mentor.html#resources >> 2. https://issues.apache.org/jira/browse/INFRA-15682 >> >> >> - >> 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: svn commit: r1802207 - /incubator/public/trunk/content/projects/impala.xml
On Tue, Jul 18, 2017 at 1:28 PM, Jim Apple <jbap...@cloudera.com> wrote: > The rosters are then hidden from people who aren't committers on some ASF > project, yes? Saying "in whimsy" is shorthand. The data is stored in LDAP. Whimsy provides a web interface to update LDAP. Yes, that interface is committer only. The plans are to have the Apache Phonebook display this information from LDAP (most likely by requesting and then parsing public JSON versions of this information from the whimsy server). I don't know the current status of that effort. It would be better if this information was maintained in one place. A place that can be used for things like authentication. That place is LDAP. - Sam Ruby > On Mon, Jul 17, 2017 at 2:38 PM, John D. Ament <johndam...@apache.org> > wrote: > >> Just as a reminder, podling rosters only need to be maintained in whimsy. >> >> John >> >> On Mon, Jul 17, 2017 at 4:09 PM <jbap...@apache.org> wrote: >> >>> Author: jbapple >>> Date: Mon Jul 17 20:09:21 2017 >>> New Revision: 1802207 >>> >>> URL: http://svn.apache.org/viewvc?rev=1802207=rev >>> Log: >>> Add Michael Brown to Impala PPMC >>> >>> Modified: >>> incubator/public/trunk/content/projects/impala.xml >>> >>> Modified: incubator/public/trunk/content/projects/impala.xml >>> URL: http://svn.apache.org/viewvc/incubator/public/trunk/ >>> content/projects/impala.xml?rev=1802207=1802206=1802207=diff >>> >>> == >>> --- incubator/public/trunk/content/projects/impala.xml [utf-8] (original) >>> +++ incubator/public/trunk/content/projects/impala.xml [utf-8] Mon Jul >>> 17 20:09:21 2017 >>> @@ -138,6 +138,11 @@ >>> >>> >>>. >>> + mikeb >>> + Michael Brown >>> + >>> + >>> + . >>>casey >>>Casey Ching >>> >>> @@ -213,11 +218,6 @@ >>> >>> >>>Committers >>> - mikeb >>> - Michael Brown >>> - >>> - >>> - . >>>tmarshall >>>Thomas Tauber-Marshall >>> >>> >>> >>> >>> - >>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: cvs-h...@incubator.apache.org >>> >>> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DRAFT] What the new Status Pages potentially look like
On Thu, Jun 15, 2017 at 1:21 PM, Jim Apple <jbap...@cloudera.com> wrote: > Here are some suggestions: > > 1. Only make this the reporting structure for new podlings. > Grandfather in old podlings to the old structure, since they may > already have workflows built around it. Impala does. We don't need to delete the old structure; but we will soon get to the point where there is tooling that depends on the new structure being in place. Let's create the new structure for old podlings, given that (if history is any guide) there are podlings that exist now that won't be graduating for many years. I'd also suggest that we consider reconciling this with how we capture data for PMCs (currently FOAF). Anything that makes podlings be modeled as much as possible like prototype PMCs is a good thing. > 2. Provide a clear description of the meaning and formatting of each > field in comments on the YAML file itself. My recommendation is to treat the YAML file as internal state, and focus instead of providing a usable web interface to manage the internal state. > 3. Provide guidance on how long it takes from SVN checkin to whimsy > render change. 10 minutes. > 4. Use git, not SVN >From an automation perspective, svn is preferred. If we make the normal way to update this data a web interface, svn is reasonable as an exception mechanism, IMHO. > 5. Make sure the Whimsy page applies to all projects. For instance, > Impala releases are source tarballs, so if "Binary Distribution > Licensing" means something about a non-source-tarball release > artefact, it's not meaningful for Impala. > > 6. Give the fields on the whimsy page names that correspond, > one-to-one, with the YAML fields. > > 7. Give the Whimsy page headers more specific meanings. "Confirmation > of ASF Copyright Headers on Source Code on" could mean confirmation by > any number of people or committees. Which one is meant by this phrase? > If it's the IPMC, and the first approved release is what is meant by > this, change the name to "First Apache release" or something. > > 8. Provide the ability to lookup the information required to fill out > the status page. How can a podling find out when the SGA was received? > Please remember that podling personnel can change during incubation. - Sam Ruby > On Tue, Jun 13, 2017 at 6:04 PM, John D. Ament <johndam...@apache.org> wrote: >> Jim, >> >> For your specific cases, if all you want is to remove red text: >> >> - for :sga: enter the date in -MM-DD format of when the ASF Secretary >> acknowledged your SGA. Based on the records I have its 2016-03-15 >> - For the :asfCopyright: and :distributionRights: attributes, I would use >> 2017-01-20 as that's the day of the results of 2.8 which was the first >> release to have no issues during review. >> >> But please do continue to provide input, want to make sure we're building >> something useful, not a pain. >> >> HTH, >> >> John >> >> On Tue, Jun 13, 2017 at 8:52 PM Jim Apple <jbap...@cloudera.com> wrote: >> >>> I'm confused. The message to podlings@ said "If you're not sure what >>> to fill out, feel free to reach out." >>> >>> It sounds like there is no set way yet to fill it out. >>> >>> What can I do to get the bolded, red, inaccurate scare messages off of >>> our whimsy page? >>> >>> On Tue, Jun 13, 2017 at 5:30 PM, John D. Ament <john.d.am...@gmail.com> >>> wrote: >>> > Good points Dave. To be honest, since this is a prototype I don't have >>> > answers any more than "If you think it should do that, we can make it do >>> > that" >>> > >>> > What I did have in mind: >>> > >>> > --- >>> > :issueTracker: jira|github|bugzilla >>> > :wiki: if using confluence, their space key >>> > :jira: if using jira, their issue key (though I suppose this can be >>> > multiple) >>> > :proposal: link to the proposal page. >>> > :asfCopyright: the date that we confirmed ASF copyright headers on the >>> > source code (e.g. the first time a source release passed without any >>> issues) >>> > :distributionRights: the date that we confirmed the resulting binary >>> > satisfied our release policies (e.g. the first time a release included a >>> > binary without any issues) >>> > :ipClearance: a link to the IP Clearance page for this podling. I guess >>> > this can be multiple? >>> > :sga: date in which a SGA was received >>> > :website: http://impala.incubator
Re: [DRAFT] What the new Status Pages potentially look like
On Tue, Jun 13, 2017 at 9:04 PM, John D. Ament <johndam...@apache.org> wrote: > Jim, > > For your specific cases, if all you want is to remove red text: > > - for :sga: enter the date in -MM-DD format of when the ASF Secretary > acknowledged your SGA. Based on the records I have its 2016-03-15 > - For the :asfCopyright: and :distributionRights: attributes, I would use > 2017-01-20 as that's the day of the results of 2.8 which was the first > release to have no issues during review. > > But please do continue to provide input, want to make sure we're building > something useful, not a pain. Suggestion: let's start talking about how we should make the roster page prompt for, validate, and apply any changes. As in, for every field that is editable, there should be a way to bring up an HTML form. That form should contain explanatory text, and perform validations. Submitting that form should update the appropriate YAML file in svn, and potentially notify various lists of the change. If people can provide the information above for a single field, I can implement that change for the first field and people can use that as an example to do the same for other fields. > HTH, > > John - Sam Ruby > On Tue, Jun 13, 2017 at 8:52 PM Jim Apple <jbap...@cloudera.com> wrote: > >> I'm confused. The message to podlings@ said "If you're not sure what >> to fill out, feel free to reach out." >> >> It sounds like there is no set way yet to fill it out. >> >> What can I do to get the bolded, red, inaccurate scare messages off of >> our whimsy page? >> >> On Tue, Jun 13, 2017 at 5:30 PM, John D. Ament <john.d.am...@gmail.com> >> wrote: >> > Good points Dave. To be honest, since this is a prototype I don't have >> > answers any more than "If you think it should do that, we can make it do >> > that" >> > >> > What I did have in mind: >> > >> > --- >> > :issueTracker: jira|github|bugzilla >> > :wiki: if using confluence, their space key >> > :jira: if using jira, their issue key (though I suppose this can be >> > multiple) >> > :proposal: link to the proposal page. >> > :asfCopyright: the date that we confirmed ASF copyright headers on the >> > source code (e.g. the first time a source release passed without any >> issues) >> > :distributionRights: the date that we confirmed the resulting binary >> > satisfied our release policies (e.g. the first time a release included a >> > binary without any issues) >> > :ipClearance: a link to the IP Clearance page for this podling. I guess >> > this can be multiple? >> > :sga: date in which a SGA was received >> > :website: http://impala.incubator.apache.org >> > :graduationDate: to be filled in when the podling graduates >> > :resolution: tlp|subproject , if subproject the TLP should be in here >> > somehwere. We may want to track as "sponsor." >> > >> > I can draft this up on a wiki page to gain more input. What do you think >> > about using https://wiki.apache.org/incubator/PodlingStatusBrainstorm to >> > work through it? I had a few more questions in line. >> > >> > On Tue, Jun 13, 2017 at 7:09 PM Dave Fisher <dave2w...@comcast.net> >> wrote: >> > >> >> Hi John - >> >> >> >> These are excellent questions. I see each of these as being tuples of >> >> various kinds. >> >> >> >> For example :sga: could have multiple grants each of which has a date >> and >> >> a file name to refer to in the foundation records. >> >> >> >> >> > We don't usually expose the file name to people outside members, so I'm >> not >> > sure this would be useful. Multiple dates are also not common. >> > >> > >> >> The path to the source repository is missing completely. >> >> >> > >> > Which source repository? The podlings? I have a prototype for gitbox >> > podlings and think I can make it work for ASF git as well. For SVN, we >> can >> > assume default or have a list of values. >> > >> > >> >> >> >> Some of these items could be transitory. For example distributionRights >> >> may be confirmed but then something is added which negates those rights >> >> until the issue is cleared up. >> >> >> >> >> > +1 >> > >> > >> >> I wonder if it makes sense to provide links to email threads and/or Wi
Re: Updating PPMC rosters via whimsy
Sorry about that. Fixed. Thanks for reviewing the output! - Sam Ruby On Sun, Jun 11, 2017 at 12:31 PM, Adina Crainiceanu <ad...@usna.edu> wrote: > John, > > I'm a committer and PPMC member for Rya > > Adina > > On Sun, Jun 11, 2017 at 12:23 PM, John D. Ament <johndam...@apache.org> > wrote: > >> Adina, >> >> What podling are you on? >> >> John >> >> On Sun, Jun 11, 2017 at 10:50 AM Adina Crainiceanu <ad...@usna.edu> wrote: >> >> > I just wanted to mention that in the "Incubator committers that are not >> on >> > the IPMC and are not listed as a committer of any podling" I noticed >> > multiple names (myself included - Adina Crainiceanu), who are committers >> on >> > active podlings and are still included in the list. For example, I am a >> > committer and PPMC member for Apache Rya (incubating). Not sure how the >> > list was generated, but not only committers of already graduated podlings >> > are on the list, but also committers of active podlings. Maybe because >> > those people are part of the PPMC of a podling and therefore they are >> > implicit committers, but somehow they were not considered committers for >> > the purpose of generating the list. (I believe that the assumption that >> > all PPMC members are commiters is/should be true) >> > >> > On Sun, Jun 11, 2017 at 10:21 AM, Sam Ruby <ru...@intertwingly.net> >> wrote: >> > >> > > On Sun, Jun 11, 2017 at 7:58 AM, John D. Ament <johndam...@apache.org> >> > > wrote: >> > > > On Sun, Jun 11, 2017 at 5:58 AM sebb <seb...@gmail.com> wrote: >> > > > >> > > >> On 11 June 2017 at 00:18, Sam Ruby <ru...@intertwingly.net> wrote: >> > > >> > On Fri, May 26, 2017 at 6:10 PM, Sam Ruby <ru...@intertwingly.net >> > >> > > >> wrote: >> > > >> >> >> > > >> >> For that reason, I'd like to make a simplifying assumption: that >> > all >> > > >> mentors >> > > >> >> are PPMC members, and all PPMC members are committers. >> > > >> > >> > > >> > Existing records that violate one or more assumptions: >> > > >> > https://whimsy.apache.org/incubator/podling-crosscheck >> > > >> >> > > >> "Podling Committers that are not Incubator committers" >> > > >> AFAIK, that should not happen. >> > > >> Probably mostly existing ASF committers being added to podlings >> > > directly. >> > > >> New committers should be added to Incubator + podling by the >> existing >> > > >> processes. >> > > >> I think it would make sense to just add them to the Incubator >> > > >> committer list so they have the appropriate karma. >> > > >> >> > > >> >> > > > Agreed. I appreciate the concise report. We should plan to add >> these >> > > > individuals. >> > > >> > > You should be able to add them from the ppmc page. >> > > >> > > >> "Incubator committers that are not on the IPMC and are not listed >> as a >> > > >> committer of any podling" >> > > >> Most likely they were on podlings that are no longer active. >> > > >> I don't think any cleanup of the list is done when podlings exit >> > > >> incubation, so this list will continue growing. >> > > >> Does that matter? >> > > >> >> > > > I was thinking about this. I think I mis-stated the behavior of >> adding >> > > > someone to the PPMC. There is no requirement to remove them from >> > > > incubator. That's actually how I got started, my podling already >> > > graduated >> > > > but I still had my incubator commit bit. >> > > >> > > Some of that list is because not all of the podling rosters have been >> > > updated. >> > > >> > > But if the plan is to have a monotonically increasing list of people >> > > who ever were associated with a podling at any point in the past, it >> > > may make sense to change things so that all committers have access to >> > > incubator resources and do away with this list. >> > > >> > > > The list that does worry me is the list of mentors not on the
Re: Updating PPMC rosters via whimsy
On Sun, Jun 11, 2017 at 7:58 AM, John D. Ament <johndam...@apache.org> wrote: > On Sun, Jun 11, 2017 at 5:58 AM sebb <seb...@gmail.com> wrote: > >> On 11 June 2017 at 00:18, Sam Ruby <ru...@intertwingly.net> wrote: >> > On Fri, May 26, 2017 at 6:10 PM, Sam Ruby <ru...@intertwingly.net> >> wrote: >> >> >> >> For that reason, I'd like to make a simplifying assumption: that all >> mentors >> >> are PPMC members, and all PPMC members are committers. >> > >> > Existing records that violate one or more assumptions: >> > https://whimsy.apache.org/incubator/podling-crosscheck >> >> "Podling Committers that are not Incubator committers" >> AFAIK, that should not happen. >> Probably mostly existing ASF committers being added to podlings directly. >> New committers should be added to Incubator + podling by the existing >> processes. >> I think it would make sense to just add them to the Incubator >> committer list so they have the appropriate karma. >> >> > Agreed. I appreciate the concise report. We should plan to add these > individuals. You should be able to add them from the ppmc page. >> "Incubator committers that are not on the IPMC and are not listed as a >> committer of any podling" >> Most likely they were on podlings that are no longer active. >> I don't think any cleanup of the list is done when podlings exit >> incubation, so this list will continue growing. >> Does that matter? >> > I was thinking about this. I think I mis-stated the behavior of adding > someone to the PPMC. There is no requirement to remove them from > incubator. That's actually how I got started, my podling already graduated > but I still had my incubator commit bit. Some of that list is because not all of the podling rosters have been updated. But if the plan is to have a monotonically increasing list of people who ever were associated with a podling at any point in the past, it may make sense to change things so that all committers have access to incubator resources and do away with this list. > The list that does worry me is the list of mentors not on the IPMC. I feel > like that requires a bit more research to find out what happened but unless > those people are members they're probably going to be removed from their > mentor roles. What do others think? The individuals should probably be evaluated separately. As Sebb points out, most are ASF members, and therefore are one ask away from being added to the IPMC: http://incubator.apache.org/guides/pmc.html#joining - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Updating PPMC rosters via whimsy
On Fri, May 26, 2017 at 6:10 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > For that reason, I'd like to make a simplifying assumption: that all mentors > are PPMC members, and all PPMC members are committers. Existing records that violate one or more assumptions: https://whimsy.apache.org/incubator/podling-crosscheck - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DRAFT] What the new Status info looks like
On Sat, Jun 10, 2017 at 11:20 AM, John D. Ament <johndam...@apache.org> wrote: > > - List of repositories. For github it's easy, we can just link to a > search. Can't say the same for ASF hosted (yet) Would these help? https://svn.apache.org/repos/asf/incubator/ https://gitbox.apache.org/repos/asf - Sam Ruby P.S. How does one search github? https://github.com/orgs/apache/repos doesn't appear to work, despite what https://developer.github.com/v3/repos/#list-your-repositories seems to imply. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Contents of Podling Status Tracking
On Tue, Jun 6, 2017 at 7:43 AM, Sam Ruby <ru...@intertwingly.net> wrote: > > YAML is more human editable than JSON. As Sebb points out elsewhere, > it also supports comments. Alternative: create DOAP files for podlings. In general, model podlings like PMCs as much and as soon as possible. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Contents of Podling Status Tracking
On Tue, Jun 6, 2017 at 7:49 AM, John D. Ament <johndam...@apache.org> wrote: > On Tue, Jun 6, 2017 at 7:44 AM Sam Ruby <ru...@intertwingly.net> wrote: >> >> Some of the data that you mentioned doesn't need to be in the status >> file as it can be generated from other sources. For example: >> https://whimsy.apache.org/board/agenda/json/podlingnamesearch. I'll >> refactor that code and add that information to the ppmc pages of the >> roster tool. > > I don't see the code that generates this. Where did it come from? Here's the code: https://github.com/apache/whimsy/blob/6752628340f330303089fd7521724381f653ca97/www/board/agenda/routes.rb#L186 The parsing logic will move to https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/podlings.rb, and therefore be usable by multiple tools (in this case, the board agenda and roster tools). >> YAML is more human editable than JSON. As Sebb points out elsewhere, >> it also supports comments. >> >> One thing that whimsy should do is spit out a digested and accumulated >> set of information in JSON which can be read by other tools. A good >> place for a public view would be the phonebook application. >> > > Agreed. All of the changes I have locally are going into > public_podlings.json first. Once that works, we can start to incorporate > into other pages. Recommendation: add any logic to https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/podlings.rb and similar pages, have the existing cron job that extracts that data merely fetch it from the library. The library can then be used by the roster tool. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Contents of Podling Status Tracking
Not sure where to comment, so I'll top post. Some of the data that you mentioned doesn't need to be in the status file as it can be generated from other sources. For example: https://whimsy.apache.org/board/agenda/json/podlingnamesearch. I'll refactor that code and add that information to the ppmc pages of the roster tool. YAML is more human editable than JSON. As Sebb points out elsewhere, it also supports comments. One thing that whimsy should do is spit out a digested and accumulated set of information in JSON which can be read by other tools. A good place for a public view would be the phonebook application. I see as I typed this Bertrand brought up clutch and graduation checklist. I see those as items that can be incorporated into the roster tool, with the added value that this tool is both read/write. See something that needs to be changed? Given the right permissions, you can fix it right there, and interested parties will be notified of the change. I've already added a button to the bottom of the PPMC roster pages to help you draft a graduation resolution. At the moment, it doesn't do anything more than display the resolution which you can copy/paste. This not only will save a few minutes, the resolution will contain the correct names and ids. - Sam Ruby On Tue, Jun 6, 2017 at 7:11 AM, John D. Ament <johndam...@apache.org> wrote: > On Tue, Jun 6, 2017 at 6:40 AM sebb <seb...@gmail.com> wrote: > >> On 6 June 2017 at 04:22, John D. Ament <johndam...@apache.org> wrote: >> > As a follow up to my prior question, ( >> > >> https://lists.apache.org/thread.html/31119aafbc4260720d222666f3efd01f2fe2975e424039ea539c9cb6@%3Cgeneral.incubator.apache.org%3E >> > ). >> > Looking at our current tracking file for podlings, I wonder how much of >> the >> > information is useful. Let's use Traffic Control as a for instance here: >> > http://incubator.apache.org/projects/trafficcontrol.html (its nothing >> > they're doing bad, I just happened to grab them) >> >> However their status file does not contain the full range of data that >> is normally present. >> e.g. no website link, no repo link, no champion/mentors >> > > > Good points. I think we definitely want to have areas for source repos, > the website (override-able?), confluence keys, etc. > > As mentioned, I'm less concerned about roster information at this point on > the status page because of Whimsy. > > >> > - The committer list is fully replaced by the Whimsy Roster Tool >> > - Do we care about News? Shouldn't this be captured in the quarterly >> > reports? >> >> It's easier for outsiders to read here. >> It perhaps encourages the podling to think about progress. >> >> > So maybe a free form area for news items? > > >> > - I see a lot of usefulness in tracking the Podling Name Search request >> > - The first few questions have to do with the actual vote. I think these >> > can best be captured by two fields - "Sponsor" and "Date Accepted into >> > Incubator" >> > - Infra section - I think all of these are important, we may want to >> expand >> > some of the options to include gitbox and other tools that are managed >> > outside our hosted infrastructure. >> > - Mentor section - I'm not sure how useful this is, but I want to get >> > others opinions. Mentors being on the IPMC is a pre-req for votes, so >> this >> > is hopefully less of an issue. >> > - Copyright - I believe this can be replaced by a single field "Date SGA >> > Received". Copyright headers are subjective. >> > - Add a new field "Date of IP Clearance" for projects using IP Clearance >> > instead of SGA (e.g. already Apache v2) >> > - Verify Distribution Rights - I think this can be rewritten to instead >> say >> > "Date of Release with no Source Licensing Issues" (listing out the bullet >> > points mentioned here) and a new field "Date of Release with no Binary >> > Licensing Issues" (indicating some of the Cat-B/Optional Cat-X stuff) >> > - I don't think we need the committers section at the bottom, since the >> > roster would be controlled from Whimsy itself. >> > >> > Is there more information that we could leverage to make this easier to >> > watch? I figure that once a podling has filled out all of these (except >> > for one of SGA/IP Clearance) we can tell them they're close to >> graduation. >> >> I find the status files useful for quickly finding information about a >> project that would otherwise require a trawl o
Re: [NOTICE] Community Vote for Apache Atlas Graduation to TLP
On Mon, Jun 5, 2017 at 3:17 PM, Suma Shivaprasad <sumasai.shivapra...@gmail.com> wrote: > Thanks Sam. Have added the rest of the PPMC/committers. Cool! For future reference, you can click on + multiple times to queue up additions, and then add them all at once. Also, take a look at the "Draft graduation resolution" at the bottom of the page. It can help you draft a resolution that contains correct names and IDs, etc. > Suma - Sam Ruby > On Thu, Jun 1, 2017 at 7:46 PM, Sam Ruby <ru...@intertwingly.net> wrote: > >> On Thu, Jun 1, 2017 at 6:25 PM, Suma Shivaprasad >> <sumasai.shivapra...@gmail.com> wrote: >> >> > >> > Once the issues are rectified, will work with one of the mentors to >> update >> > https://whimsy.apache.org/roster/ppmc/atlas >> >> I've added you; you should now be able to add the rest. The PPMC will >> be notified of your changes. >> >> > Thanks >> > Suma >> >> - Sam Ruby >> >> - >> 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: [NOTICE] Community Vote for Apache Atlas Graduation to TLP
On Thu, Jun 1, 2017 at 6:25 PM, Suma Shivaprasad <sumasai.shivapra...@gmail.com> wrote: > > Once the issues are rectified, will work with one of the mentors to update > https://whimsy.apache.org/roster/ppmc/atlas I've added you; you should now be able to add the rest. The PPMC will be notified of your changes. > Thanks > Suma - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [NOTICE] Community Vote for Apache Atlas Graduation to TLP
On Thu, May 25, 2017 at 8:45 PM, John D. Ament <johndam...@apache.org> wrote: > Hi Suma, > > Thanks for the heads up. There is actually no requirement for the podling > community to vote on graduation, but its a good sign. > > I'm a little concerned, can you double check your status file at [1] ? > Most of the items are marked N/A which is weird, most of these should > actually have dates. > > In addition, can you provide a list of committers you have added since > starting at Apache? The podling status report shows none, but it may be > that your status file is not up to date. > > [1]: http://incubator.apache.org/projects/atlas.html Looking at that page, I note a number of problems with the ids listed there: bad id namecorrect id? === === = aahn Andrew Ahn aa dkaspar David Kaspar? ilasek Ivo Lasek ? chyzer Chris Hyzer tjbchris jamesJames Vollmer ? adossett Aaron Dossett dossett mschussler Mitch Schussler mitchschussler VAvasarala Viswanath Avasarala ? AVarma Anil Varma ? ssuresh Suresh Srinivas suresh vranganathan Venkat Ranganathan venkatrangan It would be helpful if one of the mentors went through and updated the PPMC roster: https://whimsy.apache.org/roster/ppmc/atlas One of the things I would like to work on is adding a button to that page that will draft and post a establish PMC resolution to the board agenda. - Sam Ruby > On Thu, May 25, 2017 at 8:33 PM Suma Shivaprasad <suma...@apache.org> wrote: > >> Dear Incubator members, >> >> Please note that the community vote for graduating Apache Atlas to TLP has >> commenced and has so far received a very positive response from the Atlas >> community. You can find the vote thread at https://s.apache.org/94xI. >> >> Thanks >> Suma >>
Re: Updating PPMC rosters via whimsy
On Fri, May 26, 2017 at 10:18 PM, Sam Ruby <ru...@intertwingly.net> wrote: > On Fri, May 26, 2017 at 9:19 PM, John D. Ament <johndam...@apache.org> wrote: >> On Fri, May 26, 2017 at 6:10 PM Sam Ruby <ru...@intertwingly.net> wrote: > >>> Adding a new committer, PPMC member, or mentors should be a matter a few >>> mouse clicks and selecting the name. LDAP and/or podlings.xml will be >>> updated on your behalf. >>> >> FWIW, I just tried adding you as a mentor to a podling, it failed with a >> 500 ISE. > > I neglected to mention that that isn't implemented yet. Should now be working. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Updating PPMC rosters via whimsy
On Fri, May 26, 2017 at 9:19 PM, John D. Ament <johndam...@apache.org> wrote: > On Fri, May 26, 2017 at 6:10 PM Sam Ruby <ru...@intertwingly.net> wrote: > >> Gitbox has been updated, our ponymail installation has been updated, our >> svn server will be updated soon. Other services will be updated as well. >> > What about regular git-wip-us? Probably, but if not, it will be soon. >> Adding a new committer, PPMC member, or mentors should be a matter a few >> mouse clicks and selecting the name. LDAP and/or podlings.xml will be >> updated on your behalf. >> > FWIW, I just tried adding you as a mentor to a podling, it failed with a > 500 ISE. I neglected to mention that that isn't implemented yet. See lines 1 through 3 of the following: https://github.com/apache/whimsy/blob/master/www/roster/views/actions/ppmc.json.rb >> 3) Who should be able to add/remove PPMC members? My assumption is any >> member of the PPMC. > > Disagree. The PPMC may add a member if there is a check that a NOTICE was > sent and received >= 72 hours ago. If that check is not in place I feel it > is up to mentors only. Ack. >> 5) Who should be able to add/remove PPMC committers? Again, my >> assumption is any member of the PPMC. > > The term "PPMC committers" is hard to follow. "podling committer" may make > more sense, or simply committer. There may be cases that an IPMC member > needs to add a committer. In this case, they can just add themselves as > mentor to do it. Its a little bit of a loophole. Ack on nomenclature. I'm OK with that loophole. >> 6) Who is eligible to be added as a PPMC committer? Again, my >> assumption is any ASF committer. > > Most of the time committers to a podling are new to the ASF. Can the > processes that secretary runs include adding to a podling? Interesting question! Essentially, the secretary makes use of the new account request form, so the question is whether or not the new account request form can include both the podling name as well as the PMC name (which in this case is incubator). I'll look into it. >> Feedback on these assumptions welcome. Any change to mentors and/or >> PPMC members will result in a notification to the private incubator >> mailing list. Any change to PPMC members and committers will result in >> a notification to the infrastructure team. Any change at all will >> result in a notification to the private mailing PPMC mailing list. > > I'm not sure why infra is getting notified but IPMC is not notified, about > committers. Does infra have a requirement to be notified? If the incubator wants to be notified about committer changes, that can be accommodated. The infrastructure team has requested to be notified on all LDAP changes. >> Related: https://issues.apache.org/jira/browse/WHIMSY-90; which might >> not be practical as stated due to difference in access control between >> the various lists. Even if that turns out to be the case, a tool can be >> created to identify differences and enable bulk updating. >> > I'm not sure how that's relevant to this email, maybe you should keep > discussions around the design and development of whimsy on the dev@whimsical > list, or just reply to the JIRA and the reporter will follow up. See question 5 above. If PPMC members who don't happen to be IPMC members are authorized to add committers, they will be unable to update the list of committers for the incubator. I see this as an incubator policy question, not a whimsy implementation detail. > FWIW, until we fix all permissions to be based on podling, we need podling > committers added to incubator. In addition, the incubator website is meant > to be maintained by any incubator committer so that sort of assumes they're > in the incubator group. If the issue is auto removal, I'll point out > that's something you raised and wasn't a requirement going in (and in fact, > people stay on incubator even after their podling has graduated). No, the issue is that the person issuing the request may not be authorized to make the changes. Sorry I wasn't clearer on this point initially. Autoremoval was just a question. If the incubator wishes to have an ever growing list, that's fine with me. Another possibility might be to open the incubator website to all committers, and fix all other permissions to be based on podlings. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Updating PPMC rosters via whimsy
TL;DR: podling membership lists are being consolidated to LDAP, podling mentor lists remain in podlings.xml; the whimsy roster tool is being updated to become a one-stop-shop that can be used to update everything. For the impatient, a link: https://whimsy.apache.org/roster/ppmc/trafodion Feedback welcome on the proposal below. Fair warning: I'll treat any lack of input as lazy consensus. :-) --- Background --- In the past, we've had a number of ad-hoc ways of keeping track of who is on on a PPMC, and made policies based on the difficultly involved in keeping track of memberships. For example, JIRA requests to add svn access control lists to PPMCs (even ones that use only git!) in order to have the lists be reflected on the phonebook app. And to have every committer on the IPMC have update access to all podlings. Now we are moving towards making PPMCs more like PMCs, where the key differences are intentional - for example the addition of mentors and not being listed in commitee-info.txt. Gitbox has been updated, our ponymail installation has been updated, our svn server will be updated soon. Other services will be updated as well. --- Roster tool --- Now to the primary subject of this email: the roster tool. If you go to the link above, you will see a list of mentors and a list of PPMC members. By early next week, a separate list of committers will be shown when that list happens to be different than the list of PPMC members. Adding a new committer, PPMC member, or mentors should be a matter a few mouse clicks and selecting the name. LDAP and/or podlings.xml will be updated on your behalf. If you treat each of those lists (committer, PPMC member, and mentors) as separate, there are 2^3 possible combinations. If you subtract the current state, there are still 7 possible new states for every change. From a coding perspective, that's manageable, but having that many options makes the tool harder to use, and increases the possibility of human error. For that reason, I'd like to make a simplifying assumption: that all mentors are PPMC members, and all PPMC members are committers. Note: in the rare cases where the various lists are inconsistent, additional options will be presented. The link above has examples of mentors who are currently not members of the PPMC. --- Access control --- A final topic is access control. Public views of the underlying data will be made possible through the phonebook application. Any committer will be able to see the roster tool. The key question left is updating. Specifically: 1) Who should be able to add/remove mentors? My initial assumption is any IPMC member. 2) Who is eligible to be added as a mentor? Again, my assumption is any IPMC member. 3) Who should be able to add/remove PPMC members? My assumption is any member of the PPMC. 4) Who is eligible to be added as a PPMC member? My assumption is any ASF committer. 5) Who should be able to add/remove PPMC committers? Again, my assumption is any member of the PPMC. 6) Who is eligible to be added as a PPMC committer? Again, my assumption is any ASF committer. Feedback on these assumptions welcome. Any change to mentors and/or PPMC members will result in a notification to the private incubator mailing list. Any change to PPMC members and committers will result in a notification to the infrastructure team. Any change at all will result in a notification to the private mailing PPMC mailing list. Related: https://issues.apache.org/jira/browse/WHIMSY-90; which might not be practical as stated due to difference in access control between the various lists. Even if that turns out to be the case, a tool can be created to identify differences and enable bulk updating. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: private list subscriptions
On Mon, May 22, 2017 at 3:42 PM, Jim Jagielski <j...@jagunet.com> wrote: > >> On May 22, 2017, at 12:43 PM, sebb <seb...@gmail.com> wrote: >> >> Whimsy auto-subscribe only allows committers to use their ASF address >> or the ones listed in thei LDAP record. > > That seems, to me, a restriction that Whimsy should fix... > None of my subscriptions to any private PMC lists that I'm on > are with my a.o address, and I'm guessing I'm not unique there. Any email address you add via id.apache.org may be accessed via the dropdown at https://whimsy.apache.org/committers/subscribe - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Revisit policy that all IPMC members have commit privs to all incubator repositories.
On Mon, Apr 10, 2017 at 9:24 AM, Bertrand Delacretaz <bdelacre...@codeconsult.ch> wrote: > On Mon, Apr 10, 2017 at 1:55 PM, Sam Ruby <ru...@intertwingly.net> wrote: >> ...The very first line of this thread is a link to an INFRA ticket. A >> comment on that ticket links to this very thread... > > Ok thanks! It would be nice to change the title of that > https://issues.apache.org/jira/browse/INFRA-13804 ticket to make > things clearer, currently it says "Remove curcuru from > /apache/teams/openwhisk-committers" - and I don't seem to have karma > to make that change. Done. Note that ticket is specific to gitbox. There may be other tickets in the future. > -Bertrand - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Revisit policy that all IPMC members have commit privs to all incubator repositories.
On Mon, Apr 10, 2017 at 3:38 AM, Bertrand Delacretaz <bdelacre...@codeconsult.ch> wrote: > On Sat, Apr 8, 2017 at 8:23 PM, Sam Ruby <ru...@intertwingly.net> wrote: >> ...Can I just work with the infrastructure team to >> make this happen? Do we need a formal vote?.. > > As Marvin explains very well I don't think we need a formal vote but > I'd like whatever actions are taken, as well as their motivations, to > be briefly documented in an > https://issues.apache.org/jira/browse/INCUBATOR ticket. Or INFRA > ticket linked here. > > Links are fine, no need for long prose but just as a way to be able to > understand what happened and why, in case 2-3 years down the line this > has to be revisited. Like what's happening now ;-) The very first line of this thread is a link to an INFRA ticket. A comment on that ticket links to this very thread. > -Bertrand - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Revisit policy that all IPMC members have commit privs to all incubator repositories.
On Sun, Apr 9, 2017 at 6:29 PM, John D. Ament <johndam...@apache.org> wrote: > [...] > 3. The interface itself needs to be able to track committers and PPMC > members differently. I've created > https://issues.apache.org/jira/browse/WHIMSY-84 to track this need (since > all committers == all members, but not all members are on the PPMC) >From an implementation perspective, I've got that code for PMCs so it will be easy to add. It just means that when people are added there will be one additional question asked that will be unnecessary in the general case. >[...] > If you look at the committer vs PPMC thing, one other item may be to not > email private@incubator for new podling committers - its not relevant to us. cc private@incubator only for PPMC changes but not committer changes... got it. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Revisit policy that all IPMC members have commit privs to all incubator repositories.
On Sun, Apr 9, 2017 at 11:09 AM, John D. Ament <johndam...@apache.org> wrote: > On Sat, Apr 8, 2017 at 2:23 PM Sam Ruby <ru...@intertwingly.net> wrote: > >> What's the next step? Can I just work with the infrastructure team to >> make this happen? Do we need a formal vote? >> > Can you clarify what exactly you're going to ask infra to change? I see > that infra has made a gitbox specific change, I would expect to see a > incubator-wide change. I'm not certain I've got a crisp answer. I'm also not looking to make any quick changes. See this thread, for example, of prior work along these lines: https://s.apache.org/75Pb For the short term, what I am asking is that since committers are notified of changes (good!) that the default not be that all IPMC members are committers for all podling repositories. --- Longer term, I'm looking to establish a canonical locate for all of our records, be it LDAP, text files, whatever. If there are multiple locations of record, find ways to ensure that they are in sync, if that is at all possible. An example: https://whimsy.apache.org/roster/members Click twice on status, and you will see a handful of exceptions where LDAP doesn't match members.txt. These exceptions are intentional. Separately, I'm trying to make the whimsy roster tool an interface to find (and over time, change) these records. Note that I said "an interface", others are possible. --- More specific to the incubator, I'm proposing that we maintain in LDAP a list of members in each podling (including mentors) and use that list to drive everything from phonebook to commit access in gitbox to who can view what mailing lists in ponymail to JIRA. Having a common place to administer the roster for a podling just seems like a good idea. I encourage people to explore https://whimsy.apache.org/roster/ppmc/ and to update the membership of podlings that they are participating in. Things should be set up so that if you are in the list for that podling, you can change that list. Every change made through this interface will cause an email to be sent to the private list for the podling, the private list for the incubator, and root@ so that the infrastructure team is aware of the change. - Sam Ruby >> - Sam Ruby >> >> On Thu, Apr 6, 2017 at 1:06 AM, Sam Ruby <ru...@intertwingly.net> wrote: >> > Background, from https://issues.apache.org/jira/browse/INFRA-13804 >> > >> >> With this feedback and review, I believe we're still operating as >> >> expected. >> >> >> >> * Per current policy, IPMC members have commit privileges on all >> Incubator >> >> repositories. >> >> * The above is effected through the use of a private GitHub Team >> >> * According to users' GitHub preferences, they will Watch new >> repositories >> >> * GitHub is sending notifications of changes, per Watch selections >> >> >> >> The "answer" here is to Unwatch repositories, as appropriate, and/or >> >> to alter the GitHub user account preference for auto-Watching new >> >> repositories. >> > >> > >> > Here's my case: >> > >> > I believe that asking all IPMC members that request access to *any* ASF >> > github repository to get notification emails on *all* incubator projects >> > that participate in the gitbox experiment is unreasonable. >> > >> > I believe that asking all IPMC members to individually unwatch each and >> > every repository as they are created is unreasonable. >> > >> > I believe that asking all IPMC members to uncheck "Automatically watch" >> is >> > unreasonable as it (a) will result in people being notified for new >> > repositories that they should be watching, and (b) presumes that people >> are >> > not participating/watching in other non-ASF GitHub repositories. >> > >> > Accordingly, Since I do believe that it is reasonable for every ASF >> member >> > to get email on all ASF repositories that they have commit privileges >> to, I >> > am asking that the IPMC revisit the current policy that all IPMC members >> > have commit privileges on all Incubator repositories. >> > >> > I believe that the alternative is technically feasible: have each podling >> > manage a list of committers for that podling: >> > >> > https://whimsy.apache.org/roster/ppmc/ >> > >> > - Sam Ruby >> > >> > >> > >> > - >> > 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 >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Revisit policy that all IPMC members have commit privs to all incubator repositories.
What's the next step? Can I just work with the infrastructure team to make this happen? Do we need a formal vote? - Sam Ruby On Thu, Apr 6, 2017 at 1:06 AM, Sam Ruby <ru...@intertwingly.net> wrote: > Background, from https://issues.apache.org/jira/browse/INFRA-13804 > >> With this feedback and review, I believe we're still operating as >> expected. >> >> * Per current policy, IPMC members have commit privileges on all Incubator >> repositories. >> * The above is effected through the use of a private GitHub Team >> * According to users' GitHub preferences, they will Watch new repositories >> * GitHub is sending notifications of changes, per Watch selections >> >> The "answer" here is to Unwatch repositories, as appropriate, and/or >> to alter the GitHub user account preference for auto-Watching new >> repositories. > > > Here's my case: > > I believe that asking all IPMC members that request access to *any* ASF > github repository to get notification emails on *all* incubator projects > that participate in the gitbox experiment is unreasonable. > > I believe that asking all IPMC members to individually unwatch each and > every repository as they are created is unreasonable. > > I believe that asking all IPMC members to uncheck "Automatically watch" is > unreasonable as it (a) will result in people being notified for new > repositories that they should be watching, and (b) presumes that people are > not participating/watching in other non-ASF GitHub repositories. > > Accordingly, Since I do believe that it is reasonable for every ASF member > to get email on all ASF repositories that they have commit privileges to, I > am asking that the IPMC revisit the current policy that all IPMC members > have commit privileges on all Incubator repositories. > > I believe that the alternative is technically feasible: have each podling > manage a list of committers for that podling: > > https://whimsy.apache.org/roster/ppmc/ > > - Sam Ruby > > > > - > 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: Revisit policy that all IPMC members have commit privs to all incubator repositories.
John, your email confuses me for many reasons. On Thu, Apr 6, 2017 at 6:57 AM, John D. Ament <johndam...@apache.org> wrote: > This solution describes one of the many reasons I feel the incubator itself > is broken. We're trying to rewrite policy, as a means to work around some > awkward setup sitting around, instead of just treating podlings as regular > projects, with some restrictions in place. What I am proposing is to indeed tread podlings more like regular projects, with some restrictions in place. In fact, what I am asking is that we revisit an existing policy that treats podlings as different than regular projects. > Create something in ldap that is org.apache.incubator.$podling. When > secretary processes new accounts, they're being added into this area, > instead of the incubator area. I did exactly that. Go to the link I provided (https://whimsy.apache.org/roster/ppmc/), and click on any podling name. What you will see is a list of people that are in LDAP. I took the data sources I have access to to initially populate this list. In each case, I included the list of mentors. When I could find it, I included the list of committers. > IPMC members have access to execute something that adds committers to > podlings. It could be a special ou for mentors, which VP incubator has > access to. The way things are currently set up, any member of a podling can add or remove members from a podling. We can explore adding the entire IPMC; or limiting adding and removal to only mentors, or any other arrangement. One thing I did not mention is that adding or removing members will send out notifications to private@incubator, to the private list for the podling, and to root@ (to alert the infrastructure team() While anything is possible, my recommendation is to treat podlings more like pmcs; trust that since you have mentors on the list, notifications in place, and both the secretarial team and the infrastructure team to fall back on, IPMC members don't need the direct access to update lists. But that is just a recommendation. For those that want more background on the current implementation and implications, see this thread: https://s.apache.org/75Pb > This has to net less maintenance from infra to make podlings more like TLPs. Agreed. :-) > The one thing Sam misses in this email, there is a way to fix your > notification scheme easily in github - > https://github.com/settings/notifications - uncheck "Automatically Watch > Repositories" I think I covered that in the paragraph that begins with "I believe that asking all IPMC members to uncheck "Automatically watch"... > John - Sam Ruby > On Thu, Apr 6, 2017 at 1:07 AM Sam Ruby <ru...@intertwingly.net> wrote: > >> Background, from https://issues.apache.org/jira/browse/INFRA-13804 >> >> > With this feedback and review, I believe we're still operating as >> expected. >> > >> > * Per current policy, IPMC members have commit privileges on all >> Incubator repositories. >> > * The above is effected through the use of a private GitHub Team >> > * According to users' GitHub preferences, they will Watch new >> repositories >> > * GitHub is sending notifications of changes, per Watch selections >> > >> > The "answer" here is to Unwatch repositories, as appropriate, and/or >> > to alter the GitHub user account preference for auto-Watching new >> > repositories. >> >> Here's my case: >> >> I believe that asking all IPMC members that request access to *any* ASF >> github repository to get notification emails on *all* incubator projects >> that participate in the gitbox experiment is unreasonable. >> >> I believe that asking all IPMC members to individually unwatch each and >> every repository as they are created is unreasonable. >> >> I believe that asking all IPMC members to uncheck "Automatically watch" >> is unreasonable as it (a) will result in people being notified for new >> repositories that they should be watching, and (b) presumes that people >> are not participating/watching in other non-ASF GitHub repositories. >> >> Accordingly, Since I do believe that it is reasonable for every ASF >> member to get email on all ASF repositories that they have commit >> privileges to, I am asking that the IPMC revisit the current policy that >> all IPMC members have commit privileges on all Incubator repositories. >> >> I believe that the alternative is technically feasible: have each >> podling manage a list of committers for that podling: >> >> https://whimsy.apache.org/roster/ppmc/ >> >> - Sam Ruby >> >> >> >> - >> 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
Revisit policy that all IPMC members have commit privs to all incubator repositories.
Background, from https://issues.apache.org/jira/browse/INFRA-13804 With this feedback and review, I believe we're still operating as expected. * Per current policy, IPMC members have commit privileges on all Incubator repositories. * The above is effected through the use of a private GitHub Team * According to users' GitHub preferences, they will Watch new repositories * GitHub is sending notifications of changes, per Watch selections The "answer" here is to Unwatch repositories, as appropriate, and/or to alter the GitHub user account preference for auto-Watching new repositories. Here's my case: I believe that asking all IPMC members that request access to *any* ASF github repository to get notification emails on *all* incubator projects that participate in the gitbox experiment is unreasonable. I believe that asking all IPMC members to individually unwatch each and every repository as they are created is unreasonable. I believe that asking all IPMC members to uncheck "Automatically watch" is unreasonable as it (a) will result in people being notified for new repositories that they should be watching, and (b) presumes that people are not participating/watching in other non-ASF GitHub repositories. Accordingly, Since I do believe that it is reasonable for every ASF member to get email on all ASF repositories that they have commit privileges to, I am asking that the IPMC revisit the current policy that all IPMC members have commit privileges on all Incubator repositories. I believe that the alternative is technically feasible: have each podling manage a list of committers for that podling: https://whimsy.apache.org/roster/ppmc/ - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LDAP changes to support podlings
On Wed, Jan 18, 2017 at 8:51 PM, John D. Ament <johndam...@apache.org> wrote: > On Wed, Jan 18, 2017 at 8:25 PM Sam Ruby <ru...@intertwingly.net> wrote: > >> On Wed, Jan 18, 2017 at 1:37 PM, Felix Meschberger <fmesc...@adobe.com> >> wrote: >> > >> > Hi Sam >> > >> > Like this very much. Thanks ! >> > >> > Started doing that for OpenWhisk and realized some strange UI behaviour: >> > To add a PPMC member I have to click + then search for the user, click >> on + >> > again and then click on „Add to PPMC“ button >> > >> > What is the reason for the last „Add to PPMC“ button click ? This somehow >> > breaks the otherwise nice experience. Or would it be possible to >> batch-add >> > multiple members ? >> >> Not an excuse, but some insight: this code is largely shared with the >> code to manage PMCs, and was designed in anticipation of supporting >> somebody who infrequently uses this interface. If you are adding a >> single person to a PMC, it is helpful to have confirmations every step >> of the way. And for PMCs, there is an option to add a person only as >> a committer or as a committer and to the PMC, so that's the reason for >> the extra step. >> >> The plans are to open up the PMC interface to all members of the PMC, >> and not just PMC chairs. >> >> No question that the PPMC interface can be streamlined, but let's let >> the current code 'bake' for a brief period before trying to improve >> it. >> >> > Maybe you can provide us a file to update to fill in the gaps. Once that > file is imported we turn on the UI. I've committed a change that allows multiple people to be added to a PPMC with a single confirmation. Later, when I revisit PMC updates, I'll likely backport this change there too. >> > Thanks >> > Felix >> >> - Sam Ruby - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LDAP changes to support podlings
On Wed, Jan 18, 2017 at 1:37 PM, Felix Meschberger <fmesc...@adobe.com> wrote: > > Hi Sam > > Like this very much. Thanks ! > > Started doing that for OpenWhisk and realized some strange UI behaviour: > To add a PPMC member I have to click + then search for the user, click on + > again and then click on „Add to PPMC“ button > > What is the reason for the last „Add to PPMC“ button click ? This somehow > breaks the otherwise nice experience. Or would it be possible to batch-add > multiple members ? Not an excuse, but some insight: this code is largely shared with the code to manage PMCs, and was designed in anticipation of supporting somebody who infrequently uses this interface. If you are adding a single person to a PMC, it is helpful to have confirmations every step of the way. And for PMCs, there is an option to add a person only as a committer or as a committer and to the PMC, so that's the reason for the extra step. The plans are to open up the PMC interface to all members of the PMC, and not just PMC chairs. No question that the PPMC interface can be streamlined, but let's let the current code 'bake' for a brief period before trying to improve it. > Thanks > Felix - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LDAP changes to support podlings
On Mon, Jan 16, 2017 at 1:05 PM, Sam Ruby <ru...@intertwingly.net> wrote: > Current status: for ppmcs that have lists in the subversion puppet > definitions, those lists have been loaded into LDAP, and augmented with > mentor information from podlings.xml. A list of all current podlings can be > found here, and those that have been loaded contain links to individual > pages: > > https://whimsy.apache.org/roster/ppmc/ > > These pages are currently read-only, and contain links to the project page, > mailing lists, and prior published reports. These pages are now live. If you are a mentor of a podling, please go in and add ppmc members. Or add one ppmc member and ask them to add the rest. :-) Or simply verify that the list is accurate if it was seeded from the authentication lists in the puppet configuration. Note: for the moment, private@incubator will be copied on all changes. Once things have been verified as working, this will be removed. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LDAP changes to support podlings
On Tue, Jan 17, 2017 at 1:57 PM, John D. Ament <johndam...@apache.org> wrote: > On Tue, Jan 17, 2017 at 1:11 PM Sam Ruby <ru...@intertwingly.net> wrote: > >> On Mon, Jan 16, 2017 at 1:31 PM, Stian Soiland-Reyes <st...@apache.org> >> wrote: >> > Not sure what was the decision to be made here, but +1 to all >> suggestions. >> > All of PPMC as podling owners makes sense to me as long as >> private@podling >> > is notified. >> >> The following four podlings don't have private@podling lists: >> ["log4cxx2", "odftoolkit", "ratis"]. >> > private@logging and odf-private. > >> ratis being a clear example of 'not yet'. >> >> So a revised approach: emails go to private@podling list, if there is >> one. If not, it goes to the designated private list (e.g. >> private@logging). If there are no such private list designated, it >> goes to private@incubator. >> > > It sounds like we need to have an attribute for the private list. Currently I have this implemented via code: https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/podlings.rb#L155 https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/podlings.rb#L173 Note that this code supports both dev and private lists. Also note that while the code could be reduced if there were an attribute that could be queried for this purpose, I don't think it can ever be entirely eliminated as there will always be windows where (for example) the ratis list hasn't been created yet. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LDAP changes to support podlings
On Mon, Jan 16, 2017 at 1:31 PM, Stian Soiland-Reyes <st...@apache.org> wrote: > Not sure what was the decision to be made here, but +1 to all suggestions. > All of PPMC as podling owners makes sense to me as long as private@podling > is notified. The following four podlings don't have private@podling lists: ["log4cxx2", "odftoolkit", "ratis"]. ratis being a clear example of 'not yet'. So a revised approach: emails go to private@podling list, if there is one. If not, it goes to the designated private list (e.g. private@logging). If there are no such private list designated, it goes to private@incubator. If people would like, I could always copy private@incubator on all changes for additional oversight. That might be a bit much, however. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
LDAP changes to support podlings
TL;DR: We need to decide, for each PPMC, who gets to update the PPMC list and where notifications to be sent on changes. --- Background: we have a variety of tools that need access to PPMC member lists, including but not limited to: gitbox, phonebook, ponymail, roller, sonar, subversion, and whimsy. The plan is to consolidate all of this to LDAP. Previously, a number of 'auth groups' were migrated from the subversion puppet definition to LDAP. The plan is to do podlings next, and ultimately change the way PMCs are stored in LDAP. Currently the 'best' (as in machine readable) list of ppmc member information is in the subversion puppet definition - even for podlings that don't make use of subversion as this currently is the most expeditious way to get ppmc member lists to show up in the the phonebook application. The cleanest list of mentors can be found in podlings.xml. More complete, but less machine readable, and not always consistently maintained information can be found on the individual https://incubator.apache.org/projects/ pages. --- gitbox, phonebook, ponymail, roller, sonar, subversion Current status: for ppmcs that have lists in the subversion puppet definitions, those lists have been loaded into LDAP, and augmented with mentor information from podlings.xml. A list of all current podlings can be found here, and those that have been loaded contain links to individual pages: https://whimsy.apache.org/roster/ppmc/ These pages are currently read-only, and contain links to the project page, mailing lists, and prior published reports. --- Near future: what we need to resolve is who should be the 'owners' and who should be the 'members' for each PPMC. These are LDAP terms, and they can be disjoint, overlapping, or even identical. The key point is that owners can change membership of the lists, and members are what gitbox, ponymail, roller, sonar, and subversion will use for access control. No matter what is decided, owners will be limited to adding and removing people who are already committers; adding new ids entirely will still require using the new account request web page. Furthermore, all change will trigger notification to, at a minimum, root@. Additionally notifying the individual affected, the private list for the podling, and or the private list for the incubator are possibilities. Given that these controls will be in place, allowing all members to also be owners should be safe. Limiting owners to only mentors would also be a valid choice. This need not be the same choice for all PPMCs, but it probably would make life (and tooling) easier if it were. Once this decision is made, the whimsy roster tool will be updated to allow owners to update lists, and those owners will be asked to do so. At that point, the subversion access lists in puppet will be converted over to LDAP, and the infra team will stop accepting JIRA requests to maintain these lists. --- Not so distant future: the tools mentioned above will all be updated to use the common LDAP definition for podling membership. As an example, the phonebook application will include all podlings, with data automatically updated within hours of a change. The whimsy roster tool currently contains links to mailing lists and posted board reports. It could be updated to include links to other tools ranging from subscribing and unsubscribing to mailing lists to static sonar analysis. New tools could be built using this data: for example, all of the data needed to draft board resolutions related to graduation could be gathered from LDAP and podlings.xml. --- Further in the future: PMC definitions will be changed to match the way PPMC definitions are done. At the present time, only PMC chairs can update PMC member and committer lists -- even for PMCs to which they don't belong. Other PMC members who aren't PMC chairs can't update their own lists. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE][RESULT] Accept OpenWhisk into the Apache Incubator
This vote passes with 10 binding +1's, 3 non-binding +1, and no -1's Binding: John D. Ament Bertrand Delacretaz Ted Dunning Niclas Hedhman Sergio Fernández Felix Meschberger Jean-Baptiste Onofré Karl Pauls Edward J. Yoon Reynold Xin Non-binding: Liang Chen Debo Dutta Charith Elvitigala Note that John Ament indicated his intention to vote -1 on any OpenWhisk release until the "GitHub as master" issue is resolved by the Apache Infrastructure team. - Sam Ruby On Thu, Nov 17, 2016 at 10:22 AM, Sam Ruby <ru...@intertwingly.net> wrote: > Now that the discussion thread on the OpenWhisk Proposal has died > down, please take a moment to vote on accepting OpenWhisk into the > Apache Incubator. > > The ASF voting rules are described at: >http://www.apache.org/foundation/voting.html > > A vote for accepting a new Apache Incubator podling is a majority vote > for which only Incubator PMC member votes are binding. > > Votes from other people are also welcome as an indication of peoples > enthusiasm (or lack thereof). > > Please do not use this VOTE thread for discussions. > If needed, start a new thread instead. > > This vote will run for at least 72 hours. Please VOTE as follows > [] +1 Accept OpenWhisk into the Apache Incubator > [] +0 Abstain. > [] -1 Do not accept OpenWhisk into the Apache Incubator because ... > > The proposal is listed below, but you can also access it on the wiki: >https://wiki.apache.org/incubator/OpenWhiskProposal > > - Sam Ruby > > = OpenWhisk Proposal = > > OpenWhisk is an open source, distributed Serverless computing platform > able to execute application logic (Actions) in response to events > (Triggers) from external sources (Feeds) or HTTP requests governed by > conditional logic (Rules). It provides a programming environment > supported by a REST API-based Command Line Interface (CLI) along with > tooling to support packaging and catalog services. > > Champion: Sam Ruby, IBM > > Mentors: > * Felix Meschberger, Adobe > * Isabel Drost-Fromm, Elasticsearch GmbH > * Sergio Fernández, Redlink GmbH > > == Background == > > Serverless computing is the evolutionary next stage in Cloud computing > carrying further the abstraction offered to software developers using > Container-based operating system virtualization. The Serverless > paradigm enables programmers to just “write” functional code and not > worry about having to configure any aspect of a server needed for > execution. Such Serverless functions are single purpose and stateless > that respond to event-driven data sources and can be scaled on-demand. > > The OpenWhisk project offers a truly open, highly scalable, performant > distributed Serverless platform leveraging other open technologies > along with a robust programming model, catalog of service and event > provider integrations and developer tooling. > Specifically, every architectural component service of the OpenWhisk > platform (e.g., Controller, Invokers, Messaging, Router, Catalog, API > Gateway, etc.) all is designed to be run and scaled as a Docker > container. In addition, OpenWhisk uniquely leverages aspects of Docker > engine to manage, load balance and scale supported OpenWhisk runtime > environments (e.g., JavaScript, Python, Swift, Java, etc.), that run > Serverless functional code within Invoker compute instances, using > Docker containers. > > OpenWhisk's containerized design tenants not only allows it to be > hosted in various IaaS, PaaS Clouds platforms that support Docker > containers, but also achieves the high expectation of the Serverless > computing experience by masking all aspects of traditional resource > specification and configuration from the end user simplifying and > accelerating Cloud application development. > In order to enable HTTP requests as a source of events, and thus the > creation of Serverless microservices that expose REST APIs, OpenWhisk > includes an API Gateway that performs tasks like security, request > routing, throttling, and logging. > > == Rationale == > > Serverless computing is in the very early stages of the technology > adoption curve and has great promise in enabling new paradigms in > event-driven application development, but current implementation > efforts are fractured as most are tied to specific Cloud platforms and > services. Having an open implementation of a Serverless platform, such > as OpenWhisk, available and governed by an open community like Apache > could accelerate growth of this technology, as well as encourage > dialog and interoperability. > > Having the ASF accept and incubate OpenWhisk would provide a clear > signal to developers interested in Serverless and its future that they >
[VOTE] Accept OpenWhisk into the Apache Incubator
Now that the discussion thread on the OpenWhisk Proposal has died down, please take a moment to vote on accepting OpenWhisk into the Apache Incubator. The ASF voting rules are described at: http://www.apache.org/foundation/voting.html A vote for accepting a new Apache Incubator podling is a majority vote for which only Incubator PMC member votes are binding. Votes from other people are also welcome as an indication of peoples enthusiasm (or lack thereof). Please do not use this VOTE thread for discussions. If needed, start a new thread instead. This vote will run for at least 72 hours. Please VOTE as follows [] +1 Accept OpenWhisk into the Apache Incubator [] +0 Abstain. [] -1 Do not accept OpenWhisk into the Apache Incubator because ... The proposal is listed below, but you can also access it on the wiki: https://wiki.apache.org/incubator/OpenWhiskProposal - Sam Ruby = OpenWhisk Proposal = OpenWhisk is an open source, distributed Serverless computing platform able to execute application logic (Actions) in response to events (Triggers) from external sources (Feeds) or HTTP requests governed by conditional logic (Rules). It provides a programming environment supported by a REST API-based Command Line Interface (CLI) along with tooling to support packaging and catalog services. Champion: Sam Ruby, IBM Mentors: * Felix Meschberger, Adobe * Isabel Drost-Fromm, Elasticsearch GmbH * Sergio Fernández, Redlink GmbH == Background == Serverless computing is the evolutionary next stage in Cloud computing carrying further the abstraction offered to software developers using Container-based operating system virtualization. The Serverless paradigm enables programmers to just “write” functional code and not worry about having to configure any aspect of a server needed for execution. Such Serverless functions are single purpose and stateless that respond to event-driven data sources and can be scaled on-demand. The OpenWhisk project offers a truly open, highly scalable, performant distributed Serverless platform leveraging other open technologies along with a robust programming model, catalog of service and event provider integrations and developer tooling. Specifically, every architectural component service of the OpenWhisk platform (e.g., Controller, Invokers, Messaging, Router, Catalog, API Gateway, etc.) all is designed to be run and scaled as a Docker container. In addition, OpenWhisk uniquely leverages aspects of Docker engine to manage, load balance and scale supported OpenWhisk runtime environments (e.g., JavaScript, Python, Swift, Java, etc.), that run Serverless functional code within Invoker compute instances, using Docker containers. OpenWhisk's containerized design tenants not only allows it to be hosted in various IaaS, PaaS Clouds platforms that support Docker containers, but also achieves the high expectation of the Serverless computing experience by masking all aspects of traditional resource specification and configuration from the end user simplifying and accelerating Cloud application development. In order to enable HTTP requests as a source of events, and thus the creation of Serverless microservices that expose REST APIs, OpenWhisk includes an API Gateway that performs tasks like security, request routing, throttling, and logging. == Rationale == Serverless computing is in the very early stages of the technology adoption curve and has great promise in enabling new paradigms in event-driven application development, but current implementation efforts are fractured as most are tied to specific Cloud platforms and services. Having an open implementation of a Serverless platform, such as OpenWhisk, available and governed by an open community like Apache could accelerate growth of this technology, as well as encourage dialog and interoperability. Having the ASF accept and incubate OpenWhisk would provide a clear signal to developers interested in Serverless and its future that they are welcome to participate and contribute in its development, growth and governance. In addition, there are numerous projects already at the ASF that would provide a natural fit to the API-centric, event-driven programming model that OpenWhisk sees as integral to a Serverless future. In fact, any project that includes a service that can produce or consume actionable events could become an integration point with OpenWhisk-enabled functions. Apache projects that manage programming languages and (micro) service runtimes could become part of the OpenWhisk set of supported runtime environments for functions. Device and API gateways would provide natural event sources that could utilize OpenWhisk functions to process, store and analyze vast amounts of information immediately unlocking the potential of fast-growing computing fields offered in spaces as IoT, analytics, cognitive, mobile and more. == Initial Goals == OpenWhisk is an open source community project which seeks to adopt the Apache way through
Re: [DISCUSS] Policy Question: GA for GitHub for Podlings
On Mon, Nov 7, 2016 at 9:45 PM, John D. Ament <johndam...@apache.org> wrote: > On Mon, Nov 7, 2016 at 9:30 PM Sam Ruby <ru...@intertwingly.net> wrote: > >> On Mon, Nov 7, 2016 at 9:10 PM, John D. Ament <johndam...@apache.org> >> wrote: >> > I'm +0.5 for this right now. There's some challenges I would like to see >> > answered to be able to move forward on this. >> > >> > - Who controls the ACLs? I have some strong opinions of the ACL. >> > Specifically, when the podling joins the incubator, I expect that the >> > "OpenWhisk" organization be handed over to us, and all non-IPMC members >> are >> > removed. Once we receive ICLAs members are granted access back. Or the >> > equivalent - we create a new "ApacheOpenWhisk" organization. >> > >> > - All committers who are in the "incubator" group are granted write >> access >> > to OpenWhisk >> >> I have strong opinions on this subject too, and they don't match >> yours. It happens. :-) >> > > And I honestly wouldn't want them to match. > > In my opinion, for this to happen, we need to finish up the LDAP work, > allowing each podling to be given a separate permission set. I would > generally prefer that approach. Cool. >> As one of the member of the IPMC, I would very much like to see >> podlings set up *EXACTLY* like PMCs, albeit with oversight by mentors. >> That means non-IPMC members are NOT removed, and committers in the >> "incubator" group are NOT added, only mentors. >> > > I'm a bit iffy here. IMHO, we cannot leave existing accounts in place on > the organization, as we won't have ICLAs on file (except for a few who > already exist I bet). What I don't want to see is the PPMC, for non-IPMC > members, be given the ability to grant committer privileges to the repo > without having an ICLA on file. Good point. - Sam Ruby >> That being said, as the person who volunteered to set up LDAP for >> podlings, I will set aside my preference in favor of the consensus of >> the IPMC. Logistically, however, giving every member of the incubator >> group write access to an existing GitHub repository would be a >> nightmare. Granting mentors (a much smaller set) would be a smaller >> set. >> >> > - the ASF still needs to maintain records of the revision history. I >> would >> > like to understand the plan to provide this history. >> >> Here's an example: >> >> https://matt.apache.org/pushlogs.html?repo=whimsy >> >> > I'm not very comfortable with a policy that allows podlings to do things >> > they can't do as TLPs. This is setting up for major delays in >> graduation. >> >> The goal, for quite some time now, has been to resolve GitHub as a >> Master one way or another. It is time to do so. If the conclusion is >> that GitHub as a Master is not to be, OpenWhisk will need to be >> migrated at that time. Until then, there is no reason to migrate it >> only to potentially migrate it back. >> >> > John >> >> - Sam Ruby >> >> > On Mon, Nov 7, 2016 at 5:23 PM Chris Mattmann <mattm...@apache.org> >> wrote: >> > >> >> Hi, >> >> >> >> As some of you may have seen the OpenWhisk podling being discussed now >> has >> >> requested to use GitHub as its primary master. Greg Stein our ASF Infra >> >> Admin >> >> has OK’ed this for OpenWhisk iff the IPMC is OK with it. >> >> >> >> I ask now: >> >> >> >> 1. Is the IPMC OK with this for OpenWhisk? >> >> 2. Is the IPMC OK with this in general availability for Podlings? >> >> >> >> I am +1 on both (IPMC hat on). >> >> >> >> Thanks. >> >> >> >> Cheers, >> >> Chris >> >> >> >> >> >> >> >> >> >> >> >> >> >> - >> >> 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 >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Policy Question: GA for GitHub for Podlings
On Mon, Nov 7, 2016 at 9:10 PM, John D. Ament <johndam...@apache.org> wrote: > I'm +0.5 for this right now. There's some challenges I would like to see > answered to be able to move forward on this. > > - Who controls the ACLs? I have some strong opinions of the ACL. > Specifically, when the podling joins the incubator, I expect that the > "OpenWhisk" organization be handed over to us, and all non-IPMC members are > removed. Once we receive ICLAs members are granted access back. Or the > equivalent - we create a new "ApacheOpenWhisk" organization. > > - All committers who are in the "incubator" group are granted write access > to OpenWhisk I have strong opinions on this subject too, and they don't match yours. It happens. :-) As one of the member of the IPMC, I would very much like to see podlings set up *EXACTLY* like PMCs, albeit with oversight by mentors. That means non-IPMC members are NOT removed, and committers in the "incubator" group are NOT added, only mentors. That being said, as the person who volunteered to set up LDAP for podlings, I will set aside my preference in favor of the consensus of the IPMC. Logistically, however, giving every member of the incubator group write access to an existing GitHub repository would be a nightmare. Granting mentors (a much smaller set) would be a smaller set. > - the ASF still needs to maintain records of the revision history. I would > like to understand the plan to provide this history. Here's an example: https://matt.apache.org/pushlogs.html?repo=whimsy > I'm not very comfortable with a policy that allows podlings to do things > they can't do as TLPs. This is setting up for major delays in graduation. The goal, for quite some time now, has been to resolve GitHub as a Master one way or another. It is time to do so. If the conclusion is that GitHub as a Master is not to be, OpenWhisk will need to be migrated at that time. Until then, there is no reason to migrate it only to potentially migrate it back. > John - Sam Ruby > On Mon, Nov 7, 2016 at 5:23 PM Chris Mattmann <mattm...@apache.org> wrote: > >> Hi, >> >> As some of you may have seen the OpenWhisk podling being discussed now has >> requested to use GitHub as its primary master. Greg Stein our ASF Infra >> Admin >> has OK’ed this for OpenWhisk iff the IPMC is OK with it. >> >> I ask now: >> >> 1. Is the IPMC OK with this for OpenWhisk? >> 2. Is the IPMC OK with this in general availability for Podlings? >> >> I am +1 on both (IPMC hat on). >> >> Thanks. >> >> Cheers, >> Chris >> >> >> >> >> >> >> - >> 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] Policy Question: GA for GitHub for Podlings
On Mon, Nov 7, 2016 at 6:29 PM, Phil Sorber <sor...@apache.org> wrote: > I am +1 on both as well. My understanding is that there was an LDAP hurdle. > Has that been resolved? LDAP is tens of hours worth of work - total. And I volunteered to do the bulk of the initial effort. Frankly, it is more of a timing consideration than either a cost or risk consideration. There will be unanticipated breakage (probably mostly in tools like the phone book, various whimsy tools, and ponymail) but those should be identified and fixable quickly. The right time seems to be shortly after people return from ACEU, so probably early December. - Sam Ruby > On Mon, Nov 7, 2016, 15:24 Chris Mattmann <mattm...@apache.org> wrote: > >> Hi, >> >> As some of you may have seen the OpenWhisk podling being discussed now has >> requested to use GitHub as its primary master. Greg Stein our ASF Infra >> Admin >> has OK’ed this for OpenWhisk iff the IPMC is OK with it. >> >> I ask now: >> >> 1. Is the IPMC OK with this for OpenWhisk? >> 2. Is the IPMC OK with this in general availability for Podlings? >> >> I am +1 on both (IPMC hat on). >> >> Thanks. >> >> Cheers, >> Chris >> >> >> >> >> >> >> - >> 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] Apache OpenWhisk Incubator Proposal
On Mon, Oct 17, 2016 at 11:30 AM, Jim Jagielski <j...@jagunet.com> wrote: > I see that this is a proposal that originates, basically from IBM. IBM + Adobe > I have an issue, based on past history, related to IBM's continued > efforts and dedication on ASF projects. I will not mention specific > projects, but the ASF has a number of projects which died (or > almost died and only were revived via super-human effort) when > IBM decided to switch gears and no longer support the project. > > Now most of all this was our fault: the whole intent of Incubation > and the Apache Way is to prevent dependence on a single person > or entity: diversity means being able to continue, in a healthy > way, should someone (or some-thing) decide that the project is > no longer for them. > > Considering all this, I would hope and expect that this podling > take extra steps to ensure that we don't get "burned" again... +1 I see this as an issue to be resolved prior to exiting incubation, not something that should impact being accepted for incubation. > PS: Nothing against IBM of course: being a business, their strategy > is wont to change, and we cannot (and should not) "fault" them > when such a strategy change adversely affects a project. My > only point is that, based on past experience, we should simply > recognize that IBM dropping their support/resources on this > project at some point is a very real, statistical possibility, > and be serious in our efforts in ensuring this podling/project > can and will survive that. Agreed on both points: this is a general concern that should apply everywhere, and given IBM's past history is particularly relevant to this proposal. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [discuss] Apache OpenWhisk Incubator Proposal
On Fri, Oct 14, 2016 at 1:31 AM, Greg Stein <gst...@gmail.com> wrote: > On Thu, Oct 13, 2016 at 3:27 PM, Sam Ruby <ru...@intertwingly.net> wrote: > >> Hello everyone, >> >> Attached to this message is a proposed new project - Apache OpenWhisk. >> >> The text of the proposal is included below. Additionally, the proposal is >> in draft form on the Wiki, where we will make any required changes: >> >> https://wiki.apache.org/incubator/OpenWhiskProposal >> >> We look forward to your feedback and input. > > OpenWhisk has a first-time-unique request on its Git repository request. I > inserted a comment about OpenWhisk's use of a GitHub repository [from > Infra's standpoint], and the relation to the Foundation and a possible > block on graduation. If I could get some help in the form of an infrastructure team review of the following plan, I would appreciate it: https://lists.apache.org/thread.html/5b93ec0517ce7f90c0a467db9fc5e9cd087f1d4d9305c5491198b6c1@%3Cinfrastructure-private.apache.org%3E > Thx, > -g - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[discuss] Apache OpenWhisk Incubator Proposal
Hello everyone, Attached to this message is a proposed new project - Apache OpenWhisk. The text of the proposal is included below. Additionally, the proposal is in draft form on the Wiki, where we will make any required changes: https://wiki.apache.org/incubator/OpenWhiskProposal We look forward to your feedback and input. - Sam Ruby OpenWhisk Proposal /OpenWhisk is an open source, distributed //Serverless/ <https://developer.ibm.com/openwhisk/what-is-serverless-computing/>/computing platform able to execute application logic (Actions) in response to events (Triggers) from external sources (Feeds) or HTTP requests governed by conditional logic (Rules). It provides a programming environment supported by a REST API-based Command Line Interface (CLI) along with tooling to support packaging and catalog services. / *Champion**: *Sam Ruby, IBM *Mentors**:* Felix Meschberger, Adobe; Isabel Drost-Fromm, Elasticsearch GmbH *Proposal* *Background* Serverless computing is the evolutionary next stage in Cloud computing carrying further the abstraction offered to software developers using Container-based operating system virtualization. The Serverless paradigm enables programmers to just “write” functional code and not worry about having to configure any aspect of a server needed for execution. Such Serverless functions are single purpose and stateless that respond to event-driven data sources and can be scaled on-demand. The OpenWhisk project offers a truly open, highly scalable, performant distributed Serverless platform leveraging other open technologies along with a robust programming model, catalog of service and event provider integrations and developer tooling. Specifically, every architectural component service of the OpenWhisk platform (e.g., Controller, Invokers, Messaging, Router, Catalog, API Gateway, etc.) all is designed to be run and scaled as a Docker container. In addition, OpenWhisk uniquely leverages aspects of Docker engine to manage, load balance and scale supported OpenWhisk runtime environments (e.g., JavaScript, Python, Swift, Java, etc.), that run Serverless functional code within Invoker compute instances, using Docker containers. OpenWhisk's containerized design tenants not only allows it to be hosted in various IaaS, PaaS Clouds platforms that support Docker containers, but also achieves the high expectation of the Serverless computing experience by masking all aspects of traditional resource specification and configuration from the end user simplifying and accelerating Cloud application development. In order to enable HTTP requests as a source of events, and thus the creation of Serverless microservices that expose REST APIs, OpenWhisk includes an API Gateway that performs tasks like request routing, throttling and logging. *Rationale* Serverless computing is in the very early stages of the technology adoption curve and has great promise in enabling new paradigms in event-driven application development, but current implementation efforts are fractured as most are tied to specific Cloud platforms and services. Having an open implementation of a Serverless platform, such as OpenWhisk, available and governed by an open community like Apache could accelerate growth of this technology, as well as encourage dialog and interoperability. Having the ASF accept and incubate OpenWhisk would provide a clear signal to developers interested in Serverless and its future that they are welcome to participate and contribute in its development, growth and governance. In addition, there are numerous projects already at the ASF that would provide a natural fit to the API-centric, event-driven programming model that OpenWhisk sees as integral to a Serverless future. In fact, any project that includes a service that can produce or consume actionable events could become an integration point with OpenWhisk-enabled functions. Apache projects that manage programming languages and (micro) service runtimes could become part of the OpenWhisk set of supported runtime environments for functions. Device and API gateways would provide natural event sources that could utilize OpenWhisk functions to process, store and analyze vast amounts of information immediately unlocking the potential of fast-growing computing fields offered in spaces as IoT, analytics, cognitive, mobile and more. *Initial **Goals* OpenWhisk is an open source community project which seeks to adopt the Apache way through the course of the incubator process and foster collaborative development in the Serverless space. Currently, the OpenWhisk project's source repository is in GitHub using its associated project tooling, but we believe the open Apache processes, democratic project governance, along with its rich developer community and natural integrations with existing projects provide the ideal fit for the technology to grow. Serv
Re: [discuss] Move podling rosters to LDAP
On 2016-09-02 12:41 (-0400), Sam Ruby <ru...@intertwingly.net> wrote: > > Longer term this change would lay the groundwork for more fine-grained > access control whereever it may be desired: not just for svn, but also > for web pages, git, and any other location that can be configured to use > LDAP to obtain ACL information. .. and mailing lists. See: https://issues.apache.org/jira/browse/INFRA-12744 - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
On Thu, Sep 22, 2016 at 12:08 PM, Stian Soiland-Reyes <st...@apache.org> wrote: > Does means podlings will also need to define both a $podling and > $podling-pmc group? It doesn't require that... it doesn't preclude that. My original proposal was not to add that separation, but such could be handled if it were desirable. If you go to https://whimsy.apache.org/roster/group/, you will see a number of LDAP Auth Groups interspersed amongst the various other types of groups (if it helps, click on the column heading to sort by group type). Any member of those groups can modify the groups that they are a member of using that web interface. If you go to this page, you will see a number of PMCs: https://whimsy.apache.org/roster/committee/. PMCs have separate lists for members of the PMC and committers. Currently, only pmc chairs can modify PMC lists (and not just limited to their own). My preference would be that any PMC member could modify the PMCs that they are a member of. I started with non-podling LDAP Auth Groups. I would like to do Podlings next, followed by PMCs. From an implementation perspective, I don't care where in the spectrum between LDAP Auth Groups and PMCs Podlings will fall, but for the moment I don't see a need for separation between owners of podlings and members of podlings. I can see an argument for mentors being owners (and the only ones who can modify membership), but my personal preference would be for members of Podlings being the owners, with mentors providing oversight. > Many podlings don't have a clear distinction - at least not in listings. > Perhaps they should.. >From a technical point of view, that's not an issue. So the question is what does the IPMC want here? - Sam Ruby > On 22 Sep 2016 3:17 a.m., "Sam Ruby" <ru...@intertwingly.net> wrote: > >> cc += gstein >> >> On Wed, Sep 21, 2016 at 9:55 PM, Stian Soiland-Reyes <st...@apache.org> >> wrote: >> > Did this conclude..? Just in case it didn't, here's my +1 as well to >> > make podling membership be in proper LDAP groups; with email >> > notifications to private@podling as you mention. >> >> This did not conclude, but you picked an opportune time to resurrect >> this thread with Greg joining the infrastructure team. In fact, I was >> planning to restart this thread for exactly that reason; thank you for >> doing it. >> >> My assessment previously was that there wasn't enough demand at the >> time to overcome inertia. This change will undoubtedly break things >> temporarily, but nothing that can't be fixed quickly. >> >> > (I am lucky enough to have faced the asf-authorization-template a >> > couple of times :) ) >> >> Join the club. :-) The current process sucks, doesn't it. :-) >> >> > Ensuring people.apache.org is updated would also make it easier for >> > podlings to refer to a canonical list of who are their members; which >> > would work somewhat the same way after graduating. >> >> That's part of the discussion I would like to have. I'm proposing >> that members of the podling can update the group. Currently only PMC >> chairs can modify PMCs. And furthermore, PMC chairs can modify *any* >> PMC, not just the one(s) they chair. >> >> I'd like to change this so that PMC members can modify their own >> group. And I believe that the increased notifications that this tool >> will provide will enable proper oversight. >> >> I also believe this to be fully in line with the President's (Ross's) >> desire to enable self-service. >> >> But a change of this magnitude to the way that we operate is something >> that requires a critical mass of support. Thanks for lending your >> voice to this discussion. >> >> > Letting podling members modify the group themselves is good (as you >> > said the worst they can do is add another committer), as long as we'll >> > keep the account creation process under the hands of ASF Members (as >> > it is now). >> >> ASF members and officers. >> >> By the way, if you ever want to submit an account request, you might >> want to try https://whimsy.apache.org/officers/acreq/; it loads much >> faster than https://id.apache.org/acreq/; if you like it, spread the >> word. >> >> - Sam Ruby >> >> > On 2 September 2016 at 18:52, Sam Ruby <ru...@intertwingly.net> wrote: >> >> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament <johndam...@apache.org> >> wrote: >> >>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby <ru...@intertwingly.net> >> wrote: >> >>> >> >>>> The first stage would b
Re: [discuss] Move podling rosters to LDAP
cc += gstein On Wed, Sep 21, 2016 at 9:55 PM, Stian Soiland-Reyes <st...@apache.org> wrote: > Did this conclude..? Just in case it didn't, here's my +1 as well to > make podling membership be in proper LDAP groups; with email > notifications to private@podling as you mention. This did not conclude, but you picked an opportune time to resurrect this thread with Greg joining the infrastructure team. In fact, I was planning to restart this thread for exactly that reason; thank you for doing it. My assessment previously was that there wasn't enough demand at the time to overcome inertia. This change will undoubtedly break things temporarily, but nothing that can't be fixed quickly. > (I am lucky enough to have faced the asf-authorization-template a > couple of times :) ) Join the club. :-) The current process sucks, doesn't it. :-) > Ensuring people.apache.org is updated would also make it easier for > podlings to refer to a canonical list of who are their members; which > would work somewhat the same way after graduating. That's part of the discussion I would like to have. I'm proposing that members of the podling can update the group. Currently only PMC chairs can modify PMCs. And furthermore, PMC chairs can modify *any* PMC, not just the one(s) they chair. I'd like to change this so that PMC members can modify their own group. And I believe that the increased notifications that this tool will provide will enable proper oversight. I also believe this to be fully in line with the President's (Ross's) desire to enable self-service. But a change of this magnitude to the way that we operate is something that requires a critical mass of support. Thanks for lending your voice to this discussion. > Letting podling members modify the group themselves is good (as you > said the worst they can do is add another committer), as long as we'll > keep the account creation process under the hands of ASF Members (as > it is now). ASF members and officers. By the way, if you ever want to submit an account request, you might want to try https://whimsy.apache.org/officers/acreq/; it loads much faster than https://id.apache.org/acreq/; if you like it, spread the word. - Sam Ruby > On 2 September 2016 at 18:52, Sam Ruby <ru...@intertwingly.net> wrote: >> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament <johndam...@apache.org> wrote: >>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby <ru...@intertwingly.net> wrote: >>> >>>> The first stage would be migrating existing lists to LDAP. This will >>>> require some small changes to whimsy and the phone book application. >>>> The whole effort will only take a few hours and be spread over a few >>>> days elapsed time. >>>> >>>> To prepare, we will need to decide who gets to modify these lists, and >>>> who gets notified. I propose that members of podlings be able to modify >>>> the list, and the private list associated with that podling be notified >>>> on changes. Alternate choices would include mentors for the podling, or >>>> the IPMC. Given that notification facilitates oversight, I encourage >>>> this to be pushed down to the podling, but will go with whatever the >>>> consensus turns out to be. >>> >>> My vote would be for mentors to be able to do this. The podlings don't >>> know enough yet to manage this on their own. I would be concerned of >>> missed process steps if the podling themselves could do it. >> >> See Mark's comment, and my response to it. >> >>>> The second stage would be to define an interface for adding (and perhaps >>>> removing) podlings. This could be limited to the IPMC and the web >>>> interface could ensure that it is only possible to create entries that >>>> are present in podlings.xml. >>>> >>> >>> Could this lead to the eventual removal of podlings.xml ? >> >> It could lead to where-ever the IPMC wants to go. :-) >> >> My preference is that the canonical definition be in SVN, git, LDAP or >> some such, and that tools like whimsy remain only a convenient >> mechanism to update these definitions. >> >>> Does any of this have a relationship to projects.apache.org ? >> >> At a minimum, both would derive information from a common source. >> >> My understanding is that the focus of projects.apache.org is to >> provide a public-facing and read-only interface to this data. >> >> The whimsy roster tool would provide an authenticated read-write >> interface to this data. And a non-exclusive one. Other tools could >> be written that update that information. >> >> - Sam
Re: [discuss] Move podling rosters to LDAP
On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament <johndam...@apache.org> wrote: > On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby <ru...@intertwingly.net> wrote: > >> The first stage would be migrating existing lists to LDAP. This will >> require some small changes to whimsy and the phone book application. >> The whole effort will only take a few hours and be spread over a few >> days elapsed time. >> >> To prepare, we will need to decide who gets to modify these lists, and >> who gets notified. I propose that members of podlings be able to modify >> the list, and the private list associated with that podling be notified >> on changes. Alternate choices would include mentors for the podling, or >> the IPMC. Given that notification facilitates oversight, I encourage >> this to be pushed down to the podling, but will go with whatever the >> consensus turns out to be. > > My vote would be for mentors to be able to do this. The podlings don't > know enough yet to manage this on their own. I would be concerned of > missed process steps if the podling themselves could do it. See Mark's comment, and my response to it. >> The second stage would be to define an interface for adding (and perhaps >> removing) podlings. This could be limited to the IPMC and the web >> interface could ensure that it is only possible to create entries that >> are present in podlings.xml. >> > > Could this lead to the eventual removal of podlings.xml ? It could lead to where-ever the IPMC wants to go. :-) My preference is that the canonical definition be in SVN, git, LDAP or some such, and that tools like whimsy remain only a convenient mechanism to update these definitions. > Does any of this have a relationship to projects.apache.org ? At a minimum, both would derive information from a common source. My understanding is that the focus of projects.apache.org is to provide a public-facing and read-only interface to this data. The whimsy roster tool would provide an authenticated read-write interface to this data. And a non-exclusive one. Other tools could be written that update that information. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [discuss] Move podling rosters to LDAP
On Fri, Sep 2, 2016 at 1:06 PM, Mark Thomas <ma...@apache.org> wrote: > On 02/09/2016 17:41, Sam Ruby wrote: >> To prepare, we will need to decide who gets to modify these lists, and >> who gets notified. I propose that members of podlings be able to modify >> the list, and the private list associated with that podling be notified >> on changes. Alternate choices would include mentors for the podling, or >> the IPMC. Given that notification facilitates oversight, I encourage >> this to be pushed down to the podling, but will go with whatever the >> consensus turns out to be. > > (from the peanut gallery) > > +1 to pushing it down to the podling. If I am reading this proposal > correctly, the worst they can do is grant an ASF committer write access > to their svn area. I should probably have called that out. You are correct, it is only possible to add existing committers to an LDAP group. I would hope that that would go a long way to addressing John's concern. Additionally, the web interface could provide helpful text describing the process, and provide links to where more information can be found. Also, mistakes can readily be reverted. In all, with the website providing helpful guidance, and with notification and the oversight this enables, this should provide the opportunity for "teachable moments" and move the PPMC towards self-government. >> Longer term this change would lay the groundwork for more fine-grained >> access control whereever it may be desired: not just for svn, but also >> for web pages, git, and any other location that can be configured to use >> LDAP to obtain ACL information. > > The key being "where it may be desired". > > I'd prefer to see us moving towards coarser technical access control and > using social controls for the fine-grained aspects across the ASF. I'm not sure where I fall on that spectrum. For example, while I would support enabling those listed as being a member of a podling to adjust the roster for that podling, and while I do believe that notification to PPMCs would provide an effective social control, I would be mildly opposed to allowing members of any podling to modify the roster to podlings that they are not a member of. > Mark > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[discuss] Move podling rosters to LDAP
For background, if you go to the Apache phonebook (https://people.apache.org/phonebook.html) and click on the "Podling name" input field and click on enter you will see an incomplete list of podlings. If you click on a podling, you will see a list of members for that podling. The ultimate source for this is the following file, which is nominally used to define access control to portions of svn repositories: https://github.com/apache/infrastructure-puppet/blob/deployment/modules/subversion_server/files/authorization/asf-authorization-template In some cases (like commonsrdf) the list is in that file only in order to populate the phonebook. The workflow for updating these lists is documented here: https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo Or, and perhaps more commonly, by entering a JIRA and having the infrastructure team make the change for you. --- More generally, over the years the ASF has accrued a number of ad-hoc lists of members. In addition to PMCs and committees, we have the following: https://whimsy.apache.org/roster/group/ I previously moved a number of non-podling svn authorizations to LDAP, and they show up on this list as "LDAP Auth Group"s. As currently defined, members of those groups can use the web interface to add or remove members, and the private list for the associated PMC will be notified of any changes if there is an associated PMC, or the list of members (including the person added or removed) will be notified if there is no associated PMC. This seems to be working well, so I'd like to move on to the next stage: moving podling lists to LDAP. --- The first stage would be migrating existing lists to LDAP. This will require some small changes to whimsy and the phone book application. The whole effort will only take a few hours and be spread over a few days elapsed time. To prepare, we will need to decide who gets to modify these lists, and who gets notified. I propose that members of podlings be able to modify the list, and the private list associated with that podling be notified on changes. Alternate choices would include mentors for the podling, or the IPMC. Given that notification facilitates oversight, I encourage this to be pushed down to the podling, but will go with whatever the consensus turns out to be. The second stage would be to define an interface for adding (and perhaps removing) podlings. This could be limited to the IPMC and the web interface could ensure that it is only possible to create entries that are present in podlings.xml. Ultimately, I would like the roster page for a give podling to enable the updating of relevant information about that podling independent of the ultimately location of that data. For example, adding or removing a mentor could be done via this interface, and the result would be an update to podlings.xml. --- Immediate benefits for this would be a reduction in routine requests made on our infrastructure contractors, and the potential for lists being kept more up to date by enabling those most directly affected by the correctness of these lists to make changes. Longer term this change would lay the groundwork for more fine-grained access control whereever it may be desired: not just for svn, but also for web pages, git, and any other location that can be configured to use LDAP to obtain ACL information. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] move the Incubator Report section to SVN or GIT?
On Mon, Aug 8, 2016 at 11:28 AM, John D. Ament <johndam...@apache.org> wrote: > How hard would that be? To be brutally honest: to me (as the original author of the code), fairly easy. For others, perhaps not so much. I would be quite willing to do the bulk of the initial work enabling this. It would be my hope that there would be at least one person who was capable of running this code on their own machine (prereqs: at least one of the following: a machine running Linux, Mac OS/X, Docker or VirtualBox/Vagrant), and interested in making tweaks after the basics are in place. > is there data we could seed? Actually, yes. Every month we have a board report from the Incubator, in text format, in SVN. The way the board agenda tool works is that it parses this data into JSON which is then used by the client. ASF Officers and Members can an example of the results here: https://whimsy.apache.org/board/agenda/2016-08-17.json So the first step would be to parse the data into individual reports. I've already got the basics for that in the board minutes tool. Code: https://github.com/apache/whimsy/blob/master/tools/collate_minutes.rb#L236 ; output: https://whimsy.apache.org/board/minutes/ . This could be presented as individual pages in the board agenda tool. Next step would be for draft minutes to be available someplace (my preference would be svn). It would need to be someplace with a large set of people who have access than just officers and members. That data could be parsed by the same code and be presented as separate pages. None of the above is hard. The hardest part will be tweaking the authentication to allow only a subset of people to see the full agenda, and a wider set of people to see the incubator parts. What would be next is deciding what buttons and actions should be supported. This is truly the fun part. Adding a button for moderator approval is a matter of a few lines, as is the back end code that makes the change to the text file and commits the result. If there are people who are interested, I can point to examples of how to do this; otherwise I can make these changes. All of this can be developed and tested on your own machine, and will automatically be deployed via a push. Instructions on getting started (including running tests) can be found here: https://github.com/apache/whimsy/tree/master/www/board/agenda#readme - Sam Ruby > On Mon, Aug 8, 2016 at 9:04 AM Sam Ruby <ru...@intertwingly.net> wrote: > >> On Mon, Aug 8, 2016 at 4:06 AM, Daniel Gruno <humbed...@apache.org> wrote: >> > On 08/08/2016 10:03 AM, Christopher wrote: >> >> On Mon, Aug 8, 2016 at 3:34 AM Mark Struberg <strub...@yahoo.de.invalid >> > >> >> wrote: >> >> >> >>> Another possible option would be to move it to our CMS. >> >>> >> >>> That would bring us SVN for the people who prefer vi, but also a >> graphical >> >>> UI for editing. >> >>> And it would make people make familiar with our CMS. >> >> >> >> >> >> I prefer the Wiki over CMS. I find CMS to be clumsy and annoying. I'm >> glad >> >> the projects I'm involved in no longer use (or never have used) it. I'd >> be >> >> willing to use SVN (reluctantly, and with git-svn), but if it were tied >> to >> >> CMS, there'd still be the second publication step using CMS which would >> be >> >> annoying. >> >> >> >> There is something to be said about the low barrier to entry of a Wiki, >> >> though. Anybody can do it. It's the least developer-centric way of doing >> >> things out there. I know CMS tries to be that, but it hasn't quite >> >> succeeded. >> > >> > Why not make a whimsy-like application for this? That would ensure that >> > you are only meddling with the specific sub-section of the report you >> > are working on, and would allow multiple people to work on the report at >> > the same time, maybe even have a simple sign-off button for mentors? >> >> Or even adapt the current board agenda application to take a different >> data source? >> >> You could have svn as a data source, and have a web interface. >> >> > Shouldn't take long to make that :) >> > >> > With regards, >> > Daniel. >> > >> > - >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> >> - Sam Ruby >> >> - >> 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] move the Incubator Report section to SVN or GIT?
On Mon, Aug 8, 2016 at 4:06 AM, Daniel Gruno <humbed...@apache.org> wrote: > On 08/08/2016 10:03 AM, Christopher wrote: >> On Mon, Aug 8, 2016 at 3:34 AM Mark Struberg <strub...@yahoo.de.invalid> >> wrote: >> >>> Another possible option would be to move it to our CMS. >>> >>> That would bring us SVN for the people who prefer vi, but also a graphical >>> UI for editing. >>> And it would make people make familiar with our CMS. >> >> >> I prefer the Wiki over CMS. I find CMS to be clumsy and annoying. I'm glad >> the projects I'm involved in no longer use (or never have used) it. I'd be >> willing to use SVN (reluctantly, and with git-svn), but if it were tied to >> CMS, there'd still be the second publication step using CMS which would be >> annoying. >> >> There is something to be said about the low barrier to entry of a Wiki, >> though. Anybody can do it. It's the least developer-centric way of doing >> things out there. I know CMS tries to be that, but it hasn't quite >> succeeded. > > Why not make a whimsy-like application for this? That would ensure that > you are only meddling with the specific sub-section of the report you > are working on, and would allow multiple people to work on the report at > the same time, maybe even have a simple sign-off button for mentors? Or even adapt the current board agenda application to take a different data source? You could have svn as a data source, and have a web interface. > Shouldn't take long to make that :) > > With regards, > Daniel. > > --------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Report Reminder Emails
On Mon, Jun 27, 2016 at 12:19 AM, John D. Ament <johndam...@apache.org> wrote: > On Sun, Jun 26, 2016 at 5:52 PM Sam Ruby <ru...@intertwingly.net> wrote: > >> On Sun, Jun 26, 2016 at 11:21 PM, John D. Ament <john.d.am...@gmail.com> >> wrote: >> > All, >> > >> > Over the past 2 months, mostly in the days leading up to sending the >> report >> > timeline emaisl, I've been putting together a simple script to generate >> the >> > podling report reminders. I used this as an opportunity to learn me some >> > python, and figure out how our mail servers work. I finally finished it, >> > except for maybe some minor tweaks to the date calculation. >> > >> > You can find the script here: >> > >> http://svn.apache.org/viewvc/incubator/public/trunk/report_reminders.py?view=markup=1750261 >> > >> > My next steps are: >> > >> > 1. Add it to the report runbook, indicating when to send the reminders. >> > >> > 2. Try to get it incorporated into whimsy. >> >> /me waves :-) >> > > Hey! Its Sam Ruby! The guy who shares his name with the Ruby programming > language! I'll note that my last name predates the language by a considerable margin. :-) >> Because whimsy-vm is within the ASF's infrastructure, there is no need >> for a user and password to send mail. There also shouldn't be a need >> to prompt for a month? > > Yes, I'm aware of the email issue. It took a while to figure out that this > was why I was getting blacklisted on email. It took me a while too to figure out why whimsy-vm3 (the current vm) couldn't send email either; but that's now sorted out. > about the month... not sure. We could assume that when we're between board > meetings, we are sending for the next month's report. Board meetings are typically, but not always, on the third Wednesday of the month. The current podling reporting schedule backs up based on this rule. Perhaps it might be better to define everything in terms of how many days or weeks before the board meeting actually is instead? >> If you wouldn't mind, what I would like to do is to integrate this >> with Whimsy's library (which means recoding in Ruby, a language very >> much like Python). What that would mean is that things like the email >> list override would be available to all of Whimsy's applications, and >> not be locked into this one. It also will make this script even >> smaller. > > From what I remember, we started on a process to build a podling library. > I lost track of where that was since it wasn't really in anywhere public. > Is it still in SVN somewhere or has it mosey'd over to git? Here's the definition of the class: https://github.com/apache/whimsy/blob/master/lib/whimsy/asf/podlings.rb This truly is a class in the same sense as you would find in Java and other languages; once you obtain a pointer to a Podling object, you can invoke methods against it. > Personally, I'd like to move the override logic in to podlings.xml. I have > no idea why CMDA's name doesn't match its mailing lists, but they may > retire soon, so not sure its worth chasing. The others are all older > podlings. It may be worth spending time converting them to new format. I've roughed in a method to return the name of the dev mailing list for a given podling: https://github.com/apache/whimsy/commit/0f9ea1fc2a13abc3a7e2f205543b47ccde7b6632 Should this data become available in podlings.xml, the method implementation can be changed without affecting the callers of this method. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Report Reminder Emails
On Sun, Jun 26, 2016 at 11:21 PM, John D. Ament <john.d.am...@gmail.com> wrote: > All, > > Over the past 2 months, mostly in the days leading up to sending the report > timeline emaisl, I've been putting together a simple script to generate the > podling report reminders. I used this as an opportunity to learn me some > python, and figure out how our mail servers work. I finally finished it, > except for maybe some minor tweaks to the date calculation. > > You can find the script here: > http://svn.apache.org/viewvc/incubator/public/trunk/report_reminders.py?view=markup=1750261 > > My next steps are: > > 1. Add it to the report runbook, indicating when to send the reminders. > > 2. Try to get it incorporated into whimsy. /me waves :-) Because whimsy-vm is within the ASF's infrastructure, there is no need for a user and password to send mail. There also shouldn't be a need to prompt for a month? If you wouldn't mind, what I would like to do is to integrate this with Whimsy's library (which means recoding in Ruby, a language very much like Python). What that would mean is that things like the email list override would be available to all of Whimsy's applications, and not be locked into this one. It also will make this script even smaller. - Sam Ruby > John - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Pony Mail into the Apache Incubator
On Tue, May 24, 2016 at 1:56 AM, Daniel Gruno <humbed...@apache.org> wrote: > Since it seems the discussion has died down, I am now calling a vote on > accepting Pony Mail into the Incubator. Sorry in advance for potato. > > This vote will run for the usual 72 hours. +1 (binding) - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Pony Mail
On Thu, May 19, 2016 at 10:40 PM, Daniel Gruno <humbed...@apache.org> wrote: > On 05/20/2016 04:26 AM, John D. Ament wrote: >> Daniel, >> >> I'm a bit curious, what does the proposed plan to gain by going through >> incubation, instead of becoming a TLP directly? >> >> Is it the community diversity aspects, to bring in non-infra team members >> on to the code base? > > I would not feel comfortable bringing a project straight to TLP when a > portion of the initial members of the community have had no experience > whatsoever with the Apache Way before. What is listed is the bare bones > group of people who have worked on Pony Mail in one way or the other (I > should probably add Sam Ruby to that list), there are other peripheral > people who are curious but also have no experience with Apache. Too late, I've already added myself. :-) I've already contributed to the code base, have another patch in the queue, and plan to run this code myself on my own personal email server. - Sam Ruby P.S. I have no particular input on the choice of incubator vs direct to TLP for this particular codebase. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: 54 podlings - too many?
On Mon, Mar 28, 2016 at 8:37 AM, Harbs <harbs.li...@gmail.com> wrote: > What about recommending that it be adopted by OpenOffice? > > IIUC, ODF Toolkit predates OpenOffice becoming an Apache Project. It seems > (to an outsider like me) like the OpenOffice community would be a good home > for a related toolkit. It was proposed as a separate project from the beginning by a member of the Open Office community. - Sam Ruby > Harbs > > On Mar 28, 2016, at 2:33 PM, Sam Ruby <ru...@intertwingly.net> wrote: > >> On Mon, Mar 28, 2016 at 6:44 AM, John D. Ament <johndam...@apache.org> wrote: >>> Both great ideas. Thanksfully, Whimsy helps a bit on the age part >>> >>> https://whimsy.apache.org/incubator/podlings/by-age >>> >>> It also gives a clean dashboard to display who the mentors are, etc. Is it >>> possible we can have the mentors of each project give this feedback in an >>> objective manner? >> >> Hmmm, that pie chart looks wonky. >> >> Second on the list is ODF Toolkit, with my name. Relevant links: >> >> http://mail-archives.apache.org/mod_mbox/incubator-odf-commits/ >> https://whimsy.apache.org/board/minutes/ODF_Toolkit.html >> >> Short summary: development continues in a slow, sometimes bursty, but >> steady manner; hasn't had a release in nearly two years; hasn't added >> any committers or PMC members in over three years; has an >> understanding of what they need to do to graduate. >> >> Periodically I peek in expecting to make a recommendation one way or >> another, but not seeing anything worth adding. I honestly don't know >> what to recommend. >> >> - Sam Ruby >> >>> John >>> >>> On Mon, Mar 28, 2016 at 2:00 AM Jean-Baptiste Onofré <j...@nanthrax.net> >>> wrote: >>> >>>> Hi, >>>> >>>> I agree with Justin. >>>> >>>> Maybe, we should do kind of audit: >>>> - are the podlings actually active (commits, messages on the mailing >>>> list, releases, etc) ? >>>> - for how long are they in the incubator ? >>>> - how far are they from graduation ? >>>> >>>> We can spread this work with "buckets" assigned to volunteer Incubator >>>> PMC members. I would be happy to help there. >>>> >>>> Regards >>>> JB >>>> >>>> On 03/28/2016 03:42 AM, Justin Mclean wrote: >>>>> Hi, >>>>> >>>>>> We're currently at 54 podlings in the incubator. >>>>> >>>>> A more use stat would perhaps to see: >>>>> a) How long they have been in incubation? >>>>> b) How many releases have they made? >>>>> >>>>> May be easier to then target one that should graduate or perhaps retire? >>>>> >>>>> Thanks, >>>>> Justin >>>>> >>>>> - >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>> >>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> - >>>> 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: 54 podlings - too many?
On Mon, Mar 28, 2016 at 7:36 AM, John D. Ament <johndam...@apache.org> wrote: > On Mon, Mar 28, 2016 at 7:33 AM Sam Ruby <ru...@intertwingly.net> wrote: > >> On Mon, Mar 28, 2016 at 6:44 AM, John D. Ament <johndam...@apache.org> >> wrote: >> > Both great ideas. Thanksfully, Whimsy helps a bit on the age part >> > >> > https://whimsy.apache.org/incubator/podlings/by-age >> > >> > It also gives a clean dashboard to display who the mentors are, etc. Is >> it >> > possible we can have the mentors of each project give this feedback in an >> > objective manner? >> >> Hmmm, that pie chart looks wonky. > > What does the pie chart even mean? Try hovering your cursor over it :-) - Sam Ruby >> Second on the list is ODF Toolkit, with my name. Relevant links: >> >> http://mail-archives.apache.org/mod_mbox/incubator-odf-commits/ >> https://whimsy.apache.org/board/minutes/ODF_Toolkit.html >> >> Short summary: development continues in a slow, sometimes bursty, but >> steady manner; hasn't had a release in nearly two years; hasn't added >> any committers or PMC members in over three years; has an >> understanding of what they need to do to graduate. >> >> Periodically I peek in expecting to make a recommendation one way or >> another, but not seeing anything worth adding. I honestly don't know >> what to recommend. >> >> - Sam Ruby >> >> > John >> > >> > On Mon, Mar 28, 2016 at 2:00 AM Jean-Baptiste Onofré <j...@nanthrax.net> >> > wrote: >> > >> >> Hi, >> >> >> >> I agree with Justin. >> >> >> >> Maybe, we should do kind of audit: >> >> - are the podlings actually active (commits, messages on the mailing >> >> list, releases, etc) ? >> >> - for how long are they in the incubator ? >> >> - how far are they from graduation ? >> >> >> >> We can spread this work with "buckets" assigned to volunteer Incubator >> >> PMC members. I would be happy to help there. >> >> >> >> Regards >> >> JB >> >> >> >> On 03/28/2016 03:42 AM, Justin Mclean wrote: >> >> > Hi, >> >> > >> >> >> We're currently at 54 podlings in the incubator. >> >> > >> >> > A more use stat would perhaps to see: >> >> > a) How long they have been in incubation? >> >> > b) How many releases have they made? >> >> > >> >> > May be easier to then target one that should graduate or perhaps >> retire? >> >> > >> >> > Thanks, >> >> > Justin >> >> > >> >> > - >> >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> >> > For additional commands, e-mail: general-h...@incubator.apache.org >> >> > >> >> >> >> -- >> >> Jean-Baptiste Onofré >> >> jbono...@apache.org >> >> http://blog.nanthrax.net >> >> Talend - http://www.talend.com >> >> >> >> - >> >> 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 >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: 54 podlings - too many?
On Mon, Mar 28, 2016 at 6:44 AM, John D. Ament <johndam...@apache.org> wrote: > Both great ideas. Thanksfully, Whimsy helps a bit on the age part > > https://whimsy.apache.org/incubator/podlings/by-age > > It also gives a clean dashboard to display who the mentors are, etc. Is it > possible we can have the mentors of each project give this feedback in an > objective manner? Hmmm, that pie chart looks wonky. Second on the list is ODF Toolkit, with my name. Relevant links: http://mail-archives.apache.org/mod_mbox/incubator-odf-commits/ https://whimsy.apache.org/board/minutes/ODF_Toolkit.html Short summary: development continues in a slow, sometimes bursty, but steady manner; hasn't had a release in nearly two years; hasn't added any committers or PMC members in over three years; has an understanding of what they need to do to graduate. Periodically I peek in expecting to make a recommendation one way or another, but not seeing anything worth adding. I honestly don't know what to recommend. - Sam Ruby > John > > On Mon, Mar 28, 2016 at 2:00 AM Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Hi, >> >> I agree with Justin. >> >> Maybe, we should do kind of audit: >> - are the podlings actually active (commits, messages on the mailing >> list, releases, etc) ? >> - for how long are they in the incubator ? >> - how far are they from graduation ? >> >> We can spread this work with "buckets" assigned to volunteer Incubator >> PMC members. I would be happy to help there. >> >> Regards >> JB >> >> On 03/28/2016 03:42 AM, Justin Mclean wrote: >> > Hi, >> > >> >> We're currently at 54 podlings in the incubator. >> > >> > A more use stat would perhaps to see: >> > a) How long they have been in incubation? >> > b) How many releases have they made? >> > >> > May be easier to then target one that should graduate or perhaps retire? >> > >> > Thanks, >> > Justin >> > >> > - >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> > For additional commands, e-mail: general-h...@incubator.apache.org >> > >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> - >> 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: Final report?
On Wed, Mar 9, 2016 at 9:37 PM, Greg Stein <gst...@gmail.com> wrote: > On Wed, Mar 9, 2016 at 8:27 PM, Sam Ruby <ru...@intertwingly.net> wrote: > >> On Tue, Mar 8, 2016 at 1:24 PM, John D. Ament <johndam...@apache.org> >> wrote: >> > * Graduations >> > >> > The board has motions for the following: >> > >> > - Sentry >> >> Not... yet. :-) >> >> Does somebody intend to post this to the agenda? >> > > To be clear: it was emailed to the Board on Feb 28. ... so we technically > "have" it. But it does need to be in the agenda before it is "official". Sorry about that, I did a quick search and missed it, otherwise I would have committed the resolution. > ... I've committed the resolution. :-) Thanks! > Cheers, > -g - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Final report?
On Tue, Mar 8, 2016 at 1:24 PM, John D. Ament <johndam...@apache.org> wrote: > * Graduations > > The board has motions for the following: > > - Sentry Not... yet. :-) Does somebody intend to post this to the agenda? - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LICENSE info for ALv2, not ASF
On Mon, Mar 7, 2016 at 5:38 PM, Craig Russell <craig.russ...@oracle.com> wrote: > >>> Agreed. Sebb's recommendation, AIUI, was to simply mention in LICENSE >>> that there is a non-ASF AL bundle without copying the entire LICENSE. > > That’s what I was objecting to. LICENSE is for licenses. If notice is > required, then use NOTICE. +1 though I would word the latter more strongly. ONLY legally required notices should go into NOTICE. Absolutely nothing else, as doing so would increase the obligations on licensees. Now in this case, if they have a NOTICE file, then by their their/our license, we are obligated to include it in our NOTICE file (see Apache License, Version 2 section 4, item d). Others can weigh in on short vs long form of the licenses (it is a single copy, so I personally don't see the issue), but as a legally required notice, it belongs in the NOTICE file. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release dependant on LGPL
PIng? Can I get a confirmation that you are OK with Toree proceeding under similar circumstances? They are actively working towards a release. If you like, I can open a legal JIRA or move this to legal-discuss. - Sam Ruby On Fri, Feb 19, 2016 at 9:04 AM, Sam Ruby <ru...@intertwingly.net> wrote: > On Fri, Feb 19, 2016 at 8:29 AM, Jim Jagielski <j...@jagunet.com> wrote: >> I would say that for this single request and this single release, a one-time >> exception is warranted. > > Cool, except that I will note that Toree is in the same situation, and > is preparing a release. I would hope that that request would be OK > too? > > - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release dependant on LGPL
On Fri, Feb 19, 2016 at 8:29 AM, Jim Jagielski <j...@jagunet.com> wrote: > I would say that for this single request and this single release, a one-time > exception is warranted. Cool, except that I will note that Toree is in the same situation, and is preparing a release. I would hope that that request would be OK too? - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Release dependant on LGPL
On Mon, Feb 15, 2016 at 4:49 PM, Marvin Humphrey <mar...@rectangular.com> wrote: > On Mon, Feb 15, 2016 at 1:16 PM, Luciano Resende <luckbr1...@gmail.com> wrote: >> Apache Toree had a similar issue, and we have discussed this in >> legal-discuss, and here is the feedback from Jim, VP of Legal >> >> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201602.mbox/%3C2A8B931C-1AD6-4230-B2DE-0B33361B3A2B%40jaguNET.com%3E > > The LGPL's reverse engineering provisions make it more difficult to > understand the licensing obligations of any ostensibly > Apache-2-licensed product with an LGPL-licensed mandatory runtime > dependency. Jim speaks for many of us in that thread. > > However, one of the reasons we have the "incubating" label is to let > people know that "incubating" releases may not be fully compliant with > all Apache policies. > > See https://issues.apache.org/jira/browse/LEGAL-86 for an example of > where incubating releases were allowed with a runtime dependency on a > non-approved license. Just as Greg laid out, a plan was proposed for > removing the dependency before graduation and the VP Legal at the > time, Sam Ruby, gave his OK. > > With LEGAL-86, VP Legal's approval was sought in advance, and in > general podlings should should be aware of resources like the > legal-discuss@apache list and should learn when and how to utilize > them. However, unless Greg advises Mynewt to consult VP Legal (and I'm > all but certain he won't), that won't be necessary in this case. I'm not Greg, but I would suggest at least notifying VP Legal, and by that I mean sending a note to Jim copying legal-discuss, and not merely assuming that he is both lurking here and is likely to make the same determination that I would (and did) under similar circumstances. I'm just being careful and respectful - I am NOT expecting this to turn up any issues. And a single request can cover both the Mynewt and Toree cases, even though they are subtly different (Mynewt plans to replace the library under question, and the library that Toree depends on is actively being re-licensed). Unless anybody objects or would rather be the one to do so, I will send this note, and refer to this discussion for context. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Torii into Apache Incubator
On Tue, Dec 1, 2015 at 10:24 AM, Steve Loughran <ste...@hortonworks.com> wrote: > Think I've missed the vote window, but > > +1 binding > > I will repeat what I raised when the proposal first came up, something that > wasn't addresses at all: ZeroMQ is LGPL, which is forbidden as a mandatory > dependency in ASF projects. > > Step 1 of the project is going to have to confirm that the zeroMQ : LGPL+ > Static Linking Exception is sufficient for it to be allowed as a dependency > on the project. I'd like to encourage zeroMQ to move to MPL (and I'm willing to help make that case). Given that LGPL is essentially GPL+a static linking exception, I don't know how LGPL+Static Linking Exception helps; the ZeroMQ licensing page[1] suggests that it is a problem for corporate lawyers to accept; Jim has repeatedly said in various ways that our goal is to be a no-brainer. > If it's not, then that's going to be a fundamental barrier to releasing Torii > as ASF-signed off artifacts - Sam Ruby [1] http://zeromq.org/area:licensing >>> On Thu, Nov 26, 2015 at 10:33 AM, Luciano Resende <luckbr1...@gmail.com> >>> wrote: >>>> After initial discussion (under the name Spark-Kernel), please vote on >>>> the >>>> acceptance of Torii Project for incubation at the Apache Incubator. The >>>> full proposal is >>>> available at the end of this message and on the wiki at : >>>> >>>> https://wiki.apache.org/incubator/ToriiProposal >>>> >>>> Please cast your votes: >>>> >>>> [ ] +1, bring Torii into Incubator >>>> [ ] +0, I don't care either way >>>> [ ] -1, do not bring Torii into Incubator, because... >>>> >>>> Due to long weekend holiday in US, I will leave the vote open until >>>> December 1st. >>>> >>>> >>>> = Torii = >>>> >>>> == Abstract == >>>> Torii provides applications with a mechanism to interactively and >>>> remotely >>>> access Apache Spark. >>>> >>>> == Proposal == >>>> Torii enables interactive applications to access Apache Spark clusters. >>>> More specifically: >>>> * Applications can send code-snippets and libraries for execution by >>>> Spark >>>> * Applications can be deployed separately from Spark clusters and >>>> communicate with the Torii using the provided Torii client >>>> * Execution results and streaming data can be sent back to calling >>>> applications >>>> * Applications no longer have to be network connected to the workers >>>> on a >>>> Spark cluster because the Torii acts as each application’s proxy >>>> * Work has started on enabling Torii to support languages in addition >>>> to >>>> Scala, namely Python (with PySpark), R (with SparkR), and SQL (with >>>> SparkSQL) >>>> >>>> == Background & Rationale == >>>> Apache Spark provides applications with a fast and general purpose >>>> distributed computing engine that supports static and streaming data, >>>> tabular and graph representations of data, and an extensive library of >>>> machine learning libraries. Consequently, a wide variety of applications >>>> will be written for Spark and there will be interactive applications >>>> that >>>> require relatively frequent function evaluations, and batch-oriented >>>> applications that require one-shot or only occasional evaluation. >>>> >>>> Apache Spark provides two mechanisms for applications to connect with >>>> Spark. The primary mechanism launches applications on Spark clusters >>>> using >>>> spark-submit ( >>>> http://spark.apache.org/docs/latest/submitting-applications.html); this >>>> requires developers to bundle their application code plus any >>>> dependencies >>>> into JAR files, and then submit them to Spark. A second mechanism is an >>>> ODBC/JDBC API ( >>>> >>>> http://spark.apache.org/docs/latest/sql-programming-guide.html#distribute >>>> d-sql-engine) >>>> which enables applications to issue SQL queries against SparkSQL. >>>> >>>> Our experience when developing interactive applications, such as >>>> analytic >>>> applications integrated with Notebooks, to run against Spark was that >>>> the >>>> spark-submit mechanism was overly cumbersome and slow (requiring JAR >>
Re: [DISCUSS] Spark-Kernel Incubator Proposal
On Wed, Dec 2, 2015 at 5:52 PM, Luciano Resende <luckbr1...@gmail.com> wrote: > On Mon, Nov 30, 2015 at 4:13 PM, Julien Le Dem <jul...@dremio.com> wrote: > >> Sorry for the late reply. >> FYI there is an opensource project called torii already: >> https://vestorly.github.io/torii/ >> Whether there is a trademark or not, I'd recommend a name that does not >> collide with another project. >> >> > We missed that, and I guess we are also getting out of names... > > Any name suggestion from the community ? Random thought, take a name from this list and replace a random vowel with a 'y': https://en.wikipedia.org/wiki/Moons_of_Jupiter#List Example: Eyropa. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Torii into Apache Incubator
+1 (binding) - Sam Ruby On Thu, Nov 26, 2015 at 10:33 AM, Luciano Resende <luckbr1...@gmail.com> wrote: > After initial discussion (under the name Spark-Kernel), please vote on the > acceptance of Torii Project for incubation at the Apache Incubator. The > full proposal is > available at the end of this message and on the wiki at : > > https://wiki.apache.org/incubator/ToriiProposal > > Please cast your votes: > > [ ] +1, bring Torii into Incubator > [ ] +0, I don't care either way > [ ] -1, do not bring Torii into Incubator, because... > > Due to long weekend holiday in US, I will leave the vote open until > December 1st. > > > = Torii = > > == Abstract == > Torii provides applications with a mechanism to interactively and remotely > access Apache Spark. > > == Proposal == > Torii enables interactive applications to access Apache Spark clusters. > More specifically: > * Applications can send code-snippets and libraries for execution by Spark > * Applications can be deployed separately from Spark clusters and > communicate with the Torii using the provided Torii client > * Execution results and streaming data can be sent back to calling > applications > * Applications no longer have to be network connected to the workers on a > Spark cluster because the Torii acts as each application’s proxy > * Work has started on enabling Torii to support languages in addition to > Scala, namely Python (with PySpark), R (with SparkR), and SQL (with > SparkSQL) > > == Background & Rationale == > Apache Spark provides applications with a fast and general purpose > distributed computing engine that supports static and streaming data, > tabular and graph representations of data, and an extensive library of > machine learning libraries. Consequently, a wide variety of applications > will be written for Spark and there will be interactive applications that > require relatively frequent function evaluations, and batch-oriented > applications that require one-shot or only occasional evaluation. > > Apache Spark provides two mechanisms for applications to connect with > Spark. The primary mechanism launches applications on Spark clusters using > spark-submit ( > http://spark.apache.org/docs/latest/submitting-applications.html); this > requires developers to bundle their application code plus any dependencies > into JAR files, and then submit them to Spark. A second mechanism is an > ODBC/JDBC API ( > http://spark.apache.org/docs/latest/sql-programming-guide.html#distributed-sql-engine) > which enables applications to issue SQL queries against SparkSQL. > > Our experience when developing interactive applications, such as analytic > applications integrated with Notebooks, to run against Spark was that the > spark-submit mechanism was overly cumbersome and slow (requiring JAR > creation and forking processes to run spark-submit), and the SQL interface > was too limiting and did not offer easy access to components other than > SparkSQL, such as streaming. The most promising mechanism provided by > Apache Spark was the command-line shell ( > http://spark.apache.org/docs/latest/programming-guide.html#using-the-shell) > which enabled us to execute code snippets and dynamically control the tasks > submitted to a Spark cluster. Spark does not provide the command-line > shell as a consumable service but it provided us with the starting point > from which we developed Torii. > > == Current Status == > Torii was first developed by a small team working on an internal-IBM > Spark-related project in July 2014. In recognition of its likely general > utility to Spark users and developers, in November 2014 the Torii project > was moved to GitHub and made available under the Apache License V2. > > == Meritocracy == > The current developers are familiar with the meritocratic open source > development process at Apache. As the project has gathered interest at > GitHub the developers have actively started a process to invite additional > developers into the project, and we have at least one new developer who is > ready to contribute code to the project. > > == Community == > We started building a community around Torii project when we moved it to > GitHub about one year ago. Since then we have grown to about 70 people, and > there are regular requests and suggestions from the community. We believe > that providing Apache Spark application developers with a general-purpose > and interactive API holds a lot of community potential, especially > considering possible tie-in’s with Notebooks and data science community. > > == Core Developers == > The core developers of the project are currently all from IBM, from the IBM > Emerging Technology team and from
Re: RTC vs CTR (was: Concerning Sentry...)
On Wed, Nov 25, 2015 at 5:18 PM, Greg Stein <gst...@gmail.com> wrote: > On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby <ru...@intertwingly.net> wrote: > >> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein <gst...@gmail.com> wrote: >> > >> > Don't shut down trunk/master for product development. >> >> I don't believe you heard my point, but I'm not going to repeat it. > > I read your post several times, completely :-P ... I just think it didn't > argue against RTC being a form on control. (and yeah, maybe you weren't > trying to argue that?) I don't believe that RTC is a form of control over others. I believe that RTC is a mechanism to ensure that every change is adequately reviewed. >> Instead I will add a new point. >> >> 'trunk/master for product development' is not the only development >> model available to a project. As an example, I've seen models where >> 'trunk/master is for product maintenance', and all development occurs >> in a branch explicitly designated as where work on the next release is >> to occur. >> > > I think that is just playing with names. In Apache Subversion the "product > maintenance" is branches/1.8.x and branches/1.9.x (1.7.x and prior are > deprecated). trunk is for "next release". > > In your naming model, where we've seen the name "develop" for "next > release" (aka where all new dev occurs), then I'd say making it RTC is > harmful. > > trunk/master was shorthand for "where dev occurs". If you want to use a > different name... okay. :-) I don't believe it is just playing with names. There are projects in when all non-trivial development occurs in feature branches. > Cheers, > -g > > ps. fwiw, trunk/tags/branches isn't mandated in svn either. It was just an > ad hoc template we came up with back near the start of the project. We > assumed third-party tools would focus around that naming, which is > generally true, but svn itself has never cared. Ack. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Wed, Nov 25, 2015 at 9:13 PM, Konstantin Boudnik <c...@apache.org> wrote: > > And that goes, as always, to the question "Who makes the decision about the > _right_ level of trust". The community. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein <gst...@gmail.com> wrote: > > Don't shut down trunk/master for product development. I don't believe you heard my point, but I'm not going to repeat it. Instead I will add a new point. 'trunk/master for product development' is not the only development model available to a project. As an example, I've seen models where 'trunk/master is for product maintenance', and all development occurs in a branch explicitly designated as where work on the next release is to occur. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Wed, Nov 25, 2015 at 3:39 PM, Greg Stein <gst...@gmail.com> wrote: > > Over the 17 years I've been around Apache, every single time I've seen > somebody attempt to justify something like RTC, it always goes back to > control. Always. Strongly disagree. If you say 'every', all it takes is one counter example to disprove the assertion. Here is a counter example: https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo It is not a hypothetical example from the distant past. It is a live example which seems to work well. I've witnessed it being used for single line patches (a removal of a line, in fact) in a YAML file. Gavin created a branch, made a patch, pushed it, and Daniel merged it. Not for provenance reasons. Or for control reasons. But to ensure a second set of eyes looked at the change and evaluated whether or not there may be some unanticipated side effect. I'll propose a thought experiment. We seem to agree that there is room for teams to impose some form of RTC on branches that are to be released "soonish" (for some value of "soonish"). Let's take the next step... what happens if releases are frequent (i.e. approaching continuous?). That's essentially what the infrastructure team is faced with. I don't give a whit about 'control issues' (perceived or real, doesn't matter). Anything I commit may be reverted. I'm fine with that. I don't presume to control anything. And if somebody wants to try to control me -- all I can say is: good luck with that. :-P What I care most about is languishing patches. Whether they come from team members or drive by contributors, doesn't matter. That's harmful. Git, and in particular, GitHub, makes them less harmful, but they are the root problem not whether the process is Commit-Then-Revert or Post-Then-Ignore. If most communities in the Hadoop ecosystem use RTC, I don't care UNLESS there is evidence of them not being responsive to patches. For quieter communities (including apparently BigTop), RTC could lead to problems, and CTR is arguably more appropriate. I'm fine with that too. - Sam Ruby P.S. My personal preference remains CTR. I would much rather be reverted with an explanation than to be ignored without one. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gst...@gmail.com> wrote: > > Nobody is forcing anything. > > Personally, I am saying RTC is destructive, and am willing to give every > podling that message. If it is truly destructive, SHOULDN'T you/we be trying to force something? And if not, doesn't that mean that it isn't really all that destructive? As a Director, would you consider stop approving reports from ASF projects that operate under a RTC model? If not, aren't you sending a mixed message? - Sam Ruby P.S. To be clear: I am not a fan of RTC when applied to release.next branches. I can't conceive of myself wanting to participate in a community that does so and chooses to use SVN. And if a community that used RTC turned out to not be healthy, that would be one of the first things I would suggest that they explore changing. But if a community is healthy (and there demonstrably are quite a number of healthy communities using RTC), then I personally wouldn't chose to interfere. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Mon, Nov 23, 2015 at 7:10 AM, Greg Stein <gst...@gmail.com> wrote: > On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby <ru...@intertwingly.net> wrote: > >> >> P.S. To be clear: I am not a fan of RTC when applied to release.next >> branches. > > I'd appreciate your explanation of this, as "most" CTR communities apply > RTC to a branch as they prepare a release. What disturbs you about this > approach? Agreed that "most" CTR communities apply RTC to a branch as they prepare a release. Normally when they do so, there is a branch (could be trunk or master, could be something else like "develop" or even the working name for the next release) which is where things intended for the *next* release go. I'm generally OK with "please work over there while we prep a release", which is what I meant by "release.next" branches. Going a bit further, I can live with RTC when commits are reviewed promptly. I avoid projects where reviews are mandatory and are done on a time permitting basis. > Cheers, > -g - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
+1 here too. Most projects here fall somewhere in a spectrum between "do whatever you want in a branch" and "don't release without having others approve your work". Different projects put the point where CTR crosses over to RTC at different points. *shrug* - Sam Ruby P.S. Personally a fan of CTR, but I'm starting to appreciate our infrastructure team's puppet workflow where everything (even one line changes) are done in a branch and everybody asks other person to merge the changes. https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <j...@jagunet.com> wrote: > ++1 >> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bdelacre...@apache.org> >> wrote: >> >> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <j...@jagunet.com> wrote: >>> ...httpd for example) uses RTC, CTR and Lazy Consensus >>> simultaneously and works like a dream >> >> Indeed - those are different tools that each have their own purpose. >> They just need to be applied in the right places and at the right >> time. >> >> -Bertrand >> >> - >> 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler <ross.gard...@microsoft.com> wrote: > Good point. I should add to my comments that even a CTR project uses RTC for > non-committers. And that a release vote means that at least three people have > reviewed the code from (at least) an IP standpoint, if not from a code > quality standpoint. > > In other words, +1 > > However, RTC projects do not use a mix and that's the point of contention > here, some people feel it is suboptimal (I'm one, but others disagree). The > discussion is not whether CTR also uses RTC at points, I believe that is a > given. Let me be pedantic for a moment. While RTC projects that use Subversion may disallow work in branches, even by committers; such a restriction isn't even possible in Git -- even for non committers. > Ross - Sam Ruby > -Original Message- > From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby > Sent: Friday, November 20, 2015 7:43 AM > To: general@incubator.apache.org > Subject: Re: RTC vs CTR (was: Concerning Sentry...) > > +1 here too. > > Most projects here fall somewhere in a spectrum between "do whatever you want > in a branch" and "don't release without having others approve your work". > Different projects put the point where CTR crosses over to RTC at different > points. > > *shrug* > > - Sam Ruby > > P.S. Personally a fan of CTR, but I'm starting to appreciate our > infrastructure team's puppet workflow where everything (even one line > changes) are done in a branch and everybody asks other person to merge the > changes. > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fINFRA%2fGit%2bworkflow%2bfor%2binfrastructure-puppet%2brepo=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d > > On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <j...@jagunet.com> wrote: >> ++1 >>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bdelacre...@apache.org> >>> wrote: >>> >>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <j...@jagunet.com> wrote: >>>> ...httpd for example) uses RTC, CTR and Lazy Consensus >>>> simultaneously and works like a dream >>> >>> Indeed - those are different tools that each have their own purpose. >>> They just need to be applied in the right places and at the right >>> time. >>> >>> -Bertrand >>> >>> - >>> 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 >> > > - > 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: RTC vs CTR (was: Concerning Sentry...)
On Fri, Nov 20, 2015 at 11:47 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > On Sat, Nov 21, 2015 at 12:40 AM, Sam Ruby <ru...@intertwingly.net> wrote: > >> On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler >> <ross.gard...@microsoft.com> wrote: >> > Good point. I should add to my comments that even a CTR project uses RTC >> for non-committers. And that a release vote means that at least three >> people have reviewed the code from (at least) an IP standpoint, if not from >> a code quality standpoint. >> > >> > In other words, +1 >> > >> > However, RTC projects do not use a mix and that's the point of >> contention here, some people feel it is suboptimal (I'm one, but others >> disagree). The discussion is not whether CTR also uses RTC at points, I >> believe that is a given. >> >> Let me be pedantic for a moment. While RTC projects that use >> Subversion may disallow work in branches, even by committers; such a >> restriction isn't even possible in Git -- even for non committers. > > Not only isn't something you can forbid, it isn't even something that I > could understand without reading your sentence three times. > > Git is all about branching. Forbidding branches is a non sequitur. The most you can do in Git is to say that you can't do it in THIS location or give it THAT name. In which case, the inevitable response will be, OK, I'll do it elsewhere and/or give it a different name. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Spark-Kernel Incubator Proposal
On Fri, Nov 13, 2015 at 6:49 PM, Reynold Xin <r...@apache.org> wrote: > > I'd also like to second Matei that spark-kernel as a name is fairly > confusing. It only makes sense when viewing from IPython notebook's point > of view to refer to these things as kernels. Outside of that context, it > sounds like it is the spark-core module, which this obviously isn't. That name is indeed unlikely to survive incubation, particularly if this result of graduation is a separate PMC (as opposed to, say, becoming a subproject of Apache Spark). - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Short form IP clearance
On Sun, Nov 1, 2015 at 7:20 AM, Marvin Humphrey <mar...@rectangular.com> wrote: > On Sun, Nov 1, 2015 at 3:41 AM, John D. Ament <johndam...@apache.org> wrote: >> I don't think anyone in the incubator is begging to be responsible. We >> just need a new process defined. > > Actually, since the Incubator continues to receive criticism for its > role in IP Clearance, I specifically request that the Incubator be > relieved of that role. If having the Incubator hold the power to > "meddle" causes such alarm, the Board should find somebody else to do > this work. I don't think we should be looking to the Board directly for this, we should be looking to Legal Affairs to reaffirm, adjust, or revoke this arrangement. > We have enough to worry about with our primary responsibility of > incubating podlings. We don't need more reasons for powers-that-be to > give us grief. The powers that be (a.k.a., the board) either need to reinstate Jim as VP of Affairs or find a replacement, and then hold that individual (and associated committee) accountable for revisiting this issue. - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Short form IP clearance
On Fri, Oct 23, 2015 at 7:41 AM, John D. Ament <johndam...@apache.org> wrote: > I think probably the better question is "which contributions require IP > Clearance"? "Any code that was developed outside of the ASF SVN repository and our public mailing lists must be processed like this, even if the external developer is already an ASF committer." Source: http://incubator.apache.org/ip-clearance/ At a minimum, the word "SVN" should be removed. Any other changes people feel are necessary? - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Short form IP clearance
On Fri, Oct 23, 2015 at 7:55 AM, John D. Ament <johndam...@apache.org> wrote: > So basically if someone attaches a patch to a JIRA, which becomes part > of our public mailing lists, we're good? If that code was all that poster's original work, not previously published elsewhere (particularly under a different license), then that's fine. If that code was previously developed elsewhere, had multiple contributors, and made available (particularly under a different license), then no. I'll also note that the goal of IP Clearance isn't to disallow such contributions, it is merely to make sure that we capture all of the relevant history (IP provenance) for posterity. > Would github PR's fall under the same premise, since the contents of those > mails become public record? See above. - Sam Ruby > On Fri, Oct 23, 2015 at 7:51 AM Sam Ruby <ru...@intertwingly.net> wrote: > >> On Fri, Oct 23, 2015 at 7:41 AM, John D. Ament <johndam...@apache.org> >> wrote: >> > I think probably the better question is "which contributions require IP >> > Clearance"? >> >> "Any code that was developed outside of the ASF SVN repository and our >> public mailing lists must be processed like this, even if the external >> developer is already an ASF committer." >> >> Source: http://incubator.apache.org/ip-clearance/ >> >> At a minimum, the word "SVN" should be removed. Any other changes >> people feel are necessary? >> >> - Sam Ruby >> >> - >> 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: Not just yet
On Fri, Oct 23, 2015 at 8:09 AM, John D. Ament <johndam...@apache.org> wrote: > On Fri, Oct 23, 2015 at 8:07 AM Greg Stein <gst...@gmail.com> wrote: > >> On Fri, Oct 23, 2015 at 2:15 AM, Sam Ruby <ru...@intertwingly.net> wrote: >> >... >> >> > I'm a bit bothered by the fact that this would mean that the community >> > voted on one resolution and then a different resolution is constructed >> > anew for the board to approve. But at the moment, I'm not sure how to >> > solve that problem. >> > >> >> New workflow: >> >> 1. $somebody uses whimsy to post a resolution >> 2. commit message is forwarded to $list >> 3. community sees $resolution >> >> I believe the question is "does the commit message reach the appropriate >> audience?" >> > > Maybe it stays in a waiting area until approved by the community? There's an idea. I prefer to focus on defining a process with whimsy in mind, and then add support for making it easier to do something that could also be done outside of whimsy. Applied here, there could be a simple directory in https://svn.apache.org/repos/private/committers of draft resolutions. The board agenda tool could have one or more forms forms that assist with drafting resolutions and place them in that directory. People could update those resolutions directory, and perhaps the tool could also be used for update. The board agenda tool could add support for posting a draft resolution found in this directory to this month's agenda. >> Cheers, >> -g - Sam Ruby P.S. Perhaps it is time for a different subject line and/or move to dev@whimsical? - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Not just yet
On Thu, Oct 22, 2015 at 10:17 PM, Greg Stein <gst...@gmail.com> wrote: > On Oct 22, 2015 9:57 AM, "Sam Ruby" <ru...@intertwingly.net> wrote: >>... >> I've also opened another issue that I would appreciate feedback on: >> >> https://issues.apache.org/jira/browse/WHIMSY-28 > > Cross-check is nice. > > I'd suggest another possibility: a web tool to *add* a template-based > resolution in the first place. A.K.A. A wizard or assistant[1]. Good idea, and easy peasy to implement. I can start with these: https://svn.apache.org/repos/private/committers/board/templates/ The only thing that looks moderately challenging from a UI perspective is allowing the entry of a list of users. I may just go with a textarea as people generally have a resolution that they have voted on prior to posting a board resolution. > Cheers, > -g - Sam Ruby [1] https://en.wikipedia.org/wiki/Wizard_%28software%29 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Not just yet
On Fri, Oct 23, 2015 at 2:32 AM, Greg Stein <gst...@gmail.com> wrote: > On Oct 23, 2015 1:01 AM, "Sam Ruby" <ru...@intertwingly.net> wrote: >> >> On Thu, Oct 22, 2015 at 10:17 PM, Greg Stein <gst...@gmail.com> wrote: >> > On Oct 22, 2015 9:57 AM, "Sam Ruby" <ru...@intertwingly.net> wrote: >> >>... >> >> I've also opened another issue that I would appreciate feedback on: >> >> >> >> https://issues.apache.org/jira/browse/WHIMSY-28 >> > >> > Cross-check is nice. >> > >> > I'd suggest another possibility: a web tool to *add* a template-based >> > resolution in the first place. >> >> A.K.A. A wizard or assistant[1]. Good idea, and easy peasy to >> implement. > > Yup. With the agenda editing bits you've developed, I figured you could do > this with your morning coffee :-) > >> I can start with these: >> >> https://svn.apache.org/repos/private/committers/board/templates/ > > Yes. > >> The only thing that looks moderately challenging from a UI perspective >> is allowing the entry of a list of users. I may just go with a >> textarea as people generally have a resolution that they have voted on >> prior to posting a board resolution. > > Good point. But in that whimsy issue, you mentioned checking the list of > names/emails, so you've already got some processing for that textarea. Indeed. I'm a bit bothered by the fact that this would mean that the community voted on one resolution and then a different resolution is constructed anew for the board to approve. But at the moment, I'm not sure how to solve that problem. > Cheers, > -g - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
