Marlin: Are we close to an RC7 yet?

[WheresWaldo]

As the contributors to Marlin are now nearly 370 commits past RC6 and many of those are not really fixes to existing bugs but rather new code or just different ways to accomplish the same thing. Can you think about locking down the feature set and creating an RC7?

With so much new stuff since RC6 there is no way this can go straight to a gold release and I know I have a dedicated group of people using the same printer as I that are eager to test this and use it as a daily driver. I have maintained a set of configuration files for the various flavors of the printer on their forums. I usually try to wait for the RC's as the configuration files change too much on every batch of commits for RCBugFix to keep up.

I do admire and love all the work everyone is doing but at some point you have to draw a line in the sand and create a 1.2.x branch and start putting new code in it and leave RCBugFix alone (of course except for code that actually fixes something broken).

Just really wondering what the path is moving forward, it is very foggy at the moment and I am looking to see when that fog will burn off to reveal a beautiful landscape.

[Roxy-3D]

I would like ThinkyHead and Joao to weigh in and offer their thoughts (and corrections to what I say) too.

We really thought RC-6's RCBugFix was going to get blessed with 'Golden' status. We even communicated that. But there have been so many tiny things that have shown up and changes made, I think your idea of freezing RC-6 and moving onto an RC-7 makes sense. And I think if we did that, RC-7's RCBugFix would be very likely to get promoted to 'Golden' and we would freeze the features in it. The code base is getting very solid and stable.

When we do finally promote something to 'Golden' status, new development and features would be happening in 'Development Branches' that most likely would be based off of the 'Golden' release. And the Golden release would not be getting any more features.

[jbrazio]

As of today we have less than 10 bugs identified which may require patching and this has been the tendency over the last couple of weeks.

There is a new feature that for me needs to be included on GA which is #3662, so I'm cheering for @clexpert and @petrzjunior right now ! ;-)

I believe it's time for an RC7, and I'm positive that will be our final RC release towards 1.1.0. In fact I suggested to do so on the 1st of June. Our milestone is currently set for 15th of June so maybe we tag RC7 then.

[WheresWaldo]

@jbrazio even if you created RC7 today, there is not enough time to evaluate all 367 commits in time for a gold release on the 15th. There are so many changes that just to make sure you get configuration files correct will take some time. Currently I maintain 6 different versions of the same configuration files for my little space in the 3D printing world and they are all for the same model printer!

Now granted not all 367 commits apply to everyone, but the potential is there that some code introduced for another style of printer could interfere with the proper operation of an existing printer. Since I am not a programmer I don't know how you want to 'store' any new code while there is a feature freeze on the current code. As a consumer I can tell you that consumers as a whole do not care about things like that. Personally I have kept up with the RCBugFix branch so at least one set of configuration files are done for my group. But it really is time to 'put this baby to bed', using an American colloquial expression.

[Roxy-3D]

There is a new feature that for me needs to be included on GA which is #3662,

@jbrazio If the current M600 got its feedrate numbers fixed... Would that suffice for you? The big problem for me is I use M600 without an LCD Panel so I (and I suspect others) need the new code to support that mode too.

Alternatively, Maybe this new code (and feature set) should get its own MCode number and we should just leave the old M600 alone?

[Roxy-3D]

even if you created RC7 today, there is not enough time to evaluate all 367 commits in time for a gold release on the 15th. There are so many changes that just to make sure you get configuration files correct will take some time.

@WheresWaldo When we finally declare the Release Candidate getting promoted to a 'Stable Release', that does not mean it is 100% bug free. There will be some very small issues that are causing a few people problems. In theory, this stable base just keeps getting more and more stable and small changes are made to clean things up and fix newly discovered bugs.

And jbrazio wasn't saying we were going 'Golden' on June 15th. He said, that was the original target date and it might make sense to start RC-7 on that date. Which would imply if everything went smoothly it would still be 2 or 3 weeks until RC-7's RCBugFix got promoted to that status.

But to your main point... We are trying to close in and get a Stable Release declared.

[Sebastianv650]

Another thing you might consider for the next release: What should happen with the pressure advance feature? I'm refering to both versions, the old one and my new version. I can understand that merging it to a nearly gold-release might be a risk as it could add new bugs.
On the other side, the current implementation is completely broken. So I think it should be removed or at last marked as broken very clearly, so that nobody tries to use this anymore.

[petrzjunior]

If the current M600 got its feedrate numbers fixed.

In the #3662 feedrate is being set in config, I think that it's more than just a pre-release of this function. We wanted to make it working, and now some rework on these cosmetical issues is being done for the next release.

[WheresWaldo]

@Roxy-3DPrintBoard It's code, unless it's 'Hello World' it is never bug free. I understand that having worked for one of the big 3 PC software companies.

I actually think you could go RC7 before the 15th. Just as an example of code that could have waited. The buzzer pull request and commit. It wasn't broken, it might have been inconvenient in certain circumstances. It didn't prevent anybody from doing what 3D printers are supposed to do, print things. Even though it only added a few lines of new code, it was not necessary to insert in a Release Candidate. There are other examples in those 367 commits, that was just the newest one. I was just trying to point out that the more code you add the more time it takes to reveal any show stopping bugs. It would be a big step forward if there would be enough discipline shown to not add new stuff just because it's easy or because it can be added. That is all I was trying to say, even though it didn't really come out as intended.

As soon as a decision is made on an RC7 I will have at least a dozen people working on it printing daily on their printers. Even though I use RCBugFix I find it difficult to ask these users to upgrade every time there is a batch of commits with so many changes. It will marginally help find any issues (they are all the same printer so a real world sample size of 1).

You along with the rest of the contributors have done a marvelous job with the firmware so far. I can say with 100% certainty, that my printer is more precise, more accurate and more reliable with 1.1.0 than it ever was as delivered.

[WZ9V]

As a former developer and now project manager of development projects, my preference would be to let the developers decide how RC7 should be handled. Setting an arbitrary date never works although it can serve to focus things. I do feel that the features/issues list for RC7 needs to be decided on and then lockdown the list in order to get 1.1.0 out the door. I've seen this happen on my projects where the good idea fairy keeps us from delivering because there is always one more good idea to try and squeeze in. At some point you have to say this one is good enough and then move on to the new version.

[WheresWaldo]

@WZ9V You know I will have something as soon as it goes to RC7 then Gold. I am from the same background as you are but a group product manager rather than program manager. RC's should almost always be feature frozen. Playing with new stuff and experimenting with new ways to do things should be left to Alpha and Beta code. At least that is how I ran the products I was responsible for.

[Roxy-3D]

Please believe we all pretty much agree with your thoughts. And in fact, we have several Development Branches planned. Right now (and I don't think this is going to change) they are going to be based on the Golden Release. At that point, with multiple development branches working on different topics, we can probably move faster.

Everybody wants the code to go 'Golden' !!!

[jbrazio]

You started with a bad example, the buzzer was a bug report. RC is all about killing bug and push something into the wild to get more feedback. All we do is feedback based, there no single "feature" inside RC which was not a request or came out of a discussion. Of course when you're on a RC circle freezing features helps you do not introduce more bugs, so here we agree.

I don't understand why you're complaining, Marlin was really lagging behind and we having been answering to all user request.

We strongly advice everyone to use RCBugfix instead of a tagged RC release because we're very confident that the branch is more stable now than one month ago.

[thinkyhead]

The main thing we need is lots of testing of all the most common setups so we can ensure that we've fixed all the bugs in the issue queue. Such as…

3964 - CoreXY endstops ignored

3966 - M600 feed rates (and improved M600 PRs #3605 #3662)

3974 - Hanging on temperature check

3981 - Random hanging when SD printing

I also wanted to speed up the code and reduce the binary size a bit ahead of release, in deference to the smaller boards and to make sure the Stepper::isr is optimal.

And where possible, ahead of releasing to the public, I wanted to make the configuration (especially of probes) a bit more clear, if only by writing up better descriptions in the configuration files. I know this will be an area of confusion for people in their upgrades.

Finally, rumor has it that we might have Unified Bed Leveling soon. If this is as big an improvement as it is touted to be, then I would like to see this tested and included in the release also.

And oh yeah, we need to shore up the documentation and bring it fully up to date for 1.1.x.

[Roxy-3D]

And where possible, ahead of releasing to the public, I wanted to make the configuration (especially of probes) a bit more clear, if only by writing up better descriptions in the configuration files.

I know I don't follow directions well. Some of this is my fault. But I'm 100% in favor of getting the probe configuration easier to do. I know about Auto Bed Leveling but that doesn't keep me from running off the cliff every time I setup a new printer. I can never get my probes to work right without help.

Finally, rumor has it that we might have Unified Bed Leveling soon. If this is as big an improvement as it is touted to be, then I would like to see this tested and included in the release also.

This is way too invasive to be included in a Release Candidate. What I'm trying to do is have it done at the same time you get the RC-7? promoted to Golden status. And it will be our first Development Branch and published at the same time. If you want perfectly stable, you go with the Golden Release. If you want the extra features in the Unified Bed Leveling and can tolerate a little bit of pain, you can grab the Development Branch.

And if at any time you change your mind.... Flash the other version.

[thinkyhead]

So, target UBL for 1.1.1?

[Roxy-3D]

Yes. And release it into the wild as a Development Branch within a few days of the RC-7 going Golden (and it would be based upon the Golden code). The only difference between the Golden code and this Development Branch would be the Bed Leveling has been Unified.

I'll have it pretty solid and worth using. But it won't be as debugged as you have the current RC-6 code. So, from that stand point, it would be a step backwards. I think we all can agree we want the Golden code rock solid!

That makes sure this team doesn't end up in "the line of fire". If there is a problem for some people with the Unified Bed Leveling code, we just say "Use the Stable Release". Conversely, the people that need the features can move to it knowing there is a fall back position if things don't work out for them.