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

[Peter Pentchev]

On Sun, Dec 26, 2010 at 09:42:29PM +0100, Ulrich Spörlein 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.
> > 
> > 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
> 
> 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.

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? :)

G'luck,
Peter

-- 
Peter Pentchev	roam at space.bg    roam at ringlet.net    roam at FreeBSD.org
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20101226/032815fb/attachment.pgp