[Development] Feature freeze date?

Thu Dec 15 07:40:35 CET 2011

Hi everybody,

sorry for not answering earlier. I actually wanted to bring the topic up
myself, but just didn't get it out so far. I've simply been traveling a
bit too much (I'm currently in Tokyo for the local Qt Developer event,
after we had a great one in Beijing two days ago with round 1100
participants).

So let me try to summarize my thoughts on the the feature freeze date,
what it means and how to move from there.

The feature requirements wiki page is a great initiative. But as Thiago
said: let's really limit it to the things that can't be done in 5.1. If a
it's something that can be done in a binary compatible way, it should not
be on the list.

Once we have the list, let's go through it and do some estimations of what
it requires. But let's avoid falling into the trap of requiring a perfect
world/solution. No matter how much time we give ourselves, we won't be
able to do everything we maybe would like to do, and we'll have to cut of
at some point.

Thiago's definition of the feature freeze mostly matches mine.

But I'd like to be slightly stricter on API changes requiring at least
some communication and discussion before we change things. One of the
things we need to organize for January is a review of all the new APIs
that got added for 5.0, so that we can at least reduce the amount of
changes we'll get after the feature freeze.

It doesn't make sense to freeze BC before the final 5.0.0 release, so
let's not do that. As long as your change is source compatible, we can do
binary incompatible changes almost until the end.

I believe we need to stick with the feature freeze timeline by end of
January. I know that this hasn't been a huge amount of time for externals
to get their changes in, but we have finished most of the fundamental
changes that were needed for 5.0. Jan 31st is a Tuesday, so my proposal
would be Feb 3rd.

I also still believe strongly that we need to aim for a Qt 5.0 release by
next Summer. It is important that we get 5.0 out as fast as we can to
establish a new baseline for Qt development. If we want to be able to keep
that date we need to start freezing things soon.

In case you feel there is a change that *has* to go into 5.0, but that you
think you'll not be able to finish until the feature freeze I'd like
people to speak up on this list as soon as possible and we'll then figure
out how to handle them.

Cheers,
Lars

On 12/15/11 2:42 AM, "ext Thiago Macieira" <thiago.macieira at intel.com>
wrote:

>On Wednesday, 14 de December de 2011 18.12.21, Stephen Kelly wrote:
>> Ok, well let's start the list:
>> 
>> https://wiki.qt-project.org/5.0_Feature_Requirements
>> 
>> One thing we could do is:
>> 
>> 1. Let people populate the list
>> 2. Review the list for plausibility in a reasonable timeframe
>> 	and personal availability.
>> 3. Estimate the time for the responsible people to get the work done.
>> 4. Schedule feature freeze based on that.
>> 5. Features that unfortunately don't get finished by then don't make
>> 	it into 5.0, and possibly .x.
>> 
>> That's just an idea of how to make progress though. Making a scheduling
>> decision without any idea of what needs to be done in that timeframe
>>doesn't
>> really make sense.
>
>That's why I started the thread. We need to know what we need to do so we
>can 
>make a scheduling decision. Or, alternatively, we need to decide what we
>can 
>do given the schedule.
>
>I also oppose to your item #5 above. I don't want to see anything on a
>page 
>called "5.0 requirements" that can be postponed. I want *only* the stuff
>that 
>*must* go into 5.0, i.e., what cannot go into 5.1 or a later release
>until 
>6.0.
>
>If we reach the feature freeze date and a requirement isn't complete yet,
>we'll need to make a call whether to delay the freeze or not. This is
>something we'll do only for 5.0, as for any future releases, anything can
>be 
>postponed.  That also means we don't have "feature requirements", but
>only a 
>wish-list. [That's between us developers; in public communication we may
>call 
>them differently]
>
>For those things that can be postponed, we should have a separate roadmap
>page. We can also start collecting ideas for future releases.
>
>> > > Backward incompatible change freeze?
>> > > (Yes)
>> > 
>> > See above on both SIC and BIC changes.
>> 
>> Right. This would be soft-frozen probably at RC or beta time.
>
>Depending on whether you referred to source or binary incompatible
>changes; 
>and for the source ones, it's understood it applies to new features only.
>
>> > Of the "I can't judge" QtWidgets features above, considering that
>>module
>> > is
>> > in Done state and we have a source-compatible requirement for 5.0 for
>> > existing features, I would wager that they are not Qt 5.0
>>requirements.
>> 
>> Yes, but there are also lessons which we need to ensure are not
>>forgotten so
>> that we have useful API for QML. An example is the QCompletion stuff.
>>Doing
>> that 'properly' and in a future-proof, QML compatible way probably
>>actually
>> depends on itemmodels getting new features, such as a virtual search()
>> method to supercede the match() method. That's just an example. There
>>may
>> be others.
>
>I agree. However, we'll never finish finding new requirements or need to
>improve 
>the API, so we need to make a cut somewhere based on our best
>understanding. I 
>might be an optimist here, but I'd have expected all these studies where
>we 
>need new API to have completed by now. We're 5 months into the 5.0 cycle,
>1 
>year into the QtDeclarative API, 61Ž2 years since ItemViews and the rest of
>the 
>Qt 4 API.
>
>-- 
>Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
>     Intel Sweden AB - Registration Number: 556189-6027
>     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development