                         CURRENT SERVER DEVELOPMENT

Much faster than I thought possible, there are multiple people submitting
patches/ideas for Current. Already, this has caused me to make some 
management decisions. 

Here are the rules so far. 

Notes about logging:
    *) At this point in time we are still using Hunter's logging.py
       module, which I think works overly well.  In the future we may 
       wish to move to the Python logging stuff in 2.3

    *) The more I think about it the more I'm convinced that logging
       well never be 'clean.'  But we do as much as posslible.

    *) Do we use Apache's logging system such as error_log and access_log?
       No.  All logs go into the Current logging module.  The one
       exception is logging done before the Current backend is completely
       initialized.  Users should not have to adjust Apache's log level
       to see Current information.

    *) There are several logging levels.  Each has its own purpose.  Use
       them as described below.  Avoid logging Exceptions unless you
       catch them and do something sane with them but they still really 
       need to be reported.  Otherwise the main handler will do that for 
       you.  Avoid duplicate log messages.

       MANDATORY - Cirtical errors.  Current blew up here.
       
       VERBOSE   - Information the user should know about but is not
                   impeding doom for Current

       DEBUG     - Logging of a major step in program flow.  Ie: dispatching
                   API methods

       DEBUG2    - Variables/Parameters for the DEBUG level.

       TRIVIA    - Useful information to developers.  Ie: In method foobar()

       TRACE     - Detailed program traces, stacks, variables.  Think about
                   the next level up being PDB.


For people who want to submit general patches to Current:
    1. No changes required to up2date client.
       We are only doing a server here. 

       We provide example config files (/etc/sysconfig/rhn/*) and a spec
       file to turn off rhnsd (which we dont' support yet) and add a cron
       job to replace rhnsd. HOWEVER, we make _no_ code changes to up2date.
       That distinction is important.
       
    2. Patches should be made using the -r, -u, and -N options. 
       Anything other than unified diffs will be ignored.

    3. Always have a version number with your patch - about half of all 
       patches end up needing a couple versions to go in.

    4. Follow the coding/naming conventions already in Current.
       ':'s effectively end a line - no one liners.
       Variable names should be descriptive in all but the most obvious
       cases, etc etc. 

    5. You MUST update any docs to go with your patch. If you add 
       something (sql backend, whatever) there better be a new file in the
       docs directory. If you just change something, the docs that exist
       should be updated (you added a new shelf? Better update the docs)
       If its just a bug fix, feel free to just describe it in your email -
       I'll document the bug when I apply the patch.

    6. Don't change the CHANGELOG or the version number in your patch- 
       I'll deal with that when I apply your patch.

    7. We use CVS at current.tigris.org
                     
    8. Each patch should be ONE change, and ONE change only. Don't send
       two features or a feature and bugfix in one patch - send two 
       patches. Multiple bugfixes in one patch might be ok if they are 
       related.
       
                   
For people who are working on backends for Current:
    *. Python DB API V2.0. Developed with PostgreSQL (for now)

       I will accept no other backend patches UNTIL we have a stable,
       sane postgres backend. Functionality FIRST, portability SECOND.
       Patches against the postgres work to make later porting easier
       will be carefully considered.
       
    *. Sane handling of multiple rpm name/version/release/epoch (NVRE) and
       arch (A) per channel.

    *. Rpm's and rpm headers on file system so they could be served with
       apache and mod_python.

    *. Recurse directories on database population.  Ignore files that are not
       rpms. Install trees are not just rpm files - don't require that.

    *. Works correctly with stock Redhat NFS/FTP install trees.

    *. Works correctly with simple mirror of updates.redhat.com

    *. Can add or remove rpms from channel without having to rebuild the
       entire database.

    *. Will lay foundation for "non-anonymous" mode, enabling "up2date -p",
       subscribed channels, and lots more.

    *. Provide at least as much functionality as the existing shelve
       implementation (in 1.4.x)
   
                         
What follows below is a random collection of thoughts. Ignore them at 
your peril.


* Watch out for client side caching in 2.7 and later clients - I lost a full
  days development time trying to figure out why the client never seemed to
  do more than one GET to the server, yet still knew the "wrong" answer.  It
  caches darn near everything - which is a good, desirable feature, as long
  as you know its there!. Delete everything in /var/spool/up2date to get
  fresh hits against the database.
  
  This also explained why they bothered having database "versions" or 
  last_modified values - the client will know to pull down fresh data if 
  the database changes. Yes, I felt bloody stupid.
  
* An ongoing question is whether to keep the sysid and headers that 
  the Current server issues exactly the same as what the RHN servers issue,
  or just compatible (IE, everything the client expects, but leave out the 
  RHN stuff we don't use, and add anything we want.) I can see benefits/
  problems either way. Comments welcome.
  
* One of the fundamental goals of Current is to never modify the client
  software. This software does a critical task, and modifying the client
  frankly implies I don't know what I'm doing. 

  
Comments? What do YOU want the server to look like?  
