Welcome to the forum @mr-russ, and I hope you’ll find this a suitable place to discuss developer work. There’s also a Staff category which used to be used more, but this seems like a reasonable spot to talk.
Thanks for writing up a great set of questions, most of which need better answers. Can you help there?
Although I’m a bit of a stand-in for @gpatel-fr who is interim maintainer, I can give some historical info, while adding that in my view a whole lot of process change is possible if someone has a good idea and can come up with workable ways that fit the various parties. Sometimes lightest is best, sometimes not.
This isn’t a huge organization, but I think its success and its future goals may call for some adjustments. Because this is still a volunteer effort, I hope that the actual volunteers can help some with the shaping.
Historically, Duplicati began as one developer, expanded some, contracted, and is now trying to rebuild, which won’t be instant, but does seem to offer a lot of flexibility. In that sense, good time to be talking…
This is an opinion piece, and I’m not seeking to step on toes. Any volunteer also has other things going. People have free times and busy times, and we should plan for flexibility as the resources come and go, which isn’t at all the same as not planning. I think getting a bit more specific and deliberate may help us.
Release: 2.0.6.105 (canary) 2023-04-09
Not quite success, so I’ve begun selected work with you while the new interim maintainer is fixing Macs and missing steps (real stairs… – I hope you’re OK). You can see some of the post-release fallout there, and it looks like another try at Canary will happen if we can get some more people with Macs to pre-test.
I’m not a GitHub expert, but I think I explained (maybe on some PR or Issue post, which is a bad place), how having a single master branch (from which Canary emerges then hopefully lasts into a Beta) locks merges and releases somewhat, leading to possible slow spots. With few people this matters less since someone who’s busy fixing a Canary might want to focus on that. With more people, it causes problems, however it might be useful to plan for a future that flows better if it can fit what can be varying resources.
I think having a release to 65 million backups per year with a cut from master makes master worse for riskier development, and I’m pretty sure that the mega-changes such as leaving .NET Framework give overwhelming push to change the build and release model. If you have a workable idea, please speak.
There’s been much said before, some going nowhere. There are new people now. We do have to keep within what the original developer can release, as he has decided to keep that portion. Statement was:
Is duplicati alive or stable? #4889
Hi, thanks for the concern and raising the issue. As it stands now, I have very limited time and I am not able to fix issues and review PRs. I maintain the servers and other background stuff that needs to be running.
I can commit to doing the releases (building, signing, etc) if someone wants to take on the other roles.
and I basically read this as much of the project activity being delegated downwards, so let’s sort it out.
Lack of its original developer for some years has certainly added to lack of confidence. The answer is? Basically, how to proceed confidently given the situation? I don’t think we can, fully, but processes and working agreements may help, the who-does-what-when sort of talk that’s being hashed out here a bit.
Setting up GitHub to contain risks better would seem a wise move, but I’m not the one that can do that, and I’m not the one who would have to develop for that or the one who might move some fixes around.
There is one developer pursuing further goals such as getting off .NET Framework, adding Kestrel, etc. You’ve visited there today, I see. While I’d prefer the proposal-to-proceeed from someone who is more familiar with GitHub, I’ve seen plenty of organizations have multiple branches, and sometimes messes.
From what I can see, the other varying number of core developers work on periodic releases, hopefully progressively more stable, with an eventual admittedly vague goal of finally calling Stable but imperfect. Maybe we should change the name. Nothing’s ever perfect, but IMO Duplicati still breaks a bit too often and is very laborious to repair. I tend to prioritize reliability of backups rather high, but there’s also more.
I don’t want to pull up all the discussions on whether to change the model, but here’s an example of that:
Issues to address to get out of beta and you might recognize the question below, and a lot of comments:
Upcoming beta has been used, and I think other trackers were used long ago, and now there’s this topic, which began at a lighter weight of Canary planning. Have to start somewhere, and it’s basically a re-start because the original author has had no time, and the person who was helping for awhile hasn’t in awhile.
If people like labels better than GitHub milestone, that’s probably possible to arrange. The exclude could probably be the DO NOT MERGE one for PRs, but I’m not sure I see a similar one for Issues to not pursue.
From what I hear, many projects have lots of old mystery issues that arguably could use some cleanup. Duplicati looks that way. I usually sort by last-updated to see what’s attracting any activity. If you waded deep into the issues, you might see that I went through them once, but just closing by idle time may be one approach. The code base is vastly different than it was. Anything still happening will get new issue.
The labels that exist can reduce mental load a bit too. I tend to focus on backup corruption a lot, and grow annoyed when reproducible ones get ignored, but that’s a recent thing as resources have declined. Some of these backup corruptions need an incredible amount of effort to identify the reproducible steps, however without that, it’s too hard to figure out what to fix. I suppose working on those preparation steps is certainly one very useful thing to do if merges are going slow at particular times, for whatever reasons. That’s often something one person can work on, and there is no lack of issues seeking some attention.
I’m a little more reluctant to encourage future design talks while monitoring a release, but that’s possible.
What does this refer to? If Mac fix had worked, there would typically be a break for some Canary testing from the frequently-upgrading risk-takers (this has changed as things slowed though), and Experimental serving as Beta release candidate for slow upgraders as a test that slow upgrades work, then new Beta.
That’s the historical path, and the intent of this Canary was to become Beta if nothing terrible showed up. Sometimes it’s less clear which Canary should go. Sometimes there’s a plan in advance for the Beta, to lighten up on commits to master. Risky commits are avoided at end of release cycle, but it needs plans. The published plan for this Canary was the below:
This time, it was so clear that a Beta was long overdue that it was clearer when to Beta. Answer: ASAP.
I’m told by the person with the stat that there are few people on Experimental. Additionally, new practice of very unofficial right-from-the-developer release before Canary has begun, so a lot may be in flux now.
For awhile, progress wasn’t happening, but it’s slowly coming back after some resource limitation gaps. One issue that I think the prior non-primary maintainer had (I think) was not wanting to commit PRs not understood. Not everyone knows every area. I wish we had full coverage, but I have a feeling we have gaps. I think we now have two C# and SQL devs (including you), but I’m not sure if there’s a GUI dev…
With the continued lack of time of original author, do you have proposals for how to do the best we can? Same applies to any issue. Volunteers are rare, and may have time and skill limits. What’s a good plan?
What does this refer to? I talked about pragmas in some other odd place. By name, it’s not experimental any more, but it’s not (yet) in the manual. I think this was the only survivor from pre-Canary experimental code, and the rest were specifically not added because of risk vs. reward. Allowing pragmas is aimed at performance not stability. People want everything. We both posted to a new performance issue recently.
It made it an easier decision that the safer performance experiment of adding cache worked the best, or we’d be facing a hard decision of whether the complex changes involving SQL were safe enough to ship.
One thing that can definitely reduce stability is if someone breaks the code with the pragmas, but I hope @Sami_Lehtinen (who is very good at this) knows that there are limits and can help find safe speedups:
These are all good discussion points. Any “who” question can use a volunteer. You could be a new one.
We have now moved to more of a release-on-request model, after having agreed on who’s doing them. There’s still an availability question. Previous work by original author seemed to just show up, in bursts.
Other than that, some decisions have been what I’d call rough consensus (to steal a phrase from IETF). The extended phrase adds “and running code”. Actual follow-through sometimes works, sometimes not.
If you mean stable enough to ship some release, generally it’s from the above process, especially using people who are watching for problems on GitHub and the forum. If you specifically meant when to go to Stable channel, see other comments, but that’s a harder question that historically has felt rather distant, however we’ve made much progress on stability. Anyone who thinks its bad now missed the early days.
I’ve seen organizations prioritize bugs based on guidelines, and have limits that any release must meet. This does tend to focus attention, knowing what’s needed to clear the bar. Sometimes help is called in… Agile projects might use a “Definition of Done (DoD)” concept that might also be useful. It’s collaborative. Because GitHub is a rather light bug tracker compared to specialists, that gets to a label/milestone need.
I don’t spend much time in PRs myself. Although I’m a developer, I’m new to many things Duplicati uses. My impression is that the person considering commit conducts PR reviews without specific rules on that. Duplicati has a few devs who are not super active but support their original code. There’s not any formal agreement that I know of, but being able to call on subject matters experts sometimes may help things…
I don’t know what testing was previously done on the pipeline to a Canary. I mentioned automated tests, which I believe happen even at PR submission time, but they’re generally not regarded as being able to catch all. Maintenance and continued development of these tests is another question. I don’t know them.
I’ve seen organizations do test different ways, generally with some sort of a QA department, but manual versus automated tests (and who wrote/ran them) varied. Duplicati has not found purely-test volunteers, beyond people willing to take a Canary and let us know whether it works, over some period of their uses.
What this means IMO is that before that, testing is left to developers either at their PR or on test release. This small group doesn’t have department boundaries, and working on what needs it seems reasonable.
As we’ve both been saying, I think, the question may be what can be done better with what’s available?
I hope there’s more now, so ask away, however the answer may be it needs someone to find an answer.