head	1.8;
access;
symbols
	HORDE_2_0_RC3:1.8
	HORDE_2_0:1.8
	HORDE_2_0_RC2:1.8
	HORDE_1_2_7:1.1.2.7
	RELENG_2:1.8.0.2
	HORDE_2_0_0_RC1:1.8
	HORDE_1_2_6:1.1.2.6
	HORDE_1_3_4:1.3
	HORDE_1_2_5:1.1.2.6
	HORDE_1_2_4:1.1.2.6
	HORDE_1_3_3:1.3
	HORDE_1_2_3:1.1.2.5
	HORDE_1_2_2:1.1.2.5
	HORDE_1_2_1:1.1.2.5
	HORDE_1_2_0:1.1.2.5
	HORDE_1_2_0_pre14:1.1.2.5
	HORDE_1_2_0_pre13:1.1.2.4
	HORDE_1_2_0_pre11:1.1.2.3
	HORDE_1_3_2:1.2
	HORDE_1_2_0_pre10:1.1.2.3
	HORDE_1_3_1:1.2
	HORDE_1_2_0_pre9:1.1.2.3
	HORDE_1_2_0_pre8:1.1.2.3
	HORDE_1_2_0_pre6:1.1.2.3
	horde-dev-20000104:1.2
	HORDE_1_2_0_pre5:1.1.2.2
	HORDE_1_2_0_pre4:1.1.2.1
	STABLE_1_2:1.1.0.2;
locks; strict;
comment	@# @;


1.8
date	2001.09.14.18.50.56;	author chuck;	state Exp;
branches;
next	1.7;

1.7
date	2001.09.14.18.21.18;	author chuck;	state Exp;
branches;
next	1.6;

1.6
date	2001.09.14.16.07.06;	author chuck;	state Exp;
branches;
next	1.5;

1.5
date	2001.06.25.20.33.51;	author chuck;	state Exp;
branches;
next	1.4;

1.4
date	2001.06.22.21.36.48;	author chuck;	state Exp;
branches;
next	1.3;

1.3
date	2000.10.18.19.43.43;	author bjn;	state Exp;
branches;
next	1.2;

1.2
date	99.08.26.13.09.26;	author rkrusty;	state Exp;
branches;
next	1.1;

1.1
date	99.08.25.04.48.55;	author rkrusty;	state dead;
branches
	1.1.2.1;
next	;

1.1.2.1
date	99.08.25.04.48.55;	author rkrusty;	state Exp;
branches;
next	1.1.2.2;

1.1.2.2
date	99.10.15.00.15.29;	author rkrusty;	state Exp;
branches;
next	1.1.2.3;

1.1.2.3
date	99.12.28.02.32.32;	author jon;	state Exp;
branches;
next	1.1.2.4;

1.1.2.4
date	2000.05.20.03.46.15;	author bjn;	state Exp;
branches;
next	1.1.2.5;

1.1.2.5
date	2000.06.27.14.59.47;	author bjn;	state Exp;
branches;
next	1.1.2.6;

1.1.2.6
date	2000.10.18.19.52.46;	author bjn;	state Exp;
branches;
next	1.1.2.7;

1.1.2.7
date	2001.08.29.00.44.42;	author jon;	state Exp;
branches;
next	;


desc
@@


1.8
log
@test commit
@
text
@=----------------=
HORDE: How To Help
=----------------=
Copyright 1999 Ivan E. Moore II <rkrusty@@tdyc.com>
Copyright 1999 Mike Hardy <mikeh@@spark.com>

This code is licensed under the GNU Public License.
See the file COPYING in the top directory.

Last Updated: 06/23/2001

-------------------------------------------------------------------------

There are many ways in which you can help out in the development of any of
the HORDE projects. The first and best way you are already doing. You're
using them. One of the keys to a great product is its users. Without users
we can't find bugs or get feedback on what's good and what's bad.

There are also certain areas that the development lacks in. Support for
operating systems other than Linux are secondary. Most of the developers
currently primarily use Linux (not saying all). Recently we've had more luck
with testing on other platforms. This is mainly directed towards the Windows
platform as Windows and Linux can act completely different (and Netscape and
Internet Explorer even more so).

With this said, one of the best ways you can help is to test. If you can
help us smooth out the code across all (or even any) platforms, you're doing
a great service to the project.

Now, if that's not enough and you want to dig in and help code, you should
first subscribe to the project lists and read the Coding Standards (see the
LISTS and CODING_STANDARDS files in this directory.

Please send any comments or questions pertaining to this document to:
core@@horde.org.
@


1.7
log
@test commit
@
text
@d34 1
a34 1
Please send any comments or questions pertaining to this document to
@


1.6
log
@meaningless change to test commits.
@
text
@d34 1
a34 1
Please send any comments or questions pertaining to this document to:
@


1.5
log
@Add re-organized but still mostly out of date HELP/LISTS/SOURCE files.

Submitted by: Josh Miller <joshlists@@nebonet.com>
@
text
@d34 1
a34 1
Please send any comments or questions pertaining to this document to
@


1.4
log
@this isn't a rewrite; just fixing a few typos I found in the first few
paragraphs. Yikes. I'll look more later.
@
text
@d8 1
a8 1
See the file COPYING in this directory.
d10 1
a10 1
Last Updated: 08/03/1999
d19 1
a19 1
There is also certain areas that the developement lacks in. Support for
d21 1
a21 1
currently primarily use Linux. (not saying all) Recently we've had more luck
d23 2
a24 2
platform as Windows and Linux at times act totally different. (especially
between Netscape and Internet Explorer).
d27 2
a28 2
help us in any way smooth out the code across all the different platforms
your doing a great service to the project.
d30 3
a32 2
Now, if that's not enough and you want to dig in and help code there's some
things we need to cover.
d34 2
a35 242
First off. You need to remember that when you do get access to the CVS tree
you will have the ability to mess some things up. Not for good mind you as
CVS is pretty kewl in how it handles things. I'll explain more about CVS
later on. You have to remember what your doing and becareful what you commit
and when you commit it.

Because of this it's recommended (and pretty much an unspoken rule) that you
submit your work to the mailing list for a while until we get a bit
comfortable that the code your submitting is good and that your not going to
go crazy on us or anything.

If your going to be an ongoing contributor your in line for a cvs account.
If your only going to be contributing once in a while, there truely is no
need for you to have one.

Now, let's break down everything else.

==========
CVS Layout
==========

The CVS tree has gone through alot of changes lately and is still being
worked out as the new format is implimented. CVS Is layed out kinda
like this:

horde
   /lib
     /src <lots of other stuff under here>
imp
  /lib
    /src  <lots of other stuff under here>

etc...

These are the main directories. horde currently only contains the above
directories and a bunch of stuff below src. horde is the core component
of all horde based products. It will be required by all of them, but 
it does not require any of them. (though it does nothing without one of them)

All modules will reside (after installation) under the horde module like this:

  horde
    /lib
      /src
    /imp
      /lib
        /src
    /troll
       /lib

  etc...

This makes it easy for each module to know exactly where each other is and
how to talk to specific files each may have. For example, the addressbook
functionality of IMP will be torn out of it and built into it's own module
sometime after 2.0.0 is released. With it as it's own module it can work
independantly or with any other module. This would allow people to have
the same addressbook whether they are using IMP or TROLL.

-----======------
Post 2.0.0 Stuff
-----======------

After 2.0.0 is released, alot of things will be changing. Besides me
ripping the contacts section out of IMP, there will be some major 
database and library work going on. The whole sessions problem that
we've been fighting with for a long time will finally be worked out.
SSL authentication and Digital Signatures will be coming back. GNUPG
support will hopefully be added. (Depending on how well it works)

These are just a few off the top of my head. And these are just dealing
with IMP. The other projects within horde will be kicking off again. Most
of the developers have been focusing on IMP to get 2.0.0 out the door
and at the same time stabalize the library code so that all projects can
progress in the same direction and not duplicate efforts. This is
important. 

The current horde modules that I know of are:

 IMP    = IMAP webMail Program
 TROLL   = NNTP News Client
 NAG    = TODO list 
 WEBSHOP  = Shopping cart program
 KRONOLITH = Calendar program
 WHUPS   = Bug tracking system
 LEGIONS  = Enhanced Addressbook

These are at least the one's in the CVS tree. Being able to use any or
all of these at the same time and the ability for them to work within
each other is important. (using the calander within your todo list so
you can set a date correctly)

=-=-=-=-=-=-=-=-=-=-=-
Obtaining CVS accounts
=-=-=-=-=-=-=-=-=-=-=-

Currently CVS accounts are only going out to key developers. Those
contributing single translations (one language) do not fit into
this catagory at this time. Here is a small explanation from Chuck
about this:

  "Until I have either a seperate cvs machine or a nice granular way to do
  access control, I'm not handing out cvs access to people only contributing
  one translation. I'd like to, but it'd be nightmare for me right now and
  it's easy enough to submit the files..."

The best way to submit patchs is to send them either to imp@@lists.horde.org
or to dev@@lists.horde.org. If it's a patch to the horde module itself, the
same applies, plus you can also send it to horde@@lists.horde.org.

===---===
Using CVS
===---===

(Taken from the HORDE FAQ)


IMP uses CVS for source control. If you're curious, there are lots of documents 
available regarding its use and administration. Some of
them may be found at http://www.cyclic.com - they support CVS commercially, even
though it is an open source program. 

IMP CVS is not open to everyone. However, if you submit code a couple times, you
can probably get access if you ask. 

Once you have access, here are the normal things that you will need to do to 
work on the code. 

Before you do anything, you'll need to make sure you have a cvs client 
installed on your machine (check out the Cyclic homepage for
those if you don't have one), and you need to let it know where to get the 
source from. 

For IMP, the CVSROOT is :pserver:username@@cvs.horde.org:/cvs/horde

You will then need to log into the CVS server, so it knows who you are and can 
make sure you're allowed to work on the sources. The command to do is:

       'cvs login' 

One other thing you can do, if you want to, is set an environment variable 
called EDITOR to your favorite text editor. That way when you
commit software changes and it asks you to enter a change description, you 
can do is in your favorite editor (rather than vi, which some love, but
I'm lost in) 

Then for work on developmental, bleeding-edge versions:

  1) Check out the code 'cvs co imp'
  2) Work on the code <hack, hack, hack>
  3) Commit any changes with 'cvs commit "filenames"' in the directory the 
    files are in. 

Sometimes, others will make changes and you will need to update your tree so 
that the changes show up in your local sources. You do this with the
'cvs update' command in the imp directory. 

To work with any labelled version (to patch a stable release, for instance): 

  1) Check out the code 'cvs co -r"label" imp'
  2) Work on the code <hack, hack, hack>
  3) Commit any changes with 'cvs commit "filenames"' in the directory the 
    files are in. 

If somebody else also made changes to the labelled version, you can get them in 
your local source tree with a 'cvs update' command issued in the imp directory.

If you are done working with the labelled source branch, and would like to move 
back into the main development source tree, you can issue a 'cvs update -A'
command to get all the new developmental stuff back. 

If you're feeling adventurous, you can try merging code from the developmental 
branch into a labelled branch (to backport a new feature that stabilized,
for instance) by "joining" the two versions. The command for this is: 

  'cvs update -j"version number with changes" "filename to backport into"'

If you're feeling *very* adventurous, and have talked it over with the list, 
you can label the sources at the current stage of development with this
command in the imp directory, 'cvs rtag "label" imp'. 

You can also create a labelled branch (to stabilize a release, or do something 
*really* experimental) with this command in the imp directory:

   'cvs rtag -b "root label to branch at" "branch label" imp' 

Those commands encompass all of the source control voodoo you should ever 
need to know to work with the imp sources. If any of these give you
trouble, mail the CVS list for imp: cvs@@lists.horde.org and ask for help.
If you're willing to code for imp, I'm sure someone will lend a hand.

           - Mike <mikeh@@spark.com>

=-=-=-=-=-=-=-=
Other CVS Notes
=-=-=-=-=-=-=-=

If you do end up getting a cvs account here are some tips to help 
keep things happy:

  1> Subscribe to the cvs@@lists.horde.org and dev@@lists.horde.org mailing
   lists

  2> Label all uploads with your name or initials. 
   When you commit changes to cvs it asks you for comments. In this
   area do something like this:

   [IEM] fixed the lines in compose.php3 that annoyed Chuck.

   The reason for this is that it first off tells use quickly who
   made the change. CVS will then tell us exactly what was changed, but
   that requires work. CVS mails these logs to cvs@@lists.horde.org so
   with a quick glance at an email we know who did what.

  3> If your planning on doing anything major please let people know
   in advance. cvs@@lists.horde.org should be an extremly active
   mailinglist.
   Developers need to communicate extensivly in order to make sure everyone
   knows what's going on. This is extremly important when your working on
   key components.

  4> Use the Bug Tracking System. Currently we are using Bugzilla to
   keep track of bugs. All new submissions are being cc'd to the
   cvs@@lists.horde.org mailinglist so that if we aren't paying attention
   we'll at least get mail about it. Using the Bugs database will help
   us keep track of issues we are having and where we stand with the
   product.

  5> Remember to advance the library version whenever anything major is
   changed. This also goes for a ton of minor changes. This way we
   have some means to break up releases and also track down problems.
   

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This document was prepared by Ivan E. Moore II
It's far from complete and was written from the top of my head. 
It is intended to help future developers understand where we 
are coming from and what some of our current processes are.
Please send any comments or questions pertaining to this document
to:

    Ivan E. Moore II <rkrusty@@tdyc.com>
@


1.3
log
@s/horde.org/lists.horde.org/ for mailing lists.
Repointed patches from support@@horde.org to dev@@lists.horde.org.
@
text
@d14 29
a42 31
There are many ways in which you can help out in the development of
any of the HORDE projects.  The first and best way you are already
doing. Your using them.  One of the keys to a great product is 
it's users.  Without users we can't find bugs nor get feedback on
what's good and what sucks.

There is also certain areas that the developement lacks in.  Support
for operating systems other than Linux are secondary.  Most of the
developers currently primarily use Linux.  (not saying all)  Recently
we've had more luck with testing on other platforms.  This is mainly
directed towards the Windows platform as Windows and Linux at times
act totally different.  (especially between Netscape and Internet 
Explorer).

With this said, one of the best ways you can help is to test.  If
you can help us in any way smooth out the code across all the different
platforms your doing a great service to the project.

Now, if that's not enough and  you want to dig in and help code there's
some things we need to cover.

First off.  You need to remember that when you do get access to the
CVS tree you will have the ability to mess some things up.  Not for
good mind you as CVS is pretty kewl in how it handles things.  I'll
explain more about CVS later on.  You have to remember what your 
doing and becareful what you commit and when you commit it.

Because of this it's recommended (and pretty much an unspoken rule) that
you submit your work to the mailing list for a while until we get a bit
comfortable that the code your submitting is good and that your not
going to go crazy on us or anything.
d45 2
a46 2
If your only going to be contributing once in a while, there truely is
no need for you to have one. 
d48 1
a48 1
Now, let's break down everything else. 
d55 1
a55 1
worked out as the new format is implimented.  CVS Is layed out kinda
d59 2
a60 2
     /lib
         /src  <lots of other stuff under here>
d62 2
a63 2
   /lib
       /src   <lots of other stuff under here>
d67 4
a70 4
These are the main directories.  horde currently only contains the above
directories and a bunch of stuff below src.  horde is the core component
of all horde based products.  It will be required by all of them, but 
it does not require any of them.  (though it does nothing without one of them)
d74 8
a81 8
   horde
        /lib
            /src
        /imp
            /lib
                /src
        /troll
              /lib
d83 1
a83 1
   etc...
d86 1
a86 1
how to talk to specific files each may have.  For example, the addressbook
d88 2
a89 2
sometime after 2.0.0 is released.  With it as it's own module it can work
independantly or with any other module.  This would allow people to have
d96 1
a96 1
After 2.0.0 is released, alot of things will be changing.  Besides me
d98 1
a98 1
database and library work going on.  The whole sessions problem that
d100 2
a101 2
SSL authentication and Digital Signatures will be coming back.  GNUPG
support will hopefully be added.  (Depending on how well it works)
d103 2
a104 2
These are just a few off the top of my head.  And these are just dealing
with IMP.  The other projects within horde will be kicking off again.  Most
d107 2
a108 2
progress in the same direction and not duplicate efforts.  This is
important.  
d112 7
a118 7
  IMP       = IMAP webMail Program
  TROLL     = NNTP News Client
  NAG       = TODO list  
  WEBSHOP   = Shopping cart program
  KRONOLITH = Calendar program
  WHUPS     = Bug tracking system
  LEGIONS   = Enhanced Addressbook
d120 1
a120 1
These are at least the one's in the CVS tree.  Being able to use any or
d122 1
a122 1
each other is important.  (using the calander within your todo list so
d129 1
a129 1
Currently CVS accounts are only going out to key developers.  Those
d131 1
a131 1
this catagory at this time.  Here is a small explanation from Chuck
d134 4
a137 4
   "Until I have either a seperate cvs machine or a nice granular way to do
   access control, I'm not handing out cvs access to people only contributing
   one translation. I'd like to, but it'd be nightmare for me right now and
   it's easy enough to submit the files..."
d140 1
a140 1
or to dev@@lists.horde.org.  If it's a patch to the horde module itself, the
d171 1
a171 1
             'cvs login' 
d181 4
a184 4
    1) Check out the code 'cvs co imp'
    2) Work on the code <hack, hack, hack>
    3) Commit any changes with 'cvs commit "filenames"' in the directory the 
       files are in. 
d192 4
a195 4
    1) Check out the code 'cvs co -r"label" imp'
    2) Work on the code <hack, hack, hack>
    3) Commit any changes with 'cvs commit "filenames"' in the directory the 
       files are in. 
d208 1
a208 1
   'cvs update -j"version number with changes" "filename to backport into"'
d217 1
a217 1
     'cvs rtag -b "root label to branch at" "branch label" imp' 
d224 1
a224 1
                      - Mike <mikeh@@spark.com>
d233 2
a234 2
   1> Subscribe to the cvs@@lists.horde.org and dev@@lists.horde.org mailing
      lists
d236 29
a264 29
   2> Label all uploads with your name or initials.  
      When you commit changes to cvs it asks you for comments.  In this
      area do something like this:

      [IEM] fixed the lines in compose.php3 that annoyed Chuck.

      The reason for this is that it first off tells use quickly who
      made the change.  CVS will then tell us exactly what was changed, but
      that requires work.  CVS mails these logs to cvs@@lists.horde.org so
      with a quick glance at an email we know who did what.

   3> If your planning on doing anything major please let people know
      in advance.  cvs@@lists.horde.org should be an extremly active
      mailinglist.
      Developers need to communicate extensivly in order to make sure everyone
      knows what's going on.  This is extremly important when your working on
      key components.

   4> Use the Bug Tracking System.  Currently we are using Bugzilla to
      keep track of bugs.  All new submissions are being cc'd to the
      cvs@@lists.horde.org mailinglist so that if we aren't paying attention
      we'll at least get mail about it.  Using the Bugs database will help
      us keep track of issues we are having and where we stand with the
      product.

   5> Remember to advance the library version whenever anything major is
      changed.  This also goes for a ton of minor changes.  This way we
      have some means to break up releases and also track down problems.
      
d268 1
a268 1
It's far from complete and was written from the top of my head.  
d274 1
a274 3
        Ivan E. Moore II <rkrusty@@tdyc.com>


@


1.2
log
@[IEM] moving installation and support docs into docs/ subdir to clean
up main tree a bit more. (leaving COPYING and README which points to the
docs dir)
@
text
@d141 3
a143 3
The best way to submit patchs is to send them either to imp@@horde.org or
to dev@@horde.org.  If it's a patch to the horde module itself, the
same applies, plus you can also send it to horde@@horde.org.
d223 2
a224 2
trouble, mail the CVS list for imp: cvs@@horde.org and ask for help. If you're 
willing to code for imp, I'm sure someone will lend a hand.
d235 2
a236 1
   1> Subscribe to the cvs@@horde.org and dev@@horde.org mailing lists
d246 2
a247 2
      that requires work.  CVS mails these logs to cvs@@horde.org so with
      a quick glance at an email we know who did what.
d250 2
a251 1
      in advance.  cvs@@horde.org should be an extremly active mailinglist.
d258 3
a260 3
      cvs@@horde.org mailinglist so that if we aren't paying attention we'll
      at least get mail about it.  Using the Bugs database will help us
      keep track of issues we are having and where we stand with the
@


1.1
log
@file HELP was initially added on branch STABLE_1_2.
@
text
@d1 276
@


1.1.2.1
log
@[IEM] migrating all core documentaiton (except readme and copying) into
the docs/ sub directory
@
text
@a0 277
=----------------=
HORDE: How To Help
=----------------=
Copyright 1999 Ivan E. Moore II <rkrusty@@tdyc.com>
Copyright 1999 Mike Hardy <mikeh@@spark.com>

This code is licensed under the GNU Public License.
See the file COPYING in this directory.

Last Updated: 08/25/1999 [IEM]

-------------------------------------------------------------------------

There are many ways in which you can help out in the development of
any of the HORDE projects.  The first and best way you are already
doing. Your using them.  One of the keys to a great product is 
it's users.  Without users we can't find bugs nor get feedback on
what's good and what sucks.

There is also certain areas that the developement lacks in.  Support
for operating systems other than Linux are secondary.  Most of the
developers currently primarily use Linux.  (not saying all)  Recently
we've had more luck with testing on other platforms.  This is mainly
directed towards the Windows platform as Windows and Linux at times
act totally different.  (especially between Netscape and Internet 
Explorer).

With this said, one of the best ways you can help is to test.  If
you can help us in any way smooth out the code across all the different
platforms your doing a great service to the project.

Now, if that's not enough and  you want to dig in and help code there's
some things we need to cover.

First off.  You need to remember that when you do get access to the
CVS tree you will have the ability to mess some things up.  Not for
good mind you as CVS is pretty kewl in how it handles things.  I'll
explain more about CVS later on.  You have to remember what your 
doing and becareful what you commit and when you commit it.

Because of this it's recommended (and pretty much an unspoken rule) that
you submit your work to the mailing list for a while until we get a bit
comfortable that the code your submitting is good and that your not
going to go crazy on us or anything.

If your going to be an ongoing contributor your in line for a cvs account.
If your only going to be contributing once in a while, there truely is
no need for you to have one. 

Now, let's break down everything else. 

==========
CVS Layout
==========

The CVS tree has gone through alot of changes lately and is still being
worked out as the new format is implimented.  CVS Is layed out kinda
like this:

horde
     /lib
         /src  <lots of other stuff under here>
imp
   /lib
       /src   <lots of other stuff under here>

etc...

These are the main directories.  horde currently only contains the above
directories and a bunch of stuff below src.  horde is the core component
of all horde based products.  It will be required by all of them, but 
it does not require any of them.  (though it does nothing without one of them)

All modules will reside (after installation) under the horde module like this:

   horde
        /lib
            /src
        /imp
            /lib
                /src
        /troll
              /lib

   etc...

This makes it easy for each module to know exactly where each other is and
how to talk to specific files each may have.  For example, the addressbook
functionality of IMP will be torn out of it and built into it's own module
sometime after 2.2.0 is released.  With it as it's own module it can work
independantly or with any other module.  This would allow people to have
the same addressbook whether they are using IMP or TROLL.

-----======------
Post 2.0.0 Stuff
-----======------

After 2.0.0 is released, alot of things will be changing.  Besides me
ripping the contacts section out of IMP, there will be some major 
database and library work going on.  The whole sessions problem that
we've been fighting with for a long time will finally be worked out.
SSL authentication and Digital Signatures will be coming back.  GNUPG
support will hopefully be added.  (Depending on how well it works)

These are just a few off the top of my head.  And these are just dealing
with IMP.  The other projects within horde will be kicking off again.  Most
of the developers have been focusing on IMP to get 2.0.0 out the door
and at the same time stabalize the library code so that all projects can
progress in the same direction and not duplicate efforts.  This is
important.  

The current horde modules that I know of are:

  IMP       = IMAP webMail Program
  TROLL     = NNTP News Client
  NAG       = TODO list  
  WEBSHOP   = Shopping cart program
  KRONOLITH = Calendar program
  WHUPS     = Bug tracking system
  TURBA     = Enhanced Addressbook
  SKATTEK   = Linux Firewall Management System

These are at least the one's in the CVS tree.  Being able to use any or
all of these at the same time and the ability for them to work within
each other is important.  (using the calander within your todo list so
you can set a date correctly)

=-=-=-=-=-=-=-=-=-=-=-
Obtaining CVS accounts
=-=-=-=-=-=-=-=-=-=-=-

Currently CVS accounts are only going out to key developers.  Those
contributing single translations (one language) do not fit into
this catagory at this time.  Here is a small explanation from Chuck
about this:

   "Until I have either a seperate cvs machine or a nice granular way to do
   access control, I'm not handing out cvs access to people only contributing
   one translation. I'd like to, but it'd be nightmare for me right now and
   it's easy enough to submit the files..."

The best way to submit patchs is to send them either to imp@@horde.org or
to dev@@horde.org.  If it's a patch to the horde module itself, the
same applies, plus you can also send it to dev@@horde.org.

===---===
Using CVS
===---===

(Taken from the HORDE FAQ)


IMP uses CVS for source control. If you're curious, there are lots of documents 
available regarding its use and administration. Some of
them may be found at http://www.cyclic.com - they support CVS commercially, even
though it is an open source program. 

IMP CVS is not open to everyone. However, if you submit code a couple times, you
can probably get access if you ask. 

Once you have access, here are the normal things that you will need to do to 
work on the code. 

Before you do anything, you'll need to make sure you have a cvs client 
installed on your machine (check out the Cyclic homepage for
those if you don't have one), and you need to let it know where to get the 
source from. 

For IMP, the CVSROOT is :pserver:username@@cvs.horde.org:/cvs/horde

You will then need to log into the CVS server, so it knows who you are and can 
make sure you're allowed to work on the sources. The command to do is:

             'cvs login' 

One other thing you can do, if you want to, is set an environment variable 
called EDITOR to your favorite text editor. That way when you
commit software changes and it asks you to enter a change description, you 
can do is in your favorite editor (rather than vi, which some love, but
I'm lost in) 

Then for work on developmental, bleeding-edge versions:

    1) Check out the code 'cvs co imp'
    2) Work on the code <hack, hack, hack>
    3) Commit any changes with 'cvs commit "filenames"' in the directory the 
       files are in. 

Sometimes, others will make changes and you will need to update your tree so 
that the changes show up in your local sources. You do this with the
'cvs update' command in the imp directory. 

To work with any labelled version (to patch a stable release, for instance): 

    1) Check out the code 'cvs co -r"label" imp'
    2) Work on the code <hack, hack, hack>
    3) Commit any changes with 'cvs commit "filenames"' in the directory the 
       files are in. 

If somebody else also made changes to the labelled version, you can get them in 
your local source tree with a 'cvs update' command issued in the imp directory.

If you are done working with the labelled source branch, and would like to move 
back into the main development source tree, you can issue a 'cvs update -A'
command to get all the new developmental stuff back. 

If you're feeling adventurous, you can try merging code from the developmental 
branch into a labelled branch (to backport a new feature that stabilized,
for instance) by "joining" the two versions. The command for this is: 

   'cvs update -j"version number with changes" "filename to backport into"'

If you're feeling *very* adventurous, and have talked it over with the list, 
you can label the sources at the current stage of development with this
command in the imp directory, 'cvs rtag "label" imp'. 

You can also create a labelled branch (to stabilize a release, or do something 
*really* experimental) with this command in the imp directory:

     'cvs rtag -b "root label to branch at" "branch label" imp' 

Those commands encompass all of the source control voodoo you should ever 
need to know to work with the imp sources. If any of these give you
trouble, mail the CVS list for imp: cvs@@horde.org and ask for help. If you're 
willing to code for imp, I'm sure someone will lend a hand.

                      - Mike <mikeh@@spark.com>

=-=-=-=-=-=-=-=
Other CVS Notes
=-=-=-=-=-=-=-=

If you do end up getting a cvs account here are some tips to help 
keep things happy:

   1> Subscribe to the cvs@@horde.org and dev@@horde.org mailing lists

   2> Label all uploads with your name or initials.  
      When you commit changes to cvs it asks you for comments.  In this
      area do something like this:

      [IEM] fixed the lines in compose.php3 that annoyed Chuck.

      The reason for this is that it first off tells use quickly who
      made the change.  CVS will then tell us exactly what was changed, but
      that requires work.  CVS mails these logs to cvs@@horde.org so with
      a quick glance at an email we know who did what.

   3> If your planning on doing anything major please let people know
      in advance.  cvs@@horde.org should be an extremly active mailinglist.
      Developers need to communicate extensivly in order to make sure everyone
      knows what's going on.  This is extremly important when your working on
      key components.

   4> Use the Bug Tracking System.  Currently we are using Bugzilla to
      keep track of bugs.  All new submissions are being cc'd to the
      bugs@@horde.org mailinglist so that if we aren't paying attention we'll
      at least get mail about it.  Using the Bugs database will help us
      keep track of issues we are having and where we stand with the
      product.

   5> Remember to advance the library version whenever anything major is
      changed.  This also goes for a ton of minor changes.  This way we
      have some means to break up releases and also track down problems.
      

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
This document was prepared by Ivan E. Moore II
It's far from complete and was written from the top of my head.  
It is intended to help future developers understand where we 
are coming from and what some of our current processes are.
Please send any comments or questions pertaining to this document
to:

        Ivan E. Moore II <rkrusty@@tdyc.com>


@


1.1.2.2
log
@[IEM] couple minor tweaks here and there...in the help file I changed my
contact info to Horde's since stuff pertaining to this should go to the
group and not me alone. :)
@
text
@d95 1
a95 1
Post 1.0.0 Stuff
d98 1
a98 1
After 1.0.0 is released, alot of things will be changing.  Besides me
d275 3
a277 1
        Horde Development Team <dev@@horde.org>
@


1.1.2.3
log
@Correct the location of COPYING
@
text
@d8 1
a8 1
See the file COPYING in the main directory.
@


1.1.2.4
log
@Capitalization fixes (s/HORDE/Horde/ etc.)
@
text
@d2 1
a2 1
Horde: How To Help
d15 1
a15 1
any of the Horde projects.  The first and best way you are already
d150 1
a150 1
(Taken from the Horde FAQ)
@


1.1.2.5
log
@Substantial edits/improvements to the docs:

(1)  horde/docs/INSTALL: correct subdirectory list
     ** I removed "horde/db" -- if you know something I don't, put it back.
(2)  Gut horde/scripts/database/MYSQL and point them to horde/docs/DATABASE
     ** The db-specific READMEs (esp. PostgreSQL) should get merged into
        horde/docs/DATABASE as we have time.
(3)  horde/docs/DATABASE: tell the user to reload, but not restart
(4)  */docs/INSTALL: clean up the extraction/directory rename instructions
(5)  horde/docs/DATABASE: mention dbpasswd.sh
(6)  */docs/INSTALL: strongly urge the user to use test.php3
(7)  other nits...

Most of these submitted by: Robin Whittle <rw@@firstpr.com.au>
@
text
@d10 1
a10 3
$Author$
$Revision$
$Date$
@


1.1.2.6
log
@s/horde.org/lists.horde.org/ for mailing lists.
@
text
@d10 3
a12 3
$Author: bjn $
$Revision: 1.1.2.5 $
$Date: 2000/06/27 14:59:47 $
d144 3
a146 3
The best way to submit patchs is to send them either to imp@@lists.horde.org or
to dev@@lists.horde.org.  If it's a patch to the horde module itself, the
same applies, plus you can also send it to dev@@lists.horde.org.
d226 2
a227 2
trouble, mail the CVS list for imp: cvs@@lists.horde.org and ask for help. If
you're willing to code for imp, I'm sure someone will lend a hand.
d238 1
a238 2
   1> Subscribe to the cvs@@lists.horde.org and dev@@lists.horde.org mailing
      lists
d248 2
a249 2
      that requires work.  CVS mails these logs to cvs@@lists.horde.org so
      with a quick glance at an email we know who did what.
d252 4
a255 4
      in advance.  cvs@@lists.horde.org should be an extremly active
      mailinglist.  Developers need to communicate extensivly in order to
      make sure everyone knows what's going on.  This is extremly important
      when your working on key components.
d259 2
a260 2
      bugs@@lists.horde.org mailinglist so that if we aren't paying attention
      we'll at least get mail about it.  Using the Bugs database will help us
d277 1
a277 1
        Horde Development Team <dev@@lists.horde.org>
@


1.1.2.7
log
@Note the new CVSROOT.
@
text
@d11 2
a12 2
$Revision: 1.1.2.6 $
$Date: 2000/10/18 19:52:46 $
d171 1
a171 1
For IMP, the CVSROOT is :pserver:username@@anoncvs.horde.org:/repository
@


