| Translate 
 
   
 
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
IBU 
Consol
 |  | Index Of Trees Of Sources Not Yet Committed To FreeBSDIndex To Peoples ( 
    src/ ports/
    doc/ ) Trees Of Sources Not As Yet Committed To FreeBSD source trees.Motivation: 
    Mail thread starting here (a local extract of Original post here). Proposal: http://wiki.freebsd.org/
    Section: Development resources: Add a new line: Uncommitted
    Sources Pointing to a new page eg http://wiki.freebsd.org/uncommitted/
    with a table, contents to be inherited from this temporary
    table below. TableKey
      
        | EMAIL OF RECORD OWNER | Web mail page for mail, or mailto: (to contact/ check /
        authorise any change of that line in table on wiki, |  
        | CODE ROOT | Where user keeps directories src/
          ports/
        doc/ |  
        | FORMAT | Raw (code or diffs) | CVS | SVN | HG |
        GIT | MTN |  
        | DESCRIPTION | Generic hacks from an individual, or Project Name |  Extract Of Original Post
 
      
        
          |  | 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. 
              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).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 ! 
              Let's adopt standards to make searches for potential
            patch trees easier: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://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD
              My application script http://www.berklix.com/~jhs/bin/.csh/customiseThose 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.orgIt 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. 
              Later we might also list a SOC
            project for a crawler indexer,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 
              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 Replies
 |  |