Read the Guide for new committers.
That guide is also useful for existing committers, and provides links
to other sources of information.
The Apache Software Foundation periodically organizes conferences
focusing on software developed by Apache and on the way that Apache develops it's software.
Learn about what's happening at Apache, hack code and meet the faces associated with the names!
A face-to-face gathering for the hacking of code.
A face-to-face gathering for work on the Apache infrastructure.
Planet Apache aggregates RSS feeds
from Apache committers. It's not run by the ASF but committers with blogs
are welcomed. See the contents of the committers/planet directory
in the private repository.
You might notice something that needs changing, for example the
configuration for a mailing list. The request to the infrastructure@ 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.
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.
Please see the Machines List.
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 FAX'd documents, this is quick.
For smail'd 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. Others will need to wait until Jim's page
is regenerated from that file and so they may experience an additional delay.
These are legal documents.
It would be easier for the ASF to use more modern methods (for example signed emails)
but the legal standing of documents sent by these methods has not yet been well tested by US courts. The legal
standing of documents sent by FAX and postal mail has been well established in the US courts and so these
method must be used.
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. For a more technical overview, please read,
the project creation guide.
Henk Penning and
Vadim Gritsenko
have such statistics and cool charts.
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:
- Deciding on release plans and releases
- A prime responsibility of the Committers is to decide when a branch of code is ready for release.
A release is not to taken lightly; each release must uphold the Apache tradition of quality.
Each Project Management Committee formally authorizes the distribution of releases to the public.
- Applying patches
- In order to grow and maintain healthy communities, committers need to discuss, review and apply
patches submitted by volunteers. The Committers are also responsible for the quality and IP
clearance of the code that goes into ASF repositories.
- Helping users
- Committers should monitor both the dev and user lists for the projects that they work on
and (collectively) provide prompt and useful responses to questions from users.
- Monitoring commits and issues
- Committers should review commit email messages for their projects and point out
anything that looks funny or that may bring in IP issues. Monitoring Bugzilla / Jira for
bugs or enhancement requests is also a responsibility of Committers.
- Helping out with the web site
- The main Apache web site and the project web sites are in constant need of
maintenance. The Committers on a project are expected to collectively maintain
the project's web site. The Apache Committers as a whole share the responsibility to maintain
the main Apache site.
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.
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
Any message about a change to the host key 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.
The permanent home for Apache accounts is people.apache.org.
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.
The most common reason is that you've forgotten your password!
The password used for subversion is not the same as the password
you use for access to people.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.)
Please don't assume that infrastructure have made a mess of permissions
or that something has mysteriously broken: you'll just feel very small
when infrastructure tell you to log onto people.apache.org
and reset your password by typing:
> svnpasswd
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.
In Subversion, url: https://svn.apache.org/repos/private/committers
When you are initially granted karma for a new project you may see a message similar to:
svn: Commit failed (details follow):
svn: MKACTIVITY of '/repos/asf/!svn/act/090eb2e4-560f-0410-81de-d8ec7c0669a2': \
403 Forbidden (http://svn.apache.org)
The clue here is the URL: http://svn.apache.org. Commits to an ASF repository are only
allowed over https but the current working copy has been checked out over http. Subversion provides
an easy way to change the working copy: svn switch. For example:
svn switch --relocate http://svn.apache.org/repos/asf/project/module \
https://svn.apache.org/repos/asf/project/module
Very rarely if ever. Please read this.
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.
Anyone with access to the apmail account can run the command
ezmlm-list ~/lists/project/listname | wc -l
to get a count of addresses. Remember that there often are people
subscribed to the digest version too
(~lists/project/listname/digest).
Moderators can send emails to listname-list@tlp.apache.org.
However, most committers do not have access to apmail. See the notes
in the "committers" SVN module at /docs/resources.txt for another way.
Ask your PMC to send a request to the apmail alias.
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 are the existing moderators, 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, then just ignore the mail and it will bounce
after 5 days, or reply to the -reject address in the mail
header.
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 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 apmail@apache.org and
get them to enable remote administration.
See the EZMLM
"Moderator's and Administrator's Manual". You can
also send email to {listname}-help@tlp.apache.org 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
If you have a troublesome poster, then you can un-subscribe them from
the list using {listname}-unsubscribe-badboy=menace.com@tlp.apache.org
(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}-deny-subscribe-badpostmaster=menace.com@tlp.apache.org
(and send a courtesy email to them).
When there is no .forward file then mail builds up in the Mailbox
of your people.apache.org home directory.
This is a bad thing. Sooner or later, all that mail will need to be downloaded.
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!
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.
Committers' FAQ