Of course releases are important. But if our current cadence is putting too much pressure on the community, one option might be to do our releases further apart from each other. Or, we get strict about the principal of time based releases: i.e. if your feature is not ready for the freeze, then it doesn't make it in. No big deal. If it's ready for the next freeze, then we'll ship it then.
Also, I may be reading your message wrong, but there's no need for this to be a divisive argument. There are no "sides" to this. As a community, it is up to us all to identify our problems, and figure out solutions. So what problems do you think we'll run in to if we stop assigning the majority of bugs, and how do you think we can mitigate those problems? Or do you have another idea in mind altogether? On 11 April 2013 12:40, Abhinandan Prateek <abhinandan.prat...@citrix.com>wrote: > I think it will be good if we also find out a process so that the release > cycle is not affected by unclaimed bugs sitting out there. Here I am > assuming the releases are important. > > I guess the discussion has turned into keeping things free without > offering solutions to problems that that system will create. > > > On 11/04/13 5:04 PM, "John Burwell" <jburw...@basho.com> wrote: > > >+1 > > > >On Apr 11, 2013, at 7:22 AM, Noah Slater <nsla...@apache.org> wrote: > > > >> On 11 April 2013 11:22, Abhinandan Prateek > >><abhinandan.prat...@citrix.com>wrote: > >> > >>> > >>> 7-8 days is a huge time lost. I was suggesting that this to be 3 days. > >>>Let > >>> other community members chime in too. > >> > >> > >> I should have replied to this in my previous missive. But I want to > >> reenforce how unhealthy I believe this practice is. 7-8 days, or even 3 > >> days "being a huge time loss" makes absolutely no sense to me at all. > >> Assigning a bug should not mean it gets fixed any faster. If it does, > >>then > >> we need to change the way we are working. (And if this means changing > >>the > >> JIRA ticket workflow, then so be it. If something isn't working for us, > >>we > >> change it.) > >> > >> In fact, I would go so far as to say that we should think of assigning > >>bugs > >> as an exclusionary practice. Every time you assign a bug, you're > >>shutting > >> out the community. That's how we should think about it. Assign the bug, > >> shut out the community. And so, I would say we should try to avoid doing > >> it, unless it is absolutely necessary. (Such as when you're > >>co-ordinating > >> some release critical work, or when you, yourself, are about to start > >>work > >> on something. Of course, it's perfectly fine to shut out the community, > >>if > >> you're doing that at the same time as starting work on something!) > >> > >> > >> -- > >> NS > > > > -- NS
