> -----Original Message----- > From: Development <development-boun...@qt-project.org> On Behalf Of > Bernhard Lindner > Subject: Re: [Development] Qt XML and Qt Xml Patterns > > > It's good that Bernhard has received an official statement. > > I agree! Thank you!
Indeed, thanks for bringing this up here! We quite obviously should improve the processes here. > > In general, I think the Qt Company could make a little more effort to > > communicate such decisions, educate its user community, and attract > > new potential maintainers. Actually, communication should start before > > a problem results in a decision. Isn't that an important aspect of community > building? No question about that. I can assure you though there was no ill-intend. Let's try to do better in the future. > Agreed as well. > > > Assuming that Qt Xml is deprecated as well (still not sure) this is the fourth > time a deprecated component tears major holes in my applications. Regarding > Qt Xml and Qt Xml Patterns it surprises me a lot since I consider them > essential > components. I will use the stream classes under no circumstances. This means > in my book Qt does not support one of the most important techniques (XML) > anymore. Hard to believe. I'm with you on Qt XML; Uploaded https://codereview.qt-project.org/c/qt/qtbase/+/262779 for improving the documentation. But maybe some approver wants to step up and become the official maintainer of Qt XML? For Qt XML Patterns, the situation is IMO a bit different. The module has some architectural problems, and there are good alternatives out there (check out e.g. https://xml.apache.org/xalan-c/ for XSLT). So I think it's more honest to our users to mark it deprecated, than to assume it's in a good state and should be used for new projects. > Obviously "no maintainer" is enough for a deprecation. No, there's no automatism here. We have other areas without an official maintainer, and they are not deprecated (nor do I expect them to be any time soon): https://wiki.qt.io/Maintainers Having no official maintainer is obviously not a very satisfying situation though. But in the end we should consider each case individually. My 2 cents, Kai _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
