Let's adopt a standard nomenclature for webs of patch trees
etc.
Julian H. Stacey
jhs at berklix.com
Thu Dec 30 00:36:16 UTC 2010
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.
More information about the freebsd-arch
mailing list