This document is targeted at Apache committers. A committer is an individual who was given write access to the codebase of any Apache project. We also have a New Committers Guide.
If you are not an Apache committer, but wish to become one, you will find the instructions on how to contribute to Apache projects more useful.
Read the Guide for new committers. That guide is also useful for existing committers, and provides links to other sources of information.
Planet Apache aggregates RSS feeds
from Apache committers. It is run by the ASF and committers with blogs are
welcome to add their own blog to its feed. See the contents of the committers/planet directory in the
private repository.
The Apache Software Foundation periodically organizes conferences focusing on software developed at Apache and on the way that Apache develops its software. Learn about what's happening at Apache, hack code and meet the faces associated with the names!
A face-to-face gathering for hacking of code. Hackathons are generally held at ApacheCons, as well as at other times.
A face-to-face gathering for work on Apache infrastructure by our amazing infra contractors and volunteers.
Heed the warnings in these two email threads (read them all the way through): What is a member and volunteeritis. The discussion is about what it means to be a committed person at the ASF and how to deal with your internal pressure that arises from such dedication.
We each need to re-read those two important messages from time-to-time and remind our communities.
Or move a project into the ASF?
Please contact the Incubator Project. They will assist you in starting projects or moving them into the ASF.
Apache Labs could also be for you if you want to start something new.
Note: this is an incomplete collection and not authoritative.
As an Apache volunteer, you have the right to set your own priorities and do the work that scratches your own itch. As a Committer, you have a responsibility to the community to help create a product that will outlive the interest of any particular volunteer (including yourself). This means, for example, that the code that you commit should be clear enough that others not involved in its current development will be able to maintain and extend it. It also means that you are responsible for helping to grow and maintain the health of the Apache community.
More specific responsibilities of Committers include:
No - committer status and merit never expires. If you become inactive for a time (usually six months or more) your account may be deactivated for security reasons. Most projects allow reactivation of committer status by application to the pmc.
Some projects use the concept of a emeritus committer status. This is
typically suitable for those committers who can no longer they can give the
time they feel is required.
For any substantial codebase that has been developed outside the ASF, a small amount of process is required before the code can be committed. This is managed by the Incubator. The first step is to contact your PMC.
You might notice something that needs changing, for example the configuration for a mailing list. The request to the users@infra list or the apmail@ alias needs to come from your Project Management Committee. That ensures that the requests are official, and not just an individual user's desire. This is the same for all requests for infrastructure changes. However, please try to get your PMC to assist first. There are many things that the PMC or PMC chair can do, thereby easing the load on the infrastructure team.
Infrastructure has the [email protected] mailing list to discuss new infrastructure developments at the ASF. For service downtime announcements and current information on operations, we use http://twitter.com/infrabot. For general announcements regarding services and the like, infrastructure has a blog.
Committers may access home.apache.org (documentation).
Note that you do only have sftp access. There is no shell access.
Apache infrastructure
provides a list of other Apache services/hosts.
You can publish a small personal website in public_html, as described elsewhere. You must never store secret/private keys (the private half of an SSH keypair, or a PGP private key) on any ASF machines.
Henk Penning and Vadim Gritsenko have such statistics and cool charts.
Any message about a change to the host key or any "Error validating server certificate" should be taken very seriously: it may indicate a man-in-the-middle attack is in progress.
Do not ignore this message and continue.
Before contacting the Apache infrastructure team, check that you are logging in to the correct machine, and check the currently published SSH fingerprints for Apache hosts here: new-committers-guide.html#spoof
See Why Do I Get An Authorization Failure When Accessing SVN
Nexus is LDAP based auth. If you have changed your LDAP password recently it is possible you have a cached version of your old password stored , perhaps in a settings.xml file locally. Maven makes repeated attempts to try this authorization and within 10 seconds you might find your LDAP account locked as a result.
Try accessing another LDAP based service to test the theory and if you cant get access you can bet that is what happened.
The cure is to go to https://id.apache.org/reset/enter and reset your LDAP password to clear the locked account. Change any cached creds locally and try staging to Nexus again.
The most common reason is that you've forgotten your password!
The password used for subversion is the same as the password you use
for access to LDAP id.apache.org. You will not be prompted to enter it
frequently. This makes it is easy to forget.
Apache employs a number of different HTTP authentication realms. You will need to enter your password whenever you access a new realm. (Subversion prints information about the realm when you are prompted for the password.)
Of course, it is also possible that you're accessing an url which is restricted. That's probably for a good reason so unless you know that you should have access, don't bother the infrastructure team.
If you do forget your password please visit https://id.apache.org/ to reset it.
In Subversion, url: https://svn.apache.org/repos/private/committers
See the Version Control FAQ.
Very rarely if ever. Please read this for why you shouldn't lock.
The Version Control FAQ.
See these instructions.
If it is a public list, email the -subscribe address (such as
[email protected]) from the address you want subscribed, and
reply to the confirmation mail.
Private lists use the same procedure, but it's recommended to use the self-subscribe app instead; that avoids needing to wait for the human moderators to check and green-light your subscription request.
At the time of writing the self-subscribe app lets ASF
Members subscribe to any ASF list (see
<../foundation/governance/members> for the rationale behind this) and other
committers to subscribe to a few foundation-wide lists. Notably, committers
who wish to subscribe to other lists (such as a private@ list of their project)
should still email the -subscribe address.
Mail lists are the virtual room where the communities live, form and grow. It is wiser to keep the number of mail lists per codebase the smallest possible to allow the community to reach that critical mass that is necessary to bootstrap a codebase and keep it in good shape.
At the same time, as communities grow, the need for more specialized mail lists appears. This is the suggested chain of actions to request the creation of a new mail list:
Request a vote in the community
If the creation is accepted, your Project Management Committee needs to send in a request (more details ).
WARNING: the creation of a user mail list can be a very dangerous thing for a community if the developers don't pay attention to their users and if users don't have developers that reply to their emails. Sure, active developers should expect a well behaving user community to reply to one another for simple questions, but this doesn't happen overnight and the creation of a user mail list alone can turn into a very harmful change.
Moderators can send an email to:
listname-list@tlp.apache.org
Anyone with access to the apmail account can run the following command to get a count of the subscribers.
ezmlm-list~/lists/project/listname| wc -l
Remember that there often are people subscribed to the digest version too:
~lists/project/listname/digest
However, most committers do not have access to apmail. See the notes in the "committers" SVN module at /docs/resources.txt for another way.
See our overall guide for mailing list moderation.
File an INFRA Jira ticket or ask your PMC to send a request to the apmail@ alias (apache.org)
If you have access to apmail, you can just change the list of subscribers to list/mod. For example for the mod_perl dev list that is in
~apmail/lists/perl.apache.org/dev/mod/
Use ezmlm-list , ezmlm-sub and ezmlm-unsub to do that.
To determine who the existing moderators are, any committer can use the technique described in the "committers" SVN module at /docs/resources.txt
First look in the mail and check if it is spam (or other severely misguided mail). If it is spam then just ignore the mail to have it silently dropped after 5 days. To bounce non-spam with a notice to the sender, reply to the -reject address in the mail header. If you wish to include a comment with the rejection, the body of the message should look like this:
%%% Start comment Your message goes here... %%% End comment
If it is legitimate mail from a non-subscriber (or someone sending with a different envelope sender than the one subscribed), reply to the moderate request to the -accept address. If you also send mail to the -allow address (i.e. reply to all) then future postings from that address will be allowed through automatically.
If there is no -allow address in the moderate requests the list was misconfigured when it was setup and you should contact [email protected] and get them to enable remote administration.
See the EZMLM "Moderator's and Administrator's Manual". You can also send email to {listname}[email protected] from your moderation address (there are extra details for moderators).
Some lists are only open to ASF committers. The moderators have methods to ensure that subscribers are committers, so subscribers can use whatever email address that they want. Moderators see the tips described in the "committers" SVN module at /docs/resources.txt
Most lists require posters to be subscribed. However subscribers are sent copies of all mails (or digests). This is obviously unsuitable for bots -- or private lists which need to accept posts from non-subscribers.
A moderator can fix this by using 'Reply All' to a moderation message from the poster. This will both 'accept' the message and 'allow' further posts.
It's also possible to set this up in advance, by subscribing the poster to the 'allow' list. E.g. if you want [email protected] to be able to post:
{listname}[email protected]
Note that the '@' in the sender email must be replaced by '='
If you have a troublesome poster, then you can un-subscribe them from the list using
{listname}[email protected]
(and send a courtesy email to them).
Occasionally you will get someone with a poorly-configured spam filter sending automated replies to the list. You can deny their postings using
{listname}[email protected]
(and send a courtesy email to them).
If someone (an unsubscribed user) was added to the moderation list (intentionally or unintentionally) and now they are sending spam to the list, you can remove them by sending an email to:
{listname}[email protected]
Note that to see a list of who is allowed to post on the moderation list you can send an email to:
{listname}[email protected]
All of these must be sent from your moderator address. You can tell if
you're sending from the right address by emailing the -help address (e.g.,
[email protected]) and checking if the subject of the reply contains
the word "Moderator help".
If a subscriber reports that they are not receiving some e-mails, check which ones this affects. If they are not seeing their own e-mails, note that GMail hides duplicates. Also check whether the emails could have been treated as SPAM by their e-mail client.
If a subscriber reports getting a bounce message from ezmlm, ask them to provide the details. For example:
Hi! This is the ezmlm program. I'm managing the user@tlp.apache.org mailing list. Messages to you from the user mailing list seem to have been bouncing ... Here are the message numbers: 12345
This can occur if the recipients mail system has stricter SPAM detection rules. One way to find such emails is to request an index listing from ezmlm, for example by sending an email to
dev-index-12345@tlp.apache.org
This will show the subject, timestamp and sender of the email. That may be sufficient to identify it as spam. If not, the subject and date should make it easy to find in the archives.
If the content of the MODERATE request is clearly SPAM, then the simplest solution is just to delete the request. (Do not reject it).
However, if you are receiving a lot of such requests, it may perhaps be worth taking additional action.
Some SPAM mails have an opt-out link. Whether this will actually do anything useful is another matter, but it might be worth trying if the spam seems to be from a legitimate business. To avoid revealing your personal IP address, you may wish to use an anonymising service such as Tor.
If the SPAM mails are all sent from the same address (*), then try adding them to the 'deny' list:
{listname}[email protected]
(*) Note that the sender address can be extracted from the Cc: address in the moderation request. This has the form:
Cc: {listname}-allow-tc.<digits>.<alphanumeric>-badposter=menace.com@tlp.apache.org
The sender e-mail address is contained between the '-' (hyphen) immediately following the "alphanumerics" and the '@' sign. This is already in the correct form for use in the 'deny' subscription request, i.e. the '@' has been changed to '='. In the example above this is:
badposter=menace.com
If this address contains random alphanumerics then it is probably a short-lived address, in which case there is no point trying to use the deny list.
In the early days, users were responsible for updating the .forward file in their home directory.
The forwarding address(es) are now stored in LDAP and maintained by the use of the Self Serve app.
At first, the LDAP data was extracted and used to populate
the .forward files. However the forwarding is now done directly from LDAP, so the .forward
files now have no effect and should be ignored.
It's been a long while since e-mail was stored on the people.apache.org server.
However some mailboxes may still be present on the server.
Here is presented a simple method to move the mail from people.apache.org
into a Thunderbird mail
client. Copy the mailbox from your people.apache.org directory to your
local machine. For example:
$ scp USER@people.apache.org:/home/USER/Mailbox /tmp/Mailbox
And then copy it into your Thunderbird Mail folder. For example:
$ mv /tmp/Mailbox "thunderbird/profile/Mail/Local Folders"
The name of the directory might differ depending on your Thunderbird version and configuration.
That's all!
Apache project business should almost always be on your public dev@
mailing list, unless there is a specific reason to use private@.
See the discussion about private vs. public lists.
The most likely explanation is that the commit message is awaiting
moderation. Messages will be delivered promptly without moderation once the
moderator approves posts from your apache.org address.
Note: While there is not an official list, the following six principles have been cited as the core beliefs of The Apache Way:
collaborative software development
commercial-friendly standard license
consistently high quality software
respectful, honest, technical-based interaction
faithful implementation of standards
security as a mandatory feature
Similarly, a non-official The Apache Way website is available.
Yes, Apache projects must always be managed independently of undue commercial influence.
Yes, Apache software products are always available to download and use at no cost.
You need to make sure that the commit message contains at least the name of the contributor and ideally a reference to the Bugzilla or JIRA issue where the patch was submitted. The reasons: this preserves the legal trail and makes sure that contributors are recognized. Obviously, the latter doesn't mean it's not a good idea to list the names of all contributors somewhere on the website. To make it easier to "grep" for commits with patches from contributors, always use the same pattern in the commit message. Traditionally, we use "Submitted by: <name>" or "Obtained from: <name>".
Here's an example of what such a commit message could look like:
Bugzilla #43835:
Added some cool new feature.
Submitted by: John Doe <john.doe.at.null.org>
The short answer is: it depends. You shouldn't be worried until a week or two has passed since the date you expected the document to arrive.
When a CLA is submitted, there are several stages to the process.
The first is that it has to arrive in the hands of an Officer of the ASF. For emailed and faxed documents, this is quick. For snail mailed documents, this is sometimes slow and often very slow if posted from outside the US.
The second is that the document has to be acknowledged by the ASF Secretary. Acknowledged documents are noted in the appropriate file in the foundation repository.
The third stage is waiting until you know that the ASF has registered the document. ASF members can watch the commit records or check the file. PMC members can watch their private@ list for a notice from secretary@ (this only happens if the ICLA mentioned which TLP to notify) . Others will need to check the [list of ICLAs]http://home.apache.org/unlistedclas.html) This is automatically generated from the file maintained by the Secretary about every hour.
PMCs are responsible for managing their own Apache project brands, and committers are encouraged to assist. If you spot any potential misuse or infringement of Apache brands or trademarks by third parties, please follow our Apache Trademark Use Reporting Guidelines.
