Andre has a point that the freeze results in a waste of resources, because the resource we have is not willing to work on the things that are missing.
But a change in policy will not fix this problem. Only people willing to work on the missing things will bring the release forward. Other solutions just paper the problem away, and will ultimately make it worse. The problem is that if the freeze is opened, there will be more things that needs to be fixed. Effectively, the pile of things that nobody has time or willingness to work on increases. The solution is not to open up the development. This will only make the problem worse. Only in the extreme case where we have volunteers that can finish a project to production quality on their own, will this risk not exist. In practice, letting work continue will always bring new un-tied ends. For one thing, the documentation is chronically out-of-date, because developers are unwilling or unable to document the new or changed features. So, opening up will be like pissing in your pants to keep warm. The solution is to get people to work on the release, as far as possible. There is no mechanism for forcing people to work on a given thing, but there is no problem in asking people to do so. That should not de-motivate, because we all agree that these things needs to be done. So this is a case where only hard work will make it fun again. It is de-motivating that the needed things are not done fast enough. But once again, you can bring the fun back by biting the bullet, and doing some of the needed work. Yes, it might seem like a huge task to start with: Learning Qt, and then doing GUI-work, which might not be your favourite programming task. But you have to look at yourself and ask: Is it really that huge and difficult a task, or am I being a little lazy? Could I not help the community out by doing this? It is always fair to say, "No, I don't have the resources to do this". In that case, there is a risk that the project as a whole is loosing resources, because those people could have the resources to work on other things. But these people can do this: It is a simple matter to open a development branch in CVS, and continue such work there. But the base line is simple: Only by finishing the Qt-port will we be moving closer to a release. Yes, we can always decide that the Qt-port is not a requirement for the release, but I think it is too soon to take such a step, and for now, it is just swiping the problem under the carpet. We need work on the Qt-port. So what should we do? It's simple. We should make it attractive to work on this: - Express our gratitude to the people that *do* work on this task - Express our gratitude to people that demonstrate a willingness to try to work on this, and motivate them to keep going - Help where we can with technical questions in this area - Express that this project is a high-prestige area. Working on this project gives you ultra-geek-credit - Consider to ask for external help: We have a case where the most anticipated LyX release with GUI independence is being held up by a lack of skilled Qt developers. It should not be impossible to find some KDE hackers that can implement the missing dialogs. In this case, we should offer those hackers as much support as possible, and prominent credit in the release notes. Only when it has been demonstrated that such steps did not work, should we consider to adjust the release criteria for such a major thing as the Qt-port. Greets, Asger
