Hi Robert, I think the fundamental problem here is a misunderstanding of how this project is supposed to work. We have lowered the barrier to us developers exactly so that people can contribute what they think is important. Instead of accusing each other, I would really like to see a collaboration going on, based on technical grounds, not on some weird accusations or strict ideas on how the world has to look like.
There is a substantial difference between 'sharing concerns' and constant provocation. I've been working in (non-for-profit) open source development communities long before joining Nokia (or Trolltech, for that matter). Posts like the one Danny keeps writing poison the project and provoke such reactions. While I agree that the reaction was harsh, in the end telling people off is the right thing to do. Now if you feel that Nokia as a company offends you because individual developers express their opinion, we can all go back and put layers of layers of PR and Marketing between us and 'you, the end user'. Would that make you feel warm and cosy? For this concrete project, it could start by giving an overview about the current architecture in terms of project settings: There is a wide array of possible settings for projects such as: - Build directory - Build configuration (Debug/Release,...) - Dependencies - Actual build commands (qmake, make, ...) - Header/Code Templates ... Some of them are project-specific while others are user specific. There is also a small set that could arguably fit into both categories. Machine independent, but project specific settings should be specified in the .pro files, whereas user specific settings should remain in local-only .pro.user files and the session. The reason for storing those settings in the .pro file is that taking the .pro file and the sources should be enough to get the project building on a different OS/machine/build chain/IDE. For example, we don't save the actual qmake command, spec or Qt version in the .pro file, because other platforms most likely _will_ have other requirements or Qt versions. Stuff to share should always be implemented in the profile. This includes dependencies and extra commands (e.g. overriding tools like LEX, UIC, MOC, etc.). So I think we need a better .pro file editor, but adding that stuff in the IDE without modifying the .pro file is mostly useless. It is easy to sacrifice a sane concept for short-sighted convenience, but Creator should be all about getting it right, rather than rushing things. Remember: copying Visual Studio 1:1 is not an option, because it's neither cross-platform nor does it assume different conditions or different environments. It is simply too static for most real world scenarios where Qt is being used IMHO. So what do we make of this? Tthe next step would be to collect scenarios on how different people collaborate and what is currently missing. We could then deduct a useful scheme that is more suitable. We have everything there that's needed to get this going (except for a user-writable wiki, but I am confident we could try to get something working on short notice). We also have the mailing list. Modifying the code in a separate branch and looking as to when to merge it back into main line are the last steps, and only these require coders. It does, however, also require a constructive environment on both sides. And just to make that clear: "We" in this paragraph means "us, the community". So please guys, let's do this together. And remember, there is no such entity as "Nokia, the fortune 500 company putting all their resources behind a single application", but a low two digit number of software engineers that has to prioritize, but gave you, the rest of the world, the possibility to bring in your features. Please make use of it. Cheers, Daniel Disclaimer: this is my private opinion. -- Daniel Molkentin, Software Engineer, Nokia, Qt Development Frameworks _______________________________________________ Qt-creator mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-creator
