Marlinfirmware.org is down

[indazoo]

Hi

The website is down.

---

Sorry! This site is experiencing technical difficulties.
Try waiting a few minutes and reloading.
...

---

Issue 1775 needs maybe a reopen. I created a new issue because I'm unsure if anybody would notice the comment I made on the closed issue 1775.

#1775

Would be nice to have it up. I wanted to know what is new in Marlin 1.1 vs 1.0.0 RC2 of my huxley.
Thanks!

[indazoo]

ah I just saw issue #2737. So maybe someone should update https://github.com/MarlinFirmware/Marlin

with the link to https://github.com/MarlinFirmware/Marlin/wiki/Main-Page ??

[Roxy-3D]

That sounds like a good idea!

@Wackerbarth Do you agree?

[Wackerbarth]

Agreed and done. But we really need to open a different wiki on MarlinDev so that we can document the aspects of that repository which differ from the version found in the Marlin repository.

[Wackerbarth]

@AnHardt -- Shouldn't we just close this? It would be nice to have access to Marlinfirmware.org, but since "we" don't, why even consider it?

[AnHardt]

@Wackerbarth
One of the reasons for " marlinfirmware.org" was the much more pregnant name than "github.com/MarlinFirmware/Marlin" what did not fit on the boot-screen.

Since some minutes "marlin-firmware.org" is pointing to "github.com/MarlinFirmware/Marlin". But don't use it for now. Maybe tomorrow it will point to the already prepared "github.com/Marlin-Firmware" organisation with a "old fashioned" Marlin.

You deeply shocked me with #2797
If you really insist in deleting parts of the code i'm away. When i go away,
I hope to reactivate some of the former developers there, with a very conventional repository with a dev-branch in Marlin, without a second MarlinDev repository and a nice, old fashioned, way of using the Arduino IDE.

[Wackerbarth]

@AnHardt -- Re: #2797
I think that you are misinterpreting what I am saying about "deleting" features.
I have no intention to delete ANY feature from the 1.1.x development chain. That chain is presently in a pre-release state and as soon as we actually release 1.1.0, it will become the basis for 1.1.1, etc.

However, I do not think that it is a good idea to actually release "features" that are known to have serious functionality problems. Doing so is going to cause significant support issues and create disappointed "customers" who find that things don't work. IMHO, it is far better to tell those users that we had to withhold the feature and are still developing it. If they really want to try to use it, they can always build from the branch where that development is happening (just as they do today).

So, I am suggesting that we may need to make the 1.1.0 release a spur off of the 1.1.x line by deleting some functionality that isn't working anyway. That way, a user may find something "missing", but, hopefully, not "present, but broken".

Those who choose to use non-release code will also be doing so with the knowledge that there are likely to be issues which they will need to address or otherwise work around.
But, hopefully, the less sophisticated user will be able to experience a quality product that we can be proud of.

If we choose to drop some features from 1.1.0, then I hope that we won't run into the excessive delays that are plaguing the 1.1.0 release. As long as we are actively adding features, I suggest that we have quarterly releases and that ALL contributors respect the necessary deadlines for inclusion in a particular release. If the feature isn't ready on time, it will miss the boat and need to wait for the next one.

[github-actions]

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.