[LEDE-DEV] Release Preparation Questions

[James Feeney]

On 11/20/2016 08:26 PM, David Lang wrote:
> replying to details other than the feeds concept/
> ...
>> There were two different definitions offered.  I'm guessing that you meant the
>> "build number" after the "major.minor" version number.
> 
> not quite
> 
> the branch would be Year.Month, tags/builds within that branch would be
> Year.Month.Build

Ok, I get that.

> ...
>> 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.
> 
> The branch is really based on the LEDE maintained git repository, ignoring the
> feeds that are not maintained by LEDE or OpenWRT.
> 
> There is an interesting question of how to refer to what state of each feed you
> use for a release. Currently OpenWRT doesn't even try to do this. The feed
> version you get is the feed version that exists at the time you last pulled from
> the feeds.

Uhm - I'm a bit taken aback by that.

> This hasn't been a big problem in practice, but it does mean that you don't
> really have a repeatable build.

I would have thought that that was a "show stopper".  It certainly does not
inspire confidence.

I say this is a "problem" and should be a high priority issue.

> See my other e-mail about submodules for a
> discussion on this.

Yes, I looked at that.  It would seem to address and solve a number of issues.
There would be no need for a separate "manifest", and, most importantly, there
would be a git "snapshot" of the *entire* project state.  If I understand, that
also means there would be a unique git tag that would label that state, and
could be associated with any kind of specific nickname, version, and build
number.  It would mean that every build was repeatable.

>> It would be possible, I suppose, that each of these linked repositories could be
>> *required* to use the *same* versioned naming scheme.
> 
> can't be done, these other repositories are not under our control. The most we
> can do is reference exactly which release we use..

I see that now.

> ...
> actually, the LEDE/OpenWRT releases are long, they are trying to get them down
> to only a year or so.
> 
> What most people end up using is the roughly the equivalent of the nightly
> builds, but even more granular in that people grab the source code and compile
> it, so they get up-to-the-minute changes, not even nightly snapshots.

I don't understand the point of having a LEDE "release" then.  But then, I
prefer using Arch, a rolling release distribution, where other people prefer
something like Debian, for stability.  So maybe LEDE would have a yearly
"release" version for some people, and other people can grab the latest buildbot
build?  Or compile it themselves.

With the git submodule idea, LEDE could have a repository that even includes the
entire cross-compiler tool chain?  Or maybe that's going too far?

>> 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.
> 
> more or less. OpenWRT was stuck for a long time using subversion instead of git,
> so things developed differently, but you seem to be mapping the concepts more or
> less correctly.

Ok, thanks for confirming.

>> 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.
> 
> ignore the feeds for now, they are not part of the LEDE release.

Yeah, I see now how that works - scary, but clarified.

>> 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".
> 
> that would be inventing another layer of abstraction, I don't think we need to
> do that. But this is the submodule discussion I raised in another branch of this
> thread.

Again, git submodules would answer all of those issues.  And there would be no
need for another one-off custom build tool, like "repo" or "feeds".

> ... 
> The first thing to do is to ignore the feeds and all software involved in them..

Well, based on what I am understanding now, that would be an oversimplification,
but I get the idea.

>> 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,
> 
> it does.

Ok, I'll assume that then.

>> 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.
> 
> partly for historical reasons, partly because LEDE/OpenWRT are usually installed
> on systems that have very little storage, so you don't have a 'normal'
> filesystem that you can replace different parts of, you have a compressed
> filesystem where everything you are installing has to be combined into one blob
> and installed all at once.

Ah!  Thanks for that.  On reflection, yes, of course.  That makes sense.

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

> I hate to disappoint you, but Cyanogenmod's terminology is pretty unique to it,
> it's not universal. It makes more sense to you because you ran across it first,
> but changing the terminology in LEDE would just add to the confusion of the
> exisiting LEDE/OpenWRT users and introduce incompatibilities with years of
> documentation and how-tos
> 
> The version does refer to the exact state of the LEDE maintained git repository
> (feeds are a different/complicating issue)

Git submodules ;)


> David Lang
James