Details on contacting Infra

Here is detailed information on how to contact Infra in a wide range of situations.

How should I make contact?¶

That depends on your role and what you want to do. If this chart doesn't help, Infra maintains a publicly accessible channel (#asfinfra) within the ASF presence on Slack, and you can ask there whether to create a bug report or do something else.

If you are...	and want to...	then contact...	Notes
anyone	report a security vulnerability in a service that runs on apache.org	`root@apache.org`	You may optionally encrypt the email to this set of keys.
anyone	report a security vulnerability in an Apache project	Apache Security Team	The Security Team is not part of Infra.
anyone	report that a service is down and status.apache.org doesn't show it	Slack channel	Slack preferred, email to `users@infra.apache.org` is an acceptable alternative. The infrabot Twitter feed may contain information about current outages and maintenances.
a newly-invited committer	ask a question about your committership	`private@$project`
a committer	regain access to your account; resetting your password didn't work	See Regaining account access	If commits fail, double-check that you are using `https://` (not `http://`).
a supplier (you donate or sell hardware or services to Apache)	anything	`private@infra.apache.org`	Passwords should be encrypted or sent by other means
submitted an ICLA in the past	change your contact details of record	`secretary@apache.org`	Fax or snail mail are possible too; see apache.org/foundation/contact
prospective official download mirror	request being listed as an official download mirror	see the "new mirror" documentation	Please email mirrors@apache.org if you have any questions.
existing official download mirror	ask a question concerning your mirror	`mirrors@apache.org`	Questions not suitable for public discussion may be sent to `apmirror@apache.org` (an alias with limited distribution).
anyone	report a problem with a download mirror (other than it being out of date	the Apache project whose product you were trying to download	The project will escalate to infra if necessary.
anyone	unsubscribe from a mailing list	See unsubscription instructions
a committer	change your account details	Self-serve	Details include forwarding email address, password, and SSH or PGP public keys of record.
a PMC	request account creation for a newly-elected committer	Whimsy	See docs for details
a newly-accepted podling	create podling infrastructure (site, lists, etc.)	Requesting podling
a podling that has just graduated	migrate resources from Incubator locations to TLP locations	requesting graduation
an existing PMC or podling	request mailing list creation	Self-serve	Only Members and Officers (this includes all PMC chairs) can submit the form.
a committer or PMC	add/remove mailing list moderators	create a JIRA ticket	Feel free to follow up via the Slack channel or file a Jira ticket if no reply after 48 hours
a committer or PMC	change Jenkins build settings	builds@apache.org	Project members having hudson-jobadmin karma can perform some tasks; ask your dev@ list
a PMC	request Infra to do something	create a Jira ticket	See "On Requests" and "Providing needed information".
an Officer of the ASF	ask an organizational (as opposed to technical) question	VP Infrastructure, or private@infra.apache.org	The target audience for this item is the Apache Board of Directors, the VP of Fundraising, etc.
posted to an Apache mailing list	edit the mail archives	Public Forum Archive Policy	Virtually all requests are denied.
anyone	discuss something publicly with Infra	users@infra.apache.org	Archives: discussion archives - for ASF Members only!
anyone	ask Infra a question	users@infra.apache.org	Consider the users@infra mailing list as a semi-public list as many Apache committers subscribe to it.
anyone	get your IP unblocked	users@infra.apache.org	Consider the users@infra mailing list as a semi-public list as many Apache committers subscribe to it.

Providing needed information¶

If you ask us to...	then we need to know...	Notes
Promote a podling to TLP	See requesting podling graduation
Create a podling	See requesting a podling
Load Subversion history	URL and checksum (or PGP signature) of a dumpfile; proof of IP rights	Produce with svnadmin dump --incremental --deltas or svnrdump. The paths within the dumpfile should be relative to the project root (e.g., to /repos/asf/incubator/MyPodling).
Load Git history	URL and of a repository or an export stream; proof of IP rights	If linking to a file, provide PGP signature or checksum. If to a remote repository, you must review and sign off on the import ("Yes, that is the repository and history we asked to import and have IP rights for") before it will be writable.
Create an svnpubsub-based site	SVN URL of the compiled site (directory containing HTML files)	SvnPubSub does not support Git. Use the webreq app
Create an svnpubsub-based Dist area	Create or ask Infra to create a dist release directory. Specify release area only or release and dev areas. If you omit a list of emails for commit notices to go to, the default is the project commits list.	Any existing release dir will be blown away (archive releases remain). Infra will ask for a release or KEYS/NOTICE file once the directory is in place.
Create a project blog	project name, brief one-line description of the project, and Apache usernames (and fullnames) of 1+ editors
Create a blog account for an editor	The Apache username (and fullnames) of the editor	Non-PMC members need to demonstrate PMC consensus (link to a lazy consensus thread suffices).
Create a moin wiki	Moin is deprecated and no more Moin wikis are being created.	Plan on using Confluence instead. See the next entry.
Create a Confluence wiki	wiki name, destination for commit mails, and Confluence usernames of two+ community members - volunteer space admins	Go to selfserve and follow the prompts.
Set up your project on Review Board	Project name, which svn/git branches to support	Review Board is a web-based collaborative code review tool, available as free software under the MIT License.
Create a Jira project	Key name (e.g., INFRA), Jira user names of 1-2 project members - volunteer project admins, mailing list address to which Jira notifications should go	Go to selfserve and follow the prompts.
Migrate your project's SVN to Git	n/a	Please use self-serve to create your intended Git repo(s). Run svn2git locally using this authors file and push once the conversion result is confirmed. File an Infra ticket to mark your SVN repository readonly. Optionally, file a ticket to temporarily disable commit emails for when you push your converted clone.

Don't see here what you're looking for? See above for other cases.

Requesting podling creation¶

The podling creation process is as follows:

1. The IPMC vote passes.
2. The podling is added to the IPMC's podlings.xml summary file with status=current. (See notes about that, and other initial tasks.)
3. Create a Jira ticket asking Infra to create a DNS for your new podling (include the podling's name).
4. After the DNS is created, an ASF Member or PMC chair files mailing list creation requests.
5. Infra creates the lists, which also notifies the IPMC of the mailing list creation.
6. An Incubator PMC member who is also an ASF member or a PMC chair edits the asf-authorization-template and adds an [/incubator/podling] section. If the section refers to an @podling group, add a definition of that group as a comma-separated list of availids (usernames), to the [groups] section. Alternatively, just set @incubator = rw as the section's body.
7. If the podling wants to use SVN, an Incubator PMC member runs svn mkdir ^/incubator/podling. The commit mail goes to the mailing list created earlier.
8. If the podling wants to use GIT, one of the mentors submits a request via Self-Serve.
9. The podling community sets up a project site.
10. An ASF Member or PMC chair files a website creation request.

If the project needs additional services (issue tracker, Wiki, blog, etc.), file a ticket via Jira using appropriate categories and providing as much information as possible. To save everyone's time, consult "Providing needed information" before filing each ticket.

Requesting podling graduation to top level project (TLP)¶

Once your podling has graduated to a TLP, create the following Jira tickets:

1. A "Graduate Foo to TLP" parent ticket.
2. A "Foo TLP: common tasks" ticket as a sub-task of (1). This ticket handles DNS entry, Unix/LDAP group creation, PMC Chair karma, mailing list migration, native Git repository migrations (but not git-svn mirrors), Subversion public tree migration, buildbot config changes, and website migration. There is no need to file individual tickets for these tasks. In the ticket, specify the LDAP name of the TLP --- that is, the foo in dev@foo.apache.org.
3. For each additional service that needs configuration changes as the result of the migration, create another sub-task. If you have N services, create N sub-tasks. "Services" here includes everything indicated below, such as Subversion private tree, git-svn mirrors, issue trackers, wikis, and continuous integration (Jenkins, Buildbot, Continuum etc.). See Flex's graduation tickets for a good example.

Note that the new PMC chair is still responsible for using Whimsy as appropriate. The group membership is initialized on a best-guess basis, but the chair must check that it's accurate and add and remove people as needed. Infra intializes the Committee data directly from the information in the Board resolution.

Regaining access to a committer account¶

If you forgot your password, try...

1. to reset it at id.apache.org/reset/enter. That will email your @apache.org address (which forwards to your non-apache email account) a short-lived password reset link. The link may be encrypted to your PGP key.
2. decrypting the e-mail - one way to do this is to sve the e-mail contents as a text file, e.g. password.txt. Open a shell command window, and run the following command:

gpg -d password.txt</code>

This should decrypt the file and display the output in the window.

3. If you have lost access to your registered email address, file an additional ICLA with Secretary. Follow the directions for submitting an ICLA. Include your current Apache ID and mention in your cover email that you are requesting a change to your email address.

4. If that didn't work, email root@. In your email, mention the following information:

• Your username.
• The fact that you have tried a self-service password reset, and why it didn't work. (Was the mail received? Did you decrypt it successfully?)
• Why you need to regain access to your Apache account --- e.g., if it is to work on a foundation project, name that project; or if you are a foundation member, state that.
• Whether you have SSH access to minotaur.apache.org or to a PMC jail/zone/VM via public-key authentication<
• Whether you ever set up OPIE on any *.apache.org box. (This is only applicable to people who had root permissions on PMC VMs.)
• Whether you have access to the private part of a PGP key associated with your Apache account.
• Whether the contact information on your ICLA is valid.
• For (ASF Members only, whether the contact information in your members.txt entry is valid.
• Whether you are able to send a new ICLA, with the same signature as your original one, which specifies new contact information.

• Whether there is any other way in which we (infra) might satisfy ourselves that you are the legitimate owner of that account.

Note: please do not ask other ASF committers or Members to email root@ to vouch for you.

Other Requests¶

What can I ask for?¶

See the list of Services and tools Infra provides for projects. If you want something that isn't listed, get in touch. It might be possible to support it, especially if the feature request includes a list of volunteers who will help maintain it hint, hint.

Where should I submit my request?¶

The short answer: If there is a dedicated webapp, use it. If not, file a Jira ticket for Infra.

The more complete answer is in the table above. Please review the table before filing a ticket - often you or someone in your PMC can effect the change without involving infra at all.

Before you press `Send` on your ticket:¶

• Ask in your project whether someone has the karma to implement the requested change. This eases the load on the infra team. The moderators and volunteer admins of the project's issue tracker and wiki can often address issues with those services.
• Aggregate requests: instead of sending five emails, each asking for one more moderator to be added, send one email asking for five moderators to be added.
• CC your PMC on emails. In Jira tickets, it is helpful to link to a thread that demonstrates PMC consensus. (If you request a significant or major configuration change, we will probably ask for that link if you don't provide it.)
• If you create a Jira ticket, create it in the right Jira component. This helps the team spot pending tasks in their areas. If it's not obvious which component is the right one, report a bug in the documentation.
• Be patient. It may take a few days for someone to respond.
• Research your topic. See the developer information section.

Thanks. Making requests following these guidelines might require a little effort, but saves time for all involved.

My issue got closed with a request to reopen it¶

Then reopen it. Usually we ask that you do something as you reopen it, so do that too (or say why you didn't).

Background: we tend to close issues that we cannot act on for an extended period, since we use the INFRA queue as a to-do list. In our workflow, this kind of close/reopen cycle is a matter of ordinary routing (much like reverting a commit that broke the build system).

My issue got ignored¶

There could be a few reasons: some areas have longer turn-around times than others; sometimes we're busy on backend projects like installing new hardware and have little time for user-facing tasks; sometimes an issue blocks on prerequisite new hardware to get shipped, installed, and configured, which takes time; sometimes we're just backlogged and are working on issues ahead of yours in the queue; and sometimes we do tickets of a certain category in batch, and yours will be done in the next batch in a few days.

To make sure your issue doesn't get lost, feel free to add a comment to the relevant Jira issue, or email the users@infra list with a question. If the matter remains unresolved after that, feel free to escalate it to the VP, Infrastructure or to the operations@ privately-archived mailing list (everyone may post to it).

In case of emergency¶

The following describes how to page root@ people when there is an absolutely urgent problem, such as a malicious cracker having an active root shell on archive.apache.org. This is only for urgent, ASF-wide problems that must be handled at once, even if that means waking people up in the middle of the night or having them miss their flight

Normally, pinging #asfinfra or emailing root@ or private@infra suffices. We discourage pinging people privately (via email, Slack, or Twitter) as then only a single person is aware of a request.

If you have exhausted these options, the last resort is to look up root@ people the list of names (see here or here) and call them or SMS them.

Finally, the VP Infrastructure has the authority to contact third parties directly. The contact information is available to him via docs/vp/littleblackbook.txt.

Reminder: this facility is for emergency use only. It wakes people up.