On 7/10/13 8:59 AM, "David Nalley" <da...@gnsa.us> wrote: >On Wed, Jul 10, 2013 at 9:40 AM, Chip Childers ><chip.child...@sungard.com> wrote: >> On Wed, Jul 10, 2013 at 06:45:39AM +0000, Animesh Chaturvedi wrote: >>> >>> >>> > -----Original Message----- >>> > From: Mathias Mullins [mailto:mathias.mull...@citrix.com] >>> > Sent: Tuesday, July 09, 2013 5:40 PM >>> > To: dev@cloudstack.apache.org; Edison Su >>> > Subject: Re: Swift in 4.2 is broken, anybody wants it to be >>>supported in >>> > 4.2? >>> > >>> > I've been watching from the outside and tracking the entire >>>discussion, >>> > and with what has happened with the delays with 4.0 and 4.1 am >>>worried >>> > that this could be come the next delayer to the release of 4.2. At >>>the >>> > same time, I'm very much in agreement with David N., Chip and John B. >>> > that we can't just drop a feature because it hasn't been attiquately >>> > tested in that past releases. >>> > >>> > My observations - >>> > 1. There is not a quick fix here. >>> > 2. We don't know who can do it. >>> > 3. We're not sure how to do it properly >>> > 4. Currently we can't even agree on whether we go with the original >>> > version or the newer one. >>> > 5. We can't validate user base immediate need and requirement for the >>> > feature. >>> > 6. We're stuck in Analysis paralysis! >>> > >>> > Conclusion - If we don't get past these in short order we are going >>>to >>> > jeopardize 4.2 timely release. >>> > >>> > Suggestion: >>> > Based off my work with other (corporate) software releases, if we >>>can't >>> > validate the immediate need, we don't know the immediate fix, and we >>> > don't have the right people to do it should we slate this for 4.2.1 >>>and >>> > lower this to a Major for 4.2? We don't delay a major release, and at >>> > the same time we dedicate ourselves to not stranding a user. We need >>>to >>> > do this, but at this point we need to do it right for that user base >>> > too. >>> > >>> > We work to fix the previous version and we work to support new >>>versions. >>> > We get the right resources in to assist, and we make it an immediate >>> > priority to address. If we can fix and test properly before the cut >>>of >>> > 4.2, WONDERFUL! If not, then it doesn't block the release, but it >>>goes >>> > out with 4.2.1 asap. >>> > >>> > So there's my ramblings. How far off base am I? :-) >>> > >>> > Ready, setŠ fire! >>> > Matt >>> > >>> [Animesh>] Mathias thanks for a detailed and clear description. I >>>agree if we can fix it fine but if not it should not block 4.2. Given >>>that we are 3 weeks away from code freeze any uncertainties either >>>needs to be addressed or we need to defer them. >> >> Based on CLOUDSTACK-3350, we have a known user. IMO, this should be a >> blocker. We should either fix Swift to support users or revert the >>object >> store branch merge changes. > >Agreed, though honestly I would agree with those decisions regardless >of whether there was a user or not. >Breaking features in an unplanned manner is a blocker. >If it can't be fixed, the change that broke it should be reverted IMO. >--David
And what if we have nothing to revert too that we can make compatible and function, and a expert to make it functional, What do we do then? This seems to be the state we are in. Matt
