[Starlingx-discuss] Flock Versioning for packaging

[Bailey, Henry Albert (Al)]

Sounds good Dean.  I would be in favor of breaking some of these pieces into unique repos.

I like the idea of starting with cgtsclient (and its also an opportunity to rename it)

Al

-----Original Message-----
From: Dean Troyer [mailto:dtroyer at gmail.com] 
Sent: Thursday, May 16, 2019 1:34 PM
To: Bailey, Henry Albert (Al)
Cc: Jones, Bruce E; Saul Wold; starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Flock Versioning for packaging

On Wed, May 15, 2019 at 3:19 PM Bailey, Henry Albert (Al)
<Al.Bailey at windriver.com> wrote:
> If we update the build tool (and remove those variables from the spec files), then all python components in a particular repo will have the same version.
> We have some repos where there are multiple python components in the same repo.

As you note PBR and other OpenStack tooling has the assumption that
everything in a git repo is related and is a single "thing".  This
could be changed, thus far it really has been easier to break out
common components.  We have to work around this in other areas too,
such as maintaining multiple tox job definitions rather than using a
single top-level tox.ini.

I think we need to break out more parts from the existing repos but
within the same sub-project teams.  I would start with either major
pieces (inventory) or the small dependencies (tsconfig,
fm-common/fm-core) and clients (cgts-client).  I have done an
experiment with cgts-client that took a couple of hours and is even
mostly automated and maintains the git history.

dt

-- 
Dean Troyer
dtroyer at gmail.com

_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss