Comments on i'm special.: Qt: Bootstrapping openness

@Thomas: please see the added note on the bottom o...

2010-07-23T20:21:24.702+01:00

@Thomas: please see the added note on the bottom of the post, this isn't (just) about Qt3Support, in fact, the original issue was brought up due to a patch to QWorkspace which I (incorrectly) attributed to Qt3Support due to being busy at the time.

note that just moving to a seperate module it isn't possible. Qt3Support requires (ifdef'd) support throughout the core of Qt itself.

also note that there is nothing wrong with keeping code where it is, provided that patches to it aren't rejected without good reason, which is what the open governance discussions will (I hope) help lead to.

thanks for your comments!

Qt3 support is a module that allows people to keep...

2010-07-23T19:14:41.853+01:00

Qt3 support is a module that allows people to keep using code that was end-of-lifed 6 years ago. In internet time thats an eon ago. If people still depend on that, I'm not entirely sure that the pain they have is not worth it.
What people seem to assume is that you should *port* that code, while we have new technologies that allow writing it from scratch 10% of the work it was a decade ago.
The qt3support code should be removed from Qt and maintained by volunteers as a separate project IMOHO.

Actually the patch that I was submitting and which...

2010-07-23T17:27:24.624+01:00

Actually the patch that I was submitting and which got rejected, was a patch for QWorkspace.
That's not even as old as Qt3Support, i.e. it got deprecated more recently.

I was really furious because it was rejected for fear of it increasing support work. But
if I do all the work (actually fixing the bug, not just reporting that a bug exists), then
they should be happy about that, and integrate that work, rather than just hiding behind
"it's dead jim, we'd rather not touch it anymore". The code is shipped, therefore it is assumed
to work. If not, then every migration to Qt 4 becomes more expensive because we must also
port away from QWorkspace, and at some point it just becomes too expensive for the customer,
who will end up giving up on Qt.

I agree with you that accepting patches to deprecated areas *MIGHT* end up with people stepping
up as voluntary maintainers of some areas, but I certainly wish that this doesn't become a requirement
(which seems to be a floating idea in qt-labs at the moment). In KDE we accept contributions to
unmaintained areas even if the contributor doesn't promise to become maintainer. Of course we'll
contact him in case his change broke stuff, but that doesn't mean we'll ask him to fix every
bug that was there before he came in, that's just nonsense. Some people do step up and actually
do that, but we can't require that of every contributor.

For instance I could actually maintain Q3ButtonGroup after all the projects where we had to fix it
so that it finally behaves almost like the Qt3 QButtonGroup, but just because I fixed one bug in QWorkspace
doesn't mean that I want to maintain QWorkspace in the future...

Anyway. We agree, rejecting patches to deprecated code (for that reason) is nonsense.

I should have been more clear on this point, but t...

2010-07-22T10:21:55.344+01:00

I should have been more clear on this point, but this is an underlying, more general problem - not just related to Qt3Support. QtSql is another area of Qt with similar problems. Patches to it have (in some cases) gone unreviewed for almost a year now, simply because it is unmaintained - and there is no "newer API" to switch to.

Regardless of that, switching API - especially in a commercial product - is a serious undertaking. Trying to convince your boss that you're going to be working hard for the next month or two to "port" an application, which will end up more or less where it started, isn't going to go down all that well, as well as being boring - and as a result, we have code today still using Qt3Support.

It doesn't burden Qt overly much at present to keep this code, but I would personally quite like to see a firm lifespan put on it being removed unless someone steps up to maintain it (and are given the appropriate help and tooling to do so).

Leaving it in its present (unfixed) state isn't really all that great.

the fact is, if you that code this bad you can for...

2010-07-22T08:36:12.494+01:00

the fact is, if you that code this bad you can fork qt.
Conducing users to switch to newer API is something perfectly reasonable. The problem with old code is not only maintenance, but it can prevent you to improve or change some behavior in the rest of the code (because you have to keep compatibility with legashit code).