From owner-freebsd-arch@FreeBSD.ORG Thu Dec 30 00:36:16 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 95EF41065670 for ; Thu, 30 Dec 2010 00:36:16 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from tower.berklix.org (tower.berklix.org [83.236.223.114]) by mx1.freebsd.org (Postfix) with ESMTP id E17F68FC13 for ; Thu, 30 Dec 2010 00:36:15 +0000 (UTC) Received: from park.js.berklix.net (p5B22C67B.dip.t-dialin.net [91.34.198.123]) (authenticated bits=0) by tower.berklix.org (8.14.2/8.14.2) with ESMTP id oBU0a8rW080032 for ; Thu, 30 Dec 2010 00:36:11 GMT (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id oBU0a3Zh010426 for ; Thu, 30 Dec 2010 01:36:05 +0100 (CET) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id oBU0ZwdB094266 for ; Thu, 30 Dec 2010 01:36:03 +0100 (CET) (envelope-from jhs@fire.js.berklix.net) Message-Id: <201012300036.oBU0ZwdB094266@fire.js.berklix.net> To: freebsd-arch@freebsd.org From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Sun, 26 Dec 2010 22:50:33 +0200." <20101226205033.GA4135@straylight.ringlet.net> Date: Thu, 30 Dec 2010 01:35:58 +0100 Sender: jhs@berklix.com 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: Thu, 30 Dec 2010 00:36:16 -0000 Peter Pentchev wrote: > 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? :) I don't know enough to comment re. Git versus others, but there's a comparative feature table of 4 : SVN HG GIT MTN at http://wiki.freebsd.org/VersionControl I take the point that patches would be better in source code control systems, not raw (BTW which revisions my own patches apply to, is currently in (mostly sym-linked) names, I'd convert to whatever if we achieve a standard. ) Taking into account all written, how about this: http://www.berklix.com/~jhs/src/bsd/indexes.html Anything to change Or add to format? Any entries to add ? If agreeable here ? I'd then float it to hackers@ to get more entries, then offer it to be adopted into wiki if possible. Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Mail plain text; Not quoted-printable, or HTML or base 64. Avoid top posting, it cripples itemised cumulative responses.