[Releasing] Deprecation - we are doing that wrong

[Oswald Buddenhagen]

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.

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.