All of extensions from "newby" are invalid and needs to be pulled. I'd suggest that further extensions from this user do not be posted for now - evidently, this user did not heed to any advice given in the user's (older) forum thread. See jhfCAPTCHA.310107-1.tar.gz and bdfedit1.3.tar.gz.
This brings me to ask (roberts): are there any checks automatically done on new submitted extensions (such as the declobber script)? If so, perhaps an addition that can check for directory structures (such as being in /opt for targz's), etc. could be used as well. Or maybe something a submitter has to run and verify before sending it in?
I know that myDSL is a community process that can take a lot of time, but these files can be considered harmful to users' systems. And even though they are in testing, these kind of mistakes should always be avoided so that they don't get online. Side note: the only reason why I looked into these extensions was because I remembered the other thread.Extensions are a community process and as such are to be self policed. I am only the conduit to get the extensions posted.
I don't have time and/or equipment necessary to test and/or moderate submitted extensions. I have asked John to assist in this task but to no avail. When Kent was active in DSL, he would thoroughly review each extension. We currently don't have such luxury.
Currently there are so many extensions in testing that need to be categorized or
Open to suggestions for handling submitted extensions. Should there be some automated test procedure?
^thehatsrule^, thanks for bringing to my attention.With those I checked from newby, it was easy enough to just test the archive and see that they weren't self-contained (iirc, they installed across /). I think this particular issue is isolated. If it were more prevalent and others were submitting things that were similarly misconfigured for MyDSL, then I could see doing more before posting to testing. The policing/testing from the community should be adequate if there are other issues that crop up like bugs, bad behavior, etc.
Maybe one way around it is to require additional steps for initial submissions from new contributors to make sure they have the concepts straight before posting to testing. Or have initial submitters post to their own or third-party sites and then get community approval for adding to a contributors list. There has to be some way that won't require Robert to micromanage this.
Quote
(such as the declobber script)? If so, perhaps an addition that can check for directory structures (such as being in /opt for targz's)
It would be easy enough for me to add tests for some more basic mistakes to extend the declobber script, such as location of installed files not matching extension type. Eg also maybe to find and/or fix things like "Status: anchor" lines in xtdesktop icon .lnk files, and maybe non-dsl4+ compatible menus etc. I need to revisit that script anyway and add getopts as Robert suggested. Anyone have other bug hunting suggestions I could try to implement?
I see where you are coming from kicking ideas around like prior community approval for extensions posted externally but I have a few doubts about that one. Last time I looked, all puppy packages were on disparate sites and the community was supposed to provide feedback in their forum, but it just doesn't work very well. They end up with multiple versions of the same software in various places, some hard to find, some in various states of repair, and some plain broken. However they have no central repo at all, which is a key difference with what you're suggesting.I assumed that's what the "testing" category was for. All new extensions go there. I would hope they stay there forever until there is positive feedback concerning their useability (rather than just being integrated after not receiving any negative feedback), or get removed when found to be faulty or replaced with a better version.Next Page...
original here.
