[Releasing] HEADS-UP: Branching from 'dev' to '5.9' started
thiago.macieira at intel.com
Mon Jan 30 19:43:38 CET 2017
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
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
More information about the Releasing