I completely agree but when does features an enhancements come before QA an overall stability of a product? I guess it all depends on customers base.
Sean On May 21, 2013, at 7:28 PM, Chiradeep Vittal <chiradeep.vit...@citrix.com> wrote: > There's ALWAYS known issues in every release. The release manager, > developers, support (in this case developers), product managers (in this > case community at large) and customers (users) at some point put the value > of getting new code and new features ahead of fixing ALL known issues. > > I suggest that that point is NOW. But that is just my opinion. > > On 5/21/13 5:12 PM, "Sean Truman" <stru...@gmail.com> wrote: > >> All, >> >> I would prefer a better release an wait for it then to have to deal with >> multiple updates because of issues, just my $.02.. >> >> Sean >> >> On May 21, 2013, at 7:00 PM, Chiradeep Vittal >> <chiradeep.vit...@citrix.com> wrote: >> >>> But the longer we hold the window open for folks to raise defects, the >>> longer it will take to release. Why can't we enforce our own timelines >>> and >>> say "this is it". Any release will have blockers for a subset of users. >>> It >>> seems to me that we are inefficient in estimating the harm from a >>> 'blocker' defect -- I.e., the defect is assumed to affect 100% of the >>> users and therefore blocks the release. There's always 4.1.1 >>> >>> >>> On 5/21/13 2:20 PM, "David Nalley" <da...@gnsa.us> wrote: >>> >>>> On Tue, May 21, 2013 at 4:18 PM, Chip Childers >>>> <chip.child...@sungard.com> wrote: >>>>> On Tue, May 21, 2013 at 12:34:45AM +0000, Chiradeep Vittal wrote: >>>>>> I don't see limited interest. It seems that bugs are trickling in >>>>>> every >>>>>> day and they are being taken up as they come in. Is there any blocker >>>>>> without any action for more than a few days? The only one I can see >>>>>> CLOUDSTACK-2463. >>>>> >>>>> Chiradeep, >>>>> >>>>> My response to Animesh was flippant and not overly helpful. You are >>>>> correct that things are being addressed. My point was more that the >>>>> community in general seems to have moved on from 4.1, yet we have not >>>>> released it yet. Bugs that have come up are taking several requests >>>>> for >>>>> attention, and once there is a reply it's frequently taking several >>>>> requests >>>>> to get follow ups. This is a volunteer project, so that alone isn't >>>>> the >>>>> issue. I raise the question about what to do about 4.1 in the >>>>> interest >>>>> of asking the rest of the community if you have, indeed, moved on and >>>>> want to focus on 4.2 instead. >>>>> >>>>> Others, >>>>> >>>>> I'm frankly surprised at how few people have responded to this thread, >>>>> given the volume of commit / merge / jira activity going on for new >>>>> features. >>>>> Obviously there is lots of effort going into new feature dev, so it's >>>>> not at >>>>> all like we have stopped paying attention to the project as a >>>>> community >>>>> (far from it). >>>>> >>>>> As for the current state of consensus around my questions: >>>>> >>>>> * Animesh indicated a desire to keep moving on both fronts. >>>>> * Prasanna indicated his concern that changes in master are being >>>>> missed >>>>> by people looking at 4.1. >>>>> * John indicated his concern about the priority conflict WRT >>>>> stabilizing >>>>> 4.2 and 4.1 concurrently. >>>>> * Chiradeep - I know you replied to this thread (obviously), but I'm >>>>> not >>>>> sure if I saw an answer to the questions I raised (although you make >>>>> a >>>>> fair point, which I address above). >>>>> >>>>> I'm looking for more feedback one way or the other here. >>>>> >>>>> -chip >>>> >>>> >>>> So here's my thoughts - and I apologize if this seems like a rant. >>>> >>>> The goal of the project is to release code. It's the cornerstone of >>>> much of what we do. We've done a very good job in my opinion of making >>>> CloudStack consumable by people who are comfortable hacking on the >>>> source code. We have a number of people running versions of CloudStack >>>> that have never been released yet, and doing so pretty confidently. >>>> Most of our target audience is either not comfortable doing that, or >>>> not comfortable running something in production that hasn't been >>>> blessed as a release, and doesn't have a known upgrade path. >>>> >>>> While it's not just the goal and purpose of the project to release >>>> code - it's also vital to the health and growth of our user community. >>>> Regular, timely releases are important. The 50,000 foot view of things >>>> is that there is apathy about the 4.1 release. Lots of activity is >>>> happening around feature development, but not a lot of care (even in >>>> form of opinions in these threads) given to some of the 4.1 blocker >>>> issues. >>>> >>>> Performing a release is how we show the world how awesome we are, and >>>> how awesome our software is. Writing the software, developing cool new >>>> features and never pushing it out the door is a waste - virtually no >>>> one but us will see it. The equivalent of getting dressed up for a >>>> night on the town, but never leaving the house. In short it isn't done >>>> until there is a release, and seeing large features being developed >>>> and landing while bugs that block a release take a lot of coaxing to >>>> get fixed gives a bad impression. >>>> >>>> --David >
