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

Mon Dec 27 12:42:43 UTC 2010

It occasionally goes down.

I/Bernard are sort of using it at the moment for our wireless hacking.
I've not yet really had a shot at using it for collaborative work or
trying to track -head, so I can't comment on that.

Adrian

On 27 December 2010 04:50, Peter Pentchev <roam at ringlet.net> wrote:
> 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.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJNF6qVAAoJEGUe77AlJ98TeacQAJQEVJJqR/3Lrx/ksypGOgLL
> sL8PR8bPEHxur6IBanpmhGuDidxym9xhj/VSsxqAiAEIiOKfX1tsE+fOLcA7Ygtg
> pusQTfhJD4KOCS86aFucXGL0r2gAEKkPUyJAwfORiZSaQsDjfVWKClEvZQNuBEOv
> wk4DeeZsPcKBJCTDiplF/MJLTLgPTHQT30Xjsq2Ci9/f2atqD630v+GicywRo1Ha
> jx9BF4wOF4o/1+XImB/eRWy8ZGAoHAwiFioFQwWSncEVbTPbnrHhiOZGBs2Ad57S
> iaD+qEDRrD+Pc/fOcrHEKxE6frk1dskl9TOYUGWXh/XOhrCA4B0I+J8Q7elTCsrB
> FFrsO2OTZOzWwTzSF/zLMsx8jAA/Flk7N86Fz5mf566P0GMn4dd/XR6oZXbAMasy
> FJOPi7SllmQeVwLERwwQgxKCVIUB2ofYN+76jMxM11qbpXlBD5wipMV/nOAULrSg
> vvj2Mi4d4aunUPy8J2AOYfc3RpqPRmDALXGz+g2ExFii2qN6qYxvrrxUa3PZHIu1
> N1d5yZM5Mm0NoiJJtQOlSi51NKydL5wcNvpPKg4XWJXz3H7b+4fNXKY/D4O+lkBr
> jhC9OvWV3vzx/ME34GVjJAP3LT7E1ArWz0kyGQYEU5jzthPJd27L7vO+ftLJziVA
> yQRepT6Dh6BtD6SdIFCQ
> =o6Cb
> -----END PGP SIGNATURE-----
>
>