Hello,
There's a communities network-profile I contributed up to LibreMesh,
but am not a maintainer. Also a few projects in openwrt-routing I
keep maintainer eyes on as well.
I'm leaning towards #2 because its proper. However, I also want
to see #1 accepted into openwrt/master as a dependable mirror
at https://git.openwrt.org/feed/libremesh.git
Please see Inline response below:
> Currently we maintain a custom feed git repo at
> https://github.com/libremesh/lime-packages
> and what we would like to achieve in the end is that those packages
> become available in the official downloads.openwrt.org servers,
> basically.
The current feeds.conf.default (at openwrt/openwrt) is pointing to
git.openwrt.org. I'm betting because github has had multiple outages
due to content delivery network returning 404s or 500s.
I could be wrong, but.. Hah, yep @1e0f650d7d55
8< GitHub seems to be a bit unreliable on feeds updates on the buildbot
8< lately, so hopefully our own mirror will be more reliable than that.
> as far as i understand, we have two options (in decreasing order of
> desirability):
> 1) make a proposal (PR against this[0]) to include a new feed in
> feeds.conf.default, uncommented so that the packages inside are by
> default compiled and published along with other packages (luci, routing,
> telephony...)
>
I'd like to know a duplicate package is impossible. I haven't checked
every package, but I am betting 'tinc' would clash in openwrt-routing.
Having SNAPSHOT builds include LiMe feeds makes sense, but
for release builds it does not. Need to freeze at some point.
I trust Gui since they're both an Openwrt and LibreMesh maintainer. Accounting
for this case and perhaps others I've not considered is trivial. I'm
in agreement
having lime-feeds packages compiled and hosted by openwrt buildbots will
shift a bunch of weight from the LiMe developers and operators.
Obtaining LiMe packages via Openwrt builders/servers would be ideal.
> 2) alternatively, make a series of pull requests adding each of "our"
> packages to the standard "packages" feed
> https://git.openwrt.org/feed/packages.git
>
I'm thinking more eyes would be able to review because commits run
past LiMe and Openwrt eyes albeit at a different rate. I think there's
2 or more OpenWrt devs contributing to LiMe so not so much an issue.
> is there any other option i'm missing, or caveat regarding those two
> that would help us decide? (i.e. would a PR against feeds.conf.default
> be acceptable?)
>
I'm sure the 21 members of to LiMe packages are fun and develop in
good faith / good intention, but I'd want to see proof LiMe packages can't
conflict with upstream packages. I could have sworn the youngest
package rev wins compile time and becomes an .opkg, no?
The next obvious is github's dependability. I'd like to think we'd be able to
follow suit with say, https://git.openwrt.org/feed/libremesh.git
-Will
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
