Re: How to handle "module" contributions
Judgement call depending on what you might consider a reasonable size for a minor fix versus an independent work (e.g. new module). The larger the patch the more likely you should consider having the author file some paperwork with Apache to cover the contribution. HTH On Feb 17, 2014, at 7:20 PM, P. Taylor Goetz wrote: > Thanks Ted. > > Regarding contributions, if someone contributes (e.g. A pull request) to a > project with an established license, couldn't that be considered an implicit > grant of rights unless otherwise specified (e.g. License headers)? > > -Taylor > >> On Feb 17, 2014, at 6:19 PM, Ted Dunning wrote: >> >> The basic idea is that you have to have the right to incorporate the code >> and be able to demonstrate that right. >> >> For example #1, you can switch your contributions to ASL2 and be good, but >> you may have problems with the contributions of the others unless the >> contributions are trivial. >> >> For example #2, it is typically necessary to get a specific grant licensing >> the code to Apache. If the corporate entity were to relicense the code >> being donated under ASL2, that would suffice, but a letter indicating >> intent to donate would be nice. >> >> Others may have additional opinions so don't assume my answer is definitive. >> >> >> >> >>> On Mon, Feb 17, 2014 at 3:04 PM, P. Taylor Goetz wrote: >>> >>> My apologies if this has been asked before or is well documented >>> somewhere. If it is I couldn't find it. >>> >>> What is the process for handling "contrib module" code donations from an >>> IP clearance perspective? >>> >>> Example #1 (https://github.com/ptgoetz/storm-jms) >>> An individual (me in this case) wishes to donate code that is licensed >>> under the EPL, and has had a few contributions (no CLAs). Is switching to >>> Apache v2 license and adding license headers all that would be necessary? >>> >>> Example #2 (https://github.com/hmsonline/storm-cassandra) >>> Same story as the previous example, except this time it is a corporate >>> entity. The project has transitioned to the Apache license. >>> >>> In each case, what is necessary to incorporate the code into an incubator >>> project? >>> >>> (Sorry for the double post, I hit send accidentally.) >>> >>> -Taylor > > - > 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: [VOTE] Release Apache Storm 0.9.1-incubating
I would say that is the right approach, and that this vote should continue on. On Feb 15, 2014, at 2:34 PM, P. Taylor Goetz wrote: > Hi Joseph, > > Thank you very much for the clarification. > > After checking the history of the NOTICE file [1], it turns out that those > entries were made by Nathan and a Yahoo! employee. > > (I thought I had added Nathan to the file, but after checking the history, > realized I didn’t, so there is a commit rollback in the history). > > I have reached out to both of them with a request to remove those entries. > > I’m assuming we can continue with the vote without having to start over at > this point? > > Thanks again for your input. > > - Taylor > > On Feb 15, 2014, at 1:07 PM, Joseph Schaefer wrote: > >> It means that unless Nathan Marz and an Yahoo! employee >> added those items to the NOTICE, you can remove them. But >> if they did, than either Nathan Marz or a Y! employee should >> be asked to. >> >> In terms of being a release blocker, I’d say not. If you fix >> this in HEAD that should be sufficient to continue. >> >> On Feb 15, 2014, at 1:02 PM, P. Taylor Goetz wrote: >> >>> With the exception of some JavaScript code [1], all source code files use >>> the Apache v2 license. >>> >>> Prior to entering the incubator, the project used the Eclipse Public >>> License. In the incubator, all source files that did not have a license >>> header already (the JavaScript files mentioned above), were updated with >>> the Apache v2 license header. >>> >>> So from a LICENSE/NOTICE file perspective, where does that put us? >>> >>> -Taylor >>> >>>> On Feb 15, 2014, at 12:10 PM, sebb wrote: >>>> >>>>> On 15 February 2014 16:44, P. Taylor Goetz wrote: >>>>> Hi sebb, >>>>> >>>>> What specifically needs to be done to correct the NOTICE file? >>>>> >>>>> Should the references to Nathan Marz and Yahoo! be removed? >>>> >>>> As I already wrote, this depends on the exact license(s) of the >>>> file(s) involved. >>>> >>>>> Thanks, >>>>> >>>>> Taylor >>>>> >>>>>> On Feb 14, 2014, at 12:44 PM, sebb wrote: >>>>>> >>>>>> If the code has not changed substantially in 2014 then the date can >>>>>> stay as 2013. >>>>>> >>>>>> As to the attribution, that depends on the _exact text_ of the license >>>>>> provided with the files. >>>>>> The license(s) should also be included in the LICENSE file. >>>>>> >>>>>> Note that attributions in the NOTICE file must be passed to downstream >>>>>> consumers so it is important not to include anything that is not >>>>>> required. >>>>>> >>>>>> >>>>>>> On 14 February 2014 17:31, Suresh Srinivas >>>>>>> wrote: >>>>>>> +1 (binding) from me. >>>>>>> >>>>>>> Sebb, can you please answer the question related to the NOTICE file. I >>>>>>> think while it may not be necessary to call out individual or companies >>>>>>> contributing large portions of the code, it should not block this >>>>>>> release >>>>>>> and can be addressed later. >>>>>>> >>>>>>> >>>>>>>> On Thu, Feb 13, 2014 at 7:49 AM, P. Taylor Goetz >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks for the input! >>>>>>>> >>>>>>>> The majority of the codebase was originally developed by Nathan Marz, >>>>>>>> and >>>>>>>> it includes significant contributions from Yahoo!. >>>>>>>> >>>>>>>> The project was originally licensed under the Eclipse Public License, >>>>>>>> but >>>>>>>> has not transitioned to the Apache v2 license. >>>>>>>> >>>>>>>> If putting those attributions in the NOTICE file is not the correct >>>>>>>> thing >>>>>>>> to do, please let me know the right way to handle it. >>>>>>>> >>>>>>>> It was still 2013
Re: [VOTE] Release Apache Storm 0.9.1-incubating
It means that unless Nathan Marz and an Yahoo! employee added those items to the NOTICE, you can remove them. But if they did, than either Nathan Marz or a Y! employee should be asked to. In terms of being a release blocker, I’d say not. If you fix this in HEAD that should be sufficient to continue. On Feb 15, 2014, at 1:02 PM, P. Taylor Goetz wrote: > With the exception of some JavaScript code [1], all source code files use the > Apache v2 license. > > Prior to entering the incubator, the project used the Eclipse Public License. > In the incubator, all source files that did not have a license header already > (the JavaScript files mentioned above), were updated with the Apache v2 > license header. > > So from a LICENSE/NOTICE file perspective, where does that put us? > > -Taylor > >> On Feb 15, 2014, at 12:10 PM, sebb wrote: >> >>> On 15 February 2014 16:44, P. Taylor Goetz wrote: >>> Hi sebb, >>> >>> What specifically needs to be done to correct the NOTICE file? >>> >>> Should the references to Nathan Marz and Yahoo! be removed? >> >> As I already wrote, this depends on the exact license(s) of the >> file(s) involved. >> >>> Thanks, >>> >>> Taylor >>> On Feb 14, 2014, at 12:44 PM, sebb wrote: If the code has not changed substantially in 2014 then the date can stay as 2013. As to the attribution, that depends on the _exact text_ of the license provided with the files. The license(s) should also be included in the LICENSE file. Note that attributions in the NOTICE file must be passed to downstream consumers so it is important not to include anything that is not required. > On 14 February 2014 17:31, Suresh Srinivas wrote: > +1 (binding) from me. > > Sebb, can you please answer the question related to the NOTICE file. I > think while it may not be necessary to call out individual or companies > contributing large portions of the code, it should not block this release > and can be addressed later. > > >> On Thu, Feb 13, 2014 at 7:49 AM, P. Taylor Goetz >> wrote: >> >> Thanks for the input! >> >> The majority of the codebase was originally developed by Nathan Marz, and >> it includes significant contributions from Yahoo!. >> >> The project was originally licensed under the Eclipse Public License, but >> has not transitioned to the Apache v2 license. >> >> If putting those attributions in the NOTICE file is not the correct thing >> to do, please let me know the right way to handle it. >> >> It was still 2013 when I last updated the NOTICE file. I'm not sure if >> that is a blocker for release or not. >> >> - Taylor >> >> On Feb 13, 2014, at 5:59 AM, sebb wrote: >> >> On 13 February 2014 07:00, P. Taylor Goetz wrote: >> >> This is a call for a vote to release Apache Storm (incubating) version >> 0.9.1. This will be the first release of Apache Storm. >> >> A vote was held on the developer mailing list, and passed with 9 +1 votes >> (6 >> binding, 3 non-binding), no 0 votes, and no -1 votes. >> >> Release Vote: >> >> http://mail-archives.apache.org/mod_mbox/incubator-storm-dev/201402.mbox/%3c44c5baad-0fd8-454c-84d7-c8da92442...@gmail.com%3e >> >> Release Vote Result: >> >> http://mail-archives.apache.org/mod_mbox/incubator-storm-dev/201402.mbox/%3c3a207f1c-3b07-4029-93d4-87abeb412...@gmail.com%3e >> >> >> The tag to be voted upon is v0.9.1-incubating: >> >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-storm.git;a=tree;h=ffc7a81bfba60c735dd6801af4f5e8db3812658c;hb=ffc7a81bfba60c735dd6801af4f5e8db3812658c >> >> >> NOTICE file still refers to 2013. >> >> The NOTICE file also references software from >> >> Nathan Marz and Yahoo! >> >> However there are no corresponding licenses in the LICENSE file. >> >> Does the source *contain* software from either of the above? >> If so, where are the license files? >> If not, why are the attributions present in the NOTICE file? >> >> Remember that N&L file entries are only for bits that are actually >> included in the distributiion. >> >> The specific source archive being voted upon can be found here: >> >> >> http://people.apache.org/~ptgoetz/storm/storm-0.9.1-incubating-dist-rc3/apache-storm-0.9.1-incubating-src.tar.gz >> >> Other release files, signatures and digests can be found here: >> >> http://people.apache.org/~ptgoetz/storm/storm-0.9.1-incubating-dist-rc3 >> >> The release artifacts are signed with the key available here: >> >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >> >> The staging repository for this
Re: [VOTE] Release of Apache Allura 1.1.0 incubating
The copyright date is not a showstopper. Sent from my iPhone > On Feb 13, 2014, at 10:34 AM, Dave Brondsema wrote: > > Doh. I've fixed that in git just now. If its a blocker for this release, I > can > go ahead and do new one, but obviously it'd be easier to continue with this > one > if that's acceptable. > > FYI we also got additional +1s on the dev list after I tallied. Jim Jagielski > and Roberto Galoppini. > >> On 2/13/14 5:54 AM, sebb wrote: >> NOTICE file still refers to 2013. >> >>> On 13 February 2014 01:06, Dave Brondsema wrote: >>> Hi everyone, >>> >>> This is a call for a vote on Apache Allura 1.1.0 incubating. This will be >>> our >>> second release in the incubator. Allura is forge software for the >>> development >>> of software projects, including source control systems, issue tracking, >>> discussion, wiki, and other software project management tools. >>> >>> A vote was held on developer mailing list and it passed with 7 +1's, and no >>> -1's or +0's. 1 vote was from an IPMC member (me). >>> >>> Vote thread: >>> http://mail-archives.apache.org/mod_mbox/incubator-allura-dev/201402.mbox/%3C52F15D4C.7060906%40brondsema.net%3E >>> >>> Result thread: >>> http://mail-archives.apache.org/mod_mbox/incubator-allura-dev/201402.mbox/%3C52FBA8A9.502%40brondsema.net%3E >>> >>> Source tarball, signature and checksums are available at: >>> https://dist.apache.org/repos/dist/dev/incubator/allura/ >>> >>> Checksums: >>> MD5:ea72b33323dc8c85ad26d08de4bbc534 >>> SHA1: 170729db7c7b26fc3244293bc0a37989121d3973 >>> SHA512: >>> 24b65e731d2ec5df33ab4959b0edd72ec5fee58ae5ce704b10ef45ecc07259357a645d4989935423a6be7d4f1add8b2512578b9b2133ac5059f6d3c6d7235934 >>> >>> The KEYS file can be found at: >>> http://www.apache.org/dist/incubator/allura/KEYS >>> >>> The release has been signed with key (9BB3CE70): >>> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x56F0526F9BB3CE70 >>> >>> Source corresponding to this release can be found at: >>> Commit: a2bc6726d63298638bacf4d02e697e92aaee0bf4 >>> Tag:asf_release_1.1.0 >>> Browse: >>> https://git-wip-us.apache.org/repos/asf?p=incubator-allura.git;a=shortlog;h=refs/tags/asf_release_1.1.0 >>> >>> The RAT report is available at: >>> https://sourceforge.net/p/allura/pastebin/52f15c143e5e833783530b74 >>> >>> Vote will be open for at least 72 hours: >>> >>> [ ] +1 approve >>> [ ] +0 no opinion >>> [ ] -1 disapprove (and reason why) >>> >>> >>> Thanks! >>> >>> -- >>> Dave Brondsema : d...@brondsema.net >>> http://www.brondsema.net : personal >>> http://www.splike.com : programming >>> <>< >>> >>> - >>> 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 > > > > -- > Dave Brondsema : d...@brondsema.net > http://www.brondsema.net : personal > http://www.splike.com : programming > <>< > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] [VOTE] Graduation of Apache Spark from the Incubator
Chris no offense but all we can do is vote on what you put in front of us. As soon as you realized that that document was a mess the vote should have been cancelled. Right now you have no clear picture of what each vote *means* because the thing we are supposed to be approving is in flux. Right now you have people voting on the subject on moral grounds, eg whether the project deserves to graduate, all mixed in with votes cast on technical objective grounds. The only way to fix this is with a fresh start IMO. Sent from my iPhone > On Feb 9, 2014, at 8:19 PM, "Mattmann, Chris A (3980)" > wrote: > > Hi Sebb, > > -Original Message- > > From: sebb > Reply-To: "general@incubator.apache.org" > Date: Sunday, February 9, 2014 4:39 PM > To: "general@incubator.apache.org" > Subject: Re: [VOTE] Graduation of Apache Spark from the Incubator > >> On 9 February 2014 17:11, Mattmann, Chris A (3980) >> wrote: >>> Thanks Matei and sebb. >>> >>> Starting a new thread and collecting the VOTEs all over again would be >>> time consuming. >> >> So? > > I don't appreciate this tone -- what do you mean "so"? > >> >> Better to than being confusing, as the current thread has become. > > The thread's not confusing to me at all -- The diligence to update > the resolution to the specific Apache IDs has been performed by Matei, > so that work is done. I'll make the typo fix in the pasted board > resolution, > so that will be done too. > >> >> Also it may not be clear whether new votes are intended for the update >> resolution or the old one. >> >> Do the original votes even count for the amended resolution? > > Actually it's quite clear to me and to those who VOTEd, some multiple > times. > If folks have an issue as I mentioned, I've left the VOTE open for quite a > long > bit of time and am closing it tomorrow. That's plenty of time for folks to > amend > their VOTE should they have wanted to. > > Cheers, > Chris > > >>> >>> >>> >>> -Original Message- >>> From: sebb >>> Reply-To: "general@incubator.apache.org" >>> Date: Sunday, February 9, 2014 7:10 AM >>> To: "general@incubator.apache.org" >>> Subject: Re: [VOTE] Graduation of Apache Spark from the Incubator >>> I think it would be better to start a new thread with the updated text. Also, the two scope descriptions are slightly different: "related to fast and flexible large-scale data analysis on clusters." v. "related to efficient cluster management, resource isolation and sharing across distributed applications" I don't know whether that is important or not. > On 8 February 2014 22:46, Matei Zaharia wrote: > Thanks everyone for the votes. Since we now have accounts for > everyone, > I've updated the committer list below to include ASF IDs. Thanks to > INFRA, we also now have both pull request postings and comments on them > forwarded to the our mailing list. > > snip > > WHEREAS, the Board of Directors deems it to be in the best > interests of the Foundation and consistent with the > Foundation's purpose to establish a Project Management > Committee charged with the creation and maintenance of > open-source software, for distribution at no charge to the > public, related to fast and flexible large-scale data analysis > on clusters. > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management > Committee (PMC), to be known as the "Apache Spark Project", be > and hereby is established pursuant to Bylaws of the Foundation; > and be it further > > RESOLVED, that the Apache Spark Project be and hereby is > responsible for the creation and maintenance of software > related to efficient cluster management, resource isolation > and sharing across distributed applications; and be it further > RESOLVED, that the office of "Vice President, Apache Spark" be > and hereby is created, the person holding such office to serve > at the direction of the Board of Directors as the chair of the > Apache Spark Project, and to have primary responsibility for > management of the projects within the scope of responsibility > of the Apache Spark Project; and be it further > RESOLVED, that the persons listed immediately below be and > hereby are appointed to serve as the initial members of the > Apache Spark Project: > > * Mosharaf Chowdhury > * Jason Dai > * Tathagata Das > * Ankur Dave > * Aaron Davidson > * Thomas Dudziak > * Robert Evans > * Thomas Graves > * Andy Konwinski > * Stephen Haberman > * Mark Hamstra > * Shane Huang > * Ryan LeCompte > * Haoyuan Li > * Sean McNamara > * Mridul Muralidharam > * Kay Ousterhout > * Nick Pentreath > * Imran Rashid > * Charles Reiss > * Josh Rosen > * Prashant Sharma >
Re: lost dist changes
We recovered from revision 4134 and the incubator tree was at 4146, which was the highest revision on the live www server checkouts. On Jan 26, 2014, at 7:54 PM, sebb wrote: > It would help to know what was the latest commit in the backup. > > Can then in theory check the commit e-mails to see what occurred > since, and recover any missing files from archive.a.o (presumably) > > On 26 January 2014 23:17, Joseph Schaefer wrote: >> Unfortunately we had to restore dist.apache.org >> from offsite backups and a few commits to the incubator >> tree were lost as a result. Projects are encouraged >> to check out their dist trees and ensure that the >> latest content is available via dist.apache.org and >> releases at www.apache.org/dist/incubator >> >> Thanks. >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
lost dist changes
Unfortunately we had to restore dist.apache.org from offsite backups and a few commits to the incubator tree were lost as a result. Projects are encouraged to check out their dist trees and ensure that the latest content is available via dist.apache.org and releases at www.apache.org/dist/incubator Thanks. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Question about jar files in svn.
No policy says anything about binaries in svn, but if you can't have them in your source package it probably doesn't make much sense to keep them in svn. But really that part is up to the project not the IPMC. Sent from my iPhone > On Dec 18, 2013, at 10:45 PM, Greg Trasuk wrote: > > > Hi all: > > We’re having a discussion over in d...@river.apache.org that was triggered by > the recent discussion here about the Spark podling release. In particular, > http://mail-archives.apache.org/mod_mbox/incubator-general/201312.mbox/%3CCAAS6%3D7iQSKTgNdO-0Qyd3T9--%2B%2BHQFEmhJi7CHoByqvQvp9_bg%40mail.gmail.com%3E > has caused me to start asking questions… > > Since Incubator is a good repository of Apache’s institutional knowledge, I > wonder if someone could point me towards resources that clarify the policy on > dependency jars in releases and in the svn repository. If I understand it > correctly, there shouldn’t (perhaps even must not be) any jar files checked > into subversion or included in a source release. Is that correct? To be > more specific, there doesn’t seem to be any doubt that jars shouldn’t be > included in source release packages, but would it be fair to say that they > should also not be in the svn? > > Thanks in advance, > > Greg Trasuk > PMC Chair, Apache River. > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Spark 0.8.0-incubating (rc4)
The core issue is that what you are currently doing was actually the recommended way of dealing with external dependencies back when maven central didn't exist. We changed course a few years ago based on Roy's complaints about source packages consisting solely of source code. I don't remember precisely when nor do I remember any formal process vote indicating a change which in retrospect might have helped lessen the confusion but it was a foundation wide problem not just an incubator issue. In this situation I'd like to say go ahead and complete the release and just fix this prior to graduation. Sent from my iPhone > On Dec 15, 2013, at 12:24 AM, Patrick Wendell wrote: > > Hey Marvin, > > Is this policy actually written up anywhere (along with best practices > on how to deal with this issue if you indeed have third party > dependencies)? I'm just asking because I don't see an obvious "fix" > for this based on the way Spark is built. > > Second - this issue was not brought to our attention before - and in > particular was not raised during our 0.8.0 major release through the > incubator. Since this (0.8.1) release is a maintenance release, doing > a large change to the build system is not possible. It seems to me a > bit much to ask us to completely re-tool this entire project in order > for a simple maintenance release to pass. Especially since other top > level projects are clearly still employing this practice (not that > they are in-the-right, but just that this is a policy which it seems > is still being shaped). > > We are planning to do our next major release (Spark 0.9.0) while still > under incubation in the next few weeks. Could I propose that we create > a parallel discussion about how we might re-tool or build process with > the aim towards satisfying whatever policy exists in that release? > We'll probably need guidance on that from people at Apache since, > again, there is no documented guidelines about what is allowed and > what isn't. > > - Patrick > >> On Sat, Dec 14, 2013 at 8:20 PM, Marvin Humphrey >> wrote: >> On Sat, Dec 14, 2013 at 3:43 PM, Patrick Wendell wrote: However they both contain binaries, which is not good. Third party jars should *not* be included in SCM nor in source releases. >>> >>> These are not binary artifacts containing our project's code. They are >>> our build tool and immediate dependencies that are not published in >>> maven. I've looked around to find TL projects that also use sbt and >>> they also include the sbt jar in the source release. For instance >>> Apache Kafka does the same thing: >>> >>> https://kafka.apache.org/downloads.html >> >> I appreciate your doing the research, and I understand why you might think >> following Kafka's example is a reasonable approach. However, that binary is >> a >> problem for Kafka. If Kafka's releases were like that when they graduated, >> it's a failure of the Incubator as well. >> >> Please read these messages from ASF Board member Roy Fielding: >> >>http://s.apache.org/roy-binary-deps-0 >>http://s.apache.org/roy-binary-deps-1 >>http://s.apache.org/roy-binary-deps-2 >>http://s.apache.org/roy-binary-deps-3 >> >> This has to be fixed. If some TLP PMCs have not been made aware that binary >> dependencies may not be bundled in source releases, the Incubator must not >> compound the problem by failing to educate current podlings. >> >> Marvin Humphrey >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Enable Release Checklist Experiment
+1 On Dec 13, 2013, at 11:31 PM, Henry Saputra wrote: > So it begins =) > > +1 > > Thanks for leading the effort, Marvin > > - Henry > > > On Fri, Dec 13, 2013 at 12:59 PM, Marvin Humphrey > wrote: >> Greetings, >> >> As the next step in our ongoing efforts to reform the release voting process, >> I propose that we run an experiment allowing the PPMC members of select >> podlings to earn binding votes under limited circumstances by completing a >> release checklist. >> >> For participating podlings, the Incubator's release management guide... >> >>http://incubator.apache.org/guides/releasemanagement.html >> >> ... would be supplanted by the following documents: >> >>http://incubator.apache.org/guides/release_manifest.txt >>http://incubator.apache.org/guides/release.html >> >> The scope of this VOTE is limited to approving the following patch to our >> policy page: >> >>https://paste.apache.org/k4vJ >> >> Here is the patch content minus markup: >> >>2013 Alternate Release Voting Process >> >>Select podlings pre-cleared by a majority vote of the IPMC MAY >> participate in >>an alternate release voting process: >> >>Should a Podling decide it wishes to perform a release, the Podling SHALL >>hold a vote on the Podling's dev list and create a permanently archived >>Release Manifest as described in the Experimental Release Guide. At least >>three +1 votes from PPMC members are required (see the Apache Voting >>Process page). If the majority of PPMC votes is positive, then the >> Podling >>SHALL send a summary of that vote to the Incubator's general list and >>formally request the Incubator PMC approve such a release. >> >>Formal approval requires three binding +1 votes and more positive than >>negative votes. Votes cast by members of the Incubator PMC are always >>binding. For all releases after the first, votes cast by members >> of the PPMC >>are binding if a Mentor approves the Release Manifest. >> >> Please note that the proposed change is both incremental and reversible: >> >> * It is incremental because podlings must be opted in by vote of the IPMC >> to >>participate. >> * It is reversible because once the experiment has run its course the >>policy change can be reverted with zero impact through lazy consensus. >> >> Those who may have questions about the legitimacy of allowing binding votes >> from non-IPMC members should see this post from Roy Fielding: >> >>http://s.apache.org/v7 >> >> Please vote: >> >> [ ] +1 Yes, apply the patch enabling the experiment. >> [ ] -1 No, do not apply the patch enabling the experiment. >> >> This majority VOTE will run for 7 days and will close at 13:00 PST on Friday, >> December 20, 2013. Votes cast by members of the Incubator PMC are binding. >> >> Here is my own +1. >> >> Marvin Humphrey >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: INFRA-6774
Oh snap Daniel nice job with that. I didn’t
even notice that stanza in the config file
before!
On Nov 20, 2013, at 6:30 AM, Daniel Shahaf wrote:
> Joseph Schaefer wrote on Tue, Nov 19, 2013 at 23:18:11 -0500:
>>
>> On Nov 19, 2013, at 10:50 PM, Joseph Schaefer wrote:
>>
>>>
>>> On Nov 19, 2013, at 10:40 PM, Jordan Zimmerman wrote:
>>>
>>>> Can someone please explain to me what I need to do to have
>>>> curator.incubator.apache.org redirect to curator.apache.org?
>>>
>>> You need to create an .htaccess file at the top-level of your tree with the
>>> following contents
>>>
>>> RewriteCond %{HTTP_HOST} curator.incubator.apache.org
>>> RewriteRule (.*) https://curator.apache.org/
>>
>> Sorry, that last part needs an $1 tacked onto the end:
>> https://curator.apache.org/$1
>
> No htaccess is needed, it happens automagically once the TLP dist area
> is created. See vhosts/zzzothers.conf on eos.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
Can I just ask how many people have we encountered who upon being offered IPMC membership turned it down with grounds along these lines? Why do we design policy about the fringes and not the happy, average, well-adjusted individuals we meet daily here who would be honored to help out and act responsibly? On Nov 20, 2013, at 4:28 AM, Bertrand Delacretaz wrote: > Hi, > > On Fri, Nov 8, 2013 at 11:54 AM, Upayavira wrote: >> ...My issue is that granting PMC membership is too big a step for many >> podling members. Going from being newbie podling member, to a part of a >> team responsible for 50+ incubator projects is, with the freedom to >> mentor other podlings, is too big a step for most podling members, and >> will remain scary even if you attempt to restrict 'powers' through >> social convention... > > Assuming that's true, instead of inventing new roles I would suggest > electing those deserving podling committers as Incubator PMC members > *for a limited time*. > > Make them IPMC members for six months or until their podling > graduates, and elect them permanently after that if they're still > around doing good work. Make it clear that they're not really expected > to care for other podlings at this point, but welcome to do so in a > constructive way. > > Not much bad can happen, and if it's the case the IPMC can still kick > out anyone on short notice as a last resort. > > IMO that's the simplest way to empower people without scaring them too > much, without making things much more complicated - you'd just need a > file in svn to keep track of which people have such expiring > memberships. > > -Bertrand > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
Please don’t cry out for something simple, you know what my answer is but you don’t like hearing it. The bottom line is that we need to provide to the board, possibly on a per-podling basis, a list of people we have approved for making binding decisions about release votes. Why you want to tie that into mentoring, personnel voting, etc. makes little sense unless you intend for that list to be self-populating too, in which case I’d agree that PPMC alignment would make the most sense. The ultimate question is that do you want to fiddle around at the ends of the status quo or induce a sea-change into how release voting works in this part of the org? I’d expect support for your position will depend more on this answer than anything else you cook up. On Nov 20, 2013, at 4:13 AM, ant elder wrote: > Its not totally clear to me what that would look like. What would then > be the difference between an "IP Stewards" and what we currently call > "mentor", where would they discuss and vote on adding new "IP > Stewards"? I'm not saying it couldn't be made to work and i guess this > is the sort of thing an experiment would help sort out, but it does > seem like its starting to make things unnecessarily complicated. The > original pTLP approach where the PMC is all the PPMC + some others > providing oversight is easy and simple. If it looks like they're going > off course the ones providing the oversight step in, if necessary with > -1s, if those are ignored the pTLP gets sent back to the Incubator. > > ...ant > > On Tue, Nov 19, 2013 at 10:51 AM, Joseph Schaefer > wrote: >> >> Then lets disambiguate by not referring to the >> “IP Stewards” as being the PPMC. Seems simple >> enough. >> >> On Nov 19, 2013, at 4:34 AM, ant elder wrote: >> >>> The reason it might be dis-empowering is that currently one of the main >>> roles of the PPMC is voting in new committers so if the PPMC is initially >>> just the mentors then the other podling members wont be involved in that. >>> It might still be worth trying the approach as an experiment if a willing >>> podling can be found, but i doubt all new podlings would be very happy with >>> the approach. >>> >>> ...ant >>> >>> >>> >>> On Mon, Nov 18, 2013 at 12:12 PM, Joseph Schaefer >>> wrote: >>> >>>> I don’t see how the situation is any worse >>>> than it is now, where no one on the project >>>> currently has a binding vote on a release. >>>> Going from that to “a few” may seem unfair, >>>> but we have to start somewhere and we need >>>> to keep in mind that this is partly a training >>>> exercise, where we need to see people actually >>>> demonstrate good judgement on policy matters. >>>> >>>> Unfortunately this doesn’t solve the bootstrapping >>>> issue directly with the first release, unless we >>>> use it as a remedy for letting release votes stall. >>>> >>>> >>>> On Nov 18, 2013, at 6:41 AM, Andy Seaborne wrote: >>>> >>>>> On 17/11/13 11:17, Upayavira wrote: >>>>>> >>>>>> >>>>>> On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote: >>>>>>> >>>>>>> >>>>>>> On 11/16/13 8:47 AM, "Upayavira" wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Alex, >>>>>>>> >>>>>>>> I'm not sure I see the difference between a release auditor and an >>>> IPMC >>>>>>>> member. If someone is sufficiently clued up to audit a release, then >>>>>>>> they're surely ready to join the Incubator PMC. Am I missing >>>> something? >>>>>>> To me, there is more responsibility in being on the IPMC, like >>>> reviewing >>>>>>> proposals for new podlings and voting on their graduation and becoming >>>> a >>>>>>> mentor. Personally, that's why I don't want to be on the IPMC, but I >>>>>>> might be willing to help IP audit a podling's release. Just like some >>>>>>> projects don't have all committers on the PMC, a Release Auditor is >>>> just >>>>>>> someone who can do that specific task, and there is no need to vote >>>> them >>>>>>> in
Re: INFRA-6774
Already resolved. A Forbidden response instead
of a failed auth request almost always implies
committing using http.
On Nov 20, 2013, at 12:28 AM, David Crossley wrote:
> Jordan Zimmerman wrote:
>> When I tried to commit the change, I get:
>>
>> svn: E175013: Commit failed (details follow):
>> svn: E175013: Access to '/repos/asf/!svn/me' forbidden
>
> Are you able to commit to other stuff?
> e.g. your podling status page
> or to podlings.xml file.
> You would have had that access while you were in
> the Incubator and should still have it AFAIK.
>
> How are you doing this process?
> e.g. via the CMS
> or via svn checkout on your workstation
> or ...
>
> -David
>
>> On Nov 19, 2013, at 7:49 PM, Jake Farrell wrote:
>>
>>> Please follow the incubation graduation guide
>>> http://incubator.apache.org/guides/graduation.html see the Transferring
>>> resources #3.2 user Websites
>>>
>>> Websites
>>> Transfer the podling website
>>> Load the website into its new home. See infra notes.
>>> Update the incubator/site-publish/.htaccess entry to redirect traffic from
>>> the old URLs to the new. (svn location is
>>> athttp://svn.apache.org/repos/asf/incubator/public/trunk/content/.htaccess)
>>> Delete the podling website from
>>> /www/incubator.apache.org/content/${podling-name} on people.apache.org if
>>> possible. It won't be possible to remove the ${podling-name} directory
>>> (because incubator uses svnpubsub). If the podling also used svnpubsub it
>>> won't be possible to delete the files either. File a JIRA ticket under
>>> INFRA and ask for the remains to be removed.
>>> Post an announcement to user and development lists
>>> When using Maven: update pom.xml for the location of the website, as well
>>> as the place where the site plugin will deploy the web site (when
>>> applicable).
>>>
>>>
>>> -Jake
>>>
>>>
>>>
>>> On Tue, Nov 19, 2013 at 10:40 PM, Jordan Zimmerman
>>> wrote:
>>> Can someone please explain to me what I need to do to have
>>> curator.incubator.apache.org redirect to curator.apache.org?
>>>
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: INFRA-6774
No there’s a difference. Before he was asking what infra was going to do to magically make this happen. That request was denied. Now we have a better question: what can he do himself to make this happen? Here there are some answers to questions that should be addressed in the incubator docs but aren’t, because this particular website graduation is OUTSIDE of the typical incubator.apache.org/foo sub site. Technically this is a non-event by design from infra’s standpoint because once DNS is enabled we have done all we need to do to start serving up the new traffic, other than capture any site source relocations in our svnpubsub config file. All a project like curator needs to do now is add an appropriate .htaccess file to the top-level of their site with the two RewriteCond / RewriteRule directives to move traffic away from their incubator subdomain and to their top-level domain. On Nov 20, 2013, at 12:18 AM, David Crossley wrote: > David Crossley wrote: >> Jordan Zimmerman wrote: >> >>> Can someone please explain to me what I need to do to have >>> curator.incubator.apache.org redirect to curator.apache.org? >> >> You asked this a few hours ago on infrastructure@ and were given >> complete and additional answers by various separate people. >> Now you have more people at infra involved in the same stuff. >> And now expaned to include all of Incubator. >> What is up?. > > Ah, i was answering from the infrastructure@ list. Now i see > additional information about svn access in the Incubator thread. > However, your question above seemed to be a repeat. > > -David > > - > 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: INFRA-6774
On Nov 19, 2013, at 10:50 PM, Joseph Schaefer wrote:
>
> On Nov 19, 2013, at 10:40 PM, Jordan Zimmerman wrote:
>
>> Can someone please explain to me what I need to do to have
>> curator.incubator.apache.org redirect to curator.apache.org?
>
> You need to create an .htaccess file at the top-level of your tree with the
> following contents
>
> RewriteCond %{HTTP_HOST} curator.incubator.apache.org
> RewriteRule (.*) https://curator.apache.org/
Sorry, that last part needs an $1 tacked onto the end:
https://curator.apache.org/$1
>
> HTH. Please if you get this working well go back and document it for others
> to use.
>
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: INFRA-6774
On Nov 19, 2013, at 10:40 PM, Jordan Zimmerman wrote:
> Can someone please explain to me what I need to do to have
> curator.incubator.apache.org redirect to curator.apache.org?
You need to create an .htaccess file at the top-level of your tree with the
following contents
RewriteCond %{HTTP_HOST} curator.incubator.apache.org
RewriteRule (.*) https://curator.apache.org/
HTH. Please if you get this working well go back and document it for others to
use.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
Then lets disambiguate by not referring to the “IP Stewards” as being the PPMC. Seems simple enough. On Nov 19, 2013, at 4:34 AM, ant elder wrote: > The reason it might be dis-empowering is that currently one of the main > roles of the PPMC is voting in new committers so if the PPMC is initially > just the mentors then the other podling members wont be involved in that. > It might still be worth trying the approach as an experiment if a willing > podling can be found, but i doubt all new podlings would be very happy with > the approach. > > ...ant > > > > On Mon, Nov 18, 2013 at 12:12 PM, Joseph Schaefer > wrote: > >> I don’t see how the situation is any worse >> than it is now, where no one on the project >> currently has a binding vote on a release. >> Going from that to “a few” may seem unfair, >> but we have to start somewhere and we need >> to keep in mind that this is partly a training >> exercise, where we need to see people actually >> demonstrate good judgement on policy matters. >> >> Unfortunately this doesn’t solve the bootstrapping >> issue directly with the first release, unless we >> use it as a remedy for letting release votes stall. >> >> >> On Nov 18, 2013, at 6:41 AM, Andy Seaborne wrote: >> >>> On 17/11/13 11:17, Upayavira wrote: >>>> >>>> >>>> On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote: >>>>> >>>>> >>>>> On 11/16/13 8:47 AM, "Upayavira" wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Alex, >>>>>> >>>>>> I'm not sure I see the difference between a release auditor and an >> IPMC >>>>>> member. If someone is sufficiently clued up to audit a release, then >>>>>> they're surely ready to join the Incubator PMC. Am I missing >> something? >>>>> To me, there is more responsibility in being on the IPMC, like >> reviewing >>>>> proposals for new podlings and voting on their graduation and becoming >> a >>>>> mentor. Personally, that's why I don't want to be on the IPMC, but I >>>>> might be willing to help IP audit a podling's release. Just like some >>>>> projects don't have all committers on the PMC, a Release Auditor is >> just >>>>> someone who can do that specific task, and there is no need to vote >> them >>>>> in if they are already on some other TLP PMC because any member of a >> TLP >>>>> PMC supposedly knows how to do release auditing. >>>>> >>>>>> >>>>>> My interest is in a lesser level of involvement, where someone has >> shown >>>>>> merit within their own PPMC and can get a binding vote there, but >>>>>> no-where else. That feels to me like a very useful intermediate step >> to >>>>>> have. >>>>> I agree, except for the no-where else part. If you know how to check a >>>>> RAT report and have an idea of what should be in the NOTICE files, you >>>>> should be able to help out any other podling by reviewing their release >>>>> and casting a binding vote so they can learn how to do that. I'd say >>>>> that >>>>> 3 IPMC members must vote to give a person Release Auditor status if >> they >>>>> are not already on a TLP PMC. Consider this: I am an the Flex PMC but >>>>> not the IPMC, but if I join the PPMC of some new podling, why >> shouldn't I >>>>> be able to cast a binding vote for that podling's releases? >>>> >>>> With a two tier model - with PPMC membership granting voting rights on >>>> podling releases, then a podling would start with just mentors on its >>>> PPMC. If you clearly knew what you were doing, you'd get voted onto the >>>> PPMC pretty quickly, and thus you'd be able to vote on your releases. >>> >>> I am concerned that it would be dis-empowering to the incoming community >> if at least the active and major developers of the podling were not on the >> PPMC at the start. >>> >>> Andy >>> >>>> >>>> Upayavira >>>> >>>> - >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>> >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
I don’t see how the situation is any worse than it is now, where no one on the project currently has a binding vote on a release. Going from that to “a few” may seem unfair, but we have to start somewhere and we need to keep in mind that this is partly a training exercise, where we need to see people actually demonstrate good judgement on policy matters. Unfortunately this doesn’t solve the bootstrapping issue directly with the first release, unless we use it as a remedy for letting release votes stall. On Nov 18, 2013, at 6:41 AM, Andy Seaborne wrote: > On 17/11/13 11:17, Upayavira wrote: >> >> >> On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote: >>> >>> >>> On 11/16/13 8:47 AM, "Upayavira" wrote: >>> Alex, I'm not sure I see the difference between a release auditor and an IPMC member. If someone is sufficiently clued up to audit a release, then they're surely ready to join the Incubator PMC. Am I missing something? >>> To me, there is more responsibility in being on the IPMC, like reviewing >>> proposals for new podlings and voting on their graduation and becoming a >>> mentor. Personally, that's why I don't want to be on the IPMC, but I >>> might be willing to help IP audit a podling's release. Just like some >>> projects don't have all committers on the PMC, a Release Auditor is just >>> someone who can do that specific task, and there is no need to vote them >>> in if they are already on some other TLP PMC because any member of a TLP >>> PMC supposedly knows how to do release auditing. >>> My interest is in a lesser level of involvement, where someone has shown merit within their own PPMC and can get a binding vote there, but no-where else. That feels to me like a very useful intermediate step to have. >>> I agree, except for the no-where else part. If you know how to check a >>> RAT report and have an idea of what should be in the NOTICE files, you >>> should be able to help out any other podling by reviewing their release >>> and casting a binding vote so they can learn how to do that. I'd say >>> that >>> 3 IPMC members must vote to give a person Release Auditor status if they >>> are not already on a TLP PMC. Consider this: I am an the Flex PMC but >>> not the IPMC, but if I join the PPMC of some new podling, why shouldn't I >>> be able to cast a binding vote for that podling's releases? >> >> With a two tier model - with PPMC membership granting voting rights on >> podling releases, then a podling would start with just mentors on its >> PPMC. If you clearly knew what you were doing, you'd get voted onto the >> PPMC pretty quickly, and thus you'd be able to vote on your releases. > > I am concerned that it would be dis-empowering to the incoming community if > at least the active and major developers of the podling were not on the PPMC > at the start. > > Andy > >> >> Upayavira >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Majority vs Lazy Majority
Well I can assure you it’s NOT compulsory at Apache ;-). On Nov 10, 2013, at 3:54 PM, Justin Mclean wrote: > Hi, > >> Every American that has voted for a public office >> knows that winning the majority has nothing to do >> with the total population of potential voters. > Where I'm from voting is compulsory so it has a different meaning. > > 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: Majority vs Lazy Majority
Every American that has voted for a public office knows that winning the majority has nothing to do with the total population of potential voters. Let’s not try to rationalize geekdom’s love affair with special purpose terminology- my own pet peeve is what the java world did to the word distribution. That being said, what harm does it do to add this term to the glossary? It’s already in wide use, and that suggests we should incorporate a common definition on the site if one presents itself. On Nov 9, 2013, at 7:17 AM, Justin Mclean wrote: > Hi, > >> Is there such a concept as "Lazy Majority" ? > Yes many Apache projects define it (eg Ant, Kafka, Hadoop, Pig, Hive and > others ) as does Apache HTTP. [1] > "Lazy majority decides each issue in the release plan." > > Different projects however use different terms, as far as I can see "Lazy > Majority" is used more than " "Majority Approval" but both have the same > rules, ie 3 +1s and more +1's than -1's. > > My guess is that "Lazy Majority" is used because Majority implies more than > 50% of possible voters need to vote. > > Thanks, > Justin > > 1. http://httpd.apache.org/dev/guidelines.html > - > 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: Cultivating Outstanding IP Stewards
No offense folks, but this isn’t exactly new information or has anyone offered an actual PATH to follow to get us out of this mess. Bringing more people into the IPMC can be accomplished by anyone willing to put some names out there for us to consider, but that hasn’t yielded anything so far to help us manage our workload. Talk is cheap in a doocracy, we need an action plan and leadership not more argumentation passing itself off as helpful suggestions. On Nov 10, 2013, at 1:25 PM, Benson Margulies wrote: > On Sun, Nov 10, 2013 at 10:34 AM, Joseph Schaefer > wrote: >> Unlikely to get at least Roy’s approval because release >> votes are expected to be a decision of the full committee, >> not any one member of it. > > +1: Much as some people here as in favor of dismantlement, and others > would like to see some structure in between IPMC membership and > nothing, the legal structure requires a release to be voted by PMC > members. To mangle Pogo: We have met the PMC, and, friends, it is us. > It is the job of the more seasoned IPMC members to provide the > backstop for the folks like Alex. > > > >> >> On Nov 10, 2013, at 10:29 AM, Alan D. Cabrera wrote: >> >>> >>> On Nov 10, 2013, at 1:04 AM, ant elder wrote: >>> >>>> How about simply changing the rules for Incubator releases so that >>>> they don't require at least three binding votes, but instead make it >>>> at least three votes only one of which must be binding. That would >>>> mean there would still be the element of oversight that a mentor vote >>>> gives but avoids all the problems with not having three mentors. I'm >>>> sure the board would grant the Incubator authority to implement that >>>> change. >>> >>> The board has charged us to vet the podlings and their releases. What >>> process is used is up to us. >>> >>> I would prefer a variant of your proposal. The first release needs three >>> mentor/IPMC votes. Subsequent releases only require one mentor/IPMC vote. >>> >>> >>> Regards, >>> Alan >>> >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
Unlikely to get at least Roy’s approval because release votes are expected to be a decision of the full committee, not any one member of it. On Nov 10, 2013, at 10:29 AM, Alan D. Cabrera wrote: > > On Nov 10, 2013, at 1:04 AM, ant elder wrote: > >> How about simply changing the rules for Incubator releases so that >> they don't require at least three binding votes, but instead make it >> at least three votes only one of which must be binding. That would >> mean there would still be the element of oversight that a mentor vote >> gives but avoids all the problems with not having three mentors. I'm >> sure the board would grant the Incubator authority to implement that >> change. > > The board has charged us to vet the podlings and their releases. What > process is used is up to us. > > I would prefer a variant of your proposal. The first release needs three > mentor/IPMC votes. Subsequent releases only require one mentor/IPMC vote. > > > Regards, > Alan > > > - > 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: Cultivating Outstanding IP Stewards
The reason we are reduced to guesswork and posturing about how to fix what ails us is because we haven’t a clue what the core problems with incubation are. All we have are a rash of symptoms: inadequate release voting oversight, inadequate podling community development, etc. It sure would’ve been nice to collect feedback from successful podlings who cause us little or no strife to see what actually distinguishes these problems other than perceived noise levels and our strong desire to quash drama wherever it appears. I’m afraid drama in small doses is a necessary part of how we do business at the ASF, because nobody has time to think long-term unless they are dealing with another newfound crisis to remedy. On Nov 9, 2013, at 3:38 AM, Raphael Bircher wrote: > Hi Marvin > > Am 09.11.13 07:15, schrieb Marvin Humphrey: >> On Fri, Nov 8, 2013 at 2:54 AM, Upayavira wrote: >>> On Fri, Nov 8, 2013, at 08:10 AM, Ross Gardler wrote: IMO the IPMC cannot delegate legal oversight to a sub-committee (for example) unless that sub-committee consisted of members of the IPMC. The reason for this is hat only members of the IPMC are recognized by the board and thus only IPMC members have binding votes. >>> That is what the board has done to date. That is not the only >>> possibility in terms of what the board *could* do, which is much more >>> where my question was leading. >> The issue was brought before the Board earlier this week and they have >> explicitly bounced it back to us. Their rationale is that the problem lies >> within the scope of project governance that the Board has delegated to the >> Incubator PMC. The Board has plenty going on these days; I can understand >> that they don't want to get involved in debates over e.g. the nitty gritty >> details of pTLP design. >> >> So, it's our responsibility to design a solution using only the resources >> currently available to us. If we exercise a little creativity and >> flexibility, I don't think we will find ourselves unduly constrained. >> >>> My issue is that granting PMC membership is too big a step for many >>> podling members. Going from being newbie podling member, to a part of a >>> team responsible for 50+ incubator projects is, with the freedom to >>> mentor other podlings, is too big a step for most podling members, and >>> will remain scary even if you attempt to restrict 'powers' through >>> social convention. >> That sounds unreasonably pessimistic. Historically, when contributors from >> active podlings have been nominated, vetted and successfully voted onto the >> IPMC, things have worked out very well: >> >> Brian Duxbury (Thrift) >> Richard Hirsch (ESME) >> Marvin Humphrey (Lucy) >> Karl Wright (ManifoldCF) >> Dave Fisher (OpenOffice) >> Andrei Savu (Provisionr) >> >> I'm proud to be part of that group. I would like to see it grow -- in my >> view, the Incubator has erred by not recruiting aggressively enough! > Probabily yes, but a step between IPMC and nothing would lower the barrier. > Well, I'm shepherd now, reading the lists etc. But I beleve the incubator > miss samething to show the ability to be a mentor. Maybe something like a > Assistent mentor. The assistent Mentor can be assinged to a podling but have > for exemple not the right to subscribe the private lists. That would > probabily also encourage more. > > Greetings Raphael > > > - > 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: Cultivating Outstanding IP Stewards
No offense Ross but give me a break. While I’m glad to see my initial ideas gain so much traction in the incubator now that people no longer remember where they come from, and even are willing to falsely claim credit for them, but this whole idea of populating the IPMC with ordinary podling participants has been going on for years now under the experiment I started. The typical negative argument against this came from Bill Wrowe who felt that these people were unqualified to be able to cast binding decisions during things like podling graduations, but I have seen no indication that such folks overstep their welcome in real life. In any case the concept has my +1, the harder part is to find a process that will ensure appropriate people actually do get recognized. On Nov 7, 2013, at 4:36 PM, Ross Gardler wrote: > On 7 November 2013 11:20, Ted Dunning wrote: > >> On Thu, Nov 7, 2013 at 11:13 AM, Marvin Humphrey >> wrote: >> >>> The Incubator has a fundamental structural flaw: it lacks a mechanism to >>> reward merit earned by individual podling contributors. Instead, we >> teach >>> people to hate the Incubator by placing their projects at the mercy of >>> Mentors. Our Mentors care, but they don't care enough. They don't care >>> like >>> core developers care. >>> >> >> Nominate these meritorious contributors as IPMC members. >> > > +1 This is exactly what I have been proposing the incubator do for a very > long time. In fact I set the precedent by having two podling committers > voted onto the IPMC as an experiment. > > That experiment proved very successful (both helped with other podlings and > both are now Members of the foundation). > > That successful experiment should become part of the incubation process. > > Ross > > PS and yes I do see the need for me, as a mentor, of Alura to make this > happen. I did discuss the projects strategy with project members a week > ago. Not found the time to follow up yet but I would suggest highlighting > individuals in a negative rather than positive light is not the way to > encourage volunteers to find time - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Too many late reports
The script has options for pulling the svn data out of a local repo, it's just that I don't run the script on a host with such a repo available. I'm however willing to do that if someone is willing to fully automate the process by providing some frontend code for the script that ensures the script will only run on the right Wednesdays of the month. There is some pretty sophisticated date processing in the script right now just to figure out the current date sets, so it should be straightforward to reuse that logic for the purpose of determining which Wednesdays the script should actually run on. Once we have that setting up a cron job on erie will be easy. On Oct 7, 2013, at 12:19 AM, Marvin Humphrey wrote: > On Sun, Oct 6, 2013 at 11:29 AM, Dave Fisher wrote: > >>> Dave Fisher DeviceMap >>> Dave Fisher Spark >> >> Although there are no reports yet. > > On Sun, Oct 6, 2013 at 11:45 AM, Matt Franklin > wrote: > >> Missing the ODF Toolkit report for this month. > > Lots of late or missing reports this month! > > As of the due date last Wednesday, 8 podlings out of 16 had not reported: > > * Chukwa > * DeviceMap > * Helix > * ODF Toolkit > * Ripple > * Samza > * Spark > * Stratos > > Since then, Chukwa and Helix filed their reports late Saturday; Spark filed a > report today -- *after* Dave Fisher had filed his shepherding commentary, > which concludes with the sentence "I'm not sure why they have not reported > yet." > > It's inconvenient to receive podling reports late. Mentors have less time to > sign off and possibly comment; shepherds don't get to take the podling's own > self-examination into account when conducting their reviews. > > Perhaps it would be better if we ask late podlings to file next month instead. > That's what the Board asks TLPs to do when their reports show up too late. > > In the past, the Incubator PMC has not done a good job of following up when > reports are missed entirely, arguably contributing to our losing track of > low-activity podlings and delaying intervention. I've started doing it a bit, > though I've missed at least one (NPanday did not file in August but there was > no followup AFAIK). It might be nice to build a remedy into the reporting run > book -- something like this: > >After filing the report, perform the following steps for each podling >which did not report: > >* Edit podlings.xml to set the "monthly" reporting attribute for the >podling. >* Send a message to the podling's dev list requesting that they >file an out-of-cycle report next month as a makeup. > > One possible contributing factor is that podlings are still not getting a > full week's notice to file their reports. Sure, reporting isn't a huge task, > but when you're new to creating reports it takes much longer. > > The argument that podlings ought to just know these dates and file on time > rather than relying on reminders[1] simply isn't getting the job done. I > think we'd get better results if we expect punctuality from podlings, set a > good example by demonstrating punctuality ourselves, and express lenience by > requesting that a podling report next month rather than by accepting a > report too > late to give it the attention it deserves. > > The problem is that at present the reminders have to be sent out manually[2], > and despite the best of intentions, humans are not ideal replacements for cron > jobs. It's time to ask again: what would it take to get those reminders > firing with unerring reliability three weeks before the Board meeting? Is it > realistic to attempt a patch eliminating the need for an svn password? > > Marvin Humphrey > > [1] http://s.apache.org/PIj > [2] http://s.apache.org/dwM > > - > 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: Apache project bylaws
Really, Greg? Can't you tell you're not using the same language I am, but I'm using the actual documentation? Please see http://www.apache.org/foundation/glossary#ConsensusApproval and see how it jives with what you are saying. Personnel votes are always subject to veto, even committership, when we're talking about the httpd project. On Oct 4, 2013, at 3:47 PM, Greg Stein wrote: > On Oct 3, 2013 12:52 PM, "Joseph Schaefer" wrote: >> ... >> e.g. how to vote properly >> on personnel issues, and that should entirely suffice. Even Greg >> doesn't seem to know what consensus voting means in this context, > > Really, Joe? Why did you throw that in? I know what consensus voting is. I > also know some PMCs allow vetoes when adding new members. That was the > point of my prior email: you are right that committership is done by > consensus across the ASF, but that doesn't strictly hold for PMC > membership. I think Roy phrased it once as "I am allowed to veto/refuse to > work with that person. They are free to copy the codebase and establish a > community of people willing to work with that person." > > Cheers, > -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Apache project bylaws
IMO none of the new glossary entries are worth doing. Procedural votes are votes about bylaws and other rules which you will apply to self-govern, so they deserve an appropriate treatment. "Discouraged from voting" is perhaps too harsh a sentiment, what we want those people to know is their opinion carries no *formal* weight. Procedural votes are really reserved for PMC members, and it really doesn't make sense to comment that other voters sometimes hold binding votes here- that's something bylaws need to address if that sort of thing is desired. Code vetoes, or in fact vetoes of any kind, by default are reserved for PMC members, but again bylaws can change that. HTH On Oct 4, 2013, at 12:55 PM, Alex Harui wrote: > OK, here is my next offering. The patch form is at [1] > > Some notes: > > -This offering has 3 new entries to glossary.html as well. > -I was very tempted to move the Veto sections from Voting.html to Glossary > and merge the Consensus Gauging through Silence section from Voting into > Glossary. > -I am also tempted to remove the empty section about "Procedural Votes or > Opinion Polls" but I know you folks are looking for the minimum set of > changes. > -There are some sentences in Voting I'm not sure are accurate such as: > 1) "and all others are either discouraged from voting" > 2) "procedural votes from developers and committers are sometimes > considered binding..." > 3) "Only votes by PMC members are considered binding on > code-modification issues" > For #3, Can committers who are not PMC members have veto a code change? > > Thanks, > -Alex > [1] https://paste.apache.org/9uhY > > voting.mdtext > > Title: Apache Voting Process > Notice:Licensed to the Apache Software Foundation (ASF) under one > or more contributor license agreements. See the NOTICE file > distributed with this work for additional information > regarding copyright ownership. The ASF licenses this file > to you under the Apache License, Version 2.0 (the > "License"); you may not use this file except in compliance > with the License. You may obtain a copy of the License at > . > http://www.apache.org/licenses/LICENSE-2.0 > . > Unless required by applicable law or agreed to in writing, > software distributed under the License is distributed on an > "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY > KIND, either express or implied. See the License for the > specific language governing permissions and limitations > under the License. > > Because one of the fundamental aspects of accomplishing things within the > Apache framework is doing so by consensus, there obviously needs to be a > way to tell whether it has been reached. This is done by voting. > > There are essentially five types of vote: > > 1. Code modifications (including voting to accept new code donations) > > 1. Package releases > > 1. Approving people (as Committer, PMC Member, PMC Chair) > > 1. Removing people (as Committer or PMC Member) > > 1. Procedural (including approval of project bylaws) > > Votes on procedural issues follow the common format of [majority > approval](glossary.html#MajorityApproval) unless > otherwise stated. That is, if there are more favourable votes than > unfavourable ones, the issue is considered to have passed -- regardless of > the number of votes in each category. (If the number of votes seems too > small to be representative of a community consensus, the issue is typically > not pursued. However, see the description of [lazy > consensus](#LazyConsensus) for a modifying factor.) > > Votes on code modifications follow a different model. In this scenario, a > negative vote constitutes a [veto](#Veto) , which cannot be overridden. > Again, this model may be modified by a [lazy consensus](#LazyConsensus) > declaration when the request for a vote is raised, but the full-stop nature > of a negative vote is unchanged. Under normal (non-lazy consensus) > conditions, the proposal requires three positive votes and no negative ones > in order to pass; if it fails to garner the requisite amount of support, it > doesn't -- and typically is either withdrawn, modified, or simply allowed > to languish as an open issue until someone gets around to removing it. > > Votes on whether a package is ready to be released or not use yet a > different mechanism: are there are least three binding votes in favour of > the release? See more about this [below](#ReleaseVotes). > > Votes on approving people require [consensus > approval](glossary.html#ConsensusApproval) approval. > > Votes on removing people require > [consensus-but-one](glossary.html#ConsensusButOne). > > The voting process for adding people, removing people and procedural > voting may be modified and further refined by project bylaws. If a > project's bylaws do not specify an altern
Re: Apache project bylaws
The definitions are in a glossary somewhere, the more we denormalize the locations of our common understandings the harder it will be to maintain sanity over discussions. Projects don't need to be encouraged to write their own bylaws, most don't bother and that's proper. We don't need to spell every possible decision making process out in detail because they should have experienced the normal processes during incubation under competent mentorship. In other words I agree with Marvin that widespread changes to documents that have been widely referenced are not a good idea, no matter what the board happens to think today. Just clarify the actual issues before us, e.g. how to vote properly on personnel issues, and that should entirely suffice. Even Greg doesn't seem to know what consensus voting means in this context, so there's surely room for improvement. On Oct 3, 2013, at 12:44 PM, Alex Harui wrote: > > > On 10/3/13 8:48 AM, "Joseph Schaefer" wrote: > >> Good Lord man all you need to add is a one-sentence >> statement that personnel votes are consensus votes not >> procedural (simple majority) votes. > Hmm. Maybe I'm reaching too far, but my hope was to put in this document a > definition of consensus and a set of defaults for by-laws so that other > new projects don't have as much if any work to do in defining their > project-specific by-laws. > > -Alex > > > - > 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: Apache project bylaws
Good Lord man all you need to add is a one-sentence statement that personnel votes are consensus votes not procedural (simple majority) votes. On Oct 3, 2013, at 11:40 AM, Alex Harui wrote: > > > On 10/3/13 6:23 AM, "Marvin Humphrey" wrote: > >> On Thu, Oct 3, 2013 at 12:09 AM, Alex Harui wrote: >>> On 10/2/13 12:58 PM, "Marvin Humphrey" wrote: >> Rather than a "rewrite", I suggest proposing small, incremental, reversible changes. Governance is easy to mess up. >>> >>> Well, "small, incremental" was hard to do given the significantly >>> different information this document must now convey. >> >> I appreciate the labor you've put in, but what we have here is akin to a >> big patch on highly sensitive mission-critical code for which there are no >> tests. I hope we can find a less costly way to integrate your efforts. > It is a big patch for sure, but I'm not sure I agree with equating it to > code. It is probably always going to be "just words" and I'm not sure you > can create tests. I think even laws don't have tests, they only have to > survive the reviews of the approvers and are always subject to revision > later. But hopefully the reviewers will think through whether the things > they thought were "right" about the old version are retained and whether > the things that were "wrong" have been removed, and new content appears to > be "right". > >> >>> I tried to keep as >>> much as possible yet incorporate feedback from Doug and Roy. >> >> Even if it was "wrong", people have been quoting from that document, >> referencing it and following its guidance for a long time. I'm quite >> irritated that something "wrong" has persisted for so long and has been >> used >> so many times as the basis for settling disputes. >> >> My take is that if that fundamental a document is "wrong", something is >> dreadfully "wrong" with how hard-won wisdom gets handed down at the ASF. >> >> Let's step back for a moment and reassess what we're trying to accomplish. >> We're starting with a voting document which is apparently "wrong" and >> trying >> to make it quasi-authoritative. But when we're finished turd polishing, >> there >> will still be no boundaries demarcating where the authoritative stuff >> begins >> and ends. >> >> We have this problem with the Incubator website, too. It started off with >> buckets of poorly-thought-through text scooped out of mailing lists and >> dumped >> into version control. Years later, certain portions of it have been >> carefully >> wordsmithed or even negotiated under high heat; as a result, making a >> minor >> change has the potential to obliterate a great deal of other people's hard >> work. But from just looking at the surface, you can't tell what's >> garbage and >> what's crucial. >> >> Personally, I'm not eager to spend a lot of cycles negotiating large >> revisions >> to highly-utilized governance documentation under such a flawed regime. >> I'd >> rather that we limit ourselves to small tweaks, or if we're going to go >> all >> out, draw up a set of default bylaws which will in the future be set off >> from >> other documentation and subject to review-then-commit by some governing >> body >> charged with oversight. > Some good points in there. I know you want to revise the incubator site > and I wish you well on your efforts to do so because I agree it needs it., > However I just want to change this one document, and it shouldn't require > the restructuring of a site, so I want to separate the two efforts, > although maybe this effort will influence yours. > > So how about this: I will go all out and rewrite this one document so it > will demarcate what is authoritative and what isn't. And I will try to > make it clear that the goal of the document is to define a set of default > by-laws. And I will retain the entirety of the old document for > historical reference. To do so, I will insert the rewrite at the > beginning of the document after I get lazy consensus on the following text > which will go at the very beginning. > > This document is under revision. The original can be found here > (#link_to_original_further_down). All decision based on the > original document remain valid and the original document remains >valid until further notice. The text color of the original > document has been changed to (brown) to help delineate the > boundaries of the original content. > > All authoritative sections will be demarcated with: > > --this section is authoritative-- > > And end with: > > --end of authoritative section-- > > My understanding is that only the code-modification and release voting > approval type is authoritative. Please correct me if I'm wrong. > > >> >>> Below is my >>> proposed version, and below it is the svn diff in case that makes it >>> easier to see what changed. Most of the changes were made at the >>> beginning. >> >> The formatting of the diff is
Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator
Thanks for clearing that up Jim. Now who is going to make peace over all the spilled milk here? Sent from my iPhone > On Sep 25, 2013, at 6:12 AM, Jim Jagielski wrote: > > >> On Sep 25, 2013, at 12:39 AM, Joseph Schaefer wrote: >> >> All things >> considered, would it be better if Sanjiva and colleagues >> ASKED to be included in the proposal instead of just adding >> themselves in an ad hoc fashion? > > Which is exactly what they did. They expressed an interest > and were added when they specifically requested, and > the adding was done by myself as Champion since I > deemed the request "sufficient". > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Usergrid BaaS Stack for Apache Incubator
Honestly the point that keeps getting missed here is that everything we do at Apache proceeds at a notoriously slow pace so people can adjust accordingly. All things considered, would it be better if Sanjiva and colleagues ASKED to be included in the proposal instead of just adding themselves in an ad hoc fashion? In this case, perhaps so, but not because this is settled law, but because there is significant skepticism and doubt that really doesn't belong in a place like Apache. Too much time is being wasted on appearances and lip service is being paid to folks with well-established levels of trust and expertise on how to collaborate and ultimately govern here. 99% of the time attracting the talent of existing committers is a welcome event, even when one of them is a CEO who is pushing a few people along. This is no big deal folks, and shouldn't be treated like one. Competing corps collaborate every day here on a mutually successful basis, and I fully expect that to continue to be the case with this polling no matter what process is used to setup the initial committer list. On Sep 24, 2013, at 11:51 PM, Niranjan Karunanandham wrote: > I was actually looking forward to contributing for this project where ever > possible but I think people have misunderstood our intentions. As requested > by my CEO, I would like to withdraw my committer request. > > > On Wed, Sep 25, 2013 at 7:36 AM, Dulitha Wijewantha wrote: > >> +1 for the Dave Fisher's example. I believe most of the people have >> misunderstood our intentions. We were offering to help the project to grow >> and graduate faster. I am withdrawing my committer request as our CEO asked >> too. But honestly speaking - if you guys are *scared* of the *community* >> and what the *community* is - I don't believe you shouldn't mention the >> below words in the proposal - >> >> *Although we are aware of the strength of the Apache brand, we are >> primarily >> * >> *interested in the transforming power of the Apache Way to help guide* >> *Usergrid towards a more diversified and meritocratic community* >> >> >> In my humble opinion - the above line should not be a part of the proposal >> since the Apache way has always been to gather a community around the >> proposal who have shown interest towards the idea. >> >> Cheers >> >> >> On Wed, Sep 25, 2013 at 5:50 AM, Dave Fisher >> wrote: >> >>> >>> On Sep 24, 2013, at 3:19 PM, Bertrand Delacretaz wrote: >>> On Tue, Sep 24, 2013 at 10:23 PM, Alex Karasulu >>> wrote: > ...So fill the bus with anybody who volunteers? That does not sound > meritocratic It's been like that for a while in the Incubator, people who sign up as initial committers for a podling usually don't have to demonstrate any merit. When the time comes to graduate the podling, it's perfectly fine to ask it to prune its list of committers and PMC members in order to keep only people who have demonstrated their committment during incubation. >>> >>> When OpenOffice.org was brought to the Incubator there was open >>> enrollment. There were over 70 Initial Committers. I had no experience >> with >>> OpenOffice. I did have an understanding of the ASF. I could help and I >> did. >>> It was tough to have such a large list many were OpenOffice.org people >> who >>> never really adapted to the ASF. We had all these people on the PPMC. >> When >>> graduation time came we managed to reduce the PMC to 25. We left the >>> Initial Committers connected. It hasn't really been a problem. >>> >>> My point is that without the Initial Committer free for all I think that >>> AOO would not be as successful as now. >>> >>> Regards, >>> Dave >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >>> >> >> >> -- >> *Dulitha R. Wijewantha** Software Engineer* >> Tel: 94112793140 | Mobile: 94112793140 >> dulit...@gmail.com | http://dulithawijewantha.com >> > > > > -- > *Niranjan Karunanandham* > Senior Software Engineer > M: +94 777 749 661 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: binary release artifacts
Agreed. Convenience binaries have always been distributed on our mirrors. Only the corresponding source tarball requires a vote. Sent from my iPhone On Sep 19, 2013, at 2:40 AM, ant elder wrote: > On Thu, Sep 19, 2013 at 2:18 AM, Marvin Humphrey > wrote: > > >> As Tim and Luciano have already stated, artifacts which were not voted on >> by >> the IPMC cannot continue to be distributed though our channels. > > > Is that actually the case? AIUI the ASF only releases open source code. We > vote on the source packages and call the positive results a release, and > the binary artifacts are just for convenience. Go take a look at the HTTPD > project (which should know what they're doing right?), their release votes > on the dev list only mention the source, but there are binary artifacts > mentioned up on their download page. > > ...ant - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Reporting due dates
Jim added support for premonth notices several months ago. Sent from my iPhone On Aug 8, 2013, at 11:36 AM, Marvin Humphrey wrote: > On Fri, Aug 2, 2013 at 2:39 PM, Joseph Schaefer > wrote: >> I run the script by hand because it requires a password for the svn >> checkouts. >> >> If you need it to run a full week prior to the podling reports due date, >> just ask. > > Thanks, Joe -- I plan to take you up on that. > > For what it's worth -- looking at the code, I had some questions as to whether > or not running the script before the month transitions might cause problems in > terms of either deadline dates or recipient list. I suppose we can just roll > with it if only Incubator podlings might be affected or if you know something > I don't. > > I'll make sure that the wiki is prepared in time. > > Marvin Humphrey > > - > 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: Reporting due dates
I run the script by hand because it requires a password for the svn checkouts. If you need it to run a full week prior to the podling reports due date, just ask. Sent from my iPhone On Aug 2, 2013, at 5:33 PM, Marvin Humphrey wrote: > Greets, > > "Marvin" sent out report reminders earlier today. Here's my proposed timeline > for preparing our August report: > >Wed August 7 -- Podling reports due by end of day >Tue August 13 -- Mentor signoff due by end of day >Tue August 13 -- Shepherd reviews due by end of day >Tue August 13 -- Summary due by end of day >Wed August 14 -- IPMC Chair submits report (on time!) >Wed August 21 -- Board meeting > > Note that this month's schedule differs from the one I laid out for our July > report, primarily because of a mistake I made last month -- I had thought that > "Marvin" gave podlings a week and a half to submit their reports rather than > only five days. This time I'm proposing that we adhere to Marvin's compressed > schedule -- so podling reports are due in less than a week. > > In the future, I would like to send out podling reminders one week earlier. > That way, podlings will get the same amount of time that TLPs get, while still > allowing the IPMC several days for Mentor signoff and Shepherd review before > the Chair submits the report -- on time for a change, instead of a couple days > late as has been the Incubator's bad habit. > > I believe that changing the timing for reminders will require modifications to > the reminders.pl script (a.k.a. "Marvin"), which is tricky because it looks > like it's hard to run without actually sending email. > > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/board_reminders > > What I'm tempted to do is refactor some of the code in reminders.pl into a > handful of modules which can be run in non-production mode, making it > possible to write some tests and make changes with greater confidence. > Although this would be a fair amount of work, it's probably less in the long > run > than making blind, untestable changes to the current monolithic script and > then cleaning up the huge mess when things go wrong (e.g. because every TLP > receives a reminder with the wrong date). > > Thoughts? > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] PodlingBillOfRights
The typical escalation path is either board@ or board-private@ assuming private messages to the chair are ineffective. Most of the time, for most of our projects, this has worked well enough. The real issue for the IPMC boils down to the judgement call of whether the standard escalation procedures are working to everyone's satisfaction, or are we now able to recognize a clear need for an independent, neutral contact point. All I can say is that I've seen this debated in the past while seemingly always failing to capture the core decision that really needs to be made. I trust this time round we'll stay focus on the practical issues and ignore our gut feelings about artificiality or other semantic concerns. When you task someone to serve in this capacity, you don't necessarily wind up in a better place than when you started, because separating the wheat from the chaff in terms of new information gathered requires patience and skill. It's not easy to remain unbiased and objective and it can be emotionally draining and seemingly unrewarding, especially if it becomes a backdoor for leveling misconduct charges against each other. But you have to have faith that there will be an upside to doing the outreach necessary to help us understand our true impact on these podlings. Reasonable people can disagree about the time and the place for an ombudsman, but I hope our willingness to grow and learn affords us some room for having some purposeful faith in where this could lead in our quest to do a better job at this. If this isn't the time or the place, what would be? Sent from my iPhone On Jun 17, 2013, at 1:16 AM, Roman Shaposhnik wrote: > On Sun, Jun 16, 2013 at 7:16 AM, Joe Schaefer wrote: >> Since I realize that most of you can't be >> bothered to look at the wiki page I created ;-), >> I'll go ahead and post the current content >> here for commentary. I hope the bulk of it >> is non-controversial, though some of it may >> not belong on the page... > > In general, I like it very much and I think it should > be prominently displayed on Incubator web someplace. > > One comment thought: >>5. Podlings have the right to express private concerns about anything >> related >> to their incubation to the Incubator Ombudsman , >> who will handle such communications as if they were sent anonymously. > > For as long as there was a talk about Ombudsman the very > idea of something like that in ASF has rubbed me the wrong > way. The best way I can explain it is that it feels very artificial > and asymmetric: suppose you are a committer on project "foo" > and you feel like what's going on in the project is counterproductive > to the ASF's charter. What's your recourse? Why isn't it the > same for the poddling? > > Thanks, > Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Creation of the Incubator Ombudsman
I'll grant you that it is an imperfect analogy, but I have no idea why you continue to make such a fuss about things we've all come to accept about roles and responsibilities of a chair. Nobody is questioning the traditional role you seek for yourself, and you can take comfort in the idea that you were elected in part because of your position on this subject. So just chill out for a moment or two and try to take in the more substantive issue around having someone who is proactively tasked with gathering data about our overall performance as seen through the eyes of our consumers. This isn't an activity past chairs have shown a real willingness to tackle themselves other than to claim the standard open door policy we all make. Alan is right, the IPMC has little more than anecdotal evidence that we are doing the needful and from what I've heard that evidence is mixed. If you agree that this merits some attention, I would be a little disappointed in your delegation skills if you refused on principle to let someone who is not chair actually try. But at least I will know your heart is in the right place :). Sent from my iPhone On Jun 17, 2013, at 12:02 AM, Marvin Humphrey wrote: > On Sat, Jun 15, 2013 at 12:38 PM, Joseph Schaefer > wrote: >> This argument reminds me of the current debate in Congress about whether or >> not military sex offense reporting should remain within the chain of >> command. Proponents argue that it's hard to hold commanders accountable if >> they aren't empowered to act; adversaries say victims are afraid to report >> while retribution remains possible. > > I don't agree with that line of reasoning because the PMC Chair is not > supposed to be the commanding officer of a project. I think it's an abuse of > the position to act that way, and personally, I do not covet that power. To > my mind, the analogy with the military justice system does not apply because > the PMC chair is *only* the ombud, not the commander. > > If others consider that view of the PMC Chair role too idealistic, I guess I > find that disappointing. But maybe it's so tempting to wield the VP title to > further your own agenda that having some percentage of Apache PMC Chairs fail > as ombud is a statistical certainty. > > If the IPMC arrives at a consensus that an independent ombud is necessary, so > be it. Until that time, I consider that role the chair's responsibility as > part of the instruction to "ensure that everyone has a chance to be heard"[1]. > Should the Board pass the resolution appointing me as IPMC Chair on Wednesday, > I think anyone who has read my posts over the years knows that I'd pursue the > task with zeal. > > Marvin Humphrey > > [1] http://www.apache.org/dev/pmc.html#chair > > - > 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: [PROPOSAL] Creation of the Incubator Ombudsman
This argument reminds me of the current debate in Congress about whether or not military sex offense reporting should remain within the chain of command. Proponents argue that it's hard to hold commanders accountable if they aren't empowered to act; adversaries say victims are afraid to report while retribution remains possible. I don't mean to say we have problems of a similar magnitude here, just to recognize the fault lines of this debate are likely to fall along these differences in priorities. Sent from my iPhone On Jun 15, 2013, at 3:23 PM, Marvin Humphrey wrote: > On Sat, Jun 15, 2013 at 8:52 AM, Alan Cabrera wrote: >> Problem: podlings are confused on where to go when there's a problem. >> >> Cause: we seem to collect/handle/organize problems in an ad hoc manner and >> sometimes mentors are the problem. >> >> Solution: we create an elected Incubator Ombudsman. > > This is in fact one of the central responsibilities of any PMC chair at > Apache, including the IPMC chair. > >http://www.apache.org/dev/pmc.html#chair > >Remember that, as in any meeting, the chair is a facilitator and their >role within the PMC is to ensure that everyone has a chance to be heard >and to enable meetings to flow smoothly. There is no concept of "leader" >in the Apache way. > > The title of "Vice President" is misleading, as the chair is much more of an > ombudsman than a decision maker. > > If there is confusion, it may be worthwhile to emphasize the ombudsman aspect > of the chair position. > > Marvin Humphrey > > - > 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: [PROPOSAL] Creation of the Incubator Ombudsman
FWIW I support the proposal, just pointing out why this idea hasn't gained traction over the years. Sent from my iPhone On Jun 15, 2013, at 2:48 PM, "Mattmann, Chris A (398J)" wrote: > +1, the chair is already the Ombudsman. Or should be at least. > No need for duplication and more overhead (and confusion). > > ++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: chris.a.mattm...@nasa.gov > WWW: http://sunset.usc.edu/~mattmann/ > ++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++ > > > > > > > -Original Message- > From: Joseph Schaefer > Reply-To: "general@incubator.apache.org" > Date: Saturday, June 15, 2013 10:52 AM > To: "general@incubator.apache.org" > Subject: Re: [PROPOSAL] Creation of the Incubator Ombudsman > >> This is a suggestion that has come up in the past, and the typical >> counter-argument is that this is something the chair needs to provide >> themselves. >> >> Sent from my iPhone >> >> On Jun 15, 2013, at 1:18 PM, Ross Gardler >> wrote: >> >>> Sent from a mobile device, please excuse mistakes and brevity >>> On 15 Jun 2013 16:53, "Alan Cabrera" wrote: >>>> >>>> >>>> Problem: podlings are confused on where to go when there's a problem. >>>> >>>> Cause: we seem to collect/handle/organize problems in an ad hoc manner >>> and sometimes mentors are the problem. >>>> >>>> Solution: we create an elected Incubator Ombudsman. >>> >>> From now on I'm only going to look at solutions in the context of the >>> issues on the wiki page. If a proposal doesn't apply to one or more >>> issues >>> I'm not interested. >>> >>> In this case... >>> >>> The only problem that would need an ombudsmen is ISSUE 01 (inactive >>> mentors). Mentors should always know where to go to solve a problem (we >>> have specialist committees for pretty much every issue that will >>> arise). If >>> mentors are inactive then ISSUE 01 is in play. >>> >>> The current place to go is the IPMC. At this point ISSUE 03 may well >>> come >>> into play. >>> >>> The idea of an Ombudsman overlaps with my earlier proposal for a >>> psuedo-board in the IPMC. Its also similar to both suggested solutions >>> for >>> ISSUE 03 in the wiki. >>> >>> For these reasons I suggest the Ombudsmen proposal has merit. >>> >>> I also suggest that this ombudsmen could be the organisation responsible >>> for acting if a podling (or a pTLP, if the experiment shows merit in >>> this >>> model) is failing. >>> >>> As always the details needs to be ironed out but since the proposal >>> directly addresses ISSUE 03 I would like to see it explored. I >>> especially >>> like that it complements my pTLP experiment which is designed to address >>> ISSUE 01 (but clearly your proposal is worth exploring even without that >>> potential advantage). >>> >>> Ross >>> >>>> >>>> >>>> Regards, >>>> Alan >>>> >>>> >>>> - >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Creation of the Incubator Ombudsman
This is a suggestion that has come up in the past, and the typical counter-argument is that this is something the chair needs to provide themselves. Sent from my iPhone On Jun 15, 2013, at 1:18 PM, Ross Gardler wrote: > Sent from a mobile device, please excuse mistakes and brevity > On 15 Jun 2013 16:53, "Alan Cabrera" wrote: >> >> >> Problem: podlings are confused on where to go when there's a problem. >> >> Cause: we seem to collect/handle/organize problems in an ad hoc manner > and sometimes mentors are the problem. >> >> Solution: we create an elected Incubator Ombudsman. > > From now on I'm only going to look at solutions in the context of the > issues on the wiki page. If a proposal doesn't apply to one or more issues > I'm not interested. > > In this case... > > The only problem that would need an ombudsmen is ISSUE 01 (inactive > mentors). Mentors should always know where to go to solve a problem (we > have specialist committees for pretty much every issue that will arise). If > mentors are inactive then ISSUE 01 is in play. > > The current place to go is the IPMC. At this point ISSUE 03 may well come > into play. > > The idea of an Ombudsman overlaps with my earlier proposal for a > psuedo-board in the IPMC. Its also similar to both suggested solutions for > ISSUE 03 in the wiki. > > For these reasons I suggest the Ombudsmen proposal has merit. > > I also suggest that this ombudsmen could be the organisation responsible > for acting if a podling (or a pTLP, if the experiment shows merit in this > model) is failing. > > As always the details needs to be ironed out but since the proposal > directly addresses ISSUE 03 I would like to see it explored. I especially > like that it complements my pTLP experiment which is designed to address > ISSUE 01 (but clearly your proposal is worth exploring even without that > potential advantage). > > Ross > >> >> >> Regards, >> Alan >> >> >> - >> 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: [PROPOSAL] Mandatory podling exit interviews
Agreed on the undesirability of making survey participation mandatory. On the wiki page in question I framed it as a right that surveys are available fwiw. Sent from my iPhone On Jun 15, 2013, at 1:18 PM, Ross Gardler wrote: > I'm not keen on this one. I don't like surveys and I don't like mandatory > activities for volunteers. > > However, a pro-active invitation to feedback on experiences at any time > during incubation or shortly after would be good. Even better would be > recruiting more valuable people from podlings as mentors. > > Sent from a mobile device, please excuse mistakes and brevity > On 15 Jun 2013 16:48, "Alan Cabrera" wrote: > >> >> Problem: we seem to have unclear and conflicting ideas as to what the >> areas of improvement are for the Incubator. >> >> Cause: we have no concrete, anonymized, information on what the podlings' >> experiences were during incubation. >> >> Solution: require all podlings to submit anonymous exit interviews as part >> of the graduation requirements. These exit interviews will be suitably >> scrubbed and organized by the Incubator Ombudsman; see next proposal. >> >> >> Regards, >> Alan >> >> >> - >> 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: Unused OpenOffice source tree in incubator: keep or remove?
Yes infra can setup a manual redirect once the tree is gone from the repo. Just ping me when it's time. Sent from my iPhone On Jun 1, 2013, at 11:22 AM, Andrea Pescetti wrote: > On 29/05/2013 Daniel Shahaf wrote: >> On Tue, May 21, 2013 at 09:40:19PM +0200, Andrea Pescetti wrote: >>> Is this the recommended configuration or shall we "svn remove" the whole >>> old tree, maybe leaving only a README.txt pointing to the new location? >> >> Ask infra about arranging a redirect - this might be possible but would have >> to >> be done manually since "ooo" != "openoffice". > > OK, thanks. We will have a look at this once OpenOffice 4.0 is released and > the old trunk will become effectively obsolete. > > Regards, > Andrea. > > - > 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: What's the difference between dormant and retired?
What we really need now is a few hundred more emails on this exciting subject, just like every other year! At the end we can all agree to disagree and go away sad that nothing ever gets done around here, just like every other year we have this interesting debate! Party on I say. Sent from my iPhone On May 29, 2013, at 3:38 PM, "John D. Ament" wrote: > I can't see any place in the docs that describe dormant. > > > On Wed, May 29, 2013 at 3:36 PM, ant elder wrote: > >> I agree with Mark and John, the terms mean different things, and the term >> "retired" is reasonably well understood now and mentioned in various places >> in the Incubator documentation so wouldn't it be better to keep it as is? >> Are there really any dormant poddlings? If so probably they are really >> retired now and they should just be changed to that. >> >> ...ant >> >> On Wed, May 29, 2013 at 6:47 PM, Alan Cabrera >> wrote: >> >>> If no one minds I will change them all to dormant, since all are welcome >>> back to the fold, should they so desire. >>> >>> >>> Regards, >>> Alan >>> >>> On May 27, 2013, at 12:58 PM, Christian Grobmeier >>> wrote: >>> On Mon, May 27, 2013 at 9:17 PM, John D. Ament >> >>> wrote: > I think the terms mean different things, from the incubator >> perspective. > > Dormant - we're not active enough right now for a full community, but > believe later on we can build it back up. > Retired - we've given up all hope of becoming a TLP, instead we think >>> it's > best to archive the code/move it to github/move it to bitbucket and >>> allow > others who want to work on it to just grab it and go. The difference is one goes to github and one does not? After this interpretation I would expect dormant projects to retire. Retired projects can be revived too. It does not matter if there was something on GitHub >>> or not. Not enough for me to maintain two terms. > > Just my 2 cents.. > > > On Mon, May 27, 2013 at 2:10 PM, Christian Grobmeier < >>> grobme...@gmail.com>wrote: > >> On Mon, May 27, 2013 at 7:40 PM, Alan Cabrera >> wrote: >>> Yeah, I like the word dormant as well. Should we rename them all to >> dormant? >> >> +1 from me. So far I don't see any difference in the end. >> >> >> >>> >>> Regards, >>> Alan >>> >>> On May 27, 2013, at 10:32 AM, Upayavira wrote: >>> I think it was just a question of 'retiring' sounding too final. >>> Using the word 'dormant' was less threatening, and made it more feasible >>> for the podlings to go, well, dormant. Upayavira On Mon, May 27, 2013, at 05:39 PM, Alan Cabrera wrote: > They kinda sound the same. Why didn't podlings want to retire? >>> Does > anyone know? > > > Regards, > Alan > > On May 27, 2013, at 9:14 AM, Christian Grobmeier < >>> grobme...@gmail.com> > wrote: > >> I asked the same question in july 2011, and got a response from >>> Henri >> Yandell which I repost here: >> >> "Given the PPMC is closed down, I think it has to be retired. >> >> Dormant implies a PPMC is taking some time off. >> >> Basically this is a larger version of "don't be afraid to delete >> a >> line of code; it's in version control". >> >> Hen" >> >> >> >> >> >> On Mon, May 27, 2013 at 5:38 PM, Alan Cabrera < >> a...@toolazydogs.com >> wrote: >>> Looking at the podlings.xml and it's not clear to me what the >> difference is. I'm sure I neglected to read some documentation bit. >>> >>> >>> Regards, >>> Alan >>> - >>> To unsubscribe, e-mail: >> general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: >>> general-h...@incubator.apache.org >> >> >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de >>> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: >> general-h...@incubator.apache.org >>> - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: >> general-h...@incubator.apache.org >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org >> ---
Re: [META DISCUSS] talking about the overall state of this PMC
I firmly believe our priority in mentoring podlings is to instill self-governance as early as is feasible, and the proven way to accomplish that task is to identify suitable members of the podling and elect them to the IPMC so they are fully empowered to do it. Every other approach is suboptimal. Sent from my iPhone On May 11, 2013, at 1:09 PM, Alan Cabrera wrote: > > On May 11, 2013, at 7:33 AM, Joseph Schaefer wrote: > >> Frankly I find the notion that the board will do a better job of MENTORING >> these projects than the IPMC to be batshit insane, but that's just me. >> We need manpower, and there is plenty of that available amongst the competent >> volunteers who actively participate in these projects. Let's just do >> what's easiest for once and promote these folks to the IPMC in order >> to get the job done right. It's a proven model that we need to stop >> fighting. > > > Yes, shuttling the kids off the the grandparents is not going to solve > anything. If individuals on the board have the bandwidth to help they should > come over here. There's nothing specific about the auspices of the board that > would improve the situation. > > I personally think that we have "almost" enough people to mentor. I think > that the burnout comes from our constant churning of policy and lack of > tooling to make mundane tasks easier. > > For example, maybe > better reminders for reports > automatic nudging of mentors who have not signed reports > dead pilot buttons to detect inactive mentors (Is it called a dead pilot > button) > maybe a standard to podling releases to make vetting easier - i.e. apply > tooling > changes/additions to vetting procedures taking place outside of release > votes. (ok not a tooling issue) > > > Regards, > Alan > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [META DISCUSS] talking about the overall state of this PMC
Frankly I find the notion that the board will do a better job of MENTORING these projects than the IPMC to be batshit insane, but that's just me. We need manpower, and there is plenty of that available amongst the competent volunteers who actively participate in these projects. Let's just do what's easiest for once and promote these folks to the IPMC in order to get the job done right. It's a proven model that we need to stop fighting. On May 11, 2013, at 10:26 AM, ant elder wrote: > Actually I wasn't thinking it would be you Benson who talked to the > board. There are several directors here including a couple on this > thread who've said they support trying this so i thought they could > bring it up informally at the upcoming meeting just to get us an idea > if this is something the board would entertain at all. > > I agree with you that there are a lot of details that would need to be > worked out, but right now it doesn't look like anyone is doing that > work so getting some feedback from the board, even if its just "maybe > but we need more details", could help motivate getting that work done > and coming up with a complete proposal. If the board sounded > interested i'd help getting to that and it sounds like there are a few > others here who would too. > > I also agree that there isn't consensus in the Incubator PMC to do > this, but I'm not sure we need it. If we come up with a process and > proposal that the board is happy with and poddlings to be guinea pigs > then we don't really need a unanimous Incubator PMC vote to go ahead. > And its just an experiment, so its a much more gentle approach than > the other big bang changes being proposed. > > So what does anyone else think, is this worth trying? Greg > specifically, you were keen we try this earlier on in the thread so is > this something you could get us some feedback from the board about? > > ...ant > > On Sat, May 11, 2013 at 1:40 PM, Benson Margulies > wrote: >> >> I'm not going to ask the May board meeting anything. There's no >> consensus of this community on 'probationary projects', and, more to >> the point, there are a host of details required to make that a viable >> proposal and no one has filled them in. As I wrote in the report, I >> plan to have a discussion with the board in June if we aren't making >> progress. >> >> A real experiment with 'probationary projects' would have to model the >> entire process of a new project launching with _no IPMC_ to >> participate in any way. Taking a proposal that has been groomed and >> vetted at the IPMC and then launching the resulting project to the >> board is purely an experiment in board supervision. I'm not going to >> bring the board a proposal to increase their workload based on my >> personal judgement, and there's no consensus here, today, that it's a >> good idea, since there are several people who are eloquently opposed. >> >> My personal thought is this: new project creation is not a 'project', >> it's a function of the Foundation. If the committee currently >> constituted by the board to handle this isn't working well enough, and >> can't agree on what to do, it is an issue for the board to consider. >> The board could decide to keep what we are, arguments and all. It >> could constitute a small (and thus consensus-prone) committee to >> survey the terrain and make a recommendation. It could tell the whiney >> VP to JFDI -- make some decisions and get on with it. (Consensus is >> desirable, but read one of the board resolutions that installs a VP.) >> >> >> On Sat, May 11, 2013 at 2:39 AM, ant elder wrote: >>> On Fri, May 10, 2013 at 5:33 PM, Eric Johnson wrote: If this was a software project, and the appropriate answer was unknown, they you might apply a "lean startup" approach, and figure out how to run tests to see which way works best. Given the number of incubating projects, should be easy to run some experiments. Then you just need to build up some consensus on how to run the experiments. And how to evaluate the results. Essential to establish some metrics that will correlate with success. Then run the experiments for a while (three months, six months?). At the end, you'll have actual data that will inform a decision. Eric. >>> >>> +1 for experimenting with some new approaches. >>> >>> Several people have been in support of the board managed poddlings or >>> probationary TLPs, lets try that. Ask at the board meeting next week >>> if the board would support the experiment and if so just pick half a >>> dozen existing poddlings to try it. >>> >>> ...ant >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> - >> To unsubscribe, e
Re: [META DISCUSS] talking about the overall state of this PMC
You go girl! Spot on. Sent from my iPhone On May 8, 2013, at 12:54 AM, Alan Cabrera wrote: > > On May 7, 2013, at 4:03 AM, Bertrand Delacretaz > wrote: > >> On Tue, May 7, 2013 at 5:45 AM, Alan Cabrera wrote: >>> ...Let's get rid of champions and shepherds and hold the mentors to their >>> responsibilities >> >> The problem with mentors is when you have 5 of them it's unclear who's >> in charge exactly. > > Why does someone need to be in charge? The real problem is that we have five > mentors four, or more, of which do not do the job to which they signed up for. > > All we're doing is shuffling responsibilities around with the hopes that the > next person will be more responsible than the previous one. > >> The goal of the champion's role clarification was to have a single >> point of contact and responsibility for contacts with the incubator >> PMC - similar to a project's PMC chair role. >> >> So basically you have: >> >> A champion, who's a mentor, but also the primary point of contact with >> the IPMC, makes sure reports are done in time and watches the podling >> for lack of mentoring if that happens. >> >> Mentors, who are primarily tasked with coaching the podling. > > I'm hearing Benson's proposal accurately rephrased. > > We're pushing responsibilities which seemed "too much" for three or more > mentors over to a single mentor and diluting the responsibilities into > non-accountable tasks such as coaching. > > What I'm worried about is that were merely shuffling responsibilities around > without really coming to a consensus as to what to do when volunteers don't > do the job they signed up for. Until we have an answer for that we'll > continuously have this conversation every other quarter as we shuffle > responsibilities around again. > > The myth that we seem to be holding dear is that we cannot hold volunteers > accountable for the tasks they signed up for. Maybe if we did hold > volunteers accountable , they would take their responsibilities seriously and > we would have a clearer picture as to what kind of help to expect as we > discuss the IPMCs problems. > > > Regards, > Alan > > > - > 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: Vote on personal matters: majority vote vs consensus
No more so than they already had. Sent from my iPhone On Mar 28, 2013, at 9:56 AM, ant elder wrote: > No what it means Joe is that who chooses the wording of the vote gets > a lot of control the outcome. > > ...ant > > On Thu, Mar 28, 2013 at 1:25 PM, Joseph Schaefer > wrote: >> Waah. Look this just DEFINES consensus as 75% instead >> of the old 100%. It doesn't throw consensus out the window. >> Please stop with all of these exaggerations and try to >> self-moderate- half of the volume in these debates is all >> you talking to yourself. >> >> >> On Mar 28, 2013, at 9:18 AM, ant elder wrote: >> >>> On Thu, Mar 28, 2013 at 12:44 PM, Benson Margulies >>> wrote: >>>> It appears to me that we have a consensus here on using a majority system >>>> with a 3/4 supermajority. I'd like to establish the existence of this >>>> consensus with a minimum of fuss, and begin to stop wasting everyone's >>>> time. Our goal here is to achieve consensus, not to hold votes. So, I'm >>>> going to treat this as a lazy consensus issues. I'm going to watch this >>>> thread for an additional 72 hours. If anyone objects to this consensus, >>>> send along a brief summary of your objection with a -1. If there are, in >>>> fact, substantive objections, I'll organize a separate vote process to >>>> resolve this. Please do not debate objections here, we'll do that later if >>>> we have to. Everyone's had a fair opportunity to state their opinion, so >>>> the only thing we're doing now is ensuring that no one is harboring a >>>> serious objection that I have somehow overlooked. Acquiescing in this >>>> process does not prejudice the discussion of changing the PMC. >>> >>> I'd prefer we stick with consensus but not enough to vote against this. >>> >>> However as no one has mentioned this I do think its worth pointing out >>> that when using supermajority instead of consensus or simple majority >>> then the phrasing of the vote becomes important. >>> >>> Eg. Say 16 people participate in a vote then: >>> "Throw the guy out" needs 5 -1s to stop it happening >>> "Let the guy stay" needs 12 +1s to make it happen. >>> >>> ...ant >>> >>> - >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Vote on personal matters: majority vote vs consensus
Waah. Look this just DEFINES consensus as 75% instead of the old 100%. It doesn't throw consensus out the window. Please stop with all of these exaggerations and try to self-moderate- half of the volume in these debates is all you talking to yourself. On Mar 28, 2013, at 9:18 AM, ant elder wrote: > On Thu, Mar 28, 2013 at 12:44 PM, Benson Margulies > wrote: >> It appears to me that we have a consensus here on using a majority system >> with a 3/4 supermajority. I'd like to establish the existence of this >> consensus with a minimum of fuss, and begin to stop wasting everyone's >> time. Our goal here is to achieve consensus, not to hold votes. So, I'm >> going to treat this as a lazy consensus issues. I'm going to watch this >> thread for an additional 72 hours. If anyone objects to this consensus, >> send along a brief summary of your objection with a -1. If there are, in >> fact, substantive objections, I'll organize a separate vote process to >> resolve this. Please do not debate objections here, we'll do that later if >> we have to. Everyone's had a fair opportunity to state their opinion, so >> the only thing we're doing now is ensuring that no one is harboring a >> serious objection that I have somehow overlooked. Acquiescing in this >> process does not prejudice the discussion of changing the PMC. >> > > I'd prefer we stick with consensus but not enough to vote against this. > > However as no one has mentioned this I do think its worth pointing out > that when using supermajority instead of consensus or simple majority > then the phrasing of the vote becomes important. > > Eg. Say 16 people participate in a vote then: > "Throw the guy out" needs 5 -1s to stop it happening > "Let the guy stay" needs 12 +1s to make it happen. > > ...ant > > - > 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: Vote on personal matters: majority vote vs consensus
This whole exercise is pointless. Just drop the notion of vetoes for all IPMC votes and carry on as before. Sent from my iPhone On Mar 27, 2013, at 6:11 PM, Niall Pemberton wrote: > On Mon, Mar 25, 2013 at 12:12 AM, Roman Shaposhnik wrote: >> On Sat, Mar 23, 2013 at 1:24 PM, Ted Dunning wrote: >>> One alternative to going for full-on majority voting is to recognize that a >>> larger group is much more likely to have "noisy vetoes" by requiring that >>> successful votes have n positive votes and m negative votes subject to some >>> condition on n and m. Majority requires n > m, strict Apache consensus >>> requires n >= 3 and m == 0. It is easy to imagine other conditions such as >>> n >= 4 and m <= 2 which still have some of the flavor of consensus in that >>> a minority can block a decision, but allow forward progress even with >>> constant naysayers or occasional random vetoes. >> >> Personally, I'd suggest keeping these options in our backpocket >> and turning back to considering them in case a simple majority >> proposal runs into an opposition somehow. At this point, I'd rather >> try a simple solution first. > > I was in favour of simple majority - but a vote passing with, for > example 9+1 and 8-1 is as bad IMO as a vote failing because of alot of > +1 and only one -1. > > So I've changed my mind on this - I think it should be 3/4 majority. > This avoids a small minority stopping something, but also doesn't > completely throw out consensus. > > Niall > >> 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 > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Markdown issue
See http://www.apache.org/dev/cmsref#markdown in particular the elementid
plugin.
Sent from my iPhone
On Mar 5, 2013, at 4:54 PM, Juan Pablo Santos Rodríguez
wrote:
> Hi!
>
> @Manos: that's great! didn't thought of that, but it absolutely solves the
> problem
>
> @Joseph: that looks interesting too, could you provide a link to that
> extension?
>
> thx a lot for the tips & pointers
>
>
> cheers,
> juan pablo
>
> On Tue, Mar 5, 2013 at 7:56 PM, Joseph Schaefer wrote:
>
>> In the custom extension we use there is code that lets you select a CSS
>> classname by adding {.classname} to the end of the text area.
>>
>> Sent from my iPhone
>>
>> On Mar 5, 2013, at 1:48 PM, "Emmanouil Batsis (Manos)"
>> wrote:
>>
>>>
>>> IF I understand you correctly you might be able to simply tackle the
>> issue using the right CSS selector to apply styles for external links.
>>>
>>> If links pointing inside the site use URLs not starting with "http" you
>> might want to do something like the following to match external links:
>>>
>>> a[href^="http://";] { color: red; }
>>>
>>> hth,
>>>
>>> Manos
>>>
>>> On 03/05/2013 10:18 AM, Juan Pablo Santos Rodríguez wrote:
>>>> Hi,
>>>>
>>>> @Ioan: that was exactly what I was trying to avoid, it feels a bit
>>>> cumbersome to type the whole link instead something like
>>>> [text][1](.whatevercssclass) or similar
>>>>
>>>> @Shane: yep, had checked also that link, unfortunately, "Special
>> attribute
>>>> blocks can be used only with headers fenced code blocks." and I was
>> looking
>>>> to arbitrarily style a given link (btw, the preview pane doesn't like
>>>> fenced blocks, or is it just me?)
>>>>
>>>> seems I'll stick with inline html, I was puzzled to see that it doesn't
>>>> seem to be an easy way to put custom styles via markdown :-?
>>>>
>>>> anyway, thanks for the insights
>>>>
>>>>
>>>> br,
>>>> juan pablo
>>>>
>>>>
>>>> On Tue, Mar 5, 2013 at 3:30 AM, Shane Curcuru
>> wrote:
>>>>
>>>>> See if this helps:
>>>>>
>>>>> http://michelf.ca/projects/**php-markdown/extra/#spe-attr<
>> http://michelf.ca/projects/php-markdown/extra/#spe-attr>
>>>>>
>>>>> Which is linked from:
>>>>>
>>>>> http://www.apache.org/dev/**cmsref.html#markdown<
>> http://www.apache.org/dev/cmsref.html#markdown>
>>>>>
>>>>> - Shane
>>>>>
>>>>>
>>>>> On 3/4/2013 6:46 PM, Juan Pablo Santos Rodríguez wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> probably is a dumb issue and I'm missing something obvious, but so
>> far, I
>>>>>> haven't been able to solve it:
>>>>>>
>>>>>> Is there an easy way to tell a markdown link to use a specific css
>> class?
>>>>>> I'd like to render links pointing outside the incubator site with an
>>>>>> "external" css class. I know I can write the html equivalent, but that
>>>>>> feels unnatural, so I'd better avoid that option. I've been poking at
>> a
>>>>>> few
>>>>>> site's sources, but haven't had any luck yet..
>>>>>>
>>>>>>
>>>>>> thx in advance!
>>>>>>
>>>>>> br,
>>>>>> juan pablo
>> --**--**-
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.**apache.org<
>> general-unsubscr...@incubator.apache.org>
>>>>> For additional commands, e-mail: general-help@incubator.apache.**org<
>> general-h...@incubator.apache.org>
>>>
>>>
>>> --
>>> Manos Batsis, Chief Technologist
>>>___
>>> _/ /_ (_)_ __
>>> / __ `/ __ \/ / ___/ ___// __ `/ ___/
>>> / /_/ / /_/ / (__ |__ )/ /_/ / /
>>> \__,_/_.___/_//(_)__, /_/
>>> //
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Re: Markdown issue
In the custom extension we use there is code that lets you select a CSS
classname by adding {.classname} to the end of the text area.
Sent from my iPhone
On Mar 5, 2013, at 1:48 PM, "Emmanouil Batsis (Manos)" wrote:
>
> IF I understand you correctly you might be able to simply tackle the issue
> using the right CSS selector to apply styles for external links.
>
> If links pointing inside the site use URLs not starting with "http" you might
> want to do something like the following to match external links:
>
> a[href^="http://";] { color: red; }
>
> hth,
>
> Manos
>
> On 03/05/2013 10:18 AM, Juan Pablo Santos Rodríguez wrote:
>> Hi,
>>
>> @Ioan: that was exactly what I was trying to avoid, it feels a bit
>> cumbersome to type the whole link instead something like
>> [text][1](.whatevercssclass) or similar
>>
>> @Shane: yep, had checked also that link, unfortunately, "Special attribute
>> blocks can be used only with headers fenced code blocks." and I was looking
>> to arbitrarily style a given link (btw, the preview pane doesn't like
>> fenced blocks, or is it just me?)
>>
>> seems I'll stick with inline html, I was puzzled to see that it doesn't
>> seem to be an easy way to put custom styles via markdown :-?
>>
>> anyway, thanks for the insights
>>
>>
>> br,
>> juan pablo
>>
>>
>> On Tue, Mar 5, 2013 at 3:30 AM, Shane Curcuru wrote:
>>
>>> See if this helps:
>>>
>>>
>>> http://michelf.ca/projects/**php-markdown/extra/#spe-attr
>>>
>>> Which is linked from:
>>>
>>>
>>> http://www.apache.org/dev/**cmsref.html#markdown
>>>
>>> - Shane
>>>
>>>
>>> On 3/4/2013 6:46 PM, Juan Pablo Santos Rodríguez wrote:
>>>
Hi all,
probably is a dumb issue and I'm missing something obvious, but so far, I
haven't been able to solve it:
Is there an easy way to tell a markdown link to use a specific css class?
I'd like to render links pointing outside the incubator site with an
"external" css class. I know I can write the html equivalent, but that
feels unnatural, so I'd better avoid that option. I've been poking at a
few
site's sources, but haven't had any luck yet..
thx in advance!
br,
juan pablo
>>> --**--**-
>>> To unsubscribe, e-mail:
>>> general-unsubscribe@incubator.**apache.org
>>> For additional commands, e-mail:
>>> general-help@incubator.apache.**org
>
>
> --
> Manos Batsis, Chief Technologist
> ___
> _/ /_ (_)_ __
> / __ `/ __ \/ / ___/ ___// __ `/ ___/
> / /_/ / /_/ / (__ |__ )/ /_/ / /
> \__,_/_.___/_//(_)__, /_/
>//
>
> -
> 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
