Date: Sat, 04 Jul 1998 08:05:52 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Matthew Dillon <dillon@backplane.com> Cc: committers@FreeBSD.ORG Subject: Re: CVS commit privs Message-ID: <16986.899564752@time.cdrom.com> In-Reply-To: Your message of "Fri, 26 Jun 1998 20:54:47 PDT." <199806270354.UAA17913@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Welcome, new committer, to the FreeBSD development team! The following docs are provided to orient you on doing CVS operations on the FreeBSD central repository machine. A basic familiarity with CVS is already assumed, though CVS reference information, tutorials, and FAQs can also be found at: http://www.cyclic.com/cyclic-pages/books.html Table of contents: ------------------ 1.0 Administrative details 2.0 CVS operations 3.0 Conventions and Tradition 4.0 Developer relations 5.0 GNATS 6.0 Who's who 7.0 SSH quick-start guide 1.0. Administrative details --------------------------- Repository host: freefall.freebsd.org Login methods: ssh, telnet, rlogin CVSROOT: /home/ncvs CVS repository meister: Peter Wemm <peter@FreeBSD.org> Mailing list: committers@freebsd.org [which you are now on] Mentor name: Jordan Hubbard <jkh@freebsd.org> Noteworthy CVS Tags: RELENG_2_2 (2.2-stable), HEAD (-current) It is strongly recommended that you use only ssh with public key authentication to access the repository host. This is more secure than telnet or rlogin since your connection will be encrypted and your password never sent in the clear. With utilities like ssh-agent and scp also available, it's also far more convenient. If you don't know anything about ssh, please see section 7.0 of this document. 2.0. CVS operations ------------------- CVS operations are usually done by logging into freefall, making sure the CVSROOT environment variable is set to /home/ncvs, and then doing the appropriate check-out/check-in operations. If you wish to add something which is wholly new (like new ports, contrib-ifid sources, etc), a script called ``easy-import'' is also provided for making the process easier. It automatically adds the new module entry, does the appropriate thing with `cvs import', etc. - just run it without arguments and it will prompt you for everything it needs to know. If you're familiar with RCVS and consider yourself pretty studly with CVS in general, you can also do CVS operations directly from your own machine and working sources, just remember to set CVS_RSH to ssh so that you're using a relatively secure/reliable transport. If you have no idea what any of that means, on the other hand, then please stick with logging into freefall and applying your diffs with patch. :) 3.0. Conventions and Tradition ------------------------------ The CVS Repository Meister (Peter Wemm) is the owner of the CVS repository and responsible for any and _all_ direct modification of it for the purposes of cleanup or fixing some grievous abuse of CVS by a committer. If you mangle the repo by mistake, do NOT attempt to fix it yourself, mail or call Peter immediately and report the problem to him instead. No one is allowed to directly fiddle the repository bits except for the repo-meister. If you are a new committer, your very first commit should be to add yourself to the developer's section (28.2) of the Handbook. Figuring out how to check the handbook out and add an entry for yourself is relatively easy but still remains a good first test of your CVS skills. If you can handle that one, you're probably going to be OK. :) All new committers also have a "mentor" assigned to them for the first few months, the name of your mentor listed at the top of this message. Your mentor is more or less responsible for explaining anything which is confusing to you and is also responsible for your actions during this initial period. If you make a bogus commit, it's only going to embarrass your mentor and you should therefore probably make it a policy to pass at least your first few commits by your mentor before committing it to the repository. All commits should go to -current first before being merged to -stable. No major new features or high-risk modifications should be made to the -stable branch. 4.0. Developer relations ------------------------ If you are working directly on your own code or on code which is already well established as your responsibility somehow then there is probably little need to check with other committers before jumping in with a commit. If you see a bug in an area of the system which is clearly orphaned (and there are a few such areas, to our shame), the same applies. If, however, you are about to modify something which is clearly being actively maintained by someone else (and it's only by watching the cvs-all mailing list that you can really get a feel for just what is and isn't) then consider sending the change to them instead, just as you would have before becoming a committer. For ports, you should contact the listed MAINTAINER in the Makefile. For other parts of the repository, if you are unsure who the active maintainer might be, it may help to scan the output of ``cvs log'' to see who's committed changes in the past. If your queries go unanswered or the committer otherwise indicates a lack of proprietary interest in the area affected, go ahead and commit it. If you're at all unsure about a commit for any reason in general, have it reviewed by -hackers first before committing. Better to have it flamed then and there rather than when it is part of the CVS repository. If you do happen to commit something which results in controversy erupting, you may also wish to consider backing the change out again until the matter is settled. Remember - with CVS we can always change it back. :) 5.0. GNATS ---------- The FreeBSD Project utilizes GNATS for tracking bugs and change requests. Be sure that if you commit a fix or suggestion found in a GNATS PR, use ``edit-pr <pr-number>'' on freefall to close it. It's also considered nice if take time to close any PRs associated with your commits, if appropriate. Your can also make use of send-pr(1) yourself for proposing any change which you feel should probably be made, pending a more extensive peer-review first. You can find out more about GNATS at: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html http://www.freebsd.org/support.html http://www.freebsd.org/send-pr.html send-pr(1) 6.0. Who's who -------------- Besides Peter Wemm, the repository meister, there are other FreeBSD project members whom you will probably get to know in your new role as a committer. Briefly, and by no means all-inclusively, these are: Satoshi Asami <asami@FreeBSD.ORG> Is the portsmeister, meaning that he has ultimate authority during code freezes over any modifications to the ports collection or ports make macro files. Bruce Evans <bde@FreeBSD.ORG> Is Obersturmbahnfuhrer of the Style Police. When you do a commit that could have been done better, Bruce will be there to note it to you. Be thankful that someone is. David Greeman <davidg@FreeBSD.ORG> Is our principal architect and overseer of the VM system. If you have a VM system change in mind, coordinate it with David. Should you become locked in bitter, intractable dispute with some other committer over a proposed change (which doesn't happen very often, thankfully) then an appeal to David to put on his P.A. hat and make a final decision can also occasionally be necessary. Jordan K Hubbard <jkh@FreeBSD.ORG> Is the release engineer. He is responsible for setting release deadlines and controlling the release process. During code freezes, he also has final authority on all changes to the system for whichever branch is pending release status. If there's something you want merged from -current to -stable (whatever values those may have at any given time), he's also the one to talk to about it. Steve Price <steve@FreeBSD.ORG> Steve is unofficial maintainer of /usr/src/bin. If you have something significant you'd like to do there, you should probably coordinate it first with Steve. He's also Problem Report-meister, along with Poul-Henning Kamp. Brian Somers <brian@FreeBSD.ORG> Official maintainer of /usr/bin/ppp and LPD. If you as efficient as god on changing PPP, so if you intend to help out there, be prepared to feel quite inadequate as he end up doing everything. Garrett Wollman <wollman@FreeBSD.ORG> If you need advice on obscure network internals or aren't sure of some potential change to the networking subsystem you have in mind, Garrett is the man to talk to. 7.0. SSH quick-start guide -------------------------- 1. Update and install the ssh port in /usr/ports/security/ssh (should be version 1.2.25 or later). 2. Make sure that you run ssh-agent before running other applications. X users, for example, usually do this from their .xsession file. See ssh-agent(1) for details. 3. Generate a key pair using ssh-genkey(1). The key pair will wind up in the $HOME/.ssh directory. 4. Copy your public key ($HOME/.ssh/identity.pub) into your ``authorized_keys'' file in your home directory on the freefall (i.e. $HOME/.ssh/authorized_keys). 5. Now you should be able to use ssh-add(1) for authentication once per session. This will prompt you for your private key's pass phrase, and then store it in your authentication agent (ssh-agent) so that you won't have to retype it over and over. 6. Test by doing something such as ``ssh freefall.freebsd.org ls /usr''. For more information, see /usr/ports/security/ssh and ssh(1), ssh-agent(1), scp(1) and ssh-keygen(1). Good luck, and welcome aboard! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16986.899564752>