Let's adopt a standard nomenclature for webs of patch trees etc.
uqs at spoerlein.net
Sun Dec 26 20:42:35 UTC 2010
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.
> Erik Cederstrand wrote:
> > Hi Mike,
> > Den 22/12/2010 kl. 18.45 skrev Mike Karels:
> > > - 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.
> > Thanks for taking the time to write your comments. What strikes me is =
> > that we may have lots of non-FreeBSD developers working to backport =
> > stuff in their own private trees. Possibly a lot of redundant work is =
> > being done.
> > Even though you're backporting to a specific release, and even though =
> > you're only testing the work via your own software, would it not help =
> > others and possibly even yourself if this FreeBSD-specific work lands in =
> > the FreeBSD repository instead of your private tree? In my view you're =
> > just as much a FreeBSD developer as people with commit access that are =
> > scratching their own itches in CURRENT.
> > Erik=
> Good point, Probably loads of fixes from non commiters never get
> sent back to FreeBSD. Many people will have motivation only to fix local
> problems, but no time to send back, especially deterred by clunky send-pr.
> Though I & many others have sent lots of send-pr,
> contributing even a spelling correction to FreeBSD
> is much harder than to eg http://wikipedia.org
> + a beginner has to bend their brain to send-pr
> + send-pr user should not be burdened exploring tree to find
> Maintainer to send-pr CC (which should be automaticly
> extracted from tree on a ports =MAINTAINER basis
> or eg a src/ .MAINTAINER per some sub directories
> where there is a volunteer or mail list)
> + 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.
> Many a potential contributor's attitude will be: I don't
> have time: Catch the diff or drop it, your loss !
> 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).
> 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
> My application script
> 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
> It would make a search tool &/or automatic periodic indexing
> for possible diffs so much better than any general purpose
> search engine.
> Index of uncommited patches ready for test, would be ideal
> for those currently stuck, & would assist more motivated
> testers corroborating good patches worth commiting.
> A standard format would increase chances patch kits are found,
> even if patch creator too busy to file send-pr etc.
> Let's adopt standards to make searches for potential patch trees easier:
> - Adopt a common path root & nomenclature for all our trees of local diffs,
> - 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
> Later we might also list a SOC project for a crawler indexer,
> - src/ directories could also Optionaly later adopt
> .MAINTAINER files (Subject of previous discussions, please dont let that
> distract from main proposal though)
> - ports/*/*/Makefile MAINTAINER = could also be used by a SOC tool
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.
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.
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.
More information about the freebsd-arch