The foundation for your business
Fork me on GitHub
Re: [ledgersmb-devel] ledgersmb project owned repository naming
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ledgersmb-devel] ledgersmb project owned repository naming

On Sat, Aug 26, 2017 at 6:54 AM, David G <..hidden..> 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

> 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?

Robert J. Clay
devel mailing list