RE: [Fipa-os-developers] Re: Contribution process now available for review

[Chris N. <chr...@em...>]

Hi All,

Following recent discussions on the subject of whether or not to check in
non-working code into the public FIPA-OS CVS repository I would like to
propose the following solution:

1) The very latest work on each file *is* still checked in to CVS - this
will give developers access to up-to-the-minute changes (although this code
may or may not compile or be compatible with the last release versions). If
a developer performs a CVS checkout or update then they will retrieve this
"hot-off-the-press" code.

2) Each developer that checks in a piece of code is responsible for knowing
whether the code is compatible with the latest working codebase. If they
feel that the code is compatible, they will tag it with a marker that
indicates it is ready for the next build. At the end of each day, the
FIPA-OS management team will (probably via some script or cron job) produce
a tar/jar/zip file containing the latest compatible FIPA-OS codebase. This
will be checked in to our public CVS repository and tagged so that it
becomes simple for developers to retrieve just the latest compatible
codebase that contains the most recent enhancements / bug fixes. Part of the
process could be to run JUnit tests to ensure compatibility of the daily
release.

If you have any feedback on this proposed process then please reply to the
list so that we can make this a community discussion.

Best Regards,

Chris

> -----Original Message-----
> From: fip...@li...
> [mailto:fip...@li...]On Behalf Of Bob
> Krause
> Sent: 26 July 2001 19:27
> To: fip...@li...
> Subject: [Fipa-os-developers] Re: Contribution process now available for
> review
>
>
> Phil,
>
> I'd like to recommend a paper that outlines some best practices
> for software
> configuration management (read: source code control). It can be
> found at...
>
> http://www.perforce.com/perforce/bestpractices.html
>
> This paper is put out by Perforce Software, a SCC vendor. But it's very
> product-agnostic.
>
> For the sake of the discussion we're having, the paper points out the
> difference between workspaces and codelines. The workspace is where
> engineers edit source files, build the software components
> they¹re working on, and test and debug what they¹ve built. Whereas a
> codeline is a canonical set of source files required to produce software.
> Workspaces are checked in often. Codelines are updated and merged only at
> policy-conforming milestones.
>
> I'd like to hear your thoughts once you've had a chance to read the paper.
>
> Bob
>
> > The main aim of committing code that is incomplete is to ensure
> that there
> > is a backed up archive of work.  How would you counter propose
> handling the
> > development process prior to committing completed tested code into the
> > project CVS repository so that we can adopt the engineering
> approach that
> > you suggest?
> >
> > I appreciate that it is difficult for other developers to
> commit new code
> > when some work is incomplete, although something else that I
> guess should be
> > made explicit in the process is the recommendations for the development
> > process that avoids multiple people checking out and developing the same
> > source code file in parallel to avoid issues in merging different
> > development branches.  The aim of the process currently posted on the
> > website for review is that Principle Developer's will handle the
> > co-ordination of who is working into a given part of the CVS
> repository to
> > ensure that consolidated builds can be made, hence a given
> developer would
> > be working on the latest version of a piece of code.
> >
> > I can see how certain bits of information is inappropriate to
> be kept only
> > within CVS as it is almost too late to get the README files after the
> > repository has been checked out.  Would further instructions on
> the website
> > to include how the tags should be used when checking out code
> from CVS be
> > preferred?
>
> ----------
> Bob Krause
> NeoLogic Systems, Inc.
>
>
> _______________________________________________
> Fipa-os-developers mailing list
> Fip...@li...
> http://lists.sourceforge.net/lists/listinfo/fipa-os-developers
>
>