Date: Thu, 5 Mar 1998 10:18:56 +0000 From: nik@iii.co.uk To: hackers@FreeBSD.ORG, ports@FreeBSD.ORG Subject: [Proposal] Policy for ftp://ftp.freebsd.org/pub/incoming/ and its environs Message-ID: <19980305101856.57666@iii.co.uk>
next in thread | raw e-mail | index | archive | help
Hi folks [ x-posted to -hackers and -ports, since it affects both communities. Reply-to *not* set, please reply to the mailing list which is most appropriate (or directly to freebsd-maintainers@ftp.freebsd.org) ] Your FreeBSD 'maintainers' have been busy over the past few weeks working through /incoming/, and in the process have come up with the following proposal, which will affect everyone who's uploaded stuff into /incoming/, and anyone who regularly trawls through that directory to commit new ports, patches and so on. Comments appreciated. If there are no complaints then we'll (a) start doing things like this and (b) roll a variation on this description into the handbook. [Proposal] Policy for ftp://ftp.freebsd.org/pub/incoming/ and its environs $Id: policy-incoming.sgml,v 1.5 1998/03/04 22:26:51 nik Exp $ Contents 1 Outline 2 The maintainers 3 New directories and policies 3.1 development/ports/mumble/ 3.2 development/mumble/ 3.3 development/misc/ 3.4 downloads/ 3.5 incoming/ 4 Conclusion This document proposes a new policy for the maintenance of incoming/ directory (ftp://ftp.freebsd.org/pub/incoming/) and associated directories. The aim is to alleviate the current situation, where incoming/ has become a dumping ground for all manner of ports submissions, patches to the OS and other assorted bits and pieces. 1 Outline The maintainers have the job of sifting through incoming/, removing outdated files and trying to organise what remains. The maintainers will periodically (typically every few days) work through new submissions moving them into one a number of new directory hierarchies. Other people and/or automated scripts will then manage the files from there. 2 The maintainers The current maintainers are Steve Sims and Nik Clayton. They can be reached (collectively) as FreeBSD-maintainers@ftp.FreeBSD.ORG. 3 New directories and policies As files are removed from incoming/ they will be placed in one of a number of new directory hierarchies, depending on the nature of the file. 3.1 development/ports/mumble/ Anything in incoming/ that looks like a port tarball will be examined. If the port has already been committed to the ports system then it will be deleted. Otherwise, the port tarball (and any associated README) will be moved to a directory under development/ports/. The directory it is moved to depends on the port. The maintainers will endeavour to ensure that the directory hierarchy under development/ports/ mirrors that of a regular ports tree. However, there will be occasions where the specific category to use will not be obvious, in which case the port will be placed in development/ports/unfiled/. The maintainers will endeavour to see if there is an outstanding PR relating to that port. If there is, the port tarball will be renamed, and the PR number will be placed at the beginning of the filename, seperated with a period ``.''. The maintainer will then update the PR to indicate the new location of the tarball. It is envisaged that members of the ports team will periodically check these directories for new submissions, and either commit them or reject them. When the ports team member has done this, they should remove the tarball from this directory. It should be possible (with a little sh and cron) to have interested parties automatically e-mailed shortly after new ports are moved to this hierarchy. Periodically, a maintainer will check the contents of this directory, to see if any ``ports with a PR number'' have had their associated PR closed. If they have, the maintainer will delete the tarball. This directory will be read-only from the FTP server. 3.2 development/mumble/ Specific, on-going FreeBSD projects that have not yet been (and may not be) integrated into the codebase will receive (upon request from the developer) a directory under the development/ hierarchy. Examples of current projects that would fit under this scheme include PicoBSD, the soft update patches, ISA PNP code and the bISDN submission. The developer may (or may not) receive a login on wcarchive to write to that portion of this hierarchy that covers their projects. That's not yet been decided. In the event that they don't, the developer will need to e-mail the maintainers when they have uploaded a new version of their code into incoming/, and the maintainers can move it over. This directory will be read-only from the FTP server. 3.3 development/misc/ Anything that looks like a one off development project (for example, Julian Ellischer's ``suiddir'' patches) will be moved to this directory. The maintainers will endeavour to keep an up to date INDEX in this directory, outlining what the various submissions do. This directory will be read-only from the FTP server. 3.4 downloads/ Anything that's left in incoming/ that doesn't fit into the above categories is either warez/porn, or has been uploaded in order to make it available to a wider audience, but with a limited useful life span. In the case of the former, it will be deleted. In the case of the latter, it will be moved to this directory. A cron job will clear this directory of all files older than three weeks. This directory will be read-only from the FTP server. 3.5 incoming/ incoming/ stays pretty much as it is now. It is write-only from the FTP server, but the majority of its contents will be moved to another location fairly rapidly, so it shouldn't continue to grow. 4 Conclusion This scheme should mean that incoming/ becomes manageable. It seperates out the ports and development efforts (which make up most of incoming/ at the moment) which should make it easier for the ports team to find and commit submitted ports (and also see which non-PR'd ports have been submitted). It might also ``legitimise'' some of the other development efforts (such as PicoBSD) by giving them their own development directory. Finally, it lets people upload files to incoming/ of use to the wider FreeBSD community, secure in the knowledge that they'll get moved to downloads/ where other people can try them out. -- Work: nik@iii.co.uk | FreeBSD + Perl + Apache Rest: nik@nothing-going-on.demon.co.uk | Remind me again why we need Play: nik@freebsd.org | Microsoft? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980305101856.57666>