GNU Libtool


Home | News | Documentation | Contributing | Administration

Maintainership

GNU Libtool was conceived, designed and implemented by:

GNU Libtool's Dynamic Loader library (libltdl) was conceived, designed and implemented by:

GNU Libtool and libltdl have previously been maintained, enhanced, ported and otherwise advanced by:

GNU Libtool and libltdl are currently being cajoled, bullied, rewritten and otherwise dragged into the future by:

The following people also enjoy write access under the given rules:

Applying Patches

Currently we five have admin access to the libtool repository and co-ordinate changes on the libtool-patches list. We observe the following rules when changing the repository:

Submitting Bug Reports

There is a special list for reporting bugs, bug-libtool@gnu.org, to enable the developers to track submitted bug reports. If you think you have found a bug in libtool, then you should, in the first instance send as complete a report as possible to this list. Ideally, you should include the text you get by running config.guess, the text you see when you run configure, and if you can, a patch made with diff -u5 which fixes the problem. If you can send a small script, modelled after the scripts in the tests directory of the distribution which fails with the unpatched distribution, but passes with your patch applied we can add the test to the distribution to make sure the bug doesn't reappear.

Submitting Patches

Every patch must have several pieces of information before we can properly evaluate it.

If you want to be certain that your patch doesn't get lost among the noise on the mailing list, you can also upload a copy to the patch manager at savannah. Please bear in mind that not all of the maintainers have easy access to the web, so, until savannah is able to mirror new patches directly to the patch list, you will need to manually send a copy there too. If you only want to submit your patch once, then send it to the libtool-patches@gnu.org mailing list and not the savannah patch manager.

When you have submitted your patch, somebody will tell you what to do next. If the patch is small, just send it directly to the list. Be sure to send the patch as a mime text attachment, or pasted directly into the mail. Uuencoded patches, or patches otherwise rendered unreadable by peculiar mime encoding make it much harder for the libtool developers to read and/or apply your patch. If your patch is very large (more than a hundred kilobytes), try to upload the patch itself to savannah and post only a link to the mailing list.

Persistent contributors who submit high quality patches may be given direct git access. You have been warned.

Coding Standards

All contributions must conform to the GNU Coding Standards. Submissions which do not conform to the standards will be returned with a request to reformat the changes.

ChangeLog entries are formatted according to some specific rules:

Copyright Assignment

Before we can accept non-trivial code contributions from you, we need a copyright assignment on file with the FSF. A description of the process is available here. This boils down to the following instructions:

Release Numbering

Version numbers are chosen to make it easy for users to decide two things:

To make this happen, the maintainers apply patches to the master branch after review, tagging releases as they are made. Before any non-bugfix patch is applied to master, a maintenance branch for the last stable release is made.

Any distribution made from an untagged release in git will have part of that revision's SHA1 appended to the release numebr, so that the users can tell it is an untested build if they use it.

git conventions

The source for libtool is managed collaboratively in git on the FSF Savannah system. The conventions set out below represent how we plan to do things from here on in, although historically, the tree has not been maintained in quite the same way.

git tag names

Libtool releases three types of source tarball from git:

  1. Alpha releases are the lowest quality tarballs we build. They come from master, and indicate that a new point release is coming. You can distinguish an alpha by its four part version number: 2.5.0.1 and 2.5.0.4 for example. Alpha releases are tagged in git as v[major].[minor].0.[alpha-count]: v2.5.0.1 and v2.5.0.4 here.
  2. Point releases are normally reasonable stable, and are the first release made from a new release branch. You can distinguish a point release, because in has only major and minor parts in its version number: 2.2 and 2.4 for example. Point releases are tagged in git as v[major].[minor]: v2.2 and v2.4 here.
  3. Patch releases are only ever made from the most recent release branch and never contain any new features over the point release they fix. You can distinguish a patch release, because it carries a numeric micro version suffix: 2.2.6 and 2.4.2 for example. Patch releases are tagged in git as v[major].[minor].[micro].


Home | News | Documentation | Contributing | Administration

Return to GNU's home page.

Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.

Please send comments on these web pages to webmasters@www.gnu.org, send other questions to gnu@gnu.org.

This article, Copyright © 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA

Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

$Date: 2011/12/21 16:38:17 $ $Author: pogma $