On Sat, Aug 26, 2017 at 6:54 AM, David G lsmbdev@sbts.com.au wrote:

Hi,

Currently we have 30 repositories in the LedgerSMB github project. over half of them are related to PGObject modules and are reasonably named in the form of PGObject-foo-bar

However, not all of our repositories are named so sensibly.

In particular we now have 4 "packaging" repositories

• pkg-ledgersmb

That's the one for Debian compliant packages. Which is the primary entry point (or can be) for LedgerSMB to all of the Debian derived distros (including especially Ubuntu, which is the one I track and that is the recommended way to get and keep an app in Ubuntu.)

• pkg-ledgersmb-1.4
• pkg-ledgersmb-1.5

Those are separate especially because of the different policies and procedures related to them and our use of them. And intent, as the ledgersmb-1.4 and ledgersmb-1.5 packages are intended to be co-installable (I do wonder if that is emphasized enough) and are therefore not the same 'package', as might be at least implied if they were maintained in different branches of the same repository.

And note that I'd thought about creating separate repositories for 1.2 & 1.3 pkgs, but have so far not seen any urgent need for them. And one for 1.6 hasn't been created yet, since we're not (TMK) to the point where that would be useful.

From the names, it's obscure at best which distro etc each of those repositories is for, more confusing is the fact that the first 3 seem to be duplicates of each other, excepting for the fact that they target different releases of our code.

The first 3 are for debian packages,

And could perhaps be reduced to two, if there turns out be a consenus about that.

To help with "discoverability" and generally make it more obvious what a repo is for, I'd propose a naming scheme along the following lines. $purpose-$project-$detail

For true "project" repositories such as LedgerSMB, and PGObject projects $purpose may not make sense, but for others it likely does. Some examples ....

• pkg-debian-LedgerSMB

That's limiting it to only Debian, which I don't see the point of. (From what I've seen, using "pkg-" in the repository name is generally only used for Debian packaging in any case. Although it is true that is what I primarily look it.) What else would be used? If there's a need for trackable differences from the master branch for packaging (which generally does not include 'no change' packaging for, for instance, a specific Ubuntu release on our PPA), branch naming using the distro name is done.

I think it's probably early enough in the lifecycle of most of the repositories that could do with renaming to rename them now. I say that as the ones that would change have little use outside of our project controlled resources.

As for having the pkg-ledgersmb-1.x repositories as well as the unversioned one, Unless Jame has a reason to do otherwise,

Which I do, as they are for quite different purposes.

I'd suggest we simply use tags in the pkg-ledgersmb repo instead.

That won't work: I'd already tried that before separating them out to their own repository. The existing history in the pkg-ledgersmb repository already contains packaging back to LSMB 1.2 (and multiple branches with currently over 115 tags) and is for the Debian compliant packaging. Having the non-strictly Debian compliant packaging in the same repository is not, IMO, a good idea. At most, I could perhaps see using only two packaging repositories; one for Debian compliant pkgs and one for not (and other experimental versions we might need...). Although in the latter case, one would need to decide on branch naming and how to name the repository itself. (Calling it something like 'ledgersmb-pkg' or LedgerSMB-pkg might be confusing...)

Consider the situation if we ended up with packaging repos for every different distro,

Why would we? The only widely used packaging that has separate (albeit, derived from upstream) versioning and therefore is useful to be tracked separately from upstream is (TMK) Debian. Which we already have repositories for; one of which is for Debian compliant packages.

and also every release series we do in the future, things would quickly become unmanageable

I don't see any such issues (if there are any) happening "quickly". How often does a new release series come out? And how long does a release series stay active? And there is an overlap in time between those, after all; LSMB 1.4 was released in September of 2014 and is still supported while LSMB 1.5 was not released until December of 2016, over two years later. Is it anticipated that new release series will be coming out more often?