RepRapFirmware 3.0RC1 released

gtj0

Oh boy! A semantic versioning discussion and release process!!! COUNT ME IN!

OK, so here's what we do at Asterisk.
Assuming the current RRF major version is 3 and the next will be 4...

We start with 2 branches, "3" (current), and "master" (anything targeted for 4). With no prior history, "master" and "13" are equal.

We start with a "3" branch where all development goes, bug fixes and new features that are slated for major release "3". Commits are also cherry-picked to "master".
When we'd create the first RC of "3.0" (3.0.0-rc1), so we'd create branch "3.0" from "3", tag it "3.0.0-rc1" and release from it.
If there are no issues with rc1, we tag that same commit in the "3.0" branch as "3.0.0" and release it.
Meanwhile development continues in "3".
If there are issues with rc1, the fix is committed to "3" then only that commit is cherry-picked to "3.0" and rc2 is cut.
This way the ONLY difference between rc1 and rc2 are fixes for issues found in rc1.
Meanwhile development continues in "3".
If we discover a critical bug that needs to be released quickly, the fix is committed to "3" and cherry-picked to "3.0".
If there are other critical fixes, they are also cherry picked to "3.0".
We then create a release (skipping rc/beta) of "3.0.1" which ONLY has the critical fixes.
Meanwhile development continues in "3".
When it's time to create "3.1" it's the same process.

All thew while all commits in "3" are cherry-picked to "master" so "master" is always up to date with "3" plus it has any development that is slated for the next major release.

When we start thinking about a new major version, we create "4" from "master".
Assuming "3" is still the current release, from here on, any new commits are cherry-picked to both "4" and "master". New stuff for "4" also goes into "master" and any experimental stuff for the future goes only in "master".

It sounds complicated but we use Gerrit so the cherry-picking is easy.

I'm not saying all of that stuff should be done here of course. I just wanted to highlight the differences between release versions. Also, this scheme would require that commits contain only 1 functional change and that'll be a big change for both @dc42 and @chrishamm .

I do believe though that as the user base picks up with the Duet3, RRF and DSF that changes will ultimately have to be made in the release process as well as the issue reporting process or customer perception will suffer.

@dc42 and @chrishamm , Welcome to the "real" Open Source world.

dc42

Sounds good; but in trying to apply the same fixes to RRF 2.04 and RRF3beta12, I found cherry-picking left such a mess (because the code had diverged so much between the branches) that it was better to copy across the changes manually. In doing so, I spotted that one of the fixes I had done in 3.0beta wouldn't work in 2.04 anyway. Cherry picking commits would work OK if nothing had changed in/around the code that the bug fixes were applied to, and the bug fixes didn't interact with other code that was different between the branches.

Either way, applying the same fixes to more than one branch involves a lot of extra work, especially in testing. That's why I try to avoid it. If I had an army of users running tests, it might be different. Even better from my POV would be for me to work just on the next release, and for someone else to pick up fixes from the branch I work on, back-port them to the previous stable release, do the tests, and do a patch release.

Phaedrux

@dc42 said in RepRapFirmware 3.0RC1 released:

Even better from my POV would be for me to work just on the next release, and for someone else to pick up fixes from the branch I work on, back-port them to the previous stable release, do the tests, and do a patch release.

Perfect, when is your new clone being decanted?

gtj0

Yep. There is NO "right" way. It's all about what works for specific projects, community participation levels, etc. When you're only one person you have to budget your time accordingly. The more time you spend on admin, the less you can spend on real work. Making it easier for folks to contribute both code and time can help but even that takes time in the short term.

One thing that can help in the really short term with little effort is to create a new category in the forum specifically for reporting bugs, regardless of whether it's a DSF or RRF bug. A user should triage their own issue in one of the other categories by asking for help first but if they really think it's a bug, report it in that new category. I'm still confused about where I should report bugs for which components.

gtj0

@Phaedrux said in RepRapFirmware 3.0RC1 released:

@dc42 said in RepRapFirmware 3.0RC1 released:

Even better from my POV would be for me to work just on the next release, and for someone else to pick up fixes from the branch I work on, back-port them to the previous stable release, do the tests, and do a patch release.

Perfect, when is your new clone being decanted?

He needs a few unpaid interns as part of a work/study program. It might actually be pretty attractive to someone because he deals with both hardware and software design in a growing technology.

Danal

@gtj0 said in RepRapFirmware 3.0RC1 released:

One thing that can help in the really short term with little effort is to create a new category in the forum specifically for reporting bugs, regardless of whether it's a DSF or RRF bug. A user should triage their own issue in one of the other categories by asking for help first but if they really think it's a bug, report it in that new category. I'm still confused about where I should report bugs for which components.

Yes, YES, YES, please!

Phaedrux

@Danal said in RepRapFirmware 3.0RC1 released:

@gtj0 said in RepRapFirmware 3.0RC1 released:

One thing that can help in the really short term with little effort is to create a new category in the forum specifically for reporting bugs, regardless of whether it's a DSF or RRF bug. A user should triage their own issue in one of the other categories by asking for help first but if they really think it's a bug, report it in that new category. I'm still confused about where I should report bugs for which components.

Yes, YES, YES, please!

The issue with this is that the average user is not really savvy enough to determine what is a bug and what is a configuration issue and typically just assume something must be a bug.

I would think that users savvy enough to be looking through the code should report the actual bug via github, but that may actually be more work for DC42 than it just being reported on the forum.

gtj0

@Phaedrux said in RepRapFirmware 3.0RC1 released:

@Danal said in RepRapFirmware 3.0RC1 released:

@gtj0 said in RepRapFirmware 3.0RC1 released:

One thing that can help in the really short term with little effort is to create a new category in the forum specifically for reporting bugs, regardless of whether it's a DSF or RRF bug. A user should triage their own issue in one of the other categories by asking for help first but if they really think it's a bug, report it in that new category. I'm still confused about where I should report bugs for which components.

Yes, YES, YES, please!

The issue with this is that the average user is not really savvy enough to determine what is a bug and what is a configuration issue and typically just assume something must be a bug.

I would think that users savvy enough to be looking through the code should report the actual bug via github, but that may actually be more work for DC42 than it just being reported on the forum.

Yeah a new category isn't a perfect solution but @chrishamm seems to want his issues reported on github but I'm not sure where @dc42 would prefer them. Github is also a problem when an issue crosses over. For instance, I've had a few issues open against DSF but @chrishamm is waiting on @dc42 to do work in RRF. There have been a few the other way around as well.

This is where a common issue tracking system comes into play but that also takes time to set up and administer.

A Former User

@Phaedrux said in RepRapFirmware 3.0RC1 released:

typically just assume something must be a bug.

thats not how you spell feature! ... but fair point.

And how to version things is not how I'd prefer the limited development effort to be focused no matter how much I'd rather see the major.minor.bugfix scheme adopted.

dc42

@Phaedrux said in RepRapFirmware 3.0RC1 released:

The issue with this is that the average user is not really savvy enough to determine what is a bug and what is a configuration issue and typically just assume something must be a bug.

Exactly. My most common response to issues logged on the RRF repository in Github is along the lines of "This is a support question, use the forum". For a while I even disabled the Issues feature because I was getting so many support questions raised there.

Another weakness of github Issues is that it doesn't separate bug reports from feature requests.

Currently I track bug reports on a spreadsheet shared with my colleagues, linked back to the forum threads in which they were raised.

A Former User

@dc42 said in RepRapFirmware 3.0RC1 released:

it doesn't separate bug reports from feature requests.

this can actually be configured, you can mark the issues with flags such as "bug", "feature request", "regression" etc etc .. also you can setup what needs to be filled in for bug to be consider "fully reported" and the github bot will autoreply that blah blah is missing and you ignore reports that are marked such way..

look for e.g. octoprint https://github.com/foosel/OctoPrint/issues

when you go to create new issue you get to:

there's a bunch of stuff you can setup on github to make your life easier and to allow for community to better help you ... I'm not a github (I use self hosted gitlab myself and for my company) expert but I'm sure we can get one if we ask to help set all this up

gtj0

@dc42 said in RepRapFirmware 3.0RC1 released:

@Phaedrux said in RepRapFirmware 3.0RC1 released:

The issue with this is that the average user is not really savvy enough to determine what is a bug and what is a configuration issue and typically just assume something must be a bug.

Exactly. My most common response to issues logged on the RRF repository in Github is along the lines of "This is a support question, use the forum". For a while I even disabled the Issues feature because I was getting so many support questions raised there.

Another weakness of github Issues is that it doesn't separate bug reports from feature requests.

Currently I track bug reports on a spreadsheet shared with my colleagues, linked back to the forum threads in which they were raised.

See. You want them here but @chrishamm wants them on github.
So if you want them here, which category and how would a user know?

T3P3Tony

Generally it appears that most things are dumped into general discussion (not just potential bugs but most things) with only a subset of people using the other categories. Where important and appropriate and I try to move them.

If we had a "bug report" category I am not sure that would make it more likely that bugs get reported there and other issues in the appropriate category. More likely there would still be bugs in general discussion and configuration issues in the "bug report" category.

OTOH think github is an appropriate place for developers to collaborate and point out bugs/issues (as you do!)

gtj0

No to beat a dead horse but did you know that as an open source project, you can get free licenses from Atlassian for Jira?

T3P3Tony

@gtj0 said in RepRapFirmware 3.0RC1 released:

Jira

very weary to try more tools at this point!

gtj0

@T3P3Tony said in RepRapFirmware 3.0RC1 released:

@gtj0 said in RepRapFirmware 3.0RC1 released:

Jira

very weary to try more tools at this point!

I know, I was more just pulling your leg.

Synapsis

@Phaedrux Thanks will stay with 2.05 for now.

fma

@Danal said in RepRapFirmware 3.0RC1 released:

My humble apologies for saying "We will always agree to disagree...". It was not you @fma; in fact you never posted to that thread.

I didn't take it for me, don't worry

There are perspectives in the user community that the overhead of merging a "bugfix only" N.0.N into N.1.0 would yield a negative return when implemented by a very small (almost one man) development team. We'd prefer to stick to the current arrangement.

I understand that RRF is not developped by a large company/community. But I developped a few free softwares myself, and didn't have much troubles to use major.minor.bf. But I admit I was not as active as David is (it was only on my free time): RRF is releasing tons of new great features very quickly... Maybe it could be acceptable to release less often?

I also know that it is much more interesting for a developper to add new features rather than fix bugs or refactor code. But these steps are mandatory for quality.

I always take Gimp as example: releases are very rare, but always great quality, and I never had a single crash with this software, nor nasty bugs. The team ensures the code is rock solid, and I think it is a very good approach, very respectfull for users.

Last, I apologize for putting coins in the juke box, and restarting that thread

Danal

@fma said in RepRapFirmware 3.0RC1 released:

Last, I apologize for putting coins in the juke box, and restarting that thread

Hey, no problem. Philosophical debates are kinda fun.

3dmntbighker

What does the new "standard" entry look like on a Maestro for a Duet3D PT100 daughter board?

M308 S1 Y"rtdmax31865" P"ctemp" F60 ; Activate PT100 hotend temp sensor

This gives me 2000C at ambient, and the pin names for the daughter board were not obvious to me.

 edit: Ah, so spi.cs1 (from Duet WiFi section) seems to be the secret sauce. How do you do the virtual driver listed below?

 ; M308 P101 X1001 S"DuetDriversTemp"	; Virtual heater to display stepper driver over temp flags

Also, without changing my numbers when I converted the old M305 to 308 for bed thermistor...

M308 S0 P"bed_temp" Y"thermistor" R4700 T100000 B3950

I got 6.4C at ambient. Before they were within a couple of degrees at ambient.