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

[Thiago Macieira]

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.

> 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.

> 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.

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