slowing down the development schedule for a release.

drago01 drago01 at gmail.com
Wed Aug 21 11:27:59 UTC 2013


On Wed, Aug 21, 2013 at 12:36 PM, Jaroslav Reznik <jreznik at redhat.com> wrote:
> ----- Original Message -----
>> On Wed, Aug 21, 2013 at 10:13 AM, Kushal Das <kushaldas at gmail.com> wrote:
>> > On Wed, Aug 21, 2013 at 1:36 PM, Chris Murphy <lists at colorremedies.com>
>> > wrote:
>> >
>> >>
>> >> What are the options? Push 21 back 3 months, and then 8 month instead of 6
>> >> month intervals?
>> >
>> > May be pushing 21 for whole 6 months, which will give enough time to
>> > concentrate to the existing issues. Another option can be with keeping
>> > same 6months time frame but saying instead of adding 20 new features,
>> > we will fix
>> > existing issues to have a solid release.
>>
>> What exactly do you want to fix? And how do features block you from fixing
>> it?
>> This is all to hand wavy.
>> And you cannot force volunteers to just work on bugfixes for 6 months
>> instead of working on new stuff if that's what you mean. (that would
>> be pretty pointless anyway).
>>
>> The only conclusion I get out of this thread is that releng is
>> apparently unable to cope with there tasks while making progress on
>> improving stuff (whatever this improvements are).
>> So we need more resources (people) working on releng stuff not force
>> everyone to just fix bugs for 6 months.
>
> It's not only about releng but QA and other teams - time between F19
> and F20 was pretty short.

And still no word on *what* you exactly want to do and why it needs to
skip a release.

> And yes, we're still trying to get into the
> pace again after F18 that cost us a lot... But if we really want to
> do bigger changes how we produce things, we really need time for it.

We should do that once ready and not stop the release train for it. We
did that once (F18) and we all know how this ended up.

> For bugfixing - as I said, there's a chance of bigger bundled update
> accompanied with QA effort

We already can and do fix bugs in releases.

> that could serve as a replacement for
> regular release (so it could contain a limited set of new stuff too).

This is rather pointless ... if we are going to such changes we could
as well do a proper release.


More information about the devel mailing list