Let's adopt a standard nomenclature for webs of patch trees etc.

[Julian H. Stacey]

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
			http://berklix.com/~jhs/src/bsd/fixes/FreeBSD
		My application script
			http://berklix.com/~jhs/bin/.csh/customise

	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

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.