Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Fri, 18 Dec 2009 18:25:43 -0700

> Jeff: I intend to extract all the commits you have made to the CVS main
> trunk since September 3rd and put them on a separate branch.  I'm afraid that
> until you've actually finished development and thoroughly tested your new code
> it will block other development work on the trunk which could be released as
> R3.15.x sooner.  

My changes since Sept 3rd can be divided into two categories
1) large, fast moving, changes in the cas path 
2) conservative changes outside of the cas path 

Concerning (1), cas is currently commented out of the build and is not used by base. I hope to have it ready for the first release of R3.15, but currently it has no impact whatsoever on, and is not used by, the rest of base. The legacy PCAS and GDD are maintained on the R3.14 branch. I don’t migrate their fixes to the main trunk. I haven’t started yet, but certainly, if I start yanking rsrv out, that will need to be done on a branch.

Concerning (2) this is primarily changes to the C++ epicsMutex and the new SMP safe atomic primitives. The C++ epicsMutex class changes are conservative, they allow multiple epicsMutex instances to reference count a single mutex primitive. They are certainly easily ready for R3.15 if you needed to release next week. The new SMP atomic primitives are currently used only by the epicsMutex and cas, but will probably be found to be very useful by other codes. They are also close to being ready for immediate release.

Furthermore, concerning (2) I see quite a few random patches as follows. I see R3.14 patch merges to CAC coming in after Sept 3rd. Also several "fixed size_t vs unsigned issues linux 64" commits. Also "deal with archaic vxWorks g++" commits in many places which appear to have nothing to do with CAS changes, but are instead making the code build well with old vxWorks. Another one says "certain versions of mingw provide link time colliding getopt". There are changes in epicsTypes.h that add new epicsInt64 for 64 bit arch which are not currently used by CAS. My recent changes (that required almost half a day of work) fixing merge issues in the CA reference manual will also be lost.

So the bottom line; please consider carefully a filter that says (don’t allow any changes from Jeff Hill after September 3rd) into base, but do allow changes from others during that time frame. That sounds a little odd from my perspective in any case.

If you want the cas path and gdd path out of R3.15 base, I can see that as being an option. I don’t really see the idea of creating a branch for all small isolated changes as being very efficient idea however. 

I could merge the, outside of cas, changes back in after you make the branch, but is that your intent? If not, then I risk losing a lot of completed work when the target source file are heavily modified, and then the merge is no longer practical.

Thanks for your consideration,

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Friday, December 18, 2009 3:12 PM
> To: EPICS core-talk
> Subject: CVS migration to Bazaar
> 
> I will be converting the epics/base part of the EPICS repository to the
> Bazaar
> DVCS next Wednesday (12/23), and will then push the resultant branches to
> the
> Launchpad (lp) hosting site.  Please ensure that you have committed
> everything
> from your CVS working directories before you leave work on Tuesday, or be
> prepared to do some work getting your changes back into the tree after the
> conversion, which might not be complete until several days into the new
> year.
> 
> I have already created the project and a couple of associated teams at
> Launchpad; see https://launchpad.net/epics-base to start with.  There is a
> Blueprint attached to the project to cover the migration process, which
> links
> to a page on our wiki for more detail.  There's a link on that wiki page
> to
> another one I'm working on which describes how to work with Bazaar.  The
> examples won't work until I push the converted branches up to Launchpad
> though.
> 
> While you're waiting, feel free to take the Launchpad tour and to create
> an
> account there, then join the EPICS team (which is really just a collection
> point at this stage).  The EPICS Core Developers team (epics-core) will be
> used to control write access to the official release branches and will
> have a
> restricted membership, but anyone can publish their own branches of the
> project without needing to belong to it so I don't expect the epics-core
> team
> to grow very large.
> 
> Jeff: I intend to extract all the commits you have made to the CVS main
> trunk
> since September 3rd and put them on a separate branch.  I'm afraid that
> until
> you've actually finished development and thoroughly tested your new code
> it
> will block other development work on the trunk which could be released as
> R3.15.x sooner.  [As an aside, have you been keeping your recent changes
> in a
> separate VCS locally?  The fact that some of your CVS log messages have
> been
> just "sync" do rather imply that.  I don't know if we'd be able to merge
> those
> changes instead when we get to that point, although I imagine the log
> messages
> are probably better though.]
> 
> For examples of the "other work" I'm talking about, the code to do CA over
> TCP
> has been languishing in CVS on the trunk since the first Codeathon, and I
> also
> have some patches that Marty developed to allow the database to support
> Process-Get, which I felt were too major for R3.14 but which should be
> merged
> before they go stale.
> 
> Bazaar makes merging branches easy to do, and I want to change the way we
> work
> so that we develop new features on a branch which can be published, tested
> and
> reviewed before merging them into their targeted branch/branches.  I will
> probably use Marty's Process-Get changes as my first example using this
> approach, publishing a branch containing them for comment sometime after
> the
> migration is complete.
> 
> - Andrew
> 
> PS: I know we originally said we would use Mercurial, but I was unable to
> find
> a public Hg hosting site that Argonne would let me use ("indemnify" is a
> very
> scary word for our lawyers).  I also really like the features that
> Launchpad
> provides, and it only supports Bazaar.
> --
> The best FOSS code is written to be read by other humans -- Harald Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System