Re: Welcome Wagon
On Mon, Feb 25, 2019 at 11:48 AM Dave Fisher wrote: > > Hi - > > There has been mentions about lack of documentation, not being able to find > documentation, not being responsible for a policy, and not including the > rationale for a policy. > > This morning I remembered something that happened some 49 years ago when I > was a child and we moved to the suburbs of Chicago. A nice lady came over to > the house from a group that called themselves the “Welcome Wagon”. She > provided goodies and all kinds of information about both the local > subdivision and the village. > > I wonder if this is something that the Incubator could help build and > disseminate? > > An Incubator Welcome Wagon could be a Guide of Guides and include > introductory information about: > > (0) Onboarding > (1) Community Development > (2) Infrastructure and Builds > (3) Legal Policy > (4) Release Policy > (5) Press > (6) Foundation Structure > > This information would come from the definitive committee and the mentors > and podlings could provide feedback to the appropriate committees. > > I think something like this would help the Incubator and Mentors be more > facilitator and less police. +1 Back when I was IPMC Chair, I used to send out "Welcome to the Incubator, $PODLING Community" messages: https://lists.apache.org/thread.html/32b8e0f0949996db4f3e9fd7c1b61e35349325faabb985e4fbcead47@1377816395@%3Cdev.sentry.apache.org%3E I sent them out as soon as the dev@podling list creation notification would come through, and they would be cross-posted to general@incubator. These messages had less content than is suggested above; I would argue that it's more important to set the tone than it is to provide complete information. Part of the motivation for cross-posting was to inform people subscribed to general@incubator that might be interested in the podling that the podling dev list was now open. People seemed to like that. But it was mostly about getting started on a positive note (not just for the sake of the newcomers but also for our own). Just like your wonderful anecdote above about the Chicago Welcome Wagon! Any Incubator community member could take on the responsibility for sending such mails (from a template), and sign them either "on behalf of the Incubator community" or "on behalf of the Incubator PMC" (depending on whether they are on the IPMC or not). Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] introduce "[DISCUSS]" threads for podling non-ASF release candidates
+1 I think this proposal could help a lot with how feedback is perceived by podlings! On Mon, Feb 25, 2019 at 11:51 PM Myrle Krantz wrote: > Some podlings want or need feedback on their releases before they are ready > to make official Apache releases. They want to discuss releases that are > not yet ready for a VOTE, or that they are not sure they are ready for a > vote. When such a review is actively requested by the podling, it sets up a dynamic where the recipient can more easily accept and act on the feedback they receive, without losing face. Contrast that with the present, where feedback on releases most often arrives at the time of a release VOTE, where it can be interpreted as punitive. Naturally, we believe that this feedback is essential and a valuable contribution to the podling. So we should set ourselves up to increase the likelihood that it will be perceived that way! Now, it may be the case that a podling doesn't avail itself of the opportunity to request a pre-release review. But so long as they knew about that the service was available, even though they might feel resentful they can only complain so loudly. I read elsethread that some podlings already pro-actively seek out review, which speaks well of such podlings and their Mentors. But I submit while that these conscientious, well-informed podlings will also benefit from system better designed to be constructive and positive, they are not the ones most likely to become disgruntled or even end up in crisis. The linchpin of this proposal is reliable outreach to those podlings who would not seek out this service on their own. If such a podling is not informed, and then later runs into trouble, we will have missed an valuable opportunity. Therefore, I'd suggest that an email to the dev list on this subject ought to be on a mentoring checklist. > Arguments for this proposal: > > * It's a very small change which may make it easier to implement than some > of the "throw it all away and start over" proposals circulating, but... > * It doesn't prevent us from making other larger changes. +1 > * It's not a rule. It's an offering of an additional service + an > incremental reduction in stringency of the incubator. +1, and I'd add that it corrects how the Incubator should see itself -- instead of an enforcer, as a provider of services to podlings. > * It captures some of the value in what we are doing now while increasing > the degrees of freedom provided to podlings. > * It is consistent with our values of transparency, collaboration, >community, pragmatism, meritocracy, and charity. +1, well said! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Starting at the incubator and releases
Hi Mick, The ASF's official Release Policy lives here: https://www.apache.org/legal/release-policy The policy text itself is up-to-date and authoritative. (The associated FAQ, also on that page, does not live up to the same standard.) On 2019/02/25 09:05:30, "Mick Semb Wever" wrote: > ii) "There is documentation _all over the place_ and it's not possible to > know which of it is outdated and which is still current especially in > the face of conflicting information." – Lars Francke. The Incubator cannot solve the problem of excessive and inconsistent policy documentation, because the Incubator doesn't make Foundation-level policy. What the Incubator should do is request in its monthly report that the Board endorse and maintain an authoritative, bounded list of all ASF policy documents -- to say "only these and no more". It should back up this request with illustrations of how the current unbounded morass of documentation burdens our contributors -- both podlings trying to absorb and IPMC trying to explain -- and how the ensuing confusion foments conflict. > b) legal but not fully ASF compliant, The Incubator has the flexibility to make releases which deviate from ASF policy (though not law). It just has to exercise sound judgment and to keep the Board informed of what it's doing. Deviations are actually expected (within reason) and accounted for in the text of Release Policy: https://www.apache.org/legal/release-policy.html#administration Projects MUST notify the Board of Directors of any deviations from recommended or required policy directives. This applies to other top-level projects, not just the Incubator. The Board exercises a certain flexibility when enforcing policy -- if you can articulate why what you want to do is consistent with the ASF's values, the Board will work with you. This assumes you have grokked the ASF's values well enough to make your case. And that goes to show why policy per se cannot be the primary focus of incubation -- well-developed soft skills (such as biasing towards action) and an understanding of the rationales behind why the ASF is the way it is are fundamental to project success. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Edit access to add proposal
On Thu, Apr 20, 2017 at 5:06 PM, Bryan Call <bc...@apache.org> wrote: > I would like to request edit access, so I can add a proposal. > My username is BryanCall. Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [9/9] incubator git commit: Continuing progress on converting to asciidoc.
On Tue, Apr 18, 2017 at 6:39 AM, John D. Ament <johndam...@apache.org> wrote: > On Mon, Apr 17, 2017 at 11:21 PM Marvin Humphrey <mar...@rectangular.com> > wrote: > >> On Mon, Apr 17, 2017 at 5:17 PM, <johndam...@apache.org> wrote: >> > Continuing progress on converting to asciidoc. >> >> John, >> >> I can't tell what you're doing from these huge commits. >> > Don't worry, I can't tell either. Uh haha ha? No. Not cool. IPMC Members and interested Incubator community members have the right and the responsibility to review your changes. >> Are you changing any content? >> >> > So far, here's the big changes I've done: > > - Split mentor guide into several parts (it was way too big) > - Not converted proposal, and names. Not that I don't want to, but haven't > gotten to them yet. > - Not converted the Eclipse and Maven release guides, need to find a better > home for those. I'll convert those if I can't find a better home. OK, let me confirm: There are no substantive changes intended. These are only being reformatted, and the split of the mentor guide is driven by technical necessity. >> If no data is being lost, how can we confirm that? >> > Word of mouth? Its going to require significant QA to verify. Many of the > links won't work, so need reviewers. Who's going to do this QA? How do you envision a before and after check happening? Eyeballing changes on the scale of the Incubator website is not workable. >> Does the method you're working on allow people to edit the site after >> merely an SVN checkout, or would people have to install anything? >> >> > The hope is to actually make it as simple as CMS, without requiring the > overhead of infra running/maintaining CMS. Greg's team has been testing > with github integration on the infra site, and I plan to test that here as > well. Basically, you would be able to edit online via github and commit, > as long as you have write access to the repo. If you don't have write > access a pull request would be created automatically. OK, glad to hear that. > This is all conceptual at this point, mind you. So is this just a prototype? In other words, it's a dry run and when it's finished you'll present a plan for an orderly transition? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [9/9] incubator git commit: Continuing progress on converting to asciidoc.
On Mon, Apr 17, 2017 at 5:17 PM, <johndam...@apache.org> wrote: > Continuing progress on converting to asciidoc. John, I can't tell what you're doing from these huge commits. Are you changing any content? If no data is being lost, how can we confirm that? Does the method you're working on allow people to edit the site after merely an SVN checkout, or would people have to install anything? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing npm modules
On Tue, Apr 11, 2017 at 7:00 AM, Niclas Hedhman <nic...@hedhman.org> wrote: > does anyone have any information on policy/process for uploading npm > modules to global registry https://registry.npmjs.org/ With regards to publication of packages, npm is just another downstream distribution channel -- like Maven Central, Docker Hub, PyPI, CPAN, Debian, crates.io, etc. The main policy point that comes up is this one: http://www.apache.org/legal/release-policy#publication Projects SHALL publish official releases and SHALL NOT publish unreleased materials outside the development community. The second policy point that comes up frequently has to do with trademarks: we expect that anything published as "Apache Foo" will actually be "Apache Foo", and not, say, a vendor-specific "sneak peek" version incorporating controversial new features. It can also be important that multiple PMC members have upload permissions for a given distribution channel. That's a best practice, not a policy, though. But these points apply across all downstream distribution channels, not just npm. > This is for convenience and should be similar to publishing to Maven > Central, but I would like to know if there is anything explicit about it. Infra provides some extra support for certain kinds of distribution (we run repository.apache.org, we used to run a PEAR repo, etc). I don't know of any special technical support related to npm, though. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache DistributedLog release 0.4.0-incubating
On Mon, Apr 10, 2017 at 5:06 PM, John D. Ament <johndam...@apache.org> wrote: > Agreed, however this is where it gets complicated (and at least needs to be > clear to the contributors, or maybe I'm the only one thinking this is > confusing/not obvious). The ASF accepts contributions from individuals, > not companies. So while people may contribute to DLog as employees as > Twitter, the assumption is that you're doing so with the understanding that > these are individual contributions, e.g. you're eligible to license the > code under the Apache License. We assume that individuals who contribute have the right to do so, whether they are contributing material which they hold the copyright to, or whether they are contributing company material on the company's behalf. We don't document the distinction between those cases. In some jurisdictions, distinguishing who owns what gets very complicated -- but it doesn't matter to us since we trust the individual that everybody who might hold copyright is OK with the contribution. > The end date of the NOTICE would always be > when the SGA was sent to the ASF, where they allowed us to use their code. If I understand you right (the Twitter copyright notice is at the end of DLog's NOTICE file), we seem to be the same page. > ASF's copyright would read the original donation date, however if > contributions were applied to the original code base those could be updated > to 2017. The ASF copyright notice reflects the collection of materials, which is deemed to be sufficiently creative to be worthy of copyright even when the collector gathering materials together doesn't hold copyright in any of them. It should be updated every time that the collection changes, which basically means changing it is justified as soon as there's a commit anywhere in the source tree in a new year. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache ODF Toolkit 0.6.2 (incubating)
On Sun, Apr 9, 2017 at 3:40 PM, Josh Elser <els...@apache.org> wrote: > * It looks like your NOTICE file can be essentially encapsulated by > the LICENSE file. If the only "text" you're adding to the NOTICE > file is a copyright text, you can just include that in the LICENSE > file. Josh, I think I see an inadvertent ambiguity here. I'm pretty sure you only mean for this recommendation to apply to copyright notices extracted from dependency licenses (which is sound advice). However, the ASF copyright notice needs to stay in NOTICE, so the NOTICE file will never go away entirely for any ASF product. (Note that adding our copyright to the NOTICE file is an ASF policy, not a requirement of the ALv2 -- outside users of the ALv2 do not have to follow the ASF's example.) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache DistributedLog release 0.4.0-incubating
On Mon, Apr 10, 2017 at 2:28 PM, Henry Saputra <henry.sapu...@gmail.com> wrote: > The question is whether we need to keep this section: > > Portions of this software were developed by Twitter. > Copyright Twitter, 2017 > > in the NOTICE file. Since Twitter already signed off the source > contributions, we could probably remove this section. Only Twitter's authorized representative may legally remove Twitter's copyright notice. Everyone else must leave it alone. Unless something unusual has occurred (like a new SGA from Twitter in 2017), there should not have been a need to update Twitter's copyright. Josh was right to flag that as weird. Sijie, I see that it was your commit that changed the copyright year in NOTICE. It was correct to update the ASF copyright, so please leave that as 2017 (and continue to updated it in future years). For the Twitter copyright, please either restore the 2016 date or discuss any unusual circumstances. (Feel free to ask questions, we're here to help.) Josh was also right to flag the addition of the "Copyright 2017 The Apache Software Foundation" notices in source headers. http://www.apache.org/legal/src-headers.html#headers 2. Each source file should include the following license header -- note that there should be no copyright notice in the header: For individual files, contributors continue to hold copyright on their contributions. The ASF (unlike some other entities such as the FSF) does not require copyright assignment. Thus the ASF only holds copyright in the collection; that's what's expressed in the NOTICE file ASF copyright notice. Marvin Humphrey - 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 Sat, Apr 8, 2017 at 11:23 AM, 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? In my view there is no need for a vote. This is not covered on the Incubation_Policy page as far as I can tell. If memory serves correctly, when we adopted the practice of relying on social enforcement rather than technical enforcement of commit privileges, it was spurred in part by infrastructure simplification: avoiding maintenance of per-podling Subversion ACLs. That the practice we adopted didn't cause problems demonstrates that relying on social enforcement (and commit email monitoring) suffices, so the arguments that won the day back then were sound. But just because we didn't need ACLs doesn't mean that we absolutely must not have them. Today, we have a different infrastructure concern: it's simpler to divide up commit privileges than to unify them. Sure -- I don't see a problem with that. +1 to go ahead and collaborate with infra to make it happen. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator wiki karma needed
On Thu, Mar 30, 2017 at 9:13 PM, Ed Espino <esp...@apache.org> wrote: > Please grant me (username:espino) karma so I can update the Apache Incubator > Wiki for the HAWQ podling report. Looks like you're already in ContributorsGroup, so you should be good to go. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Request to be added to the ContributorsGroup
On Mon, Mar 27, 2017 at 3:52 PM, Ashutosh Chauhan <hashut...@apache.org> wrote: >>>> Wiki username: JeffFeng I added JeffFeng. Happy Wikifying! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Guacamole 0.9.12-incubating (RC1)
On Sat, Mar 25, 2017 at 11:31 AM, Mike Jumper <mike.jum...@guac-dev.org> wrote: > The link is sent out only to the dev@ list. Mike, I agree with all of your arguments and it seems to me that you grok the spirit of the policy. A while back, you and I worked through many of the same themes with regards to Docker Hub distribution, and it seems like that was time well spent. John, I don't see anything worth pursuing here. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Slack
On Thu, Mar 23, 2017 at 2:29 AM, Bertrand Delacretaz <bdelacre...@codeconsult.ch> wrote: > On Thu, Mar 23, 2017 at 2:56 AM, Marvin Humphrey <mar...@rectangular.com> > wrote: >> ...Efficient asynchronous decision making over email is a skill, and >> mastering it >> is key to success as an Apache community > > Indeed, this is one of the topics of our recent "success at Apache" > blog posts series, > https://blogs.apache.org/foundation/category/SuccessAtApache Whoa! Obviously it made an impact on me, Bertrand! The phrasing is too close, and if I had realized I would have linked myself. Apologies, and kudos for the great post. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Slack
On Wed, Mar 22, 2017 at 2:37 PM, Craig Russell <craig.russ...@oracle.com> wrote: > My takeaway is that Slack not a substitute for email. But it is useful for > ping-pong communication when people are in the heat of development. > > But no decisions are made on Slack, and any discussion there (aside from > “add a semicolon there” and “let’s get lunch") needs to be brought back to > the dev list. > > The underlying principle is that “if it didn’t happen on dev, then it didn’t > happen”. We strive for open, inclusive communications at Apache and that > means attempting to encourage participation by everyone who wants to, > regardless of primary language, time zone, and availability of tools. (We > assume everyone has a device that handles email clients). +1 I would add one more criteria: availability. Real-time communication channels, should they be used for development (as opposed to user support), privilege core devs who follow the project every waking minute and exclude everyone on the periphery. Efficient asynchronous decision making over email is a skill, and mastering it is key to success as an Apache community. It takes practice, because the way you present ideas for asynchronous consumption is not the same as the way you'd do it in real-time. The question I always have when podlings ask about Slack, IRC, videochat, face-to-face convos in meatspace, or any real-time communication channel, is whether they appreciate why they need to master email. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: New Incubator Logo Selection Results
On Sat, Mar 18, 2017 at 3:12 AM, John D. Ament <johndam...@apache.org> wrote: > Recommendations on placement? I'll note that the current layout isn't the > layout when I first sent this email, I'm very much open to suggestions. At > one point, I had them far apart, as well as much larger sizes. Move the ASF logo down to the "About The Apache Software Foundation" section. Center the Incubator logo at the top. Also, I like my bikeshed purple: http://purple.bikeshed.org/ Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: GitHub workflows?
On Mon, Mar 6, 2017 at 10:23 PM, Greg Stein <gst...@gmail.com> wrote: > On Mon, Mar 6, 2017 at 11:34 PM, Marvin Humphrey <mar...@rectangular.com> > wrote: >> For what it's worth, on one dev list I'm on, pull requests make it to the >> dev list, but commenting on a commit via the Github interface only triggers >> a private notification -- the comment never makes it to our dev list. We >> mostly avoid Github commit comments for that reason, so inclusiveness is >> not harmed -- but people new to Apache might not handle things that way. >> > We can forward those, if you want. Probably should. I think that's worthwhile as a feature request. (To be clear since I just became VP Legal, no one should take this as a ruling resulting in a new requirement -- it's a feature request humbly submitted for Infra to consider. Right now I'm just wearing my usual "Incubator contributor hat". I will make sure it's obvious when I put on the "VP Legal hat".) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache CarbonData podling graduation
On Thu, Mar 2, 2017 at 11:45 PM, Bertrand Delacretaz <bdelacre...@codeconsult.ch> wrote: > On Thu, Mar 2, 2017 at 7:49 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: >> ...To prepare this discussion, I prepared a self-assessment against the >> Maturity Model: >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68714623 > ... > > Thanks! This helps build confidence about graduating CarbonData, I'm > +1 for that. +1 On https://issues.apache.org/jira/browse/LEGAL-287 I wrote the following, which sounds harsh and may have resulted in a miscommunication: The Incubator itself does not require that podlings assess progress using the Maturity Model. If there are podlings or Mentors who need to be disabused of such a notion, that education work needs to happen in the Incubator's own forums. It's only a problem when a podling treats the Maturity Model and its soft criteria as hard requirements and lets progress be blocked. That's a misapplication of the Maturity Model itself (and arguably shows that the project is not mature). Mature contributors understand how to avoid getting hung up unnecessarily. Actually, the Maturity Model can be a very nice framework to organize incubation around. (Moreso than, say, an enumeration of our policies, which would overemphasize rules.) The Incubator might not formally integrate the Maturity Model today, but perhaps that could change. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: GitHub workflows?
On Sun, Mar 5, 2017 at 8:53 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > Thanks Daniel, I should have thought of that, since that is how I noticed > it. > > So, then the question should have been; > > Are we ok with podlings using GH "Issues" instead of ASF-hosted issue > tracker? > > Are we ok that discussions happen on pull requests and commits? > > I am a little bit uneasy about it, but does the Incubator as a whole have > an opinion/resolution on it? This was discussed in <https://issues.apache.org/jira/browse/LEGAL-249>. The main principle to be upheld is that all dev decisions need to be made on the dev list, for all the reasons that experienced Apache community members are familiar with. In addition, when people contribute, their intent to contribute needs to be captured to an Apache-archived channel. Serializing changes to an ASF mailing list can suffice for both purposes -- if done well. We accept a certain amount of data loss going from an issue tracker to a mailing list. JIRA's state is not fully reproducible -- if somebody attaches a file and then deletes it later, that file is likely gone even if there were notifications sent to a mailing list. So the same sort of data loss from Github issues is not a problem either. However, it's important that the serialization of communiques be both complete and user-friendly enough that someone on the mailing list can participate fully. So, the questions I would ask are, are all those comments making it to the list? And are the podling participants showing through their actions that they understand inclusiveness, by ensuring that dev list readers are able to follow along? For what it's worth, on one dev list I'm on, pull requests make it to the dev list, but commenting on a commit via the Github interface only triggers a private notification -- the comment never makes it to our dev list. We mostly avoid Github commit comments for that reason, so inclusiveness is not harmed -- but people new to Apache might not handle things that way. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Incubator Wiki] Update of "March2017" by MattRutkowski
I reverted the OpenWhisk wiki commit because it contained lots of conflicts. Marvin Humphrey On Wed, Mar 1, 2017 at 10:33 PM, Apache Wiki <wikidi...@apache.org> wrote: > Dear Wiki user, > > You have subscribed to a wiki page or wiki category on "Incubator Wiki" for > change notification. > > The "March2017" page has been changed by MattRutkowski: > https://wiki.apache.org/incubator/March2017?action=diff=31=32 > > > Date of last release: > > + > + /!\ '''Edit conflict - other version:''' >No Release yet > > - When were the last committers or PPMC members elected? > + /!\ '''Edit conflict - your version:''' > + -XX-XX > > + /!\ '''End of edit conflict''' > + > + When were the last committers or PPMC members elected? > + > + > + /!\ '''Edit conflict - other version:''' > Project is being set up with the initial set of committers. > > + /!\ '''Edit conflict - your version:''' > + > + > + /!\ '''End of edit conflict''' > + > Signed-off-by: > > [X](mxnet) Sebastian Schelter >Comments: > [X](mxnet) Suneel Marthi > + > + /!\ '''Edit conflict - other version:''' > + > + /!\ '''Edit conflict - your version:''' > + [ ](mxnet) Suneel Marthi > + > + /!\ '''End of edit conflict''' >Comments: > [ ](mxnet) Markus Weimer >Comments: > @@ -987, +1008 @@ > > > OpenWhisk > > - distributed Serverless computing platform > + 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. > > OpenWhisk has been incubating since 2016-11-23. > > Three most important issues to address in the move towards graduation: > > - 1. > - 2. > - 3. > + 1. Moving github repos under the Apache Github Org (organization move, > + repository renames), first 2 repos. moved; issues identified and being > worked. > + 2. Working to redirect openwhisk.incubator.apache.org to openwhisk.org, > + update openwhisk.org to be Apache compliant (pre-req is repo. move > completion > + so that we can generate site via Jenkins/Apache tooling) > + 3. Working through project incubation checklists on CWIKI > + Compliance Checklist for OpenWhisk.org website > > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be > aware of? > > + - Travis CI takes hours to process a PR on Apache Org; whereas it takes > minutes under current > + OpenWhisk org. > + - The root cause is that Apache has 185 repos enable with Travis > [1], but only an allocation of > + 30 concurrent builds. OpenWhisk typically needs 5 concurrent > build slots by itself continually. > + - Many of the OpenWhisk’s repos. have cross-build dependencies (primarily > for Travis CI tests) > + this may will cause issues as repos. are brought over 1 at a time if > forwarding links are not > + preserved by GitHub. > + - There may be issues with Committers in China being able > + to enable 2FA since it does not work with their cell phones and the > + alternative encryption tool seems to be blocked. Investigating with > + infra. > > - > - How has the community developed since the last report? > - > - > - > - How has the project developed since the last report? > + How has the community developed since the last report? > > + - Committers have begun enable 2FA for GitHub and enable cross- > + authentication to their Apache accounts using GitBox. > + - “dev", “private” email list traffic continues to be healthy; positive > + discussion of a few new code feature/change topics > + - GitHub project “Stars” = 1144 (up from 1024 last month). > +- a few new contributors in package deployment tool repo. > +- more active discussions occurring on “dev” list. > + - Created new public Slack Team (openwhisk-team.slack.com). includes > channels: > + - “general” for general project questions and help > + - “dev” channel where notifications of all OpenWhisk GitHub Issues are > posted. > + - “dev-pr” channel where notifications of all OpenWhisk GitHub Pull > Requests are posted. > + = Note: all development related discussions are directed to our “dev” > mailing list. > > + Ho
Re: Please grant permissions for Wiki
On Wed, Mar 1, 2017 at 9:50 PM, Cesar Berho <ce...@apache.org> wrote: > Please add me to ContributorsGroup on Wiki, I'm trying to upload the PMC > report > > Account: Cesar Berho Added "Cesar Berho" (with space). Happy wikifying! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling Graduation Rally
On Tue, Feb 21, 2017 at 12:15 PM, John D. Ament <johndam...@apache.org> wrote: > On Tue, Feb 21, 2017 at 2:52 PM Roman Shaposhnik <ro...@shaposhnik.org> > wrote: >> I think we all agree on what's going on and I believe (although correct >> me if I'm putting words in your mouth John) that we all feel the current >> situation with MADlib is NOT against any policy of ASF. >> > Not 100%. We are saying that code modifications should have been under > apache license, but they were still under BSD as of the release from last > year. What makes you say that? What do you mean by "they were still under BSD"? Please point us at a commit. The podling has received a recommendation from VP Legal. If you believe that recommendation was in error, please raise your objection explicitly on legal-discuss. If you can't persuade Legal to rescind the recommendation, then the remaining question is whether the podling is implementing that recommendation successfully. I have not yet seen a coherent explanation of how the podling is failing in this regard. I'm troubled by how difficult we are making things for MADlib. They consulted Legal and got a recommendation. As far as I know, they're following the recommendation. What more can we ask of them? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling Graduation Rally
On Tue, Feb 21, 2017 at 6:31 AM, John D. Ament <john.d.am...@gmail.com> wrote:
> So are we saying that the code modifications are sub-licensed? Or
> re-licensed?
Think of each file as the result of layering changesets on top of each
other. Each changeset has its own copyright holder and each copyright
holder grants a license.
When all changesets have the same license, then the end product has
uniform licensing, even though many entities hold continue to hold
copyright.
However, it is also possible that changesets may be granted under
different licenses -- in which case, the end product has heterogeneous
licensing. It may not be possible to slice up the file into code blocks
which are under one license exclusively. Instead, if you want clean
divisions by license you have to go back to the changesets.
For BSD-2-clause files which came in with MADlib but were not relicensed
(because not all authors participated in the SGA), we are saying that
changesets submitted after arrival at the ASF shall be under Apache-2.0.
PS: This workflow is not possible when the first license has reciprocity
requirements (i.e. it's a "copyleft" license like GPL or MPL),
because a key condition of such licenses is that the copyright
holder for subsequent changesets must make them available under the
original license. However, BSD licenses do not impose such a
restriction, so it's valid to create an ALv2 changeset to apply on
top of a BSD file.
Marvin Humphrey
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Podling Graduation Rally
On Mon, Feb 20, 2017 at 10:47 AM, Mike Jumper <mike.jum...@guac-dev.org> wrote: > AFAIK, only the copyright holder can relicense a copyrighted work, whereas > others may sublicense under compatible terms so long as the original > license grants that permission (ie: the license of the original work is not > actually changing). > > Is that not correct? Correct, and well said! When we assert that an Apache release package is available under the ALv2 even though it bundles BSD-2-clause licensed code (as is the case with MADlib), we are suggesting that the ALv2 "subsumes" the BSD-2-clause license -- that fulfilling all the requirements of the ALv2 suffices to fulfill all the requirements of the BSD-2-clause license. This is sometimes called "sublicensing", and it only works in one direction: a license with more restrictions can subsume one with fewer, but not the other way around. In contrast, "relicensing" is usually taken to mean the original copyright holder granting an *additional* license of any type. For example, if you're the copyright holder, you can take something which is available only under a proprietary license and make it available under an open source license. Or you could take something available under the GPL and make it available under the ALv2. (Of course the difficulty of "relicensing" in the context of open source is that there may be many copyright holders who need to participate in a relicensing effort -- and if you can't get them all on board, you might have to strip out and replace code that couldn't be relicensed.) For more information on combining software under multiple open source licenses, I like this article by Luis Villa: https://opensource.com/law/11/9/mpl-20-copyleft-and-license-compatibility This is outdated but still a good read: http://www.catb.org/esr/Licensing-HOWTO.html#compatibility Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Forming of a Selection Committee for New Incubator Logo
On Thu, Feb 16, 2017 at 4:11 AM, John D. Ament <johndam...@apache.org> wrote: > As you know, our logo submission deadline is this coming Monday (make sure > you get your submissions in if you haven't already!). In order to support > that, I believe we need to form some kind of committee to help form an > opinion around which logos make sense and don't make sense, in addition to > the community vote that is going to happen. > > So if you're looking to join that committee, please reach out. I'd like to participate. (FWIW, I used to work in graphic design and prepress.) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Approving flawed release candidates
On Wed, Feb 15, 2017 at 8:17 PM, Julian Hyde <jhyde.apa...@gmail.com> wrote: > While I agree with what both John and Marvin are saying, the key word here > is “discretion”. +1 for IPMC members applying discretion. I've submitted some suggestions which I hope other IPMC members will consider, and I've tried to think them though carefully, but situations will inevitably arise where the suggested workflow is an awkward fit. For instance, a judgment call is required when there's a dispute as to whether an issue was fixed, as John discusses elsethread. > Obviously the IPMC shouldn’t give podlings too hard a time > (we all know how difficult and time consuming it is to go through a cycle > consisting of a release candidate and TWO votes, and the mechanics of the > release process are intimidating to the uninitiated). But also IPMC members > are at liberty to say “I don’t like the look of that, I’m voting -1”. A -1 > doesn’t veto a release (we just need 3 more +1s than -1s), and IPMC members > can always change their vote after a discussion. It seems we're basically on the same page. However, there have been multiple instances going back a ways where the IPMC had the option to let through a flawed but legal RC, yet the podling was asked to respin. This thread isn't just in response to the recent Traffic Control vote. I'm not sure it's been clear to all our IPMC members when the option to approve a release with policy flaws is available, so I thought it was worthwhile to review the rationale and to analyze some of the most common cases. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Approving flawed release candidates
Greets, We take pains to advise downstream consumers that podling releases are "incubating" because they may not live up to the standards expected of Apache TLPs -- whether that is because the community is not mature, because the release is not fully compliant with ASF policies, or what have you. A while back, the IPMC arrived at a consensus about the circumstances under which we might approve incubating release candidates which are legal to distribute yet do not fulfill all aspects of Apache policy. A test was proposed by IPMC member and ASF Board member Bertrand Delacretaz: "Does it put the Foundation at risk?" https://wiki.apache.org/incubator/January2014 3. Consensus was built for a controlled regime for relaxing policy on incubating releases under appropriate circumstances, potentially reducing the number of release candidates we force podlings to cycle through. The first release candidate approved under that relaxed regime bundled jar files in the source release. The podling promised to remove them in the next point release (and subsequently followed through): * Exercising the new regime for controlled relaxation of policy, a bugfix release by Spark (0.8.1) which bundled jar files was approved by the IPMC after the podling presented a roadmap to eliminating them in the next minor point release (0.9). For IPMC members evaluating a flawed release candidate (whether Mentors or "freelance" IPMC reviewers on general@incubator), perhaps consider the following workflow: 1. When policy violations which do not put the Foundation at risk are discovered in an RC, vote -1 until tickets are filed. Once they're filed, change vote to +1. 2. If a release candidate has policy issues which were brought to light on a previous RC and should reasonably have been fixed already, vote -1. (We may be tolerant but we're still serious.) In particular, there are two common classes of problem that I think can be handled this way: The first is licensing documentation bugs, such as missing "forwarded" dependency licenses in LICENSE, and extra junk in NOTICE. (Actual licensing violations which make the RC illegal to redistribute are a different story.) The second is bundled compiled code, such as jar files. I've written at length elsewhere on why we exclude these systemically (as have others such as Roy Fielding), but they are a policy issue rather than a legal issue. Finally, there's one other common case worth mentioning which requires slightly different treatement: dependencies with unapproved licenses. These may be OK for incubating releases, but first require approval by VP Legal. Incubation disclaimers give us the flexibility to bring podlings into compliance incrementally. At the same time, because podlings may not be in compliance, incubation disclaimers are important -- two sides of the same coin. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On Wed, Feb 15, 2017 at 1:00 PM, John D. Ament <johndam...@apache.org> wrote: > On Wed, Feb 15, 2017 at 3:05 PM Marvin Humphrey <mar...@rectangular.com> > wrote: > >> On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood <dang...@apache.org> wrote: > Personally, the reason why I'm asking about the impact is to better make a > judgment call on whether to block or not. I don't particularly see why > we're now being jumped on over this fact. John, My email was rushed because I wanted to preempt cancellation of the vote. I see now that it can be read in a more confrontational tone than was meant. Thank you very much for taking the time to review the release candidate. I'll make the case for more lenience in general when approving incubating release candidates on a separate thread later today. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Traffic Control 1.8.0-incubating (RC9)
On Wed, Feb 15, 2017 at 11:58 AM, Dan Kirkwood <dang...@apache.org> wrote: > You're right -- fixing the license file is not a huge effort (now that > we understand what's expected..). The effort is in going thru the > voting process again.. > > I'll go with whatever you recommend.. Folks, we're on RC *nine*. The IPMC has the discretion to apply the "does it put the Foundation at risk" test for releases which don't follow policy yet are still legal. This would seem like a good time to be flexible. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Adding ozawa to incubator karma
On Fri, Feb 10, 2017 at 9:05 AM, Henri Yandell <bay...@apache.org> wrote: > Hi Ted, > > Could you add ozawa@ to the Incubator LDAP? He is on the MXNet project but > as he already had an Apache account he's not been granted karma as a part > of setup. I took care of this (using my VP privs as VP Lucy) -- `ozawa` should be good to go. For future reference (especially others who may have seen this thread), please send LDAP administrivia requests to private@incubator. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Podling report format changes
On Thu, Feb 2, 2017 at 5:52 AM, Shane Curcuru <a...@shanecurcuru.org> wrote: > John D. Ament wrote on 1/24/17 8:15 PM: >> 2. Add a "Podling Maturity Assessment" to the individual podling reports. >> This would give a clear opportunity for each podling to describe how they >> are doing, perhaps compared to the maturity model or our classic categories. > > +1, with a general encouragement to start each with a simple category. > That is, when scanning the whole report, it would be very helpful to see > one of "Ready to Graduate", "Some Community Growth", "No Release" and > "Still Getting Started" or a similar set of values. Any additional > description is great, but having fairly consistent markers really helps > get a sense of progress across the whole incubator. > > Personally I like the maturity model, so using that is great, but I do > understand that we may not always have cycles to use it. How we implement this matters a great deal. It should be possible to figure out what to do simply from the template -- if it is not clear, I anticipate befuddlement and backlash. A lot of our podlings and Mentors do not participate in these centralized discussions, and a disruptive change to reporting will incur a large community cost. Thus, I propose this addition to the template: How would you assess the podling's maturity? Please feel free to add your own commentary. [ ] 1. Initial setup [ ] 2. Working towards first release [ ] 3. Community building [ ] 4. Nearing graduation [ ] Other: A bit long perhaps, but that will be solved the day we integrate podling reporting into Whimsy. :) >> 3. Change the mentor sign off section to include a per-mentor comment. >> E.g. instead of the current: >> >> [ ](podling) mentor1 >> [ ](podling) mentor2 >> [ ](podling) mentor3 >> >> It would be: >> >> [ ](podling) mentor1 >> Comments: >> [ ](podling) mentor2 >> Comments: >> [ ](podling) mentor3 >> Comments: >> >> And rename Shepherd/Mentor notes: to just "Shepherd notes:" > > Big +1. Having even a sentence for most mentors with their thoughts is > a huge improvement if we can get it. I agree, this is very nice. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)
On Mon, Jan 23, 2017 at 4:35 AM, John D. Ament <johndam...@apache.org> wrote: > What I'm trying to make sure we're agreeing to is > that the problem isn't that there is a JAR to .tar.gz file in the > distribution. Its that the original source is missing. No. Bundling jar files is not OK in general and it is definitely the intent of the policy to exclude them. (Source: I led the redrafting effort for the official policy.) Among other reasons, they are potential trojan horses, because they cannot be audited by a PMC. We might choose to make exceptions in some edge cases, like when the jar files are used as data for tests. That does not invalidate the policy. > I'm personally in favor of > having the gradle wrapper (and maven wrapper) present since it helps build > the code. The gradle wrapper and similar are also not permitted. Build processes need to bootstrap it. This isn't a big deal in practice because most people don't care about the security implications of consuming the convenience binary and just use that. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)
On Sat, Jan 21, 2017 at 9:34 AM, John D. Ament <johndam...@apache.org> wrote: > On Sat, Jan 21, 2017 at 12:19 PM Marvin Humphrey <mar...@rectangular.com> > wrote: > >> On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament <john.d.am...@gmail.com> >> wrote: >> > However, regarding the >> > binaries. In a recent discussion (on legal-discuss) it was decided that >> > this was OK. Ideally the NOTICE would include the information on the >> > binary's source of origin (assuming that the source was eligible to be >> > licensed this way). In this case, the .tar.gz is actually the >> > distribution of Apache Spark R that looks like its required to build >> Toree. >> >> I must have missed this on legal-discuss, and it's counter to my >> understanding. Can you please provide a link? >> >> Here is something I wrote to legal-discuss recently, which talks about >> some of the security reasons why bundling a binary dependency is >> problematic: https://s.apache.org/OuNX >> >> > Same thread. Specifically Mark T's response [1] and Craig's affirmation [2] > > [1]: > https://lists.apache.org/thread.html/995d9ddda07363faff5306154ff3a3aa100a07aad191785d866ae097@%3Clegal-discuss.apache.org%3E > [2]: > https://lists.apache.org/thread.html/5f10a28e5f7bf117599d35e14a00290453c1741d614605950ca897c1@%3Clegal-discuss.apache.org%3E Let me be clear: compiled code does not belong in our official source releases. Here's the relevant policy clause: http://www.apache.org/legal/release-policy#compiled-packages The Apache Software Foundation produces open source software. All releases are in the form of the source materials needed to make changes to the software being released. Creating releases which adhere to this policy is almost always straightforward. Just because there are some edge cases where we have to apply judgment doesn't invalidate the policy and allow willy-nilly bundling of binaries. The OpenWebBeans case from legal-discuss was just such an edge case. The .class file wasn't on the class path and was used only when running unit tests for some bytecode stuff. This is quite difficult to exploit. The debate on legal-discuss was over whether it was worth doing anything about, because it was more of a binary resource (like a .jpeg) than compiled object form. In the end we didn't even make a policy exception because the project applied a workaround -- they extracted the bytecode out of the .class file and encoded it as a static variable in the source file. Now, that's not really all that different from a test-time security standpoint from having the .class file in a test dir outside the classpath or renaming `Foo.class` to `Foo.dat` or `Foo.bin`. It is better though from an auditing perspective because when changes are made there will be a human-readable diff in the commit notification email. And that brings me to the bundling of SparkR in Toree. The standard procedure would be for the user to fetch that dependency themselves. By embedding it, we actually make it *harder* for security-minded consumers to understand where their dependencies are coming from. I don't see a strong rationale for bundling this dependency. It isn't compiled code, it's compressed source -- but when it's updated, there's no diff because the tar.gz is binary. Why not treat it like any other dependency? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)
On Sun, Jan 22, 2017 at 5:47 PM, John D. Ament <johndam...@apache.org> wrote: > [3]: http://www.apache.org/dev/release.html#what-must-every-release-contain That document has been superseded. Official Release Policy, curated by VP Legal, is here: http://www.apache.org/legal/release-policy Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0
On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament <john.d.am...@gmail.com> wrote: > However, regarding the > binaries. In a recent discussion (on legal-discuss) it was decided that > this was OK. Ideally the NOTICE would include the information on the > binary's source of origin (assuming that the source was eligible to be > licensed this way). In this case, the .tar.gz is actually the > distribution of Apache Spark R that looks like its required to build Toree. I must have missed this on legal-discuss, and it's counter to my understanding. Can you please provide a link? Here is something I wrote to legal-discuss recently, which talks about some of the security reasons why bundling a binary dependency is problematic: https://s.apache.org/OuNX Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Staged Artifact Locations (was Re: [VOTE] Release Gossip version gossip-0.1.1-incubating (RC2))
On Thu, Jan 12, 2017 at 8:39 AM, Josh Elser <els...@apache.org> wrote: > IMO, it prevents a one-line release command for Maven projects using the > standard conventions (I'm blindly assuming is Maven is the most common tool > used). However, I can also see where Justin is coming from with the > provenance side of things (the disconnect between what was voted on and what > gets placed on dist.a.o). > > * Does anyone actually verify that people use `svn mv` now? > * Does anyone actually verify that the xsums of what was voted on is what > gets put into dist.a.o as the official release? > > So, yes it would be nice to avoid any snafu due to any incorrectly promoted > release, but I don't think it would actually get us any closer to a complete > "chain of custody" than what we have now. As such, I think it is an > unnecessary burden for an already "traumatic" release process. It would be a > good "best practice" however not a "policy". Here's the relevant policy requirement: http://www.apache.org/legal/release-policy#release-distribution Once a release is approved, all artifacts MUST be uploaded to the project's subdirectory within the canonical Apache distribution channel, www.apache.org/dist. Just how the artifacts get into the canonical source dist is left unspecified. We definitely don't want there to be mistakes leading to artifacts not being uploaded or the wrong artifacts uploaded. To that end, we have the dist.apache.org workflow to make things easier and reduce the potential for error. If projects choose not to use the full workflow, they still have the responsibility to get the canonical upload right. >From the standpoint of the ASF, Maven distibution is a downstream channel. The policy clause above later continues: After uploading to the canonical distribution channel, the project (or anyone else) MAY redistribute the artifacts in accordance with their licensing through other channels. Projects generally work hard on their downstream distributions, but those efforts are outside the scope of Release Policy. From the ASF policy standpoint, you have to get the official source release right, and whether you get the Maven release right is immaterial. It's not that we don't care if you mess up downstream distribution and damage the project's reputation, but that it's not something we need or want to control with policy constraints. But we *do* care about things such as guaranteeing that security conscious consumers will be able build from source. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Write access to January report page
On Mon, Jan 9, 2017 at 11:34 AM, Carlos Santana <csantan...@gmail.com> wrote: > Hi my I just created a userid CarlosSantana on the wiki > Can I get write access? Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Write access to January report page
On Fri, Jan 6, 2017 at 9:46 AM, Matt Rutkowski <mrutk...@us.ibm.com> wrote: > The OpenWhisk moderators would like to begin submitting status on behalf > of OpenWhisk, but have also found we do not have write access to the Wiki. > Previously, our mentor Felix Meschberger provided this for our > first/initial report, but would like to help him to not be the sole > persons responsible. > > If you could please add myself, Matt Rutkowski, along with Carlos Santana > to the ContributorsGroup similarly (below) we would like to accept that > responsibility going forward on behalf of the podling. Happy to. What usernames do the two of you use to log into wiki.apache.org/incubator ? Are your usernames actually `Matt Rutkowski` and `Carlos Santana` (with the space in the middle)? That's possible but unusual, so please confirm. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Write access to January report page
On Thu, Jan 5, 2017 at 9:41 AM, jean-frederic clere <jfcl...@gmail.com> wrote: > On 01/05/2017 01:51 AM, Niclas Hedhman wrote: >> Hi, >> Isn't the https://wiki.apache.org/incubator/January2017 supposed to be >> editable by Mentors/IPMC members? > > So I probably have a problem... JeanFredericClere my user can't edit it > or is it too late? I have added JeanFredericClere to ContributorsGroup, and you should now be able to edit the wiki report page. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Write access to January report page
On Wed, Jan 4, 2017 at 5:42 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > My login as "niclas" Added. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Wiki Contributor
On Wed, Jan 4, 2017 at 4:36 PM, Randall Leeds <rand...@apache.org> wrote: > Would someone kindly add me as a contributor to the incubator wiki? > > My username is RandallLeeds. Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Write access to January report page
On Wed, Jan 4, 2017 at 4:51 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > Isn't the https://wiki.apache.org/incubator/January2017 supposed to be > editable by Mentors/IPMC members? It's editable by anyone whose wiki username we add to the ContributorsGroup page. What's your wiki id for wiki.apache.org/incubator? (Which is distinct from your Apache ID and from logins for other Moin wikis.) I'll add you. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Drop the 2013 Alternate Voting Policy
On Thu, Dec 29, 2016 at 11:46 AM, John D. Ament <johndam...@apache.org> wrote: > Pssst really need you guys looking at the proposed replacement > documentation. > https://lists.apache.org/thread.html/fab8122d7695e47bacbff680b83eb4ceed98539a7815e2232abf5d2f@%3Cgeneral.incubator.apache.org%3E There's a lot here, and with social obligations of the holiday season, I'm having trouble finding the time to review it all. If I may suggest an approach, though: For guides, how-to's and the like, it is nice if you summarize changes in advance, but we also shouldn't let anything block your way. The Incubator has suffered from a lack of people willing to wade in and actually work on documentation -- having you show up to do work is a real boon. So if you tell people "I'm going to work on X, and here's roughly what I plan", then JFDI so long as you work incrementally and reversibly. People have the option to review your commits. But for *policy*, specifically the Incubation_Policy.html page, please take a different tack. Any change to that page should be proposed as a patch on general@incubator in a thread with a 72 hour minimum review period. Furthermore, please try to make good use of our limited capacity for review: endeavor to make clean and minimal proposals, avoiding multiple revisions and large, hard-to-digest changesets. It's important to get the fine details of policy right because even minor wording inaccuracies can spawn brutal, bitter disputes. Additionally, a deliberate, inclusive drafting and review process is a prerequisite for community buy-in, inoculating us against crises of legitimacy. Does that division make sense? Careful drafting and RTC for policy, CTR and a higher tolerance for inaccuracy in guides, FAQs, etc. One more thing: the Proposal Guide is way more important than all the others, so please treat it with care if you do any work there. During the crafting of a proposal for incubation, that page has profound influence on incoming communities as they think deeply about how their project might fit into Apache. (In fact, maybe we should make that page RTC...) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator chat on Hipchat?
On Wed, Nov 2, 2016 at 3:23 PM, John D. Ament <johndam...@apache.org> wrote: > Infra recently started leveraging hipchat. A few PMCs have made use of > it. I was wondering, would it be beneficial to anyone if we setup an > incubator room in hipchat? How about just promoting the #asf IRC channel on freenode.net? https://kiwiirc.com/client/irc.freenode.net/#asf Better for podling contributors to make connections to the wider ASF rather than to limit themselves to the current incubator, and the #asf channel is already well established. We could even embed the Kiwi IRC client in an iframe on the Incubator website, at say http://incubator.apache.org/chat alongside guidance documenting how we expect real-time communications to be used. https://kiwiirc.com/client/irc.freenode.net/#asf; style="border:0; width:100%; height:450px;"> Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
DRAFT report September 2016
Greetings, Please review this draft report. The MoinMoin wiki is slow and unreliable today. If your wiki update doesn't go through, feel free to reply on this thread and I will integrate your changes. Remaining tasks: * The following podlings need signoff: - Fineract - log4cxx - MRQL - Myriad - Toree - Trafodion - Wave * The narrative and the Legal/Trademarks/Infrastructure/Misc sections need to be fleshed out with summaries from August's conversations on general@incubator. (Ted) Thanks to everyone who has contributed to the report! Marvin Humphrey Incubator PMC report for September 2016 The Apache Incubator is the entry path into the ASF for projects and codebases wishing to become part of the Foundation's efforts. < narrative > * Community No IPMC roster changes this month. * New Podlings - Annotator - AriaTosca * Graduations None this month. * Releases The following releases entered distribution during the month of August: - 2016-08-01 Apache Pony Mail 0.9.incubating - 2016-08-02 Apache Mnemonic 0.2.0-incubating - 2016-08-03 Apache Eagle 0.3.0-incubating - 2016-08-09 Apache Datafu (incubating) 1.3.1 - 2016-08-10 Apache Gearpump 0.8.1-incubating - 2016-08-20 Apache Ranger (incubating) 0.6.1 - 2016-08-22 Apache Metron 0.2.0BETA-incubating - 2016-08-22 Apache Beam 0.2.0-incubating - 2016-08-24 Apache CarbonData 0.1.0-incubating - 2016-08-29 Apache Pirk 0.1.0-incubating * IP Clearance None this month. * Legal / Trademarks * Infrastructure * Miscellaneous * Credits - Report Manager: Marvin Humphrey / John D. Ament Summary of podling reports * Still getting started at the Incubator - AriaTosca - Traffic Control * Not yet ready to graduate No release: - DistributedLog - Edgent - Fineract - HTrace - Juneau - log4cxx2 - PredictionIO - SensSoft - Toree Community growth: - Atlas - CarbonData - CommonsRDF - Gearpump - Mnemonic - MRQL - Myriad - Omid - Pirk - Pony Mail - Singa - SAMOA - Tephra - Trafodion - Wave * Ready to graduate - Ranger - Taverna * Considering retirement - Streams * Did not report, expected next month - Quickstep - Tamaya -- Table of Contents AriaTosca Atlas CarbonData CommonsRDF DistributedLog Edgent Fineract Gearpump HTrace Juneau log4cxx2 Mnemonic MRQL Myriad Omid Pirk Pony Mail PredictionIO Quickstep Ranger SAMOA SensSoft Singa Streams Tamaya Taverna Tephra Traffic Control Trafodion Toree Wave -- AriaTosca ARIA TOSCA project offers an easily consumable Software Development Kit(SDK) and a Command Line Interface(CLI) to implement TOSCA(Topology and Orchestration Specification of Cloud Applications) based solutions. AriaTosca has been incubating since 2016-08-27. Three most important issues to address in the move towards graduation: 1. Establish a formal release process and schedule, allowing for dependable release cycles in a manner consistent with the Apache development process. 2. Grow the community around the project. 3. Migrate existing users to apache mailing lists, redirect the present external project links to Apache. Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? None How has the community developed since the last report? The project is still being setup in Apache Incubator and is presently. Received Software Grant Agreement (SGA) from Gigaspaces. The mailing lists, Jira, Github Repo, Incubator podling, Confluence Wiki have been setup for the project. How has the project developed since the last report? This would be the first report for AriaTosca. The project is presently being setup in Incubator. Date of last release: None When were the last committers or PMC members elected? Project is being established in incubator with the proposed initial set of committers. Signed-off-by: [X](ariatosca) Suneel Marthi [X](ariatosca) John D. Ament [X](ariatosca) Jakob Homan Shepherd/Mentor notes: Atlas Apache Atlas is a scalable and extensible set of core foundational governance services that enables enterprises to effectively and efficiently meet their compliance requirements within Hadoop and allows integration with the complete enterprise data ecosystem. Atlas has been incubating since 2015-05-05. Three most important issues to address in the move towards graduation: 1. Podling name search is pending. Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of? No specific issues at this time to report. How has the community developed since the last report? 1. We have added
Re: Namespacing of subproject Docker images vs. Incubator policy
On Wed, Sep 7, 2016 at 9:44 AM, Mike Jumper <mike.jum...@guac-dev.org> wrote: > Is the project-specific organization option not really an option at all > then? Frowned upon for a TLP, and not to be considered by a podling? My chief concern so far has been assuring that our nascent Infra-supported offerings do not conflict with policy. Now that this has been achieved (in planning, if not yet in implementation), it's easier to speak to your issue. The main Docker Hub at hub.docker.com is a public-facing downstream distribution channel -- similar to Maven Central, PyPI, Debian package management, etc. It is appropriate to distribute official releases through downstream channels, but inappropriate to distribute unreleased materials through them. (That's why having `latest` on hub.docker.com point to git `master` is problematic.) See Apache's formal Release Policy and Release Distribution Policy documents: http://www.apache.org/legal/release-policy#policy http://www.apache.org/dev/release-distribution#policy There are an unbounded number of such downstream channels, and there is no way we are going to formulate specific policies for all of them. Instead, we primarily rely on people respecting our trademarks: that "Apache Foo", when obtained from one of these channels, is what the consumer expects. http://www.apache.org/foundation/marks One implication is that if you're using the project name for that Docker Hub account, we'd expect the entire PMC to have access. Incubating podlings operate under additional constraints, in that the "Apache" brand needs to be tempered with "incubating" and appropriate disclaimers. http://incubator.apache.org/guides/branding.html But within those guidelines, the answer is: yes, go ahead. If Infra's offering is not to your taste, that is. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator wiki permission request for submitting report
On Tue, Sep 6, 2016 at 11:42 PM, Khurrum Nasim <khurrumnas...@gmail.com> wrote: > I have created my new account on the incubator wiki. My username is > 'KhurrumNasim'. Can you please help granting the edit permission for > submitting the podling report? Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
On Thu, Sep 1, 2016 at 7:47 PM, Mike Jumper <mike.jum...@guac-dev.org> wrote: > All, setting aside the Docker Hub vs. Apache-hosted hub vs. bintray > discussion for the moment, The issue of hub.docker.com/r/apache/* has been worked out in principle with Infra. Only official releases will be be built, and `latest` will point to an image based on the last official release. The plan has not yet been implemented, but now you know what to expect in the future. See the infrastructure@apache thread (login required): https://s.apache.org/euyI > are there any specific opinions regarding > the original issue: the actual namespacing of the podling images > themselves? > apache/incubator-guacamole:0.9.10-incubating > apache/incubator-guacd:0.9.10-incubating Using how we name Git repos as precedent, the image address would be: apache/incubator-guacamole apache/incubator-guacamole-guacd ... and with tags: apache/incubator-guacamole:0.9.10-incubating apache/incubator-guacamole-guacd:0.9.10-incubating > - Seems redundant (incubator, incubating), graduation would break > compatibility (see Maven best practices [1]) I agree that it would be best not to break compat on graduation. > apache/guacamole:0.9.10-incubating > apache/guacd:0.9.10-incubating Or, matching up with our (post-graduation) Git repo naming convention again: apache/guacamole apache/guacamole-guacd apache/guacamole:0.9.10-incubating apache/guacamole-guacd:0.9.10-incubating I think this is best. However, it bugs me that users are not provided with adequate disclaimers for the common case that fetches `latest` as the default tag: docker pull apache/guacamole I don't have any ideas beyond requiring a prominent incubation disclaimer on the repo info page at https://hub.docker.com/r/apache/$REPO/ . Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator Wiki permission request for submitting report.
On Tue, Sep 6, 2016 at 1:28 PM, Gary <ga...@apache.org> wrote: > I have create my new account on Apache Incubator Wiki page, the username is > "garyw", could you please help to add my account to ContributorsGroup asap. > for submitting our September's podding report ? Thanks! Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: September 2016 Incubator PMC Report Timeline
On Tue, Aug 30, 2016 at 3:47 AM, John D. Ament <johndam...@apache.org> wrote: > Special note - my availability has been limited, and this month is no > exception. I'm not going to be able to complete the report this month. > Consider this a call to volunteers. I can help (as I do most months). I would appreciate additional collaborators. Someone to summarize the conversations that have taken place on general@incubator and write the narrative for this month would be welcome (and is probably the most interesting task). Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
On Mon, Aug 29, 2016 at 12:53 PM, Jake Farrell <jfarr...@apache.org> wrote: > We have our own docker registry available for projects to use, its hosted > out of bintray. Access can be granted per project via an infra ticket > request. > > Dockerhub is used in an automated builds capacity, we can set it to only > build tagged versions. > > Happy to answer any questions about either offering. On the other thread, it was suggested that the Bintray Docker stuff was only for public releases. Is that not the case? Is it already set up like repository.apache.org as suggested upthread? On the other hand, if I type `docker pull apache/nutch` or `docker pull apache/thrift`, I get unreleased `master`, which is a problem. Docker images of official releases for distribution to the general public are an unalloyed good. Docker images of unreleased builds are a nice convenience for our dev communities, but distribution must be fenced off and outsiders pointed towards official releases. It would be great if there can be a strong division between hub.docker.com for public images and something analogous to repository.apache.org on Bintray or elsewhere for private builds. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Namespacing of subproject Docker images vs. Incubator policy
On Mon, Aug 29, 2016 at 8:30 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > FWIW, I say that we should just adopt a repository.apache.org approach > and declare that nightly/snapshot Docker images can only be distributed > from our own Docker repo. That way there's absolutely 0 chance anybody > can get them by accident. Running our own hub a la repository.apache.org would address the concerns about distributing unreleased materials outside the development community. It sounds like a worthwhile Infra feature request. +1 Having `latest` on the central dockerhub point derive from the last official release sounds like a good move, regardless. For background: http://www.apache.org/legal/release-policy#release-definition http://www.apache.org/legal/release-policy#publication Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 11:09 AM, Makoto Yui <m...@treasure-data.com> wrote: > There are 5 individuals, excluding project committers, sent pull requests > to the project before moving to ALv2: smly, y-tag, ryukobayashi, > spiritloose, and takahi-i. I assume that all the "project committers" (if that group is more than just you) were employed by AIST and that the copyright for any code they authored is owned by AIST. > All of contributions are recorded in github and there are no other > contributions > that are not listed in github. > > So, I can try to get I-CLA from them, in addition to committer's I-CLA sign, > in the incubation process. I think I can get permissions from them. > > Is I-CLA adequate or e-mail based confirmation is enough? > https://www.apache.org/licenses/icla.txt This doesn't have to be dealt with before entry into the Incubator. All that's required is a *plan* -- and it seems to me that there's enough of a plan to get started. Another detail is that very small contributions may not be copyrightable and thus may not require relicensing. Again, that can be dealt with later. Good luck! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 6:08 AM, Makoto Yui <m...@treasure-data.com> wrote: > Hi Marvin, > > I'm going to answer your two questions. > >> 1) Who were the copyright holders at the time of relicensing? > > At the time of re-licensing, the copyright holder was AIST, > my employer at that time. Looking at the Github history, though, it seems that there were pull requests and issues file by others prior to the Mar 16, 2015 relicensing. Were there any contributions made before then by people not employed by AIST? If everyone worked for AIST, then there is no problem. However, if there were substantial (copyrightable) contributions from people not employed by AIST pre-dating the relicensing, then it will be necessary to contact the copyright holders and secure their permission to license under the ALv2. So long as it is possible to figure out the true origin of all code from the project history, problems of permission can usually be resolved. What's more difficult to resolve is stuff like copy/pasting without attribution, so that code from somewhere else appears to be the work of a different author. (I have no reason to think any such issues exist other than the mild confusion of this thread, which could arise due to many factors including the language barrier or my own misunderstandings.) If you know of anything like that in the project history I'd suggest communicating privately. If not, then no problem. >> 2) How was their permission secured? > > Hivemall was at that time my solo research project at AIST. > I took a permission to change the license to ALv2 from AIST then. > > I did some paper works and I'm still holding it. > Unfortunately, it's written in Japanese. > > They also agreed to move Hivemall to Apache Incubator. Excellent -- it's great that AIST supports open source software! > I'm considering to take Software Grant Agreement sign from them > in the incubation process. That would be appropriate. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Hivemall Incubation Proposal
On Tue, Aug 23, 2016 at 1:22 AM, Makoto Yui <m...@treasure-data.com> wrote: > 2016-08-23 2:20 GMT+09:00 Roman Shaposhnik <r...@apache.org>: >> Two of the areas that I'd like to explicitly solicit IPMC's opinion >> on are: >> >> 1. whether the process of re-licensing from LGPL to ALv2 >> was enough given the ASF's strict IP policies > > The initial release was LGPL v2.1 but I changed the project license > to APL v2 on Mar 16, 2015. > The current codebase does not have dependencies to LGPL. > > I guess there are some other projects migrated from LGPL to ALv2 > before becoming to Apache projects. > > For example, Apache OpenOffice was LGPL in the past release > before joining to Apache. > https://www.openoffice.org/license.html To make a codebase available under an additional license, you need the permission of all copyright holders. While it was overseen by Sun and Oracle, OpenOffice.org required copyright assignment -- so at the time it came to the ASF, Oracle was the sole copyright holder. That gave Oracle the ability to issue the new license unilaterally. If a codebase has multiple copyright holders, you have to track them all down individually and secure permission. If there are any people whose permission cannot be obtained, then their contributions must be excised and replaced, if possible. This has been done for several projects at the ASF, but it's not easy. Two questions present themselves regarding the relicensing of Hivemall. Who were the copyright holders at the time of relicensing? How was their permission secured? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: wiki write access for PhilSorber
On Thu, Aug 11, 2016 at 4:40 PM, Phil Sorber <sor...@apache.org> wrote: > Hi all, can you grant karma to "PhilSorber" to edit the incubator > wiki? Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about some library dependencies.
On Tue, Aug 9, 2016 at 6:47 PM, John D. Ament <johndam...@apache.org> wrote: > This appears to be BSD 3 clause, which is OK. > > https://opensource.org/licenses/BSD-3-Clause > > Best is to check on legal-discuss, as the highlighted section is different: > https://github.com/aparapi/aparapi/blob/master/LICENSE.TXT#L25 Yes, bring this up on legal-discuss or open a LEGAL Jira. We should definitely discuss that extra section -- with the addition, this license is no longer BSD-3-clause. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [Incubator Wiki] Update of "August2016" by Franck Cuny
On Wed, Aug 3, 2016 at 7:41 PM, John D. Ament <johndam...@apache.org> wrote: > Part of me wants to revert this, but there have been other modifications > since. Is there any option here? I'll take care of it. There's no magic way to deal with a mess like this once history piles up after it -- you just revert to the clean revision, then apply the subsequent changesets. It's not conceptually difficult, it just requires high attention to detail. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: wiki.apache.org/incubator write access for EricCovener
On Wed, Aug 3, 2016 at 2:07 PM, Eric Covener <cove...@gmail.com> wrote: > Hi all, can you grant karma to "EricCovener" to edit the incubator > wiki for the podling report? Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: On Fluo (was Re: [CANCEL][VOTE] Fluo Parent POM 1-incubating (rc2))
On Tue, Aug 2, 2016 at 12:57 PM, Josh Elser <els...@apache.org> wrote: > - I think there is a very fair point brought up by Craig/Justin/John at > the gray line between "Apache Fluo" and "fluo.io". However, I will say > that I do *not* think this is remotely close to the level that we've > seen in other TLPs as of late (will avoid explicit finger-pointing). > That said, I think the outcome that the PPMC has came to on their own as > next steps is healthy (see dev@fluo list). I also plan to address why > some of these software tools which were developed in tandem with Fluo > (pre-Apache) were not included with the original incubation proposal (I > hadn't realized they were listed on the website as they were). I would > venture most are unintentional omissions as the website came verbatim > from pre-Apache fluo. The podling has already been responsive to my > nit-picks on ASF and Incubator branding requests that I put forth to > them. One of the things we're most concerned about with usage of our trademarks is project independence. Apache projects are governed by their individual contributors. There must not be another entity which exerts undue influence over an Apache project, and an Apache project must not unduly advantage a single commercial entity. https://community.apache.org/projectIndependence.html We learned a lot from the experience of Couchbase. Originally Couchbase (née CouchOne) was a great friend of Apache CouchDB, employing several people who made important contributions. However, it later split away and became a competitor -- and by then it was too late to protest their use of "Couch*". To this day, there remains confusion in the marketplace between CouchDB and Couchbase. The damage to the Apache CouchDB community has been severe and ongoing. http://s.apache.org/wHU 2. You need to apply branding rules consistently. We allowed Couchbase (and others) to share our brand because they were seen as "friendly" to the community. (And indeed, for many years, they were hugely beneficial for the project.) Unfortunately, that sets precedent. And it's hard to rewind precedent. It also leaves you vulnerable to the possibility that they won't always be "friendly". At which point, you're gonna be SOL. In response to Couchbase and several other similarly traumatic incidents, today we work harder to review trademark usage and protect our communities. Perhaps this helps the Fluo podling to understand why fluo.io is receiving such attention. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Eric Covener joins the Incubator PMC
Greets, Apache Member Eric Covener has joined the Incubator PMC. Eric is currently the PMC Chair of the original Apache project, the Apache HTTPD server. He is also a PMC member for the Apache Portable Runtime and OpenWebBeans projects. Welcome, Eric! Marvin Humphrey, on behalf of the IPMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: IPMC release vote checklist
On Fri, Jul 1, 2016 at 3:13 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > On Fri, Jul 1, 2016 at 3:07 PM, Joe Witt <joe.w...@gmail.com> wrote: >> Is this what you're looking for >> >>http://incubator.apache.org/guides/releasemanagement.html#check-list > > That's the MPV check list ;-) but I thought we had a much more expanded one > on a wiki some place. It is totally possible, thought, that I'm > confusing it with > a release checklist of one of the TLPs I've seen. Hence the question. That list is the right one. It is short because anything that wasn't blocking or wasn't actually policy was ruthlessly purged while the list was being assembled. If you look at the bottom of that link, you'll see a list to the wiki page with items that didn't make the cut. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Incubator Logo & Branding
On Fri, Jul 1, 2016 at 7:06 PM, John D. Ament <johndam...@apache.org> wrote: > As a follow up to the current discussions happening, I wanted to get > opinions from the IPMC on whether or not the Incubator logo should be > included in podling websites. Here's how I would summarize the spirit of the policy: 1. It should be apparent to a typical consumer that a podling is "incubating". 2. It should be reasonably easy to figure out what "incubating" means. It's my hope that any guidelines we adopt can uphold the spirit without getting lost in overly specific details. I do think that including that including the Incubator logo is helpful. However, when the logo is buried at the bottom of a long page, it does not contribute very much. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Notes on branding
On Fri, Jul 1, 2016 at 9:35 AM, Greg Chase <g...@gregchase.com> wrote: > The branding guidelines do not address feedback such as "logo in footer" or > "disclaimer is buried deep or below the fold". Incubation disclaimers are intended to be substantive. They are not CYA legal boilerplate that can be are buried in fine print. The intent is to communicate (effectively!) to consumers that a project is incubating. That way, people will know that certain caveats apply: Apache Foo is an effort undergoing incubation at The Apache Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. What would be best is if podlings just understood that intent, and as and took it upon themselves to ensure that their incubating status was communicated effectively -- in websites, in release announcements, etc. It should be apparent to anyone who groks that intent that websites where the disclaimers and logos are buried subvert the branding guidelines. It seems that we will have to spell things out more aggressively. The new language should make it plain that podlings are expected to uphold the *spirit* of the guidelines, and not treat them as some bs technicality to work around. If podlings don't like the disclaimers, they can hurry up and do the work to graduate. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] $podling.apache.org is the same as $podling.incubator.apache.org
On Wed, Jun 29, 2016 at 6:17 AM, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > >> The presence of the word "incubator" in the URL is deliberate: it alerts >> users >> that a podling is incubating. I'd feel better about this proposal if >> podlings >> weren't so successful about concealing their incubation status[1][2]. >> >> -0, since the Incubator remains unserious about incubation disclaimers on >> websites. > > Perhaps a solution to this it's a require poddlings to be serous about this > when they make a release? i.e. vote -1 if the incubating disclaimer is not > clear on a poddling site. > > (And I would be willing to vote that way on releases if this vote passes) Well, I hate that solution because it counts on you playing Bad Cop, Justin. Other people need to do their part. We have lots of people voting to remove the controls and only a handful stepping up to address the underlying issues that the controls were meant to address. An even worse example than Eagle: after 6 months in incubation, Impala still has no website at impala.apache.org / impala.incubator.apache.org and the existing site at impala.io encourages people to buy support from a specific vendor! http://impala.io/ Retain Freedom from Lock-in Impala is open source (Apache License), so you can self-support in perpetuity if you wish. However, technical support for those who want it is available via a Cloudera Enterprise subscription. This situation is more dire than I thought. I'm changing my vote to -1 binding. We need more confidence that we can actually count on human oversight to address branding issues before removing the automatic controls. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] $podling.apache.org is the same as $podling.incubator.apache.org
On Tue, Jun 28, 2016 at 8:01 PM, John D. Ament <johndam...@apache.org> wrote: > Marvin had sent out an audit of podlings out of alignment, we should double > check that as going through quarterly reports. This vote makes me cranky. Everyone is focused on making it easier for podlings. Is the goal of incubation to pass a graduation vote or to learn? The presence of the word "incubator" in the URL is deliberate: it alerts users that a podling is incubating. I'd feel better about this proposal if podlings weren't so successful about concealing their incubation status[1][2]. -0, since the Incubator remains unserious about incubation disclaimers on websites. Marvin Humphrey [1] See for example the current http://eagle.incubator.apache.org/ where you have to scroll waay down before finding the incubator logo and the small-type incubation disclaimers buried in the footer. [2] The earlier audit: http://markmail.org/message/cqmmfuphhx2z6n23 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Worked LICENSE and NOTICE example
On Wed, Jun 22, 2016 at 11:49 PM, Justin Mclean <jus...@classsoftware.com> wrote: Justin, thank you so much for pushing forward with this! > I could make an example with Category B licenses (weak copy left) > as I’ve not covered that yet. This gets tricky because something in category B won't be in the source release, and thus should not be in the standard LICENSE/NOTICE. We'd need to pick a strategy for adding it later, such as maintaining a separate LICENSE.binary/NOTICE.binary files or a build tool which assembles a new LICENSE/NOTICE as part of the compilation process. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Beam, version 0.1.0-incubating
On Mon, Jun 13, 2016 at 11:37 AM, Julian Hyde <jh...@apache.org> wrote: > 2. It’s customary (required?) for there to be a KEYS file in > https://dist.apache.org/repos/dist/dev/incubator/beam/ > <https://dist.apache.org/repos/dist/dev/incubator/beam/>. Maybe include it > next release? The KEYS file is required, by Release Distribution Policy. http://www.apache.org/dev/release-distribution#sigs-and-sums Projects MUST publish a "KEYS" file in their distribution directory which contains all public keys used to sign artifacts. Signing keys used at Apache MUST be published in the KEYS file and SHOULD be made available through the global public keyserver network. [...] Since the KEYS file is not part of the artifacts being voted on, there's no reason to wait to resolve this issue by committing the keys file to the following location: https://dist.apache.org/repos/dist/release/incubator/beam/KEYS > But I imported > https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS > <https://github.com/apache/incubator-beam/blob/v0.1.0-incubating-RC3/KEYS> > easily enough. Bundling PGP keys inside a package is worse than worthless -- an attacker can just bundle spoofed keys with a bogus distro! Keys need to be made available from a highly reliable, separate server: Download the main package from a mirror, get PGP keys from apache.org, pgp.mit.edu, etc. and verify. The KEYS file within the Beam source tree should be deleted. (This doesn't block the release.) Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Looking for mentors
On Thu, Jun 9, 2016 at 12:01 AM, Sergio Fernández <wik...@apache.org> wrote: > (Off-topic) At some point we may need to discuss our incubation capacity... > People present cool proposal and they get vote just because that, without > checking our available resources. Incubation capacity is limited by total Mentoring capacity across all podlings, and by our ability to cover central administration. With regards to central administration, even at ~55 podlings, we are still mostly managing to cover what's needed: * Spare release voting capacity (Justin Mclean, John Ament) * Report preparation (John, Marvin) * Followup after troubled podlings (John) * Administrivia (John, Marvin, Ted, Nick Burch) * Mediation (Ted, Marvin, others) * Relief Mentors (...) Happily, responsibility is more spread out than it used to be -- Jukka was the first line of defense for nearly all of those when he was Chair. We are heavily dependent on both John and Justin and would struggle to replace their contributions, but for the moment we are holding -- with the one weakness being that when a podling needs relief Mentors there are few to be had. Total Mentoring capacity is hard to assess. We keep adding awesome new IPMC members, and sometimes new podlings will persuade high-quality inactive IPMC Members to return to active duty. But we do appear to be getting more stretched as strong proposals keep pouring in. In recent times, the Incubator has not been voting to accept podlings that have an inadequate *number* of Mentors. However, we have for many years had podlings where several of the Mentors do not do much beyond lend their name to the proposal. Overstretched mentoring has always been a concern, but I think it is becoming a bit more of a concern now as podlings struggle more to recruit Mentors -- perhaps tempting already overcommitted Mentors to strech even further, or necessitating the recruitment of rookies from the ASF Membership with no Incubator experience. As a mitigation, I think we should be paying a little more attention to the Mentor roster in new proposals. One simple report would tell us a lot -- just list all the podlings that each proposed Mentor is already signed up for. If there are concerns that any of the proposed Mentors are overcommitted, it would be appropriate to raise them on private@incubator. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[FINAL DRAFT] Incubator PMC Board Report - June 2016 -- feedback
can work with the community to get a sense how important it is in > addition to growing a community (all 3 goals in this report). +1 to this excellent comment of Roman's on the Quickstep report. "Release early, release often" is a technique for acquiring early adopters! > > Taverna > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be > aware of? > > ASF guidance on US export ECCN cryptography registration > https://www.apache.org/dev/crypto.html > has not yet been updated for the 2010 rule changes, confusion > around this classification caused Taverna delays. Thanks, noted that ECCN is causing difficulties for Taverna. ECCN is tough -- it's one of the hardest issues to get volunteers to work on. > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be > aware of? > > TOREE-262 - Progress on removal of LGPL dependency I've looked at https://issues.apache.org/jira/browse/TOREE-262 but I don't see an action item for either the IPMC or the Board. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Joe Witt joins the Incubator PMC
Greets, I'm pleased to announce that Apache Member Joe Witt has joined the Incubator PMC! Joe is a core contributor to Apache NiFi, and is currently the project's PMC Chair. Joe knows the Incubator from NiFi's trip through it -- we look forward to him returning to contribute as a member of the IPMC! Marvin Humphrey, on behalf of the IPMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Wiki Access For Proposal Creation
On Sun, Jun 5, 2016 at 5:14 AM, Ellison Anne Williams <eawilli...@sovereign-group.net> wrote: > I would like to request access to the wiki in order to create a proposal; > my username is 'eawilliams'. It looks like this has been taken care of. Happy wikifying! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Voting new PPMC members - initial vote thread required?
On Sun, Jun 5, 2016 at 6:37 PM, P. Taylor Goetz <ptgo...@gmail.com> wrote: > IMO as long as that second email is private, then we could probably drop the > requirement for the first notification. +1 to drop one or the other. I would argue to drop the second instead and only send the email notifying the IPMC that a VOTE is taking place, because that saves 3 days. This is still parallel to the Board procedure, in that when a PMC Chair sends a [NOTICE] email to the Board, they are not required to include a link to the [VOTE] result -- that's a requirement which applies to other PMC Members, but not the Chair. Thus a Chair can send a [NOTICE] to the Board before the election completes. The parallel isn't perfect, but it's never going to be because PPMCs don't have Chairs. So I'd opt for convenience and expediency in this case. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: SVN Change?
On Sat, Jun 4, 2016 at 8:13 AM, John D. Ament <johndam...@apache.org> wrote: > On Sat, Jun 4, 2016 at 11:02 AM Marvin Humphrey <mar...@rectangular.com> > wrote: > >> On Sat, Jun 4, 2016 at 7:21 AM, John D. Ament <johndam...@apache.org> >> wrote: >> > All, >> > >> > Did anyone change something recently in SVN? I pulled this morning and >> got >> > back a larger than expected amount of content. It seems like the whole >> > site tree's been duplicated. >> >> http://svn.apache.org/viewvc?view=revision=1746519 >> >> > :-( > > Any thoughts on how to fix this? Is it just a matter of deleting a > directory tree? Yeah, it's just `svn rm FULL_URL`. I took care of it. Please folks: always preview before you commit. With Subversion, that's `svn diff`. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: SVN Change?
On Sat, Jun 4, 2016 at 7:21 AM, John D. Ament <johndam...@apache.org> wrote: > All, > > Did anyone change something recently in SVN? I pulled this morning and got > back a larger than expected amount of content. It seems like the whole > site tree's been duplicated. http://svn.apache.org/viewvc?view=revision=1746519 Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Lack of karma to manage LDAP groups as a mentor impediment
On Thu, Jun 2, 2016 at 10:04 AM, Josh Elser <els...@apache.org> wrote: > I'm a little frustrated as this has just hit me across three different > podlings in the past two days. Because I'm not a PMC chair, I don't have the > ability to actually modify LDAP groups to grant the necessary karma to > podling members to commit, access Jenkins, etc (e.g. modify_appgroups.pl) > > I'm not sure where to start with making this better, but I'm happy to engage > whoever necessary to try to make sure that all mentors have the ability to > help their podlings. This typically comes up only for a minority of committers: * People who became committers on another Apache TLP before becoming a committer on an Incubator podling (as opposed to people who join the Incubator first and are thus already in the `incubator` ldap group after Secretary processes their ICLA.) * People who need to access Jenkins and thus need `modify_appgroups.pl` run. The stopgap is that we have a number of PMC Chairs on the IPMC, and if you send a request to private@incubator someone can take care of it for you. The volume so far has been manageable. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Number of projects in Incubation [was: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1]
On Fri, May 27, 2016 at 6:10 PM, Sterling Hughes <sterl...@apache.org> wrote: > I just want to clarify here on the thread —- while I think in general there > may be problems with too many podlings/inactive mentors, that is not an > issue we often face. Justin Mclean has voted on so many releases over the last several years, he is the HERO of the Incubator. Justin should never buy his own beer at ApacheCon ever again! How many podlings owe their timely releases to Justin? How many Mentors who have failed to vote on releases has he rescued? So Justin was busy this one time. So what. As Sterling says above, this is not a trend. Justin, Greg Stein, and Sterling have all been extremely active, and all four Mynewt Mentors have voted on previous releases. If you're looking at Mynewt and seeing the Incubator burning down, that says more about your perspective than it does about either Mynewt or the state of the Incubator. Here's a suggestion: When the next Mynewt release candidate hits, if Justin is still busy, how about some of the people who owe him big-time help him out? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] CarbonData incubation proposal
On Sun, May 22, 2016 at 10:57 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Luke, > > I fully agree with you. The committers are already involved to clean-up the > repo (PRs have been created). > > IMHO, this step is decoupled from the proposal vote itself: the only > requirement is to do it for the code donation, after the proposal vote. What will the process for this be? On this thread we have two outside authors recognizing their own work, but that's obviously not a realistic mechanism for identifying all potentially problematic IP. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Grant write access to the Incubator Wiki for VictorDogaru
On Tue, May 3, 2016 at 10:57 AM, Victor Dogaru <vdog...@gmail.com> wrote: > Can you please grant write access to https://wiki.apache.org/incubator for > id VictorDogaru? Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Final draft of the Incubator Board Report - April 2016
ASF-style collaboration and governance. What we are asking of iota is not an easy task and I don't envy them. > > Quarks > How has the community developed since the last report? > > The Quarks community is keeping dev-related conversations on the mailing > list. Because of this, it's allowed for the participation of independent > contributors in mailing list discussions. Although our list of independent > contributors is small, Quarks is still very new as an Apache project and > we aim to actively grow our list in the near future. Nice -- it's good that Quarks understands the direction to head in. > > Rya > How has the community developed since the last report? > >* We have a Rya "office hour" teleconference every other week. We had > some technical difficulties with screen sharing, but we had a working > solution for the last meeting. Users and developers can ask questions, > receive answers, discuss ideas for future developments. The minutes are > sent to the dev@ list. >* We have more PRs from non-committers which are integrated into the > repository. We expect some of these non-committers to continue to > submit PRs and become committers. >* There were several ideas from Rya for Google Summer of Code, and a few > students expressed interest; one of them submitted a proposal Another very nice community development section. Thanks, Rya! > > Sirona > > Monitoring Solution. > > Sirona has been incubating since 2013-10-15. > > Three most important issues to address in the move towards graduation: > > 1. increase the community > 2. do more releases > 3. make the community more active > > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be > aware of? > > No > > How has the community developed since the last report? > > No change but some more user feedbacks. > > How has the project developed since the last report? > > Several fixes have been done and enhancements in instrumentation side. > > Date of last release: > > 2015-11-18 > > When were the last committers or PMC members elected? > > > > Signed-off-by: > > [X](sirona) Olivier Lamy > [ ](sirona) Henri Gomez > [ ](sirona) Jean-Baptiste Onofre > [ ](sirona) Tammo van Lessen > [ ](sirona) Mark Struberg > [X](sirona) Romain Manni-Bucau The reports from Sirona could stand to be a little fuller. Also, the question about last committers / PMC members really ought to be filled in. The Board is very persistent about asking TLPs for that information. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Wiki Access - Podling Mentor
On Mon, Apr 11, 2016 at 6:45 PM, David E. Jones <d...@me.com> wrote: > Thanks John, worked just fine. David, can you please request to join the IPMC on private@incubator? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Final draft of the Incubator Board Report - April 2016
On Mon, Apr 11, 2016 at 6:13 AM, John D. Ament <johndam...@apache.org> wrote: > Got it. If you're having issues with the wiki, I'd be happy to tick your > name for you (since we have email confirmation). I edited the wiki on Upayavira's behalf. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: April 2016 Draft Board Report - Please Review
On Sat, Apr 9, 2016 at 10:21 AM, John D. Ament <johndam...@apache.org> wrote: >> --- Summary of podling reports >> >> * Still getting started at the Incubator >> >> - Gearpump >> - iota >> - Joshua >> - Metron >> - Milagro >> - Mnemonic >> - Quarks >> >> * Not yet ready to graduate >> >> No release: >> >> - Hawq >> - Horn >> - Impala >> - Rya >> - Toree >> >> Community growth: >> >> - Fineract >> - Geode >> - MADlib >> - Ranger >> - Wave >> > > I always struggle with these sections since they're highly subjective. If > anyone feels differently please change it in the wiki or email back with > comments. I don't work hard on these, because it doesn't make that big a difference if the categorizations aren't perfectly apt. If the podling has no release, then they go under "no release" regardless. After that, they get put in "community growth", until there's graduation being discussed or voted on. Every once in a while there will be some sort of crisis where a custom categorization might be justifiable -- e.g. "In crisis" for a podling with no Mentors, or "Considering retirement" when retirement is actively being discussed (by the *PPMC*, because outside naysaying is harmful) -- but such states are uncommon. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Wiki Access - Podling Mentor
On Mon, Apr 11, 2016 at 5:25 PM, John D. Ament <johndam...@apache.org> wrote: > David, > > Please give it a shot in a minute or two (moin moin is slow slow) Those changes are visible and committed almost immediately. What takes a while is the notification scan. Whenever I add a new person to ContributorsGroup I hit "save" then go back to the email client and send the "done" email without waiting. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: wiki access
On Wed, Apr 6, 2016 at 11:20 AM, William Marshall <wcmar...@gmail.com> wrote: > Username: wcmarsha Done, enjoy! > Also, is it standard practice to request write access for each > individual page which needs to be edited? Nah, we only need to whitelist the username once. This is just antispam, not some fine-grained permissions scheme (which we tend to shun at Apache anyway). Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: MX4J dependency in Geode
Hi, I agree with Justin and Bertrand's analysis, but I would also request that you open a LEGAL Jira requesting that the MX4J license be added to the list of approved licenses. MX4J is not only similar to Apache 1.1, but also to the PHP license. http://www.apache.org/legal/resolved#category-a Here's a diff of the text of Apache 1.1 vs. MX4J: https://paste.apache.org/DJgO Marvin Humphrey On Wed, Apr 6, 2016 at 4:50 AM, Justin Mclean <justinmcl...@me.com> wrote: > Hi, > > INAL but this is what I would do: > - Add a pointer (i.e. path to the file) and the copyright owner to the full > text of the license in LICENSE > - Add the notice “This product includes software developed by the MX4J > project ..” mentioned in the MX4J license to the NOTICE file > > (i.e. exactly would you would do with an old Apache license) > > Thanks, > Justin > - > 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: [Incubator Wiki] Update of "April2016" by SwapnilBawaskar
On Tue, Apr 5, 2016 at 6:02 PM, John D. Ament <johndam...@apache.org> wrote: > Swapnii, > > Please correct the edit conflicts. I took the liberty of reverting the changeset with conflicts, because it's easy if you know how but a pain to figure out if you don't. All that's necessary now is to re-add the Geode report. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
New IPMC Uma Gangumalla, Suneel Marthi
Greetings, The Incubator PMC has two new members. Suneel Marthi (smarthi) is the PMC Chair of Apache Mahout and an Apache Member. Uma Gangumalla (umamahesh) serves on the Apache Hadoop and Apache Bookkeeper PMCs and is an Apache Member. Welcome! Marvin Humphrey, on behalf of the Incubator PMC - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Incubator Wiki Access
On Mon, Apr 4, 2016 at 11:00 AM, Lee <evangel...@gmail.com> wrote: > Can I get access to edit the Incubator wiki, too? > > Username: EvangeliaDendramis Done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: April 2016 Report Timeline
On Tue, Mar 29, 2016 at 5:45 PM, John D. Ament <johndam...@apache.org> wrote: > Special note: I ran a new script to generate the podling reminder emails. > I received them all, but not all podlings have. Mentors - if you see > anything from me in your moderation queue please allow it. I checked the archives and it looks like everybody got the reminders except for ODF Toolkit and CMDA. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[LAZY] Simplify Champion role
On Tue, Mar 29, 2016 at 3:54 AM, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > As for the patch I suggest a slightly expanded definition of Champion, > "A Member of the Apache Software Foundation who supports a Candidate's > application for Incubation and acts as a liaison between the incoming > podling and the Incubator in the early stages of incubation". > > Apart from that I agree that the 2012 clarification of the Champion > role does not make sense anymore, due to other (good) changes that > happened in the meantime. Thanks, Bertrand! Here's an updated version of the patch simplifying the Champion role, as discussed in another thread[1]. https://paste.apache.org/KvMQ If no one formally lodges a -1, I will claim lazy consensus after 72 hours and apply. Marvin Humphrey [1] https://s.apache.org/GDhG - 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 Sun, Mar 27, 2016 at 6:42 PM, Justin Mclean <justinmcl...@me.com> 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? The "Clutch Report" provides this sort of analysis. http://incubator.apache.org/clutch.html Column B is "number of days in incubation", helpfully color coded. Column S is "has release". Plus lots of other data. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Release Apache FreeMarker 2.3.24 (incubating)
On Sun, Mar 27, 2016 at 5:48 PM, Justin Mclean <jus...@classsoftware.com> wrote: > From memory it was that they are not automatically transferred (but I could > be wrong). Otherwise podlings could skip voting on the incubator list > altogether if they had 3 +1 votes on the dev list. IMO It’s not exactly hard > for IPMC member to vote in both places to make things clearer. Ah, now I understand where you're coming from. Other IPMC members must be given the opportunity to inspect a release, so the vote on general@incubator cannot be skipped. However, IPMC votes can be "carried over", by tradition, from the podling dev list. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [RESULT][VOTE] Release Apache FreeMarker 2.3.24 (incubating)
On Sun, Mar 27, 2016 at 5:34 PM, Justin Mclean <jus...@classsoftware.com> wrote: > Hi, > > No a big deal (as it passed), but only votes on the incubator list by the > incubator PMC are binding. Hi Justin, There's been a long tradition in the Incubator of "carrying over" IPMC votes from the podling dev list. And let's consider why -- is there really a benefit to having IPMC members cast votes twice, or a drawback to having them not cast a vote which obviously has the same value? Would we ever want to block a release that had 2 IPMC votes on general@incubator and 1 cast only on the podling dev list? I think it makes sense for the Release Manager list the IPMC votes being carried over, because then it is more apparent when a release is lacking IPMC votes. However, that's just a recommendation -- even if they don't do that, the IPMC votes can be counted. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Enable one more PPMC member of MADlib to be able to manage Jenkins builds
Done. `xtang` added to `hudson-jobadmin`. Marvin Humphrey On Thu, Mar 24, 2016 at 5:18 PM, John D. Ament <johndam...@apache.org> wrote: > Technically, any VP on this mailing list can grant such a request if they > feel so empowered. > > John > > On Thu, Mar 24, 2016 at 7:27 PM Roman Shaposhnik <r...@apache.org> wrote: > >> Ted, >> >> seems like INFRA is deferring back to you: >> https://issues.apache.org/jira/browse/INFRA-11540 >> >> Would appreciate you doing it soon. >> >> Thanks, >> Roman. >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Allowed Champions on podlings
On Thu, Mar 24, 2016 at 2:34 PM, John D. Ament <johndam...@apache.org> wrote: > On Thu, Mar 24, 2016 at 5:25 PM Jakob Homan <jgho...@gmail.com> wrote: > >> So, it's been a week with no objections. Craig's concern could also >> be addressed by allowing Officers to join the IPMC in the same way >> that Members can. >> >> I'd like to see this question resolved so that we progress the >> Airflow proposal to a vote with Chris Riccomini as Champion (VP of >> Samza). He'd do an awesome job as champion and we'd like to get >> started with the vote. >> > > Jakob, > > Not sure if your comments are relevant on this thread or the thread w/ > Marvin on it. Basically, with Marvin's incoming change, the champion role > will be clarified as being responsible for only the bootstrap of the > candidate into a vote for acceptance in to the incubator. > > There should be nothing blocking discussion/voting on Airflow based on it. +1 to proceed with the Airflow vote. John's change has been applied, so Chris Riccomini is fine as Champion. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Policy should be simple (was "Allowed Champions on podlings")
On Tue, Mar 22, 2016 at 1:56 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > On Tue, Mar 22, 2016 at 1:18 PM, Julian Hyde <jhyde.apa...@gmail.com> wrote: >> If you want to simplify policy, get rid of the champion. >> Or rather, reduce the champion’s role to nominating a project for incubation. >> Once the project has entered incubation, the champion’s role ends. > > +1000 to the above. With all of my experience getting projects through the > incubation I couldn't find a single instance where a Champion role would > prove to be really valuable ON TOP of active mentor(s). +1, I would be in favor of this. Let's make sure that we consider Julian's proposal separately from John's. The expansion of Champion role dates from 2011-2012, and I think it's fair to characterize the initiative as an attempt to deal with Mentor attrition: https://s.apache.org/XcKn Yes, that's the idea - basically make sure the Champion makes sure the podling is reporting consistently and its mentors are present. Thanks largely to Roman's efforts to get Mentor signoff happening consistently, we've addressed Mentor attrition a different way. 1. Mentors must sign off on podling reports, or the podling report is removed from the monthly Board report. 2. The Report Manager tracks missing podling reports. 3. When a podling has not reported for 2 months in a row, the Mentors are contacted via private@incubator. 4. If no Mentors are available to resolve the issue, then the issue is escalated to a public search for new Mentors. Back when expanding the Champion role was considered, there was stiff resistance to Mentor signoff, so our current approach was not feasible. However, it seems to me that the expanded Champion role is now obsolete and that therefore Julian's proposal is sound. Here is a patch: https://paste.apache.org/Ersh If no one formally lodges a -1, I will claim lazy consensus and apply this patch no sooner than a week from now, after discussion has died down. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Advice on binary NOTICE
On Sun, Mar 20, 2016 at 8:34 PM, Justin Mclean <justinmcl...@me.com> wrote: > It simple I like that. :) As expressed in another thread, I believe simple rules are really helpful for newcomers. > It will also tend to make NOTICE > files larger and that has a flow on effect to downstream projects. This is only one source of NOTICE content. We still need to emphasize leaving out other extraneous material. > Would’t it be better for incubating projects to just ask IPMC or legal for > help when putting together NOTICE files? There are other legal issues which people will still need to ask about; I don't that NOTICE is so interesting that the long and involved conversations we have about it today are especially beneficial. So making it more mechanical is desirable. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Policy should be simple (was "Allowed Champions on podlings")
On Mon, Mar 21, 2016 at 9:57 AM, Craig Russell <craig.russ...@oracle.com> wrote: > There is a sorta technical reason for the Champion to be a member of the PMC > of the sponsor. > > I’d expect the Champion to subscribe to the private@ list and to have > binding votes on podling releases. These both require PMC membership. > > The alternative is to create two different “exceptions” that would allow > Champions to subscribe to private@ and to have binding release votes. These are legitimate concerns that would need to be dealt should such an unlikely scenario arise. However, I don't think we need to carve exceptions into policy here -- other creative solutions are available, like voting the Champion onto the Sponsor PMC. And I'd like to take this opportunity to make a more general point: Policy should be simple. There are many reasons that policy should be simple, and I'm sure others will be happy to weigh in with their own favorites. But for me, this is the most compelling: Complexity harms newcomers. Right now, Apache's rules are so complex that we are all in perpetual violation. You can't even know what all the rules are! In such an environment, success is dependent, not on your own ability, but on securing alliances with powerful insiders who can help you bend or break the rules. This state of affairs is not worthy of our core principles. Particularly since the ASF does not exercise technical control over its projects, what we do here is not really that complicated. Apache, and the Incubator in particular, welcomes newcomers. It should be possible for a newcomers to discover and follow our rules largely through their own efforts. Of course a rejoinder to "Policy should be simple" is "As simple as possible and no simpler". But how close are we to "as simple as possible"? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
