How-to-build doc is needed

OpenWRT example:

https://wiki.openwrt.org/doc/howto/buildroot.exigence

I am in the process of setting up a new VM of an older OS to build LEDE, because OpenSSL 1.1 is not supported. Unfortunately it fails to build on Debian stable too, for reasons I have not yet figured out.

Based on what you just posted, do you really think anyone can replicate your issue given the extremely sparse information you provided?

Debian 8.6 (AMD64) works fine, not sure what you're using.

The topic here is about build docs. My lack of detail about my issue was intentional. I'll make a bug about it.

I am probably missing some recently added build prerequisite that I've forgotten about. That's why I mentioned it.

As a followup to my other response to you: LEDE is very much in a startup phase. Right now, there isn't a lot of good documentation. (Much of what's on the OpenWrt site still applies, but its quality is wildly variable.)

The people making LEDE documentation today are working alongside the people doing development, taking what's on the OpenWrt site and revising it to be correct and succinct, so that newcomers to the project can succeed.

We may not have reached the standard you need to be successful. In that case, please help us by taking a stab at a project, asking for help here on the forum, then writing it up. Or if that's not a possibility, come back and take another look at LEDE in six months when the software and the doc's will be vastly improved.

I hope you make the first choice - joining in. Thanks.

Perhaps will help:

https://git.lede-project.org/?p=source.git;a=commit;h=70b104f98c0657323b28fce140b73a94bf3eb756

Other projects I work on use this "Needs documentation" tag in the issue that introduce the fix/change. It means that the code introducing the changed now that the doc also needs to change. The issue is not closed, code merged/cherry-picked before the doc is updated, and the wording of the change is approved. Too me this is the "only" way to make sure that documentation does not drift from what developers are changing/adding.This does not apply to more generic documentation that not directly rely on versions but perhaps on major version but that is often solved by the documentation having a tag allowing users to tag what major versions it apply to. Example works with: 17.x, 16.x.

1 Like