Discussion: Release process

[emilecantin]

I'd like to start a discussion regarding the release process. I know we currently use the even=stable, odd=experimental convention, but is there a reason why all of them are marked as "pre-release"?

I think it'd be way easier to actually use that pre-release feature for experimental releases. That way, we could promote experimental features to stable once they've been tested; no need to cut an additional release.

It'd also make it easier to consume the list of releases from a script. I'll probably need this as I improve on the RPI image build.

[zaneclaes]

Haha, I was wondering...

[emilecantin]

Not sure, but I lost access to Webcontrol as well. I managed to add the environment variable when I created the thing on the Travis side, but when you did something with the organization, I lost access to the settings. I guess I probably have different permissions on the pi image repo, so I do have access to that one.

EDIT: Nevermind, I just checked and I have access to everything now.

Le sam. 23 mai 2020 07 h 58, madgrizzle notifications@github.com a écrit :

Done.. why does this need to be done for the firmware, but not the other two?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/WebControlCNC/WebControl/issues/139#issuecomment-633037114, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGYF3TDJI36Y5K2HE6PYBTRS63ADANCNFSM4NENV64A .

[emilecantin]

And it looks like creating a release works properly, and I get the 3 different firmwares!

Just note that the git setup is a bit convoluted at the moment; we'll be able to drastically simplify this when we get the holey firmware merged in.

[madgrizzle]

Amazing work! So much better than my scripts! Thank you so much for working on this.

[gb0101010101]

Yes, great work. Really happy to see so much activity and progress.

I like the idea of using GitFlow as it corresponds with other workflow I have used before (dev, master, hotfix, feature etc). My only concern is if it makes things harder for the hobby contributor:

• Does it complicate the simple GitHub public Fork, PR process beyond telling contributors to use 'Develop' branch?
• Does everyone need to use GitFlow to submit a Feature PR? (looks like its not mandatory)

It looks pretty straight forward to use.

Does GitFlow integrate with or extend GitHub GUI to make project management easier?

[emilecantin]

There are a lot of ways we can go about this, but if we want to go towards git-flow, we have to decide a few things:

• What should live in the default branch (HEAD on github)? i.e what should people get when they clone our repo? Stable code, or more bleeding-edge code?
  • This will guide whether we have master=stable, develop=bleeding-edge, OR release=stable and master=bleeding edge.
• Do we maintain old releases? Or do we expect users to update to the latest release to get all bugfixes?
  • This will guide whether we need the whole hotfix part of gitflow (probably not, IMO)

As for whether people need to use it to contribute, the answer is probably not, unless we want to maintain a clean git history tree. With the PR process that's already in place, we basically already have feature branches.

In my opinion, it's a little too much work for not enough benefit to maintain 2 main branches on this repo. With most people here not having a professional software development background, I feel it's better keeping things simple. However, I'd definitely encourage everyone to use git-flow conventions when naming their branches.

[zaneclaes]

My two cents:

The default (master) branch should always be stable. To do otherwise amounts to building a foot-gun for unsuspecting Fork-ers to shoot themselves with. It's best to engender a good first experience, as it means fewer issues and more good-will.

I'd also argue for not maintaining releases more than one minor version away from the current SemVer HEAD — if only as a matter of expedience for a small team. The vast majority of software development hours, I've found, go toward maintenance. Until they can justify such effort (read: $), development teams have every right to insist users upgrade to the latest if they want to be supported.

Speaking of backgrounds... by way of introduction, mine is that I was most recently a software engineer (3 years) and then engineering manager (3 years) for Airbnb. I worked first on the mobile apps, then on the API, and finally on DevOps & Observability.

[madgrizzle]

A lot of this is new to me, but what I envisioned that that we have a "stable" release and then have a series of development releases that we can test things out in.. once we are happy with what's in a development release, we do a PR and push those changes into the stable branch and create a new stable release.

As for maintenance of releases, it seems like a lot of work to go back and update releases to fix issues.. I think we'd have to have a major change to think about doing that.. like a WebControl 2.0 that works differently and some people just might want to stay on WebControl 1.0.

I also think new features need to be added in a manner to maintain backwards compatibility. For example, the support for R in g2/g3 and the zaxis limits should still work for people using old firmware. Doing it this way, I think, would allow people that just want stable, reliable operation to know that anytime they upgrade, it's not going to break their installation and they can then chose to use new features or not. This way they can get but fixes, but not be forced into making any other changes.

[zaneclaes]

Perhaps a stupid question... who are the maintainers of GroundControl? To what degree do we expect feature parity between the two?

Personally, I feel that it would be better to offer the community a single piece of software. WebControl IMO is the better approach for a number of reasons, especially: (1) OS-agnostic (2) web UI development is significantly faster than native/client development (3) remote access & monitoring is a killer feature. With some investment in modern UI frameworks and some cleanup all around, I could see WebControl becoming very user-friendly and feature-rich application.

psst... kinda wish it had been called AirControl... or AirCNC... but that's just because I like puns...

[zaneclaes]

Imagine: a built-in asset catalog that lets you upload your own designs and explore others' designs from within the app...

I could imagine this project evolving to become like Fritzing.org (an app + design tool + catalog of projects). If we wanted to go that route, I'd be happy to offer my AWS Kubernetes cluster for hosting.

[madgrizzle]

Bar (creator of the maslowcnc) created ground control.. lots of people worked on it to improve it (including me). I think he's the only one that can create releases and though I could be wrong about it, I think one of the reasons there's not been any new releases is that he's taken a step back from maslow and is working on other projects (still CNC related). It's a stable product that people use regularly and if you keep updating it, then you really need to be involved in maintaining it.. which takes time away from other things. Bar actually proposed that webcontrol become the standard software for maslow, but it was a one man show at the time and I shied away from it. That's a big part of moving this to an org and away from my personal repo.

[madgrizzle]

Good ideas.. I would like to see webcontrol maintained as a user-friendly, entry level type of program. I think that's an unserved segment and is what ground control brought to maslow. Integration with Maslow community garden (or something else) would be awesome.. so would actual CAM capabilities.. but that's a huge undertaking. Bar is working on a CAM program that might be cool if I could be tied into work with webcontrol

https://forums.maslowcnc.com/t/maslow-create-alpha-release/9885

[zaneclaes]

Thanks for the context!

One more question: what's your impression of the size of the Maslow community, and its potential to grow? I assume WebControl is permanently tied to the Maslow architecture, so the popularity will be limited to that sub-set of the CNC space.

I totally agree about the user-friendly, entry-level aspect (being that I still haven't made it past my test cuts!). It seems like MaslowCreate is already doing a lot of what I'm talking about. I'd hate to see these projects bifurcate even more. All too often, with open-source, I see stuff like this. Here's my concern about what might currently happen:

1. GroundControl becomes unmaintained, except nobody really mentions that
2. WebControl and MaslowCreate become parallel projects, not quite in competition but confusing to users nonetheless

I think if we're going to invest time in all this, we should strive toward a single unified experience. Speaking honestly, as a new user of Maslow, I still expect there to be some sort of coherent vision — and the quality of software, education, etc. is still lacking. I would hope that we could converge the project with Bar rather than diverging.

[madgrizzle]

I really don't have a handle on the size of the maslow community.. it's in the thousands, but how many I don't know.

Webcontrol is currently tied to maslow, but if we could get it to support grbl, that could change. It's not hard at that point to support other CNC machines that are grbl-based and build "quick configures" for them. I think this is important thing to be able to keep webcontrol relevant. I don't know it has to be so flexible to support others (i.e. Marlin, etc). Grbl should be enough, imo.

As for maslow create, I'm not sure bar's vision for it (i.e., will it include gcode sender functionality and all that entails?). How it would integrate into webcontrol, etc. would have to be figured out.

Finally, having a vision for moving forward makes sense, but that's a community driven endeavour at this point. Part of the issue is people come and go from the product. I think the only really community participant that's been very active from the start is @davidelang. Most everyone comes and goes in waves.

[zaneclaes]

Got it, thanks again.

I was looking around and found https://cnc.js.org/ today. They seem to have done a lot of work on the UI side of things. What if we approached them about adding Maslow support and merged the projects?

Not that I want to throw away any work done here, but I'm in favor of having fewer tools overall. I found CNCjs because I ordered a SainSmart 3019-PRO w/ laser upgrade (for my small/detailed work and making electronics cases from acrylic), which CNCjs supports, and I was reading reviews before buying that spoke highly of this web interface.

[madgrizzle]

I use cnc.js myself for one of my CNC machines that runs marlin. I wouldn't consider it an entry-level CNC program like ground control or webcontrol, but it does work well. In reality, it can be used for Maslow pretty much as-is with the grbl plugin.. I think any grbl gcode sender would work with Maslow but you need to know what you are doing. You will also need a stand alone program to do calibration calculations and it would be handy to have something that assists in setting the sprockets vertical, but the latter can be done via macros.

[gb0101010101]

FYI PR requesting new firmware release https://github.com/MaslowCNC/Firmware/issues/546 @BarbourSmith (Bar in Forums) is owner and only person that can do a release. Says he will try to get it out soon. GroundControl is not really being updated, the build process is apparently broken, and this is the holdup in releasing firmware as version IDs currently must match (GroundControl & Firmware).

As for GitFlow/Release Process: I guess I am more used to Master being stable, and only being used to commit hot fixes, but open to trying something new.

I would like to see greater testing involvement from end users (including non coders) by making it very easy to test new features in WebControl by switching between releases with a few mouse clicks. I'm not really fussed about the underlying structure, just as long as it can do this.

[davidelang]

we don't have the manpower to maintain a lot of releases, so people should upgrade to the latest to get all the fixes.

I would even say that we don't make changes to the stable branch, we just promote/tag a development release to declare it stable.

On Sun, 24 May 2020, Emile Cantin wrote:

There are a lot of ways we can go about this, but if we want to go towards git-flow, we have to decide a few things:

• What should live in the default branch (HEAD on github)? i.e what should people get when they clone our repo? Stable code, or more bleeding-edge code?
  • This will guide whether we have master=stable, develop=bleeding-edge, OR release=stable and master=bleeding edge.
• Do we maintain old releases? Or do we expect users to update to the latest release to get all bugfixes?
  • This will guide whether we need the whole hotfix part of gitflow (probably not, IMO)

[davidelang]

On Tue, 26 May 2020, Zane Claes wrote:

I was looking around and found https://cnc.js.org/ today. They seem to have done a lot of work on the UI side of things. What if we approached them about adding Maslow support and merged the projects?

'Adding Maslow support' can mean a number of things.

sending gcode to the maslow is pretty trivial, just about anything could do it.

What GC and WC add are things that are specific to the Maslow compared to all other CNC machines. Some of these things can be done by sending custom g-code, some of them are far more complex

the simple stuff are things like manually moving each motor, telling the maslow what the chain lengths are, setting Z=0

those could be done with macro buttons in any gcode sender

the complex stuff is things like flashing the firmware and calibration.

Calibration is the worst part, there is a lot of very hardware specific logic that is in GC/WC for the calibration. In the long run, I think it would be best to try to move the calibration steps into the firmware.

It's not practical to implement the calibration logic in every gcode sender.

David Lang

[davidelang]

On Mon, 25 May 2020, madgrizzle wrote:

I really don't have a handle on the size of the maslow community.. it's in the thousands, but how many I don't know.

there was a post on how many kits had been shipped, over 3K and it may have been 6k

now, how many kits are in use, and how many of those people noticed that the community exist are good questions.

Webcontrol is currently tied to maslow, but if we could get it to support grbl, that could change. It's not hard at that point to support other CNC machines that are grbl-based and build "quick configures" for them. I think this is important thing to be able to keep webcontrol relevant. I don't know it has to be so flexible to support others (i.e. Marlin, etc). Grbl should be enough, imo.

70% of it is just knowing what to look for to see what's attached (the grbl0.9 that the firmware outputs at startup) and the per-line acknoledgement

20% is going to be knowing which initialization parameters to send

As for maslow create, I'm not sure bar's vision for it (i.e., will it include gcode sender functionality and all that entails?). How it would integrate into webcontrol, etc. would have to be figured out.

the idea is to make everything as seamless as possible, but since it is a browser/cloud based solution, there are some headaches in having it send the gcode to another server (it would need to do legitimate cross site scripting, but since that's been used by the bad guys so much, it's generally blocked by browsers). So it's going to be far easier to have WC reach out to git and fetch the gcode than to have maslow create push it to WC

This would be a neat feature to add to WC, be able to give it a git URL and have it pull the gcode from there and keep it synced locally.

Finally, having a vision for moving forward makes sense, but that's a community driven endeavour at this point. Part of the issue is people come and go from the product. I think the only really community participant that's been very active from the start is @davidelang. Most everyone comes and goes in waves.

and even I get busy for a couple weeks here and there. :-)

David Lang

[davidelang]

On Tue, 26 May 2020, gb0101010101 wrote:

FYI PR requesting new firmware release https://github.com/MaslowCNC/Firmware/issues/546 @BarbourSmith (Bar in Forums) is owner and only person that can do a release. Says he will try to get it out soon. GroundControl is not really being updated, the build process is apparently broken, and this is the holdup in releasing firmware as version IDs currently must match (GroundControl & Firmware).

that's a should match, not a must match.

I would advocate that we make a new GC release that at startup recommends people switch to WC and give a pointer to a URL for instructions.

David Lang

[zaneclaes]

@davidelang thanks for the notes! We've got a more formal discussion on the future of the project over here: https://github.com/orgs/WebControlCNC/teams/developers/discussions/2