linuxcoe-devel

[Linuxcoe-devel] Developing on SourceForge

[Shank, J. R. <js...@hp...>]

Here is the proposed development process:

-----
1. Each developer checks out a sandbox from CVS on SourceForge.
Instructions are found on 
    http://sourceforge.net/cvs/?group_id=144250 
under Developer CVS Access via SSH.

2. Developers make changes to the files and test them on their
development machine. When they are ready to test them on the testing
server (which matches the production environment as closely as
possible), they check them into CVS.

3. Files from CVS head-of-stream are checked out (perhaps by cron) to
the testing server. If possible, relevant regression tests should be
done to ensure the changes do not break anything else.

4. After the changes have been fully tested, the developer tags the
files as "stable". 

5. During the next release phase the stable files in the repository are
tagged with the version number of the release and that release is
exported and tarred for delivery through the SourceForge file server.
The tarball is then downloaded to the production server, extracted, and
installed in the relevant directories with that releases version number
(for example, /*/opt/SysDes/4.0/*). On the release date, symlinks to the
current version are updated to point to the new version.
-----

There will be another e-mail going out sometime tomorrow for the process
on critical bug fixes. Until then, let me know what you think about this
process.

Thanks,
Jeff

Re: [Linuxcoe-devel] Developing on SourceForge

[ed f. <edf...@ya...>]

It sounds like a fairly standard and straight forward
process imho, but I'd like to hear Lee's spin on it
if possible.  Since I'm not in cvs every day a 
cheatsheet/brownbag would be really cool (ie, I
can't think of how to tag files as "stable" off
hand).

Also, is there a "standard" development system, or
should we expect everything to work on any Linux
distribution at any time?

xlnt process Jeff,
-craiger

--- "Shank, Jeffrey R." <js...@hp...> wrote:

> Here is the proposed development process:
> 
> -----
> 1. Each developer checks out a sandbox from CVS on
> SourceForge.
> Instructions are found on 
>     http://sourceforge.net/cvs/?group_id=144250 
> under Developer CVS Access via SSH.
> 
> 2. Developers make changes to the files and test
> them on their
> development machine. When they are ready to test
> them on the testing
> server (which matches the production environment as
> closely as
> possible), they check them into CVS.
> 
> 3. Files from CVS head-of-stream are checked out
> (perhaps by cron) to
> the testing server. If possible, relevant regression
> tests should be
> done to ensure the changes do not break anything
> else.
> 
> 4. After the changes have been fully tested, the
> developer tags the
> files as "stable". 
> 
> 5. During the next release phase the stable files in
> the repository are
> tagged with the version number of the release and
> that release is
> exported and tarred for delivery through the
> SourceForge file server.
> The tarball is then downloaded to the production
> server, extracted, and
> installed in the relevant directories with that
> releases version number
> (for example, /*/opt/SysDes/4.0/*). On the release
> date, symlinks to the
> current version are updated to point to the new
> version.
> -----
> 
> There will be another e-mail going out sometime
> tomorrow for the process
> on critical bug fixes. Until then, let me know what
> you think about this
> process.
> 
> Thanks,
> Jeff
> 
> 
>
-------------------------------------------------------
> SF.Net email is Sponsored by the Better Software
> Conference & EXPO
> September 19-22, 2005 * San Francisco, CA *
> Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects
> & Teams * Testing & QA
> Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
>
https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [Linuxcoe-devel] Developing on SourceForge

[Lee M. <lee...@hp...>]

I've got no problem with what's proposed, a little self-discipline would
be a good thing IMO.   As the CVS doc ref'd from sf.net states, and I
paraphrase: "Every developer knows that a 'stable' release is just a
snapshot of the development tree at some point in time."

Give me, oh, 3 more days (Gee, have you heard that before? :) and we'll
do a snapshot of 4.0, I'll stop coding completely, we'll get it checked
in, and I'll start learning to live and love the new process.

There's still gremlins in the Debian stuff that shouldn't see the light
of day.

Lee

On Tue, 2005-08-30 at 17:05 -0600, Shank, Jeffrey R. wrote:
> Here is the proposed development process:
> 
> -----
> 1. Each developer checks out a sandbox from CVS on SourceForge.
> Instructions are found on 
>     http://sourceforge.net/cvs/?group_id=144250 
> under Developer CVS Access via SSH.
> 
> 2. Developers make changes to the files and test them on their
> development machine. When they are ready to test them on the testing
> server (which matches the production environment as closely as
> possible), they check them into CVS.
> 
> 3. Files from CVS head-of-stream are checked out (perhaps by cron) to
> the testing server. If possible, relevant regression tests should be
> done to ensure the changes do not break anything else.
> 
> 4. After the changes have been fully tested, the developer tags the
> files as "stable". 
> 
> 5. During the next release phase the stable files in the repository are
> tagged with the version number of the release and that release is
> exported and tarred for delivery through the SourceForge file server.
> The tarball is then downloaded to the production server, extracted, and
> installed in the relevant directories with that releases version number
> (for example, /*/opt/SysDes/4.0/*). On the release date, symlinks to the
> current version are updated to point to the new version.
> -----
> 
> There will be another e-mail going out sometime tomorrow for the process
> on critical bug fixes. Until then, let me know what you think about this
> process.
> 
> Thanks,
> Jeff
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel