When to drop the next master release

[HHHartmann]

Sorry for opening an issue for this, but it seems right to discuss this in a visible place.

In #3060 (comment)
@marcelstoer wrote:

I think it would be very valuable (and thus welcome by the community) if we merged dev back to master in the coming weeks. It's been almost six months but there are a few things pending: https://github.com/nodemcu/nodemcu-firmware/milestone/14. So, I wouldn't mind landing this on dev soonish as it looks quite mature.

I would like to see some bugs fixed before we merge into master.
Uploading LFS.img with ESPlorer does not work anymore #2963
adc.readvdd33() #2925
enduser_setup "Handling POST" failure on 310faf7 and dev #2931

Especially the upload bug will leave a good part of the community without a working master.
The readvdd33 bug is a regression and I think should be fixed rather sooner than later.
They are both fixed in Terry's branch.
Also the broken enduser_setup should be addressed.

[marcelstoer]

I would like to see some bugs fixed before we merge into master.

Definitely! That's also the reason I maintain these milestones and the reference from PR to milestone (tracking yet-to-be-merged stuff).

[nwf]

I would like #3064 to land as well before the next cut.

[marcelstoer]

It's in the milestone, yes.

[nwf]

In the interest of cutting a new release, I have dropped #2854 and #3075 from the milestone. #2854 needs work, still, and #3075 should not be part of this cut to master, but rather the next one, since it touches so many modules (with a goal of NFC, to be clear, but just in case) and has not been given a thorough shakedown.

That means, I think, that we are blocking on @HHHartmann to decide that #3069 and #2985 should land or not. Given @TerryE's resurrection of the Lua 5.3 branch, I'd like to make the drop to master approximately now so that we can then land his work on dev and have all of us test it out and do point fixes as needed.

[HHHartmann]

As far as I am concerned #3069 can go in as it is tested and imposes no risk at all.
#2985 is tested only half. But with some luck it will be tested soon.

But as stated above there is at least one bug (#2963) in the current dev branch which is a showstopper and which is fixed in #3075.

It also seems wired to wait for this PR for 4 Months and then do the cut without it just the moment work on it continues.

[marcelstoer]

But as stated above there is at least one bug (#2963) in the current dev branch which is a showstopper and which is fixed in #3075.

I had suggested elsewhere to unfold it from Terry's large change set and to commit/PR it separately.

[TerryE]

@marcelstoer, it took me a solid day's work to do the current dev -> lua53 merge. It am really loath to start cherry picking little bits back out, but If someone else is willing then ... TBH I've done so much work on this branch now that I can't remember exactly what this particular fix was. 😄

Maybe this is a good argument for leaving master as-is. I also think that we should clone master to pre-lua53 master just in case.

[marcelstoer]

TBH I've done so much work on this branch now that I can't remember exactly what this particular fix was.

I was gonna comment on that only to find out your redacted comment already did 😉 I checked the commits in both #3075 and #2912 and came to the same conclusion. If at all only you would find that in reasonable time I guess. And then even if someone goes through all the comments in #2963 to figure out what you changed and manually fixes it for dev it would probably cause merge conflicts in your branch.

[TerryE]

I've just checked and ESPlorer binary upload works fine on the new PR branch for both the Lua51 and Lua53 variants.

[TerryE]

Maybe @nwf Nathaniel can form a view on whether he is comfortable with the new PR at least in the Lua51 variant, though TBH I haven't had any probs yet with the 5.3 build either. In the meantime I will press on with the tidying up.

[nwf]

@HHHartmann

As far as I am concerned #3069 can go in as it is tested and imposes no risk at all.
#3069 is tested only half. But with some luck it will be tested soon.

Did you mean to give the same two numbers? Which one should have been #2985? How soon is "soon" anyway? If we are in a rush to cut master, ideally the answer is something like "by noon GMT Sunday".

As to master-cutting #3075... I am absolutely happy to have it come to dev now (or actually yesterday, even), and I will not attempt to veto a consensus that cutting master should happen thereafter rather than before, as seems to be desired.

[HHHartmann]

@HHHartmann

As far as I am concerned #3069 can go in as it is tested and imposes no risk at all.
#3069 is tested only half. But with some luck it will be tested soon.

Did you mean to give the same two numbers? Which one should have been #2985?

Sorry I meant #2985 as you guessed already. Also fixed this in the original post.

How soon is "soon" anyway? If we are in a rush to cut master, ideally the answer is something like "by noon GMT Sunday".

I can't tell as another contributor said he would test it. Anyway, no need to wait for this PR.