On Wed, Jul 10, 2013 at 03:50:13PM +0000, Mathias Mullins wrote: > > On 7/10/13 8:59 AM, "David Nalley" <[email protected]> wrote: > > >On Wed, Jul 10, 2013 at 9:40 AM, Chip Childers > ><[email protected]> wrote: > >> On Wed, Jul 10, 2013 at 06:45:39AM +0000, Animesh Chaturvedi wrote: > >>> > >>> > >>> > -----Original Message----- > >>> > From: Mathias Mullins [mailto:[email protected]] > >>> > Sent: Tuesday, July 09, 2013 5:40 PM > >>> > To: [email protected]; 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 > >
Well, given that we have a bug about Swift (3350), we know that there are bugs... but that generally it's working.
