Release plan for FOG
-
FOG is a great peace of software! Many people appreciate it a lot and use it for “production” - and many of us often are in a hurry. Sometime bugs in software like FOG are a big problem in my daily work. So I would kindly suggest a different release plan for FOG.
As I know there are two branches now. One for experimenting (dev) and one for releasing (master). The new release is prepared in the working branch where bugs get fixed and new features are introduced from the dev branch (which brings new bugs necessarily).
Therefore I suggest introducing a third branch (stable, production). In stable only very small bugs get fixed with a high probability that no new bugs are introduced. A problem that cannot be addressed without the risk of causing new problems could be published as a known issue. So as a user I could decide if I wanted or needed the new features - bug fixings in the master/working branch.
-
There’s many more than just two branches. There’s master, dev-branch, working , and feature branches. The cycle going on now is working isbinkyk bug fixes, as a feature freeze fore 1.5.x has been implemented. Not sure what else you’re looking for. I ask people to test working to ensure the bugs that are being worked on are indeed working as expected.
-
I guess there is only a small minority who tests the working branch. In the moment a new version is tested after release when users do an upgrade.
So I think of something like the Debian or Libreoffice release plan. This would mean for FOG in the time of writing that a very stable product like FOG 1.4 (at least for my use case) would receive further bug fixing without any new features.
Of course that would slow down the development of new features. But FOG is a software “for production” by nature so stabilty is very important not only for me I guess.
-
@trialanderror To a certain extent important bugfixes are backported where possible. But certain fixes require certain changes to how it works from the get go and can’t realistically be backported. You’d have to make so many changes you’re essentially updating it to the new version anyway.
FOG is worked on by people in their free time. They offer a free and open source product, free of charge with quick support, often from the developers themselves. It’s a little bit insane to ask for a LTS support on older version, imo.
-
That’s correct. The main reason fog is constantly moving forward is because the codebase is improved upon. Major bugs tend to be addressed for the next release. We don’t do an LTS because there’s really two main people working on fog in a consistent manor. Those two are @Joe-Schmitt and myself. Debian and Libreoffice have the team too be able to perform such a feat. Their product is Opensource but they have an employment team which can afford them that luxury. FOG has a team but we make no money and as such are required to work full time jobs. We work on FOG in our free time. I’ve had the ability to even work on it from work because we used the software.
Maintaining many different versions is difficult. And we don’t have a support team. WYSIWYG and I think we’ve done pretty well on support, even if we don’t have the ability to do dedicated support for our product. 1.5 was a major step toward modernizing the GUI. 1.6 will vastly improve on this. It was only recently we kind of came up with a road map on how best to proceed. Of note, 1.5 will be maintained until 1.6 is released. 1.6 is focused on making he GUI much more modern. 1.7 will be focused mostly toward fixing and refactoring the FOG client. 1.8 will focus on making the FOS system more modular and usable. I don’t know yet for 1.9. 2.0 will bridge the gap for our rewrite based on the work from 1.5 and up. While we do plan to try to do backports where possible, it’s much easier to ask people to update to the latest version than it is to try to maintain many different versions with backports in mind. At least for what FOG does.
I doubt this will appease anybody, but it’s what I think needs to be said. We are working hard and provide support for our product as best we can. The community makes fogs support system, I think, one of the best around. Add to that and you can almost always have a developer working side by side to help and fix issues as they come up, I don’t think it’s unfair to ask users to update to a specific version. Even if there are bugs, we will always try to correct what we can, when we can. (And normally it’s a pretty quick turn around).
I’m not perfect and I’ll give you that. We don’t even have a test suite to know if things are working as intended. We have to rely on the community and suggestions are great, just understand our answers won’t always be what people want to hear.
-
I would also add that maybe resort to an older version that is more stable without the features you may not even utilize. Stick with that version and you will be fine. If you want to tinker on the latest, throw another box online and test it. That way you don’t impact your production environment until enough bugs are patched on latest releases. I think too many people jump on the latest version of FOG and expect it to be perfect. As with any software release, bugs are expected and given the great community of FOG with feedback, it will get patched.
-
@trialanderror said in Release plan for FOG:
I guess there is only a small minority who tests the working branch.
I test all the branches against many mainstream Linux distros to see if they install successfully or not. This is not feature testing, just installation testing. Results are in my signature.
-
@trialanderror I get where you’re coming from, but I agree with Tom that this for free software would be too much of a nightmare to do LTS support on. I mean, there isn’t even a support team. I’m glad they don’t spend a ton of time going back to old codebases and backporting it. The installer does a good job of not blowing stuff up and the db schema typically upgrades fine too.
I say “good” because it isn’t totally transparent about what’s going on, so you do actually have to be a bit familiar with the upgrade process to make sure that you don’t do anything that could lead to loss of data.
