From owner-freebsd-arch@FreeBSD.ORG Sun Dec 26 21:11:03 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 340B21065679 for ; Sun, 26 Dec 2010 21:11:03 +0000 (UTC) (envelope-from roam@ringlet.net) Received: from praag.hoster.bg (praag.hoster.bg [77.77.142.10]) by mx1.freebsd.org (Postfix) with ESMTP id 956928FC08 for ; Sun, 26 Dec 2010 21:11:02 +0000 (UTC) Received: from middenheim.hoster.bg (middenheim.hoster.bg [77.77.142.11]) by praag.hoster.bg (Postfix) with ESMTP id EBE678C9E8 for ; Sun, 26 Dec 2010 22:50:44 +0200 (EET) Received: from straylight.ringlet.net (unknown [94.155.53.142]) (Authenticated sender: roam@hoster.bg) by mail.hoster.bg (Postfix) with ESMTP id 5F3655C3D5 for ; Sun, 26 Dec 2010 22:50:34 +0200 (EET) Received: from roam (uid 1000) (envelope-from roam@ringlet.net) id 416007 by straylight.ringlet.net (DragonFly Mail Agent) Sun, 26 Dec 2010 22:50:33 +0200 Date: Sun, 26 Dec 2010 22:50:33 +0200 From: Peter Pentchev To: "Julian H. Stacey" , freebsd-arch@freebsd.org Message-ID: <20101226205033.GA4135@straylight.ringlet.net> Mail-Followup-To: "Julian H. Stacey" , freebsd-arch@freebsd.org References: <201012261728.oBQHSK40032421@fire.js.berklix.net> <20101226204229.GS23098@acme.spoerlein.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20101226204229.GS23098@acme.spoerlein.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-MailScanner-ID: 5F3655C3D5.71013 X-hoster-MailScanner: Found to be clean X-hoster-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0.001, required 10, autolearn=disabled, UNPARSEABLE_RELAY 0.00) X-hoster-MailScanner-From: roam@ringlet.net X-hoster-MailScanner-To: freebsd-arch@freebsd.org X-Spam-Status: No Cc: Subject: Re: Let's adopt a standard nomenclature for webs of patch trees etc. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2010 21:11:03 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 26, 2010 at 09:42:29PM +0100, Ulrich Sp=C3=B6rlein wrote: > On Sun, 26.12.2010 at 18:28:20 +0100, Julian H. Stacey wrote: > > Was Subject: Re: Schedule for releases > > I changed it, as my reply takes it too far off that topic. > >=20 > > Erik Cederstrand wrote: > > > Hi Mike, > > > Den 22/12/2010 kl. 18.45 skrev Mike Karels: > > >=20 > > > > - Those of us doing backports could probably do a better job of > > > > sharing the results. On the other hand, I'm generally backporting > > > > to a specific release (currently 6.3 or 7.2) rather than -stable, > > > > and we're testing our software rather than FreeBSD. > > >=20 > > > Thanks for taking the time to write your comments. What strikes me is= =3D > > > that we may have lots of non-FreeBSD developers working to backport = =3D > > > stuff in their own private trees. Possibly a lot of redundant work is= =3D > > > being done. > > >=20 > > > Even though you're backporting to a specific release, and even though= =3D > > > you're only testing the work via your own software, would it not help= =3D > > > others and possibly even yourself if this FreeBSD-specific work lands= in =3D > > > the FreeBSD repository instead of your private tree? In my view you'r= e =3D > > > just as much a FreeBSD developer as people with commit access that ar= e =3D > > > scratching their own itches in CURRENT. > > >=20 > > > Erik=3D > >=20 > > Good point, Probably loads of fixes from non commiters never get > > sent back to FreeBSD. Many people will have motivation only to fix loc= al > > problems, but no time to send back, especially deterred by clunky send-= pr. > >=20 > > Though I & many others have sent lots of send-pr, =20 > > contributing even a spelling correction to FreeBSD > > is much harder than to eg http://wikipedia.org > > =09 > > + a beginner has to bend their brain to send-pr=20 > > =09 > > + send-pr user should not be burdened exploring tree to find=20 > > Maintainer to send-pr CC (which should be automaticly > > extracted from tree on a ports =3DMAINTAINER basis > > or eg a src/ .MAINTAINER per some sub directories > > where there is a volunteer or mail list) > > =09 > > + send-pr user must spend time composing a > > diplomatic & attractive subject & body, to catch > > some gnats@ readers eye, to get them to stop browsing > > get interested, & commit. > > =09 > > Many a potential contributor's attitude will be: I don't > > have time: Catch the diff or drop it, your loss ! > >=20 > > So a lot of potential send-pr won't get filed, but I bet local users > > don't toss their fixes though, but keep local patch kits, till if > > ever they or others send-pr & something gets commited, (which might > > be days or years later). > >=20 > > Those diff trees stored localy, users could easily export via > > rdist/rsync etc to their local webs, eg I do this: > > My diffs in a tree structure > > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD > > My application script > > http://berklix.com/~jhs/bin/.csh/customise > >=20 > > Those trees, FreeBSD could encourage users to keep in a standard > > format (path nomenclature etc) & we should reccomend, > > indexed from a common page on eg wiki.freebsd.org > >=20 > > It would make a search tool &/or automatic periodic indexing > > for possible diffs so much better than any general purpose > > search engine. > >=20 > > Index of uncommited patches ready for test, would be ideal > > for those currently stuck, & would assist more motivated > > testers corroborating good patches worth commiting. > >=20 > > A standard format would increase chances patch kits are found, > > even if patch creator too busy to file send-pr etc. > >=20 > > Let's adopt standards to make searches for potential patch trees easier: > > - Adopt a common path root & nomenclature for all our trees of local di= ffs, > > - Ask users to mirror local uncommited trees of diffs to thir local webs > > (until if when commited after send-pr, then they delete) > > - Ask authors of local patch kits to submit a single URL to a new wiki = page, > > pointing to top automatically apply-able directory of patches > >=20 > > Later we might also list a SOC project for a crawler indexer, > > - src/ directories could also Optionaly later adopt=20 > > .MAINTAINER files (Subject of previous discussions, please dont let t= hat > > distract from main proposal though) > > - ports/*/*/Makefile MAINTAINER =3D could also be used by a SOC tool >=20 > While this idea is good as a base, doing this with patch-trees is the > worst possible move. Patchfiles lack comments or 'commit info' and they > do not easily record the revision and branch they should be applied to. >=20 > Stacking multiple patches together with comments on what they do, is > exactly what revision control systems were made for. And while we cannot > easily share svn access to random contributors, systems like git or > mercurial are exactly what we need here. >=20 > In other words, we need github for FreeBSD. I'm working on some basics > for this at repos.freebsd.your.org, but had severe VM instabilities > during the last weeks. I have to admit that this crossed my mind as soon as I read Julian's e-mail, especially as I've been keeping my local FreeBSD patches in a version-controlled tree for the past ten years - first CVS, then Subversion, and recently Git. Now, is there a reason we couldn't just use Gitorious? :) G'luck, Peter --=20 Peter Pentchev roam@space.bg roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If the meanings of 'true' and 'false' were switched, then this sentence wou= ldn't be false. --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNF6qVAAoJEGUe77AlJ98TeacQAJQEVJJqR/3Lrx/ksypGOgLL sL8PR8bPEHxur6IBanpmhGuDidxym9xhj/VSsxqAiAEIiOKfX1tsE+fOLcA7Ygtg pusQTfhJD4KOCS86aFucXGL0r2gAEKkPUyJAwfORiZSaQsDjfVWKClEvZQNuBEOv wk4DeeZsPcKBJCTDiplF/MJLTLgPTHQT30Xjsq2Ci9/f2atqD630v+GicywRo1Ha jx9BF4wOF4o/1+XImB/eRWy8ZGAoHAwiFioFQwWSncEVbTPbnrHhiOZGBs2Ad57S iaD+qEDRrD+Pc/fOcrHEKxE6frk1dskl9TOYUGWXh/XOhrCA4B0I+J8Q7elTCsrB FFrsO2OTZOzWwTzSF/zLMsx8jAA/Flk7N86Fz5mf566P0GMn4dd/XR6oZXbAMasy FJOPi7SllmQeVwLERwwQgxKCVIUB2ofYN+76jMxM11qbpXlBD5wipMV/nOAULrSg vvj2Mi4d4aunUPy8J2AOYfc3RpqPRmDALXGz+g2ExFii2qN6qYxvrrxUa3PZHIu1 N1d5yZM5Mm0NoiJJtQOlSi51NKydL5wcNvpPKg4XWJXz3H7b+4fNXKY/D4O+lkBr jhC9OvWV3vzx/ME34GVjJAP3LT7E1ArWz0kyGQYEU5jzthPJd27L7vO+ftLJziVA yQRepT6Dh6BtD6SdIFCQ =o6Cb -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--