Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 171C810BD9 for ; Thu, 27 Nov 2014 08:02:10 +0000 (UTC) Received: (qmail 68740 invoked by uid 500); 27 Nov 2014 08:02:09 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 68692 invoked by uid 500); 27 Nov 2014 08:02:09 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 68679 invoked by uid 99); 27 Nov 2014 08:02:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Nov 2014 08:02:09 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of andrija.panic@gmail.com designates 209.85.213.182 as permitted sender) Received: from [209.85.213.182] (HELO mail-ig0-f182.google.com) (209.85.213.182) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Nov 2014 08:01:43 +0000 Received: by mail-ig0-f182.google.com with SMTP id hn15so3930482igb.9 for ; Thu, 27 Nov 2014 00:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rS5wEKGuXiOvqxRb/5de5AxYmoxi7AXwXJ8hobnFjKE=; b=Egui71PvQXo3QD+8oaDg4WAaI0wimeuyJFTRsxBhk9RGmJGlortoS59oCuygvq2aFX vzCqbIavPbJbMHHdK3goUIVDXC8z+NuqKwE1EKI16rf8McRxkFdxYnZuxYygCq/K5GIe npghlQdP1MQbvdNgwQ6QL3BgXdsPUv1LOvUl5qDwalODOliDqOwnktzND8UmLCAPJyal IBC2r4ptk6uLmW26S2vvOzT2UUIjyCkHpqBCyNOGtCXtNpudfPMkjFqod4dfFV4XqVsk H5z373tDkzR96IEXVxEmeh0jMwmb40Qj34iEX961XxRXUu/Edk6q8PAX+NI2YUpghbGf 8TAw== MIME-Version: 1.0 X-Received: by 10.107.25.129 with SMTP id 123mr31265624ioz.90.1417075301850; Thu, 27 Nov 2014 00:01:41 -0800 (PST) Received: by 10.42.25.74 with HTTP; Thu, 27 Nov 2014 00:01:41 -0800 (PST) In-Reply-To: References: <1633077854.21374.1416920945439.JavaMail.zimbra@li.nux.ro> <0A510AFE-A633-4B8A-AC05-C58E951442DF@shapeblue.com> <4831C6E4-5164-4E07-AD05-769F012EEC0B@GMAIL.com> Date: Thu, 27 Nov 2014 09:01:41 +0100 Message-ID: Subject: Re: [DISCUSS] LTS Releases From: Andrija Panic To: "dev@cloudstack.apache.org" Content-Type: multipart/alternative; boundary=001a113fe4cafca8040508d28d3a X-Virus-Checked: Checked by ClamAV on apache.org --001a113fe4cafca8040508d28d3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable my 2 cents again: Whether we have this LTS release or not - is not just about having release - we need a WAY to focus here on FIXING, POLISHING product and more important to stimulate/make developers interested in doing so. If this was company owned product, it would be very easy to set goals, and then speak to devs, fix this, fix that. Since this is ofcourse comunity based product - we need some way of focusing on fixing the stuff, and really stop adding features (maybe not completely quit adding features, but...) One important note, and possible scenario - just by having LTS release, but still having majority of developer working on non-LTS release (ading new features) is a big probability, and then we are back to zero with our progress, so I guess this is also an option/problem that we need to consider. I have a very nice experience with CloudStack so far (in general, except being frustrated by some childish problems) - if this was all polished, and documentation complete - I'm 100% sure there will be no better cloud project on the market any time soon, and I really mean it ! It is my wish (and I hope of others) to see CloudStack migrate from #CloudstackWorks to #CloudStackRocks for the next CCC and I think this is VERY much possible. On 26 November 2014 at 22:40, Pierre-Luc Dion wrote: > I'm not really in favor of LTS support, it's a good idea, but not sure it > can be backed by the community?[open question here ;)]. I don't think it > fit in our current model for few reasons: > > - Upgrade path might become impossible as patches become part of multiple > versions. We could end up with problem at database schema with the curren= t > db upgrade model. > > - Enforcing user to stay on a legacy ACS release disallow usage of future > hypervisor version, Guest OSes and new hardware used by hypervisors. As > hypervisors will become out of date, they won't be able to support new > Guest OSes and new hardware. > > - I think the initiative would dilute the effort on the upgrade path and > making sure the upgrade path is easy and always work. Since 4.3.1 as been > released after 4.4.0, do we know if a 4.3.1 can be upgrade to 4.4.1 or > event 4.5? > > - Contribution to ACS and bugfixing become nightmare as bugfix might end > up in 4 branches (4.3, 4.4, 4.5, master,...) > > Why not as community (let's face it, not very a big one) we all focus on > the next 4.5 version, make sure it's properly tested, make sure upgrade > "just work" and have ACS 4 as the LTS ? ;-) > > I know a production system is not likely to run the latest version of ACS > and upgrade of such a prod tool can occur maybe one or two time a year. > > That's just my opinion on the subject, nothing against anyone or to block > the idea. > > > > On Tue, Nov 25, 2014 at 11:35 AM, Hugo Trippaers > wrote: > > > Top posting here as my remarks are mainly on the original topic. > > > > I=E2=80=99m not in favor of supporting LTS releases as a community. The= reasoning > > here is that there is a huge chance that we will fragment the community > in > > people that just want to work on the latest and greatest and some other > > folks who are trying to keep older releases from being updated with new= er > > fixes. It requires a lot of dedicated commitment to keep an LTS release > > going. Particularly if you yourself are already working with a newer > > release in your environment. So from a personal standpoint i can almost > > guarantee that i will probably not spend the time and effort of back > > porting any fixes i do to older versions of CloudStack. > > > > That doesn=E2=80=99t mean that it can=E2=80=99t happen. If people are w= illing to take > > charge of an LTS branch and are willing to do the work to back port fix= es > > where appropriate i would happily support them and even try to test the > > releases so we can have an official release. > > > > New developers might also be scared by the fact that a fix they make ha= s > > to be supported on multiple branches and might decide not to commit suc= h > a > > fix because of the work involved. With the rate of change in the code a= t > > the moment this is also very hard for seasoned developers, so much > little, > > but important stuff changes all the time that back porting is very > > difficult. It is an open source project and generally people will want = to > > focus on the latest and greatest and just get their features in. I=E2= =80=99m > > already regularly having some trouble back porting between master and > 4.5. > > Consider back porting to master, 4.5 and 4.3 as well and having to test > > each branch. > > > > Basically my point is, everyone who wants to LTS support a certain bran= ch > > is free to do so. Whether or not other contributors or committers will > want > > to do that is their choice. As a community we should not make any > promises > > about LTS support for a certain branch. > > > > Cheers, > > > > Hugo > > > > > > > > > > > > > On 25 nov. 2014, at 16:16, Rohit Yadav > > wrote: > > > > > > Hey Daan, > > > > > >> On 25-Nov-2014, at 7:26 pm, Daan Hoogland > > wrote: > > >> > > >> That is worrying, Rohit. As the rest of your mail is already a vote = of > > >> distrust, this part says we should not release 4.4.2 as it contains > > >> regressions. > > > > > > Looks like you skimmed my email and missed the following from my > > previous email: > > > =E2=80=9CNote: This is not to say that 4.4.x is not stable, we=E2=80= =99re simply saying > > we recommend 4.3.x because we have a confidence of its stability and we > > encourage serious CloudStack users to use it.=E2=80=9D > > > > > > 4.4.x is probably the greatest ACS feature release ever but I would > > still recommend conservative users (who consult me) to stick to 4.3.x f= or > > production since we know it just works with least amount of pain. The > other > > issue is I know a lot of people who are on ACS 4.3.x still (including > > ShapeBlue=E2=80=99s customers) want to have bugfix releases and they ma= y not want > > to migrate to 4.4.x right now since 4.5.x is about 2=E2=80=933 months a= way. > > > > > > ACS when consumed by enterprise companies has a typical lifecycle tha= t > > lasts at least 6 months, that means someone needs to support it, > therefore > > the idea of official LTS releases. > > > > > >> This is a very bad signal to users and the rest of the > > >> community. What you are saying is (you in transitive form), 'we won'= t > > >> port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions a= nd > > >> not to a 4.4 version. You have the right to do so but I don't like i= t. > > > > > > In any form I did not say anything about not helping out or not porti= ng > > things. People who know me, know that I love to help everyone and I=E2= =80=99m > quite > > prompt at reply and resolving things. I=E2=80=99ve taken the task to ma= intain 4.3 > > and you=E2=80=99re very welcome to go thorough JIRA etc. to backport th= ings that > > you want for 4.4 since you=E2=80=99re alone the gatekeeper of this bran= ch. > > > > > > I=E2=80=99m going through these bugs that have a different fix versio= n (not > > 4.3.0 or 4.3.1): https://issues.apache.org/jira/issues/?filter=3D123297= 75 > > > > > > Wido suggested that backporting is time consuming so as a challenge > I=E2=80=99ve > > went through 50 issues today, I was able to understand/backport about 2= 5 > of > > them that qualified for 4.3 branch (many of them were trivial, > > > https://git-wip-us.apache.org/repos/asf?p=3Dcloudstack.git;a=3Dcommit;h= =3Df72eb945540e607ff25917922b4084187246f31a > ), > > about 10 of them were hard to backport so I=E2=80=99ve asked authors to= help > out. I > > think with this speed I alone should be able to go through like 300 > issues > > reported on JIRA in about 10-15 days time and after than about 10-20 da= ys > > of testing and getting the bugfix release out. Though if we all help ou= t > we > > can get more mileage. > > > > > > It sucks for me personally that I=E2=80=99ve been emailing you privat= ely about > > cherry-pick and asking you to pick them on 4.4 (also leaving messages o= n > > JIRA). I=E2=80=99ll continue to do that :) and meanwhile, you are very = welcome to > > go see the things I picked on 4.3 and pick those applicable on 4.4. > > > > > > Yours friendly and as always, > > > > > > Rohit Yadav > > > Software Architect, ShapeBlue > > > M. +91 88 262 30892 | rohit.yadav@shapeblue.com > > > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > > > Find out more about ShapeBlue and our range of CloudStack related > > services > > > > > > IaaS Cloud Design & Build< > > http://shapeblue.com/iaas-cloud-design-and-build//> > > > CSForge =E2=80=93 rapid IaaS deployment framework< > http://shapeblue.com/csforge/> > > > CloudStack Consulting > > > CloudStack Software Engineering< > > http://shapeblue.com/cloudstack-software-engineering/> > > > CloudStack Infrastructure Support< > > http://shapeblue.com/cloudstack-infrastructure-support/> > > > CloudStack Bootcamp Training Courses< > > http://shapeblue.com/cloudstack-training/> > > > > > > This email and any attachments to it may be confidential and are > > intended solely for the use of the individual to whom it is addressed. > Any > > views or opinions expressed are solely those of the author and do not > > necessarily represent those of Shape Blue Ltd or related companies. If > you > > are not the intended recipient of this email, you must neither take any > > action based upon its contents, nor copy or show it to anyone. Please > > contact the sender if you believe you have received this email in error= . > > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue > > Services India LLP is a company incorporated in India and is operated > under > > license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a > > company incorporated in Brasil and is operated under license from Shape > > Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic = of > > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue > is > > a registered trademark. > > > > > --=20 Andrija Pani=C4=87 --001a113fe4cafca8040508d28d3a--