Date: Thu, 30 Dec 2010 01:35:58 +0100 From: "Julian H. Stacey" <jhs@berklix.com> To: freebsd-arch@freebsd.org Subject: Re: Let's adopt a standard nomenclature for webs of patch trees etc. Message-ID: <201012300036.oBU0ZwdB094266@fire.js.berklix.net> In-Reply-To: Your message "Sun, 26 Dec 2010 22:50:33 %2B0200." <20101226205033.GA4135@straylight.ringlet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012300036.oBU0ZwdB094266>