RE: [Discussion] Release Cycle
I think this discussion is a useful. BUT... Producing releases takes considerable effort and saying that we want a release every x months is all well and good, but historically there haven't been many people stepping up to coordinate them or do the spade work to close issues. So, in tandem with a conversation regarding how often the community would like to see releases, needs to be "is 'the community' going to pull together to make it happen?" Kind regards Paul Angus -Original Message- From: Pierre-Luc Dion Sent: Thursday, September 2, 2021 1:37 PM To: dev Subject: Re: [Discussion] Release Cycle I like the notion of LTS every 2 years and having 1 or 2 regular releases per year, like the Ubuntu model. Typically, upgrading our cloud from a major release is a big level of effort, especially around QA to make sure the upgrade does not affect customers. So, having to jump between LTS every year or so could be challenging. I'd be curious to know about other users' upgrade cycles. On Wed, Sep 1, 2021 at 1:11 AM David Jumani wrote: > Hi Gabriel, > > > 1. I'm a +1 on having regular releases between LTS ones and the > reasoning behind it. While stability is great, it will also be nice to > have a "pilot" as you mentioned which the community can test and > issues are resolved in the following LTS, rather than waiting for 2 - > 3 releases to get something allegedly stable in, which could still > have issues reported by users. > 2. I'm for having 1 Regular release (Mar-Apr) followed by an LTS > one > (~6 months down the line) each year. Wrt the LTS releases, they should > be supported for 1.5 to 2 years (at least 6 months after the following > LTS is out). If that might be too much then a single alternating > release annually around the same dates > 3. No strong opinion on this but it does seem like a good idea, but > not sure how religiously people will update the new page with every > feature they intend to add and follow up on it > > > From: Gabriel Bräscher > Sent: Tuesday, August 31, 2021 11:14 PM > To: dev > Subject: [Discussion] Release Cycle > > Hello, > > I would like to open a discussion regarding the project release cycle. > More specifically on the following topics: > > 1. LTS and Regular releases > > 2. Releases period > > 3. Enhance roadmap and Release cycle for users > > 1 LTS and Regular releases > > It has been a while since the last regular release. Nowadays there are > only LTS releases; maybe we should get back to having regular versions > in between LTS. > > With a “Regular” release users would be able to trade stability for > new features. Additionally, developers and users would have a “pilot” > of the next LTS which could anticipate issues and result in a stable > long-term release. > > Please, let me know what you think of this. Should we get back to > releasing Regular releases in between LTS releases? > > For reference, here follow the past releases: > > +-+-+--+-+ > | Release | Type| Release date | EOL | > +-+-+--+-+ > | 4.15| LTS | 19 Jan 2021 | 1 July 2022 | > +-+-+--+-+ > | 4.14| LTS | 26 May 2020 | 1 Jan 2022 | > +-+-+--+-+ > | 4.13| LTS | 24 Sep. 2019 | 1 May 2021 | > +-+-+--+-+ > | 4.12| Regular | 4 April 2019 | N/A | > +-+-+--+-+ > | 4.11| LTS | 12 Feb. 2018 | 1 July 2019 | > +-+-+--+-+ > | 4.10| Regular | 6 July 2017 | N/A | > +-+-+--+-+ > | 4.9 | LTS | 25 July 2016 | 1 July 2018 | > +-+-+--+-+ > > 2 Releases period > > > We had in the past a new LTS per year. Then, we got into two new LTS > per year. This led from having 2 LTS maintained at the same time to 3. > With that said, I think this is neither documented nor has it been > discussed in the ML. > > We have the LTS minimum and maximum support dates well defined, but so > far there is no definition/guidelines towards the release period. > I would like to open this discussion so we can update the CloudStack > wiki page [https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS] > and have a clear definition of when the community should expect each release. > > 3 Enhance roadmap and Release cycle for users > > This topic is an extension of Topic 2. Once we have “Topic 2” well > defined we will be able to present a draft of future releases. > > The main idea of this email is to look for project stability and > predictability with a release cycle/roadmap similar to what is done by > Ubuntu [https://ubuntu.com/about/release-cycle]. > We would then be able to give users and developer
[DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI
PMC members, PLEASE ONLY RESPOND ON THE DEV THREAD. Hi all, Please read all of this, I know it's a bit wordy.. We're pretty much there wrt to RC1 of CloudStack and the updated UI. We have one issue remaining, and that is about the packaging and voting on CloudStack 'engine' and its UI. The UI has been developed asynchronously, but at time of a CloudStack release, we really need to be able have definite link between the two codebases so that we release 'one thing' when we release CloudStack. A while back, I created a proposal [1], which I'd like to again put forward as the default process unless there are any objections. In addition; 1. I think that the repo 'apache/cloudstack-primate' should be renamed to '/apache/cloudstack-ui', to keep everything just 'cloudstack'. 2. In the repo RPM/DEB packaging make cloudstack-ui a dependency of cloudstack - and finally, when creating the repo, include both the 'cloudstack' and 'cloudstack-ui' RPMs/DEBs so that there is one repo (http://download.cloudstack.org/centos7/4.15/) which contains both. PS - PMC members, PLEASE ONLY RESPOND ON THE DEV THREAD. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=165222727 Kind regards Paul Angus
RE: [DISCUSS] Renaming default git branch name from 'master' to 'main'
Personally, I'm +1 on this change. Kind regards Paul Angus -Original Message- From: Suresh Anaparti Sent: Thursday, March 25, 2021 9:23 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Renaming default git branch name from 'master' to 'main' Yes Wei, all the integrated systems / scripts (using the CloudStack git repositories) have to replace the default branch name to 'main' wherever applicable. Regard Suresh On 25/03/21, 2:44 PM, "Wei ZHOU" wrote: Will it impact jenkins/travis/trillian and prs ? -Wei On Thu, 25 Mar 2021 at 10:00, Suresh Anaparti wrote: > Hi all, > > The default git branch name 'master' was replaced with 'main' on GitHub > [2][3] and in the wider Git community [4]. For those that have missed the > broader discussion in society, the term 'master' is offensive to some > people [1]. This is widely considered insensitive if not illegal, hence the > proposed change. > > It seems fitting the CloudStack would follow this example of > inclusiveness. For this, the project would rename its default branch name > of all the repositories to 'main'. In addition, all the applicable > integration points (Eg: Travis-CI, etc) using these repositories have to > replace the branch name 'master' with 'main'. > > The sample steps to rename and replace the default branch to 'main' are > here: > https://faun.pub/git-step-by-step-renaming-a-master-branch-to-main-16390ca7577b > > I would like to hear your thoughts and suggestions on this. > > > [1] > https://www.theserverside.com/feature/Why-GitHub-renamed-its-master-branch-to-main > [2] > https://www.techrepublic.com/article/github-to-replace-master-with-main-starting-in-october-what-developers-need-to-know > [3] https://github.com/github/renaming > [4] https://about.gitlab.com/blog/2021/03/10/new-git-default-branch-name/ > > > Regards, > Suresh > > > suresh.anapa...@shapeblue.com > www.shapeblue.com > 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK > @shapeblue > > > > suresh.anapa...@shapeblue.com www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
RE: [DISCUSS] Marvin tests interaction
I've got 6 cents to offer here; 2c - It could be good to add @peter's style of tests and indeed those specific tests into the testing regime. 2c - Every new test is being added to the 'smoke test' pile. Really, the smoke tests 'scope' should be clearly (re)defined, and anything that doesn't fit moved out to a 'more in-depth tests' set. I'd have a third category for 'external integration tests', ie Veeam, SolidFire, Juniper SRX, DPDK - anything that is going to need some kind of additional setup/hardware. 2c - The existing 'component tests' set needs a whole load of love. Kind regards Paul Angus -Original Message- From: peter.murysh...@zv.fraunhofer.de Sent: Wednesday, March 31, 2021 12:39 PM To: dev@cloudstack.apache.org; nicolas.vazq...@shapeblue.com Subject: AW: [DISCUSS] Marvin tests interaction Hi there Nicolas, why is actually interaction important in this context? I read that you want to enable developers to quickly run and check the results. For my own scenario I had a requirement to have a set of functional tests only seeing ACS as a blackbox to have a "sanity check" of the service, where Marvin is then an overkill as it runs integration tests looking deeply into the database etc. So it was indeed important to have results fast. My appoach has been to write a set of Python tests using the exoscale/cs library for most common API usage scenarios, and then I run them in our GitLab instance using the dynamic parallel CI/CD jobs feature, one separate job for each test, that is the test runtime complexity is O(1) and not O(n). The "UI" I can then interact with is GitLab CI/CD pipeline dashboard which allows to quickly identify failed tests. Here is the link to the codebase. https://gitlab.cc-asp.fraunhofer.de/fcs-public/apache-cs-extensions kind regards Peter Von: Nicolas Vazquez Gesendet: Montag, 29. März 2021 04:50:44 An: dev@cloudstack.apache.org Betreff: [DISCUSS] Marvin tests interaction Hi, I would like to propose an idea to improve the interaction with the marvin tests through the management server. This could be useful for development and test environments in which tests could be easily started, configured and their results monitored through the UI. This could be achieved by creating a new service in charge of the execution of the tests and sending results back to the management server, so it can display them. A more detailed description: https://github.com/apache/cloudstack/issues/4799 I would like to hear your thoughts and ideas about it. Would you find this useful? Regards, Nicolas Vazquez nicolas.vazq...@shapeblue.com www.shapeblue.com 3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK @shapeblue
RE: [GitHub] [cloudstack-documentation] GabrielBrascher commented on pull request #204: Remove IRC reference as it is no longer used
-1 on *steering* users, especially new ones to Slack. -- it requires signup/permission to a third party application. -- its searchablilty is clunky at best. -- messages are only going to reach people who are signed up/logged in -- even when someone has signed up etc. they'll be cut out of and unaware of, any conversations outside of their working hours/timezone. If a group of people agree to have a syncronous converstion on Slack between them, that’s up to them. And there's maybe an argument for making sure that they're aware that there is the option to use Slack for this. And lastly - if it didn't happen on a mailling list; it didn't happen. Kind regards Paul Angus -Original Message- From: GitBox Sent: Thursday, April 1, 2021 7:50 PM To: dev@cloudstack.apache.org Subject: [GitHub] [cloudstack-documentation] GabrielBrascher commented on pull request #204: Remove IRC reference as it is no longer used GabrielBrascher commented on pull request #204: URL: https://github.com/apache/cloudstack-documentation/pull/204#issuecomment-812102731 @DaanHoogland I was wondering this as well. But decided to not include Slack for now due to the ML discussion [[1]](https://lists.apache.org/thread.html/296def97c549e0b75bc14d0382ae412245cef6088e576acbcb007cc8%40%3Cdev.cloudstack.apache.org%3E). Removing IRC was a consensus; however, not everyone agreed on having Slack as an "official" communication platformCloudStack. We might need to re-open the discussion aimed at Slack then. Any thoughts @DaanHoogland @PaulAngus @svenvogel @andrijapanicsb @rhtyd @nvazquez @NuxRo (and others)? [1] https://lists.apache.org/thread.html/296def97c549e0b75bc14d0382ae412245cef6088e576acbcb007cc8%40%3Cdev.cloudstack.apache.org%3E -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
