Chris Zubrzycki wrote: []
Maybe this was silently changed during my absence. OK, but then this has not been documented anywhere; in fact our docs still explicitly state what I claim above, and our code still does it this way.
Some maintainers decided to use it this way, and it was encouraged on new maintainers, but never forced.
I am sorry, but I have to support Max here and contradict you (in fact, I said the same thing as Max before): I *was* around all the time (though not on IRC), and I did not see that this was "encouraged on new maintainers", nor seriously discussed on the lists.
*The* most important problem of Fink is maintainer manpower. You know examples yourself, but I'll mention some anyway:
- The terrible gnome mess where fatal bugs get reported repeatedly over several months and nobody does anything about them and where two major version updates don't get out of the experimental tree
- The freetype mess where only 3 people seem to be interested, although it will concern almost everybody
- All those packages where we have outdated versions, as an example gimp which is still at version 2.0.6 although 2.2 has been out for 2 months and they are at 2.2.3 now (and this is with one of the more active maintainers)
- The bindist which is almost 6 months old
I could go on, but what I want to say is that any scheme that tries to put more burden on the maintainers and requires that every single package is revisited, modified, and rebuilt in a clean sandbox, is doomed. This just won't happen. Hell, for gnome not even the existing packages have ever been cleanly tested, not even those in stable. For gimp there are 4 variants with altogether 20 splitoffs, and even the maintainer said that he was not going to test all of them, ever.
The only clean way to introduce this new feature is to keep backward compatibility in the sense that existing info files will continue to be processed according to currently existing policy, and that the new info files will be able to be parsed without crash by the presently existing versions of fink. If these two conditions are met, then there is no reason to get overly excited, and the transition to the new policy can happen gradually.
No one has explained why backward compatibility should be impossible.
-- Martin
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
