Policy for maintaining open issues

[TerryE]

The nodeMCU team have suspended active contributions to this project until further notice. However, the support and maintenance of the project is being continued by a small number of independent contributors until such a time as the nodeMCU team can re-engage. Our priority is to produce a stable release:

• Based on the current SDK (now at 1.5.1 ot time of posting).
• Including Johny Mattson's unaligned access to flash patch.
• Including Terry Ellison's strip_debug patch
• John and Terry's refactoring of duplicated string and memory utilities.
• Improved integration with Marcel Stör's, Custom Build Service
• Including improved user documentation and Lua examples.

The nodfeMCU firmware is a fairly thin eLua-based implementation layered over this SDK, and by rebaselining to this current version, this will address many report firmware issues that are in practice a result of known SDK issues (see SDK Release notes). Our other enhancements will significantly increase the effective RAM available to Lua programs.

However, in order to achieve these aims with our limited resources we have to enforce a strict scope on issues that we will accept here. We will specifically close:

• Any questions of a "how do I ..." or a "I can't get this to work ..." (Please refer these application developer forums such as StackOverflow with the esp8266, nodemcu or Lua tags, or esp8266.com)
• Any enhancement requests where the originating poster is not proposing to resource the development him or herself as we don't have the effort to resource additional enhancements
• Any issues relating to builds prior to 1.5 as all work on these has stopped. However, we encourage posters to upgrade their firmware to a SDK-1.5.1 dev build and if the issues still exists then we will investigate it as per the following item.
• Any bug reports with a SDK 1.5.1 based build that does not define the build baseline and include a standalone example (in the form of a gist or inline code) which clearly demonstrates the bug.

Notwithstanding this, if we can give constructive feedback then we may still provide guidance on such closed issues, but we reserve the right not to comment further.

We will also be reviewing all existing open issues and closing any issues which fail to achieve these criteria. However anyone is free to reopen such issues if they can provide the necessary supplementary information (e.g. by providing an example which shows that the bug is still present on the current dev build).

We apologise for what may seem very strict criteria, but we must focus our limited resources to achieve the greatest common good.

Note: there are currently no prebuilt versions of SDK1.5.1-based dev branch available, as the firmware with a full module set will not load into 512Kb flash parts. You will either need to do a local custom flash build -- see this esp8266.com article How to set up manually the GCC toolchain and SDK, use Marcel Stör's Cloud Build Service or the Docker NodeMCU build image.

[marcoskirsch]

Shouldn't this be in a read me rather than in an open issue?

Thanks for your efforts!

[TerryE]

I should think it's open until we've done the cull. Some contributors and developers might have an issue with this. However, the only real alternative as I see it is to allow the project to go inactive.

[dwery]

Thank you very much

[devsaurus]

Improved integration with Marcel Stör's custom build service

We should to revisit #386 then. It's been unattended for too long.

[nickandrew]

Thanks for your efforts!

I rebased my OneWire fixes against dev140 branch and I noticed some of them have already made it into the branch in some manner. I'll re-test the remainder against dev140 within the next few days and submit another pull request.

[TerryE]

@nickandrew, you'll need to use a branch rebaselined against dev and cherry pick your commits against that. That's what I did with my #722. The first two commits in this are cherry picked from master and the third fixed a functional merge issue against the 1.4 changes, plus a bug fix that I hadn't yet raised a PR for. This way the PR is a fast-forward merge.

[marcelstoer]

Nothing beats #719 that's pretty obvious. I'm not even gonna argue that keeping a (potentially shortened like http://j.mp/1SClr70) URL somewhere handy takes only 3s longer to copy-paste because I know it's not the same thing. Also, we can't just edit the initial description of this issue as some of the comments wouldn't make sense then.

So, if you want to stick with using an issue, nothing against that, then we should create a new one with an up-to-date description but lock it ('Lock conversation' link). That way you can adjust the description anytime without destroying a conversation thread because there won't be one. But hurry before the issue numbers move from 3-digit to 4-digit 😉

[TerryE]

Marcel, looks like you have drawn the short straw for authoring ?963? Or should just wait until #999? The markup integration means that when you hover over the number, the javascript pops up the title. You need to use the long MD format [title](link) if you use a tiny url or equiv to see the user-friendly title.

But I could do with a break from being Mr Bad Guy. 😢

[marcelstoer]

Superseded by #1010.