I am motivated to rant again on this topic. Repeating what I said last November, before the new release process was finalized, in response to David Lang:
--- >> 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 [git] 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.. --- So then, nothing was done to address this issue, when developing the new release process, where, instead, at worst, LEDE could simply "snapshot" a "feed", and keep that copy on github, and then *under LEDE's control*. And git submodules are still an available solution. I don't know that there is any polite way to express how ridiculous I find this situation, of non-repeatable builds, let alone the failure to bump the version number of the release. I might call it "unprofessional", though I'm tempted to be otherwise demeaning. Let me say again, I think that this is an important issue that the LEDE project needs to address and remedy. I believe that the ultimate credibility and reputation of the LEDE project is at stake. James _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev