Re: Cultivating Outstanding IP Stewards
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 joe_schae...@yahoo.com 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 ant.el...@gmail.com 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 joe_schae...@yahoo.comwrote: 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 a...@apache.org 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 u...@odoko.co.uk 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: 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 ant.el...@gmail.com 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 joe_schae...@yahoo.com 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 ant.el...@gmail.com 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 joe_schae...@yahoo.comwrote: 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 a...@apache.org 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 u...@odoko.co.uk 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
Re: Cultivating Outstanding IP Stewards
Hi, On Fri, Nov 8, 2013 at 11:54 AM, Upayavira u...@odoko.co.uk 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
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 bdelacre...@apache.org wrote: Hi, On Fri, Nov 8, 2013 at 11:54 AM, Upayavira u...@odoko.co.uk 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
On Wed, Nov 20, 2013 at 10:41 AM, Joseph Schaefer joe_schae...@yahoo.com wrote: Can I just ask how many people have we encountered who upon being offered IPMC membership turned it down with grounds along these lines?... I'm not saying there are any, hence starting my suggesting with assuming Upayavira's concerns are true. My temporary PMC member election suggestion is easy to implement and revert, I thought it might be easier to agree on and move on than the larger proposals seen in this thread. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: INFRA-6774
Joseph Schaefer wrote on Tue, Nov 19, 2013 at 23:18:11 -0500:
On Nov 19, 2013, at 10:50 PM, Joseph Schaefer joe_schae...@yahoo.com wrote:
On Nov 19, 2013, at 10:40 PM, Jordan Zimmerman randg...@apache.org 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
[VOTE] Release HDT version 0.0.1.incubating (RC1)
Hi, I would like to call for a vote for Apache Hadoop Development Tools (incubating), version 0.0.1.incubating. The vote has happened of the dev mailing list and the community has approved the second release candidate(RC1) for Apache Hadoop Development Tools (incubating), version 0.0.1.incubating.The release has Zookeper and HDFS features from the *hadoop-eclipse-merge* codebase. The issues raised for RC0 have been addressed in this release. 1 IPMC votes have already been cast: Roman Shaposhnik (mentor) Please vote on releasing this package as Apache Hadoop Development Tools 0.0.1.incubating. [ ] +1 Release this package as Apache HDT 0.0.1.incubating [ ] 0 I don't feel strongly about it, but I'm okay with the release [ ] -1 Do not release this package because... PPMC Vote thread : http://apache.markmail.org/message/bbdedy4bprhwngew Vote Result : http://apache.markmail.org/message/nq4pylp73n5n6wyn Source and binary files: http://people.apache.org/~rsharma/hdt-0.0.1.incubating-rc1/ The tag to be voted upon: https://git-wip-us.apache.org/repos/asf?p=incubator-hdt.git;a=commit;h=0627220f5181bfe698fdc71209ca66864068b352 KEYS file: https://dist.apache.org/repos/dist/dev/incubator/hdt/KEYS Some guideline to verify release can be found at : http://apache.markmail.org/message/qj3srhvozapbwmq6 regards, Rahul
INFRA-6774
Can someone please explain to me what I need to do to have curator.incubator.apache.org redirect to curator.apache.org?
[VOTE] Release Apache Knox-0.3.1-incubating RC3
Hello All, This is a call for a vote on Apache Knox Gateway 0.3.1 incubating. A vote was held on developer mailing list and it passed with 3 +1's, and 0 -1's or +0's and now requires a vote on general@incubator.apache.org. The [VOTE] thread can be found at: http://mail-archives.apache.org/mod_mbox/incubator-knox-dev/201311.mbox/%3CCACRbFyjgLrCSahhtWWHK-%3DaeQFM4Oegbe3fQjs-RV2-TAnhdxA%40mail.gmail.com%3E The release candidate is a zip archive of the sources in: https://git-wip-us.apache.org/repos/asf/incubator-knox.git Branch v0.3.1 (git checkout -b v0.3.1) Tag: https://git-wip-us.apache.org/repos/asf?p=incubator-knox.git;a=tag;h=5a907022dbc2b0a8534de47fe7b8c871c4f075f9 Source archive zip file and signature are available from: https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/knox-incubating-0.3.1-src.zip.asc Checksums of the source archive: SHA1: 04bb11360f57c0431c30cfb181e3199868fe6053 The KEYS file can be found at: https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/KEYS The release changes file can be found at: https://dist.apache.org/repos/dist/dev/incubator/knox/knox-incubating-0.3.1/CHANGES The release has been signed with key (587C089B): http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x82F9C371587C089B Vote will be open for 72 hours. thanks, --larry Larry McCay
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 d...@daniel.shahaf.name wrote:
Joseph Schaefer wrote on Tue, Nov 19, 2013 at 23:18:11 -0500:
On Nov 19, 2013, at 10:50 PM, Joseph Schaefer joe_schae...@yahoo.com wrote:
On Nov 19, 2013, at 10:40 PM, Jordan Zimmerman randg...@apache.org 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
[VOTE] Apache Helix as TLP Resolution
Hi, Here the vote for Apache Helix as TLP graduation. The vote result for dev@helix.i.a.o is available here: http://markmail.org/message/22orwjy2v3d4af67 Vote open for 72H [+1] [0] [-1] X. Resolution to establish the Apache Helix Project 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 related to cluster management system for managing partitioned and replicated resources in distributed data systems. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the The Apache Helix Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that The Apache Helix Project be and hereby is responsible for the creation and maintenance of a software project related to cluster management system for managing partitioned and replicated resources in distributed data systems; and be it further RESOLVED, that the office of Vice President, Helix 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 Helix Project, and to have primary responsibility for management of the projects within the scope of responsibility of The Apache Helix 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 Helix Project: * Olivier Lamy olamy * Patrick Hunt phunt * Mahadev Konar mahadev * Owen O'Malley omalley * Kishore Gopalakrishna kishoreg * Zhen Zhang zzhang * Shi Lu slu * Kapil Surlaker ksurlaker * Bob Schulman rms * Swaroop Jagadish swaroop-aj * Rahul Aggarwal rahula * Terence Yim chtyim * Santiago Perez santip * Vinayak Borkar vinayakb * Shirshanka Das sdas * Kanak Biscuitwala kanak NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kishore Gopalakrishna be and hereby is appointed to the office of Vice President, Helix, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Helix Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Helix podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator Helix podling encumbered upon the Apache Incubator PMC are hereafter discharged. -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Adding IPMC members based on PPMC merit
On Sun, Nov 17, 2013 at 2:12 PM, Benson Margulies bimargul...@gmail.com wrote: and bug #2 is this scheme of adding IPMC members based on PPMC merit. Adding IPMC members based on PPMC merit was the implementation which garnered the most support on the first go-around. Unfortunately, things look grim so far: * An email to private@incubator soliciting nominees from one specific podling came up empty. * An email to private@incubator soliciting nominees from any podling at all also failed to elicit a single response. * Nominations have been complicated by the difficulty of establishing exactly what criteria justify elevating someone with PPMC merit onto the IPMC. In order to compensate for Mentor attrition and a serious dent in the problem of release vote scarcity, I reckon we need at least at least one new IPMC member per podling on average. Maybe we could start with a handful. But zero? My analysis is that this approach cannot scale because it lacks a forcing function. If nominating potential IPMC members from podlings remains both uncomfortable and optional, it just will not get done often enough to solve a systemic problem. Do any of the people who favored this stratagem feel as though we have not yet given it our best effort? In order to arrive at a consensus solution, I believe that all of us are going to have to show some flexibility about implementation details. I hope that you feel as though your concerns have been heard, and that you will be supportive of other means which achieve similar ends. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Populating the initial PPMC
On Mon, Nov 18, 2013 at 3:41 AM, Andy Seaborne a...@apache.org wrote: 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. I don't see how we might divide up an Initial Committer List into active and major developers and everyone else, so I think it's all or nothing. That gives us four ways to populate the initial PPMC: 1. Mentors + Initial Commiter List 2. Initial Committer List 3. Mentors 4. (empty) With regards to whether voting in all project contributors is dis-empowering, I claim that it is precisely the opposite. Going through the exercise of bootstrapping the PPMC allows people who are new to the ASF to become familiar with the ritual of personnel voting, and it provides a framework for conversations about the PPMC member role and its responsibilities, community development, recruitment and meritocracy. In contrast, the present system denies ASF novices such practical experience until a new contributor wanders by. To the extent that any dis-empowerment happens under this proposal, it is exactly the same dis-empowerment which happens today: active and major developers who bring codebases to Apache relinquish control and become one vote among many on a PMC. Subjecting such individuals to a vote on their merit (which will surely pass) just reveals the truth to them sooner. Perhaps with the truth laid bare, certain projects might not enter the Incubator. Do we care? Regretful project founders who are unable to let go have caused our communities a lot of grief, from both inside and outside Apache. Still, this isn't the hill I want to die on. I think that starting with an empty PPMC is good policy for a variety of reasons, but I'm willing to be flexible for the sake of building consensus on how to address the truly damaging dis-empowerment of PPMC members with regards to release votes. If an empty initial PPMC is a deal breaker for you, does it's removal unblock your support for the rest of the proposal at http://s.apache.org/atG? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Populating the initial PPMC
Dislike. For small projects, PPMC == Committers is a great starting point. For huge projects like OpenOffice something like this would have been chaos unleashed. If it were 3 or 4 then I would not have volunteered to be a Mentor for Apache Flex. To me the answer should remain somewhere between 1 and 2 - the status quo. Regards, Dave On Nov 20, 2013, at 5:53 PM, Marvin Humphrey wrote: On Mon, Nov 18, 2013 at 3:41 AM, Andy Seaborne a...@apache.org wrote: 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. I don't see how we might divide up an Initial Committer List into active and major developers and everyone else, so I think it's all or nothing. That gives us four ways to populate the initial PPMC: 1. Mentors + Initial Commiter List 2. Initial Committer List 3. Mentors 4. (empty) With regards to whether voting in all project contributors is dis-empowering, I claim that it is precisely the opposite. Going through the exercise of bootstrapping the PPMC allows people who are new to the ASF to become familiar with the ritual of personnel voting, and it provides a framework for conversations about the PPMC member role and its responsibilities, community development, recruitment and meritocracy. In contrast, the present system denies ASF novices such practical experience until a new contributor wanders by. To the extent that any dis-empowerment happens under this proposal, it is exactly the same dis-empowerment which happens today: active and major developers who bring codebases to Apache relinquish control and become one vote among many on a PMC. Subjecting such individuals to a vote on their merit (which will surely pass) just reveals the truth to them sooner. Perhaps with the truth laid bare, certain projects might not enter the Incubator. Do we care? Regretful project founders who are unable to let go have caused our communities a lot of grief, from both inside and outside Apache. Still, this isn't the hill I want to die on. I think that starting with an empty PPMC is good policy for a variety of reasons, but I'm willing to be flexible for the sake of building consensus on how to address the truly damaging dis-empowerment of PPMC members with regards to release votes. If an empty initial PPMC is a deal breaker for you, does it's removal unblock your support for the rest of the proposal at http://s.apache.org/atG? 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: Transition Incubator dist area
On Mon, Nov 18, 2013 at 5:00 PM, Marvin Humphrey mar...@rectangular.com wrote: If I've done everything right, it should be possible for Infra to flip the switch and use new-style dist.apache.org synchronization at the incubator/ level. Infra flipped the switch today. We now use dist.apache.org exclusively. It would be nice if we continue on with the cleanup. These tasks remain to be done. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
