Pierre van Rooden <[EMAIL PROTECTED]> wrote: > Then again, you vannot kepe projects open indefinitely. It invites > people to continue changing the code without a thought-out plan. > Also, when a release comes out, I think it is best to close those > projects that define the inyterface (i.e. Taglib, MMCI) so there is no > ambiguity about which release supports what version of the project.
The taglib-project did not reach all its goals as defined in the initial description. You cannot say that the taglib project is 'open indefinitely' because imho it is certainly growing in a certain well defined direction, and I think is one of the more active projects. If the project must be closed before the release then I suggest we stall the release because the project is not finished. It would by the way be no problem to increase the taglib version number after the release. It is silly to say that a project is finished only because MMC decides that it is because there is a release. That is a turned-around reasoning which I would expect from comercial software... I think a project is finished when it's finished, and that can be after a week or after 5 years, it only depends on well er.. if it is ready or not.. > Riocvhtext is closed because nothing happens, and it is best to close it > now an re-open it at a date when time can be devoted to it. That is 'frozen' isn't it, as it is as yet. 'closed' suggest that it is ready, which it clearly is not. I don't understand why a change is needed here. We have 3 or 4 possible statuses for projects, why should they all be 'closed' or 'open'... It seems that the MMC has decided this without consulting the projects, or the rest of the community, which is a bit annoying. Michiel -- Michiel Meeuwissen Mediapark C101 Hilversum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
