[Releasing] HEADS-UP: Branching from 'dev' to '5.9' started

[Tuukka, Turunen]

> -----Original Message-----
> From: Releasing [mailto:releasing-bounces+tuukka.turunen=qt.io at qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: maanantaina 30. tammikuuta 2017 20.44
> To: releasing at qt-project.org
> Subject: Re: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started
> 
> On segunda-feira, 30 de janeiro de 2017 18:27:36 PST Jason H wrote:
> > > On segunda-feira, 30 de janeiro de 2017 16:15:26 PST Jason H wrote:
> > > > That's great, but I'm a commercial license owner. Both of these
> > > > are relatively minor changes that mean a lot to me.
> > > >
> > > > Paring my list down to just API changes, I have these two:
> > > > https://bugreports.qt.io/browse/QTBUG-51133 <- this is the main
> > > > one I'm talking about (Feb 2016)
> > > > https://bugreports.qt.io/browse/QTBUG-52013
> > > > (Mar
> > > > 2016)
> > >
> > > If you're submitting the changes yourself and you're not getting the
> > > reviews in time, then the Qt Project needs to acommodate you. As I
> > > said, the lead time is not 12 months.
> >
> > The way the project has been recently run, it is not practicable to
> > get anything done in under 12 months.
> 
> Features going in to 5.9 prove you wrong.
> 

We have almost always dev branch open for new development. Since 5.8 branched from dev on 22nd August 2016 new features merged there will be part of Qt 5.9. Soon dev will be the place to put features targeting Qt 5.10.

If you need longer time to develop a feature, we can arrange a WIP branch that can be merged to dev when the time is right (i.e. it does not have to go in to the next release). We can also make playground repos for maturing something over time to one day be a new module in Qt when seen fit.

> > If my current version is 5.6, and I want an API change, it can't go in
> > 5.7 because it's already in a feature freeze, so there's 6 months. If
> > I can get it scheduled for 5.8, then that's not going to land for a
> > year from 5.6. 5.7 was exactly 6 months from FF to release, 5.8 was
> > just over 6 months. Since no one picked this for 5.8, I'm left still
> > begging for it for 5.9 just before the feature freeze.
> 
> "If my current version" doesn't make sense. The current version is not
> specific to you. It is the same for everyone.
> 
> The current branch in development (for two more days) is the 5.9 version.
> It's the same for everyone. If you had started your feature two weeks ago
> and got it reviewed last week, it would make it into 5.9.
> 
> If you start it next week, your feature will be submitted to 5.10. You don't
> need to wait 6 months to submit it: it can be included at the moment that it is
> ready. So if you start next week and finish it by the end of February, it will be
> included in February. It will get released when 5.10 is, which should be at the
> latest in November, which would be the 9 months worst-case-scenario I
> talked about.
> 
> Yes, schedules slip. That's unfortunate. But adding more features closer to
> the release isn't going to make that any better. It's far more likely to
> destabilise further and cause more delays. The problem to be solved is not
> the feature admission process, it's the stabilisation and release process.
> 

With Qt 5.9 we are aiming to keep the schedule better than with many of our previous releases. Looking into reasons for the delays, one of the biggest reason is not respecting the feature freeze. By agreeing upon exception to squeeze some feature in we often hurt all others. Similarly pushing in something that really is not yet ready can cause delays in the maturization phase. Everyone wants new features. We just should also start trusting that there will be a new release in 6 months time, if work is not ready in time for the next release.

> > The support contract is very good for bugs,  but for anything else,
> > it's just throwing it over a wall and hoping a developer picks it up,
> > leading me to be vocal on the mailing lists.
> 
> And that's ok. I appreciate hearing you, because I get to hear what's
> important to you and to others. As I said, I'm not privy to the discussion
> between you and your support contact. They can't release your name to me
> either, so I don't know behind a report whether how many would want the
> feature.
> 

Both of the mentioned issues are known by support and in the priority queue. One of them is in progress and the other not yet. Being in the priority queue does not automatically mean the bug (or feature request) gets implemented immediately, but we do take into account factors such as how many licenses the customer has, how many other customers have reported it, what the regular bug priority is, can it be worked around or does it completely block the customer, how big an effort it is, etc. 

Yours,

	Tuukka

> And sorry, but I haven't implemented almost anything submitted as feature
> wishes in the bugtracker either. I have my hands full with reviews, bugfixes
> and the features I want done. So as it stands, if you want a feature, you have
> to get it done yourself (or paying for it).
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing