Marlin 1.1.0-GM - Githubissues

thinkyhead commented 7 years ago

Let's make a new branch as a copy of RCBugFix to prepare the code for version 1.1.0 release.

Let's also move the RCBugFix code into a 1.1.x-dev branch.

The 1.1.0-dino-egg (or whatever name we like) release-preparation branch will get all the bug-fixes and cleanup patches that we receive (and so will the concurrent 1.1.1 branch). We won't allow any commits of new features into the 1.1.0-dino-egg branch, and that will keep us more disciplined.

Expediting the release means neglecting some PRs and extant issues, but we can return to them in a couple of weeks after we have a solid release.

And, ya know… we should also start on the 1.2.x branch at or shortly before the 1.1.0 release also, and focus more energy on that, specifically because the file hierarchy will be so much less painful to work with.

Thoughts?

Roxy-3D commented 7 years ago

Let me change the words to something I can understand.

Let's do a "new feature" freeze.
We can still accommodate new features in a parallel branch.
We will still make changes to RCBugFix, but those changes will be strictly bug fixes.
Most bug fixes can easily be applied to both branches. But the focus will be on RCBugFix.
We will target the end of April as a time to tag the existing RCBugFix branch as 'Stable'
Once RCBugFix is promoted, the parallel branch will become the primary development branch.

Marlin Users... (and especially Marlin Contributors!) Please cast a vote if you have an opinion.

If this is the ballot sheet... My vote is an 'Affirmative!'

emartinez167 commented 7 years ago

+1 for that plan!

Regards,

Ernesto

On 1 Apr 2017, at 11:02, Roxy-3D notifications@github.com wrote:

Let me change the words to something I can understand.

Let's do a new feature freeze. We can still accommodate new features in a parallel branch. We will still make changes to RCBugFix, but those changes will be strictly bug fixes. We will target the end of April as a time to tag the existing RCBugFix branch as 'Stable' Marlin Users... Please cast a vote if you have an opinion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

mperdue commented 7 years ago

I'm not a contributor, but that sounds like a workable plan.

Bob-the-Kuhn commented 7 years ago

I support this plan. I understand the need to delay new features otherwise you'll always be delaying the 1.1.0 release.

I'm not happy that a couple of my PRs that required weeks of effort won't make it into 1.1.0 but ... there isn't enough time to get them out before the users and get enough testing on them before the end of April.

Now if they still haven't made it into release 1.8.0 then ... ;-)

phil-barrett commented 7 years ago

Agree. You have to draw a line. Everything else goes into the next release.

christianh17 commented 7 years ago

I totally agree. Without feature freeze you will never get a stable release.

JohnnyTheOne commented 7 years ago

+1 sounds like a good plan.

apballard commented 7 years ago

+1 agree on the approach

boelle commented 7 years ago

+reduce issue list

autonumous commented 7 years ago

I disagree.......

...
...
...
...
...
...
...
...
...
...

Nah not really :-) April 1st lol

Although not a contributor (yet, maybe one day), i agree with that approach.

thinkyhead commented 7 years ago

I'm not happy that a couple of my PRs that required weeks of effort

Well, some of the PRs that have been lingering a while, and which seem non-problematic, might still make it in. Just make sure to get them rebased and follow up on review comments.

thinkyhead commented 7 years ago

Without feature freeze you will never get a stable release.

Truly. And it's not like it's anyone's fault per se. Most of the PRs we get offer good improvements, and it's simply hard to resist accepting those improvements. The good thing about adding a 1.1 branch separately is we can still move forward on those PRs concurrently, but also call a freeze on 1.1.0-GM.

Bob-the-Kuhn commented 7 years ago

I'm not happy that a couple of my PRs that required weeks of effort

What I should have said was "weeks of my time, hours of thinkyhead time".

I'll add comments to my PRs as to their current state.

thinkyhead commented 7 years ago

hours of thinkyhead time

LOL. Sometimes I move too quick for some, apparently!

thinkyhead commented 7 years ago

I'm not happy that a couple of my PRs that required weeks of effort

@Bob-the-Kuhn Well, some of the PRs that have been lingering a while, and which seem non-problematic, might still make it in. Just make sure to get them rebased and follow up on review comments (as you have been).

thinkyhead commented 7 years ago

@Bob-the-Kuhn Let's have a chat with @Roxy-3D about getting you some credentials, yes?

Bob-the-Kuhn commented 7 years ago

I don't know what credentials are.

Roxy-3D commented 7 years ago

@thinkyhead Our 'Teams' are back. It looks like we can easily invite @Bob-the-Kuhn to the MarlinFirmware organization and pre-select a team. How about general-maintainers ? He will be able to Merge and Revert with that. (And handle what ever appropriate action needs to be done on Issues and Pull Request posts)

Bob-the-Kuhn commented 7 years ago

All my PRs have been reverted & all conflicts have been resolved.

Roxy-3D commented 7 years ago

@Bob-the-Kuhn Bob, please check your email... You should have an 'Invite' to the MarlinFirmware organization. Please be very careful as you click on buttons. I can speak first hand to how easy it is to make a horrible mistake!

Bob-the-Kuhn commented 7 years ago

I'm not comfortable doing merges into the main code base. I still want someone reviewing before they get merged.

I'm OK with being able to update issues & PRs.

Roxy-3D commented 7 years ago

That is fine. That is how I try to operate. The exception is, I'm fully confident on the UBL area and will merge if appropriate.

The thing is, there are some things that mitigate the situation. For example, if you are correcting an obvious logic error that only affects one part of a seldom used function... Well... The amount of damage that can be done is pretty minor. If you are changing the way endstops get checked... It might be best to go VERY SLOWLY. You get what I'm saying!

Bob-the-Kuhn commented 7 years ago

I'm in and DANGEROUS!!!

Thanks for the confidence.

Roxy-3D commented 7 years ago

So... I need closure. Are we going to agree that we only put bug fixes into RCBugFix and no new features that disrupt thing?

Or are we not going to all agree to that?

If we aren't going to agree to that, somebody is going to have to spend some time helping me understand why it doesn't make sense. I'm going to be very difficult to 'educate'. I'm probably going to be a very slow learner.

bgort commented 7 years ago

What was decided here?

Makes sense to me to put only bug fixes, etc. in RCBugFix and have a separate dev branch for new features, for whatever it's worth.

Roxy-3D commented 7 years ago

What was decided here?

Makes sense to me to put only bug fixes, etc. in RCBugFix and have a separate dev branch for new features, for whatever it's worth.

I think @thinkyhead is still planning on doing the release on April 30th. So, if that is true, that would imply we be very careful to only fix things and not break anything for the next 2 weeks. (which is not quite the same as you are thinking...)

bgort commented 7 years ago

Got it. Thanks.

thinkyhead commented 7 years ago

Making another branch is always a little bit dangerous 😜 because things get out of sync easily. So I'm just marking all current PRs with the 1.1.1 milestone unless they fix or improve something. Nothing too fancy will be merged before the end of the month. Whatever we have in the RCBugFix branch on April 30th will be released as Marlin 1.1.0.

The next trick after release will be keeping RCBugFix around a little longer (so we can bring in some of the extant PRs). Then pretty soon afterward we'll rename the branch and re-sort the files to start the 1.2.x branch.

When bug reports start to come in, it would be nice if there was only a single code-base to receive patches. But as soon as 1.2 starts, fixes will need to be applied to both 1.1.x and 1.2.x throughout the initial 1.2.x development cycle. So I think it will be a good idea to do the initial project file rearrangement without making a lot of changes to the code itself and do an initial 1.2.0 release as quickly as possible. Then the 1.1.0 branch can receive only the most serious bug fixes, while we can emphasize 1.2 as the future of cutting-edge development and new features.

emartinez167 commented 7 years ago

+1

On 22 Apr 2017, 10:58 +0800, Scott Lahteine notifications@github.com, wrote:

Making another branch is always a little bit dangerous 😜 because things get out of sync easily. So I'm just marking all current PRs with the 1.1.1 milestone unless they fix or improve something. Nothing too fancy will be merged before the end of the month. Whatever we have in the RCBugFix branch on April 30th will be released as Marlin 1.1.0.

The next trick after release will be keeping RCBugFix around a little longer (so we can bring in some of the extant PRs). Then pretty soon afterward we'll rename the branch and re-sort the files to start the 1.2.x branch.

When bug reports start to come in, it would be nice if there was only a single code-base to receive patches. But as soon as 1.2 starts fixes will need to be applied to both. So I think it will be a good idea to do the initial project file rearrangement without making a lot of changes to the code itself and do an initial 1.2.0 release as quickly as possible. Then the 1.1.0 branch can receive only the most serious bug fixes, while we can emphasize 1.2 as the future of cutting-edge development and new features.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub (https://github.com/MarlinFirmware/Marlin/issues/6188#issuecomment-296342481), or mute the thread (https://github.com/notifications/unsubscribe-auth/AGcPb4exU5qFgAdPycR8PsJdvvNa__37ks5ryWy-gaJpZM4MwVvb).

Roxy-3D commented 7 years ago

It looks like we are still on track to promote RC-8's RCBugFix to 'Golden Status' on Sunday, right?

thinkyhead commented 7 years ago

Ran out of time yesterday. Gathering release notes and other materials, reviewing last-minute patches, etc., and aiming to finish the release before 2am CDT.

thinkyhead commented 7 years ago

Marlin 1.1.0 is out now… Yieeeee! ✌️ 🏆 🍻 Excellent work everyone. Take a day off.

https://github.com/MarlinFirmware/Marlin/releases/tag/1.1.0

CONSULitAS commented 7 years ago

@thinkyhead Congratulations! Great work! 🏁

emartinez167 commented 7 years ago

Great work all!!!

Regards,

Ernesto.

On 4 May 2017, 15:17 +0800, Jochen Groppe notifications@github.com, wrote:

@thinkyhead (https://github.com/thinkyhead) Congratulations! Great work! 🏁

— You are receiving this because you commented. Reply to this email directly, view it on GitHub (https://github.com/MarlinFirmware/Marlin/issues/6188#issuecomment-299112973), or mute the thread (https://github.com/notifications/unsubscribe-auth/AGcPbxu5jvdP-CxwUJZuNu1cKkahTwHUks5r2Xt-gaJpZM4MwVvb).

Grogyan commented 7 years ago

Forget a day off. Take the rest of the week off. You guys have done an amazing job over these last two years. And this latest firmware feels so radically different from even a few months ago, goes to show the amazing work that has gone into it.

Well done everyone!

TGMods commented 7 years ago

Congratulations to all the contributors and especially to @thinkyhead for putting in so much time and effort to this project. If I could I'd buy you all a drink.

mroote commented 7 years ago

Great work everyone! This release looks amazing and your hard work is appreciated.

stigjoergensen commented 7 years ago

Great job.

Just one quirk so far, not related to the firmware but the front page og marlin

There is a link

where you will find in-depth articles, how-to videos, and tutorials on every aspect of Marlin, as the site develops. For release notes, see the page.

it points to

https://github.com/MarlinFirmware/Marlin/blob/1.1.x/MarlinFirmware/Marlin/releases

Which dosnt exist

Marlin 1.1.0 is out now… Yieeeee! ✌️ 🏆 🍻

Excellent work everyone. Take a day off.

https://github.com/MarlinFirmware/Marlin/releases/tag/1.1.0

CONSULitAS commented 7 years ago

@thinkyhead Hi Thinkyhead,

just recognized: It has been a really long journey! https://github.com/MarlinFirmware/Marlin/releases/tag/1.1.0-RC1

Regards

emartinez167 commented 7 years ago

Wow.... Indeed. Thanks for the commitment @thinkyhead and the rest of the team!

On 14 May 2017, 22:23 +0800, Jochen Groppe notifications@github.com, wrote:

@thinkyhead (https://github.com/thinkyhead) Hi Thinkyhead,

just recognized: It has been a really long journey! https://github.com/MarlinFirmware/Marlin/releases/tag/1.1.0-RC1

Regards

— You are receiving this because you commented. Reply to this email directly, view it on GitHub (https://github.com/MarlinFirmware/Marlin/issues/6188#issuecomment-301316494), or mute the thread (https://github.com/notifications/unsubscribe-auth/AGcPbz_RAWgNypiolr4VxigREv-6tBqoks5r5w5TgaJpZM4MwVvb).

thinkyhead commented 7 years ago

Thanks everyone for your participation and everything you've brought to this event!

When I started making small tweaks to the firmware in late 2014 I had no idea what it would spawn. At that time the project was relatively dormant. The elders of legend had moved on to other projects, and so Marlin languished, awaiting some new fools to fall under its spell. As changes started getting introduced, and as the project became more visible, it drew increasing attention. Since that time, Marlin has continued to receive more and more contributions, adding up to an immensely better user experience and —most importantly— better print results.

Think of all the plastic trees we've saved.

In the lead-up to the release of 1.1.0, with issues and PRs piling up, my role became increasingly about patching reported issues, and especially helping get PRs into shape for merging. Holding them for changes, helping the author to fix them up, and then, most of the time copying the branch into my fork for a rebase, additions, changes, and a new PR. I find it's easier to just make the changes than to explain them — the code explains itself. This technique also preserves the author on the commits, which is important to tracking user contributions.

This last release entailed a huge amount of work, and a daily effort by more and more active contributors. Throughout this very long (~28 month!) sprint it has always felt like a gradual, incremental, and necessary evolution of all the constituent parts of the firmware. There was a long list of requests for long-delayed features, performance improvement, and to iron out bugs. And, really, there just hadn't ever been much of a total cleanup and re-think of the code. So that was all due.

Anyway, Marlin wouldn't be where it is today without everyone who gave their time and expertise. So, thank you all from the bottom of my quality-obsessed heart! The next chapter is going to have a much more solid footing thanks to everyone who took the time to really science the shit out of this thing and redesign its innards to work so much more consistently and efficiently.

The long-awaited code re-organization is coming soon. But first, I need to integrate as many lingering PRs as possible, decide how to cope with the rest, and prepare a 1.1.2 release to get the latest patches out to the world.

This past week I've been filling out the website (Markdown with Jekyll is fast!). The GCode section is 99.9% done and all Configuration.h options are now covered.

I just have to add all the Configuration_adv.h options to that page, and fill in a few more GCode pages, and the core foundation of the site will be done! I'll continue to add more pages over the coming weeks and polish up the pages pertaining to the most important features of Marlin.

We need more step-by-step guides with images, photographs, illustrations, tables, graphs, etc. If anyone wants to contribute photos or other imagery for step-by-step procedures like bed leveling, filament change, and so on, please feel free to drop them in an issue!

landodragon141 commented 6 years ago

Is there any reason this is still open?

github-actions[bot] commented 4 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

MarlinFirmware / Marlin

Marlin 1.1.0-GM #6188