[Releasing] Deprecation - we are doing that wrong

[Knoll Lars]

On 04/02/16 15:11, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:



>On Thu, Feb 04, 2016 at 02:39:52PM +0100, Knoll Lars wrote:
>> On 04/02/16 14:29, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:
>> >On Thu, Feb 04, 2016 at 01:30:46PM +0100, Knoll Lars wrote:
>> >> On 04/02/16 13:25, "Releasing on behalf of Oswald Buddenhagen" <releasing-bounces at qt-project.org on behalf of oswald.buddenhagen at theqtcompany.com> wrote:
>> >> >so any reasonable calculation of pay-off assumes these modules'
>> >> >presence until qt6.
>> >> 
>> >> The question is about where they are present. They can’t be part of
>> >> what we support in the future, we have already agreed on that.
>> >> Consequently they are not part of what we release.
>> >> 
>> >we established previously that keeping them in minimal form in the
>> >releases is the overall cheapest way.
>> 
>> Depends on your definition of cheap. I don’t think delays to our release are cheap at all. Neither is the added stress to our engineers.
>>
>minimal delays aren't expensive, especially considering how much behind
>we are *already*.
>and with this in mind, there is no reason to stress ourselves at all.
>
>> >> They are and should not be part of our release. They aren’t
>> >> officially supported, and making them compile and offering a source
>> >> tarball is merely a convenient service we can offer.
>> >>
>> >this borders on mocking our "legacy" users.
>> 
>> How’s that? I still want to provide the source tar balls. I just don’t
>> believe a tight coupling between those and our official release is
>> helping anybody.
>>
>as i said before, the fact that we are taking them out at all is already
>a stretch of our compatibility promise. not introducing fully avoidable
>obstacles is the least we can do to keep the users happy.
>
>> >> The cost of them blocking our releases is what bothers me. That one is
>> >> what’s expensive, not making them compile in an independent effort.
>> >> 
>> >i don't see how this sort of tactical thinking makes any sense. what
>> >does it matter even if the release is delayed by a day by that?
>> >and we've alrady spent more time discussing the matter than it would
>> >have taken simon to implement the autotest suppression logic that would
>> >solve the entire issue (for now).
>> 
>> The ‘for now’ is the whole problem.
>> 
>that's not your argument so far at all - you were arguing for the
>immediate cost.
>the followup cost i expect is that we'll need to fix build problems from
>time to time, just like we had to this time. it is *very* unlikely that
>this will happen again within the 5.6.0 timeframe.
>i won't exclude the possiblity that we'll need to do a few other things
>to put these repos into the release, but these things would be just more
>of the same selective disabling of particular build/test steps, so it's
>not exactly rocket science.
>
>> As Jedrzej said, simply disabling the tests in qt5.git (option B) is
>> also a short term fix, as it won’t help you for the case where the
>> module stops compiling (as you then have to also fix all the tests).
>> So it delays the problem and when things go wrong it’ll hit us even
>> harder, as we then have to also fix tests. 
>> 
>that's entirely irrelevant if we skip tests for these modules during
>integration runs altogether, which is option C - the one i endorsed.

Ok, I thought you wanted option B. Option C is something we can probably live with, at least for now. But it does have the problem that we will loose all information about how well that module is working in the longer term.

Cheers,
Lars


>
>we can think of re-enabling them if somebody from the community steps up
>and commits to maintaining them, but that's nothing i'd worry about now.
>_______________________________________________
>Releasing mailing list
>Releasing at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/releasing