[LEDE-DEV] Release Preparation Questions

[James Feeney]

Ok - thanks for taking the time to explain this versioning process.  So now, I
should take the time to "feed it back" and see if I understand.  Ha!

> https://git.lede-project.org/source.git
404 Not Found

Hmm.  Try Google...

https://git.lede-project.org/?p=source.git
description	LEDE Source Repository

Ok.

$ whois lede-project.org
Admin Name: Jo-Philipp Wich
Admin Country: DE

That helps orient things.

> it does not require twenty different variables but it has to deal
> with (currently) five independent repositories:
> - feeds.conf.default: git://git.lede-project.org/feed/packages.git

Hmm - try Google again:

https://git.lede-project.org/

Ah ha.

feed/packages.git	Mirror of packages feed		Git	119 min ago
feed/routing.git	Mirror of routing feed		Git	2 weeks ago
feed/telephony.git	Mirror of telephony feed	Git	4 months ago
...
project/luci.git	Lua Configuration Interface...	Git	28 hours ago

Ok.  I don't know what I'm seeing yet, but ok.

> ... described in feeds.conf.default within the base repo.

Hmm - still drawing a blank...

source.git	LEDE Source Repository	Git	102 min ago

https://git.lede-project.org/?p=source.git;a=tree
https://git.lede-project.org/?p=source.git;a=blob;f=README

   9 Run "./scripts/feeds update -a" to get all the latest package definitions
  10 defined in feeds.conf / feeds.conf.default respectively
  11 and "./scripts/feeds install -a" to install symlinks of all of them into
  12 package/feeds/.

... getting closer...

https://git.lede-project.org/?p=source.git;a=blob;f=feeds.conf.default

Ah ha!

   1 src-git packages https://git.lede-project.org/feed/packages.git
   2 src-git luci https://git.lede-project.org/project/luci.git
   3 src-git routing https://git.lede-project.org/feed/routing.git
   4 src-git telephony https://git.lede-project.org/feed/telephony.git
   5 #src-git targets https://github.com/openwrt/targets.git
   6 #src-git management https://github.com/openwrt-management/packages.git
   7 #src-git oldpackages http://git.openwrt.org/packages.git
   8 #src-link custom /usr/src/openwrt/custom-feed

Mmm-hmm - I seem to have gone in a circle.  So, the term "feed" is a unique
concept, referring to three "gitish" directories including the name "feed", and
one "gitish" directory *not* including the name "feed".  Hmm...  Well, that
seems like an inconsistent concept.  So, a "feed" is whatever git "directory" a
file "feeds.conf.default" says it is.  That is not a traditional hierarchy, and
it is a mistake for me to try to think of LEDE as a kind of file system
hierarchy.  It is more like a kind of linked-list, with a "root" located in a
file, which is located in a git directory "projects/source.git/tree", which is
best discovered by already knowing its location.

This is an organizational model which I have not encountered before now.  It is
certainly not the most "discoverable" model which I could imagine, but ok.

And then, there is a top-level git directory name, "source.git", where the term
"source" is not used in the usual manner, to mean literally the directory
holding the source code, but instead, seems to refer to that directory which
contains the file which enumerates the elements of the term "feed".

And also, there is the idea of "base repository", where the "base" is being
defined as the "source", and the "source" is not really the "base" in the
traditional sense, but instead is located under a traditional "base" URL,
"https://git.lede-project.org/".

Again, this is a nontraditional use of the term "base", which seems to be used
interchangeably with the term "source" - but ok.

Lots of specialized, nontraditional, terminology, - "base", "source", "feed" -
but ok.

Now, revisiting the concept of "version number":

1) "base" repository - https://git.lede-project.org/?p=source.git
2) "feeds" - described in feeds.conf.default within the base repo.
   1 src-git packages https://git.lede-project.org/feed/packages.git
   2 src-git luci https://git.lede-project.org/project/luci.git
   3 src-git routing https://git.lede-project.org/feed/routing.git
   4 src-git telephony https://git.lede-project.org/feed/telephony.git
3) release branch number - an input variable, major.minor version, usually
year.month - or instead, the number of the build being produced from a branch.
There were two different definitions offered.  I'm guessing that you meant the
"build number" after the "major.minor" version number.
4) git tags - exactly match the source state; "commit hash".
5) builds - the binary artifacts produced, branch release builds.
6) master - master branch of the "base" repository.
7) release branch - used for *all* builds within a major.minor version; "source
branch".
8) subrelease - Any release within a base version; patch levels; security updates.
9) nickname - Symbolic name given to an entire release branch; all 16.11.*
releases will carry the same nickname.

Hmm - it is still not clear to me how the term "branch" will apply here,
because: 1) the hierarchy of "base.feeds" is referencing four *other* git
repositories, each of which has its *own* "head" branch name, each of which - I
assume - may be changed or selected independently; and 2) the "feeds" link list
does *not* have any version information within it, itself.

It would be possible, I suppose, that each of these linked repositories could be
*required* to use the *same* versioned naming scheme.  The implication would be
that a "build" version would mean a build of the collection of all components of
the "feed" list with identical version names.  But that is not the way it is
now.  Instead, looking into the feed components, I see some "tags" and some
"heads", but nothing that is common to all the components, except that they all
have a "head" named "master".  There are many "master branches".  Perhaps the
git cognoscenti have some way of synchronizing all of these master branches such
that a "year.month.build-number" can be uniquely associated with some
instantaneous version of several feed components?

Please explain - I'm missing some piece of the puzzle - probably because I do
not know enough about using git.

> If a builtin package or the kernel itself gain security fixes,
> the images need to get rebuilt since people cannot update those
> components with opkg.

This is what is so unusual for me about LEDE/OpenWRT.  It is not a simple
program package, where every component is versioned in lock-step.  But neither
is it a traditional distribution, in which all of the components can be
versioned and installed independently, especially as in a rolling distribution.
And it is not a "glacial" distribution, like Debian, where the versioning
measures time in years.  Perhaps it is more similar to Cyanogenmod, which has
dated "nightly" and "snapshot" builds.  The term "release" is inappropriate in a
fast moving environment like that.  The term "build" seems better suited.

Cyanogenmod uses the term "manifest" instead of "feed", and uses "repo", a
specialized "repository management tool that we built on top of Git."  You are
familiar?  In a sense, the top level of the build system is the "manifest" file
"default.xml" with its own web page, https://github.com/CyanogenMod/android.
Hmm - LEDE has a program "[source.git] / scripts / feeds", which serves the same
function as "repo", yes?  Maybe I begin to understand.  And then, the term
"feed" would actually mean one of several git source code repositories
enumerated in the LEDE "manifest".  And "feeds" means a LEDE git repository
management and build utility.

I think that, essentially, I must understand how a LEDE build version number can
be related to an instantaneous version of four independent git repositories.

Would it be useful to version the manifest, and have the versioned manifest
enumerate specific versions of the manifest components?  I assume that each
component could specify an instantaneous snapshot version of each master branch
of that component?  Perhaps git tags could be included inside the manifest, and
no one would have to memorize or recognize or refer to these, because the
manifest itself would have a human readable version number, as in
"year-month-build".

> Did you ever build the complete LEDE or OpenWrt from scratch?

Ha!  NO! That's the issue for me.  The linux kernel - ok, I'm familiar with
that.  LEDE/OpenWRT - I'm still trying to wrap my head around it!

The terminology would make more sense to me if "base" referred to a "base
package" which include the linux kernel and required utilities, unique to each
hardware system, even though it were a "package" that could not be installed by
opkg.  As I understand, the kernel and the root file system have to be installed
together, as a matched set, though I cannot say why.  The "version number" would
imply the version of this LEDE "base package".  The LEDE "source" would refer to
just the git repository "https://git.lede-project.org/", and the git directory
"source.git" would instead be named "build.git". The file "feeds.conf.default"
could be called "manifest.default", which would be a concept shared with
Cyanogenmod.