Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Mon, 5 Feb 2018 21:34:44 +0000

Hi Lewis,

> I don't understand why you want to separate out into multiple
> repositories things that everyone will just turn around and combine
> again.  Why not just leave them together?  

Here are a number of reasons:

- Clear separation.  When we release a new version of ADPilatus people who don't use ADPilatus but do use ADPointGrey know immediately that this change does not affect them.  If the Pilatus and Point Grey code were both in a large areaDetector repository then it would not be obvious.  Currently Point Grey users only need to watch for releases of ADCore and ADPointGrey.  If it were combined they would need to watch for every release of areaDetector.  Since there are now 40 detector repositories in areDetector, to first order they would need to read the release notes 20x more often.

- Easier collaboration.  With separate repositories we can assign permissions differently for each one.  I could give you write access to ADADSC since you wrote it, but not give you write permission to ADCore.

- Lower barriers for new detectors.  Because each detector is in a separate repository the barrier to accepting a new detector is lower.  They are well decoupled from ADCore. If ADxxx it does not work with some change to ADCore it does not impact the release of ADCore, and ADxxx will still work for earlier releases of ADCore.  We don't have to wait for that developer to fix it.

Consider the analogy with synApps.  That is about 25 modules which are in separate repositories (motor, calc, etc.) and need to be assembled into a tree like areaDetector.  Are you suggesting that they should also be in a single repository?  The synApps repositories get updated regularly, but the parent synApps release has only happened twice in the last 5 years (5-7 and 5-8).  I think that is an indication of how unbundling improves the frequency of releases.

Mark

> -----Original Message-----
> From: J. Lewis Muir [mailto:[email protected]]
> Sent: Monday, February 05, 2018 2:56 PM
> To: Mark Rivers <[email protected]>
> Cc: Jörn Dreyer <[email protected]>; [email protected]
> Subject: Re: AreaDetector repository inconsistent
> 
> On 02/05, Mark Rivers wrote:
> > Hi Lewis,
> >
> > > Or maybe Git submodules should be avoided.  It seems to me that
> > > there are a number of headaches related to the use of submodules
> > > in EPICS Base that come up from time to time; now it has come up
> > > in areaDetector, and I suspect the headaches will continue simply
> > > because submodules add complexity.  I think a Git repo containing
> > > all of EPICS Base and another one containing all of areaDetector
> > > would be much simpler to deal with.  I'm not a fan of submodules in
> > > general.
> >
> > I think you are mixing up 2 very separate issues:
> >
> > 1) Having multiple repositories for EPICS base or areaDetector
> > 2) Using git submodules to link those repositories
> >
> > In my opinion it would be a terrible idea to go back to having
> > areaDetector be a single git repository, which is how it was before
> > R2-0.  By having multiple repositories we can independently release
> > the core code (ADCore), the supporting libraries (ADSupport), and each
> > detector (ADPilatus, etc.).  This is essential to producing timely
> > releases.
> 
> Hi, Mark!
> 
> I can see what you're saying, but I must have never understood the
> problems being faced or bought into them, and so I never understood
> the benefit of submodules for areaDetector.  (I feel the same way for
> EPICS Base, but to avoid muddling the discussion, I'm only talking about
> areaDetector here.)
> 
> I don't understand why you want to separate out into multiple
> repositories things that everyone will just turn around and combine
> again.  Why not just leave them together?  Why is independently
> releasing core code, supporting libraries, etc. a prerequisite of
> producing timely releases?  Can't you just have a stable branch and a
> development branch?  You make bug fixes on the stable branch and can
> easily make new releases from that at any time.  You add features on the
> development branch.  You declare a freeze on the development branch to
> prepare for a new feature release, and then after ensuring everything
> works, you make a new feature release.  Repeat.
> 
> > The use of git submodules in areaDetector is completely optional
> > for the end-user.  They can simply checkout out each repository
> > independently and manually arrange them in the following hierarchy
> >
> > areaDetector
> >   ADCore
> >   ADSupport
> >   ADPilatus
> >   etc.
> 
> But that's a pain.  It would be way more convenient to just do "git
> clone https://github.com/areaDetector/areaDetector.git"; (assuming the
> one-repository approach) and know that I've got everything in the right
> structure and ready to configure and build.
> 
> > The use of "git clone --recursive" is not required.  It is just a
> > convenience if people want to check out lots of modules at the same
> > time.
> 
> Maybe that's an area where I'm missing an understanding of the problem
> as well.  I would just want to get the source code and build it.  If I
> want to be selective and only build some things, I'd want to just change
> a build configuration file to include or exclude certain things (like
> the --enable-<option> and --disable-<option> options for an Autotools
> configure script).
> 
> > In areaDetector only areaDetector repository and the ADCore repository
> > are released synchronously, i.e. they have the same tags.  All other
> > modules are released independently and have different tags.  So it
> > really does not make sense to check out R3-2 at the top-level and
> > expect it to update the submodules to some specific release (except
> > ADCore).
> 
> Right, I understand that.  That's of course only because of the chosen
> multiple-repositories approach, though.
> 
> Regards,
> 
> Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System