>I went to the web site and looked at the packages without . >aintainers. It was 11 pages long, for a total of 503 packages out of >6435 listed in my install. That is 7.8%, which on the face of it >does not seem bad. However, this list is growing fast. The last >time I looked, the list had a dozen or so packages. Plus, how many >maintainers have not bothered to update their packages to not >maintained? It would be interesting to see the number of packages >without maintainers graphed over time.
I am sure you could gather a lot of useful statistics and we could draw a lot of fancy graphs. What you would probably reveal is what everybody knows. Packages are maintained best when the maintainer uses them on a daily basis. I have proted quite a few packages that I do not use myself and I will admit that I sometimes really do not care whether they are current or not. This is also based on the fact that I rarely get feedback. If I knew that my package is widely used I have a commitment to that small users base that my package has. As a diligent person I would be more obliged to actually update those packages then. The dynamics behind maintainership, frequency of updates current status of a package is surely a very difficult haze to go trough. >So for me the issue is currency. If the package is not current for >any reason (lack of maintainer, or latency by the maintainer) then >alternatives are used. While I absolutely understand where you are coming from, I do sometimes feel that people are lazy. Fink is a community effort, Fink is a community driven project. If the maintainer is slow, but you need a package to be more current, the HELP (this is not directled at you personally). Get the package up to speed, submit it to the tracker, write a mail to devel and submit a copy to the maintainer. That should and WILL be picked up. A maintainer does not mean that you cannot, under no circumstances, touch a package. Such help is _very_ welcome. So please use this as a tool to further things. Especially with people like Benjamin who maintain a 'shit load' of packages. >Some suggestions: >1. Some packages could be updated automatically without maintainer >intervention. Especially in unstable. Maybe this should be a >different tree. The point being that once a .info file is approved, >why should it require maintainer interaction for point upgrades. >This becomes even more true with the ability to automatically run the >test suites. Good ideas, but this requires infrastructure. Something we do not have right now. We do have a X86 system that has been sponsored, but this would have to run on a Mac OS X machine. Right now this also would have to run on Intel and PPC machines and it would have to build for 10.3 and 10.4 That is a long list, but I agree with you, it is a possibility. >2. There should be some way to clean out the junk (old versions) and >maintain availability of the old info file should someone want to >update it. One option would be another tree for old and >unmaintained. Once the fink release is out-of-date the package >should be moved. Another option would be better to have an out-of- >date flag. This benefits me as a user, but probably does not benefit >Fink. But then again what is good for the user is probably also good >for Fink in the long run. I do not quite understand what you mean by that? >3. Have an automated way to test package submissions and approve them >with the exception of the MD5. This should only be set by known >maintainers. This reduces the work and improves the response time >for new maintainers. Same issue as above. This requires infrastructure. This ideas actually has been discussed and you should be able to find it on the Wiki. >4. Find other ways to reduce the amount of time required for >maintainers. Agreed and I will be the first one to help and support such efforts. I would also do my best to adopt into an official 'Fink' effort. >Fink is an elegant solution. But if Fink packages are not current or >if they are a limited quantity then Fink will languish. Which is not >my preference. I do not think quantity is an issue. There is still a substantial gap between Fink and most other packaging systems when you include unstable. If could be an asshole and simply state that whether Fink vanishes or not is in the hands of the community, as we are a special purpose project and nothing mainstream like Mozilla, but that would mean I am oversimplifying things. I agree with you, something needs to be done, so please keep the ideas flowing. If you know someone that would be willing to provide, sponsor or donate Infrastructure, hardware, money, time, then please let me (us) know. David Fink PR dude FDN Board member. Neil ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
