Zitat von Roland Winklmeier <[email protected]>:
2017-02-15 12:52 GMT+01:00 Shawn Rutledge <[email protected]>:
> On 15 Feb 2017, at 11:11, Marc Mutz <[email protected]> wrote:
>
> On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote:
>> First of all, apologies for not being able to make the release meeting
>> yesterday. I was in a workshop all day.
>>
>> For the record I think skipping 5.8.1 is a big mistake. I would much
rather
>> delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and
try
>> for a quick 5.9.0.
>
> Amen.
>
> I would like to add that this decision, made behind closed doors, does
not
> match well with Qt-as-an-open-governance-project. In particular, it
feels like
> we OSS contributors are being held hostage here. If you close the 5.8 CI,
> anything we can do, incl. following the dictate of TQC to focus on 5.9,
will
> hurt Qt users one way or another. Either we fragment Qt by releasing a
5.8.1
> without TQC backing or we leave users hanging in the air for extended
periods
> of time without the ability for bugfixes. Both are unacceptable, IMHO.
There are a lot of potential bug fixes. Skipping 5.8.1 might pull some
users into upgrading to 5.9 sooner than they might otherwise, which is good
from one side, but the ones who are afraid of new features and new
regressions will resist. So I think it’s a mistake because of those
people…
Speaking for myself, I also think, skipping 5.8.1 is a mistake. We just
upgraded our project from 5.6 to 5.8 and realized that it had several
regressions. For example we are using a QNetworkAccessManager and for
random reasons it always switches to NotAccessible after some minutes. No
recovery possible except restarting the application. I wonder why nobody
else got affected by this. I _think_ the cause was QTBUG-51543, even though
I never finally understood whats going on. In any case, the fix for this
bug went into 5.8.1, which now won't get released. For me this is very
frustrating, since we counted our next milestone on an early 5.8.1 release.
Now I would have to wait for 5.9.0 which is planned end of May if
everything goes smooth. Even then, there is no guarantee that there is no
new regression which would require 5.9.1 release.
I also can't produce custom builds, since I never managed to create a
custom offline installer for my team members (we are are non profil OSS
group without many infrastructure and resources). I do regular builds of Qt
itself, but the rest is out of my capabilities.
In summary, for me it is very unfortunate that I have to delay our
milestone minimum until June if everything goes well.
+1
I think, for many quality focused software projects, skipping patch
releases in Qt is a pain.
I would even go further: I recommend to establish guidelines how many
patch releases should be published (I think at minimum 1, better 2). I
would give them absolute priority over new minor (or even major)
releases. If there are shortages in CI , CPU or Disk power, whis
should primary affeect new releases, not patch releases.
This would
a) support Qt not bo become one of the thousand feature rich but
unstable and buggy software frameworks/projects
b) taking pressure on fixing this basic shortages
If I had to decide between new features and bugfixed/mature code - I
would go for mature code.
just my 2 cents,
Torben
_______________________________________________
Releasing mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/releasing
