kerframil

Thanks for the tip. The problem is that this leads to further cruft and duplication because the requirement for a unique name means that it's impossible to overwrite the original (redundant) entry in the database. In this case, what I need to do is mark an existing application as obsolete or - better yet - delete it outright because it's no longer provided by upstream. Unfortunately, neither option is within my grasp. As a side note, you can generate a truly random GUID by running the following in a Powershell prompt (use right-click to paste the command from the clipboard into the shell, left drag to select the resulting GUID, then right-click to copy the GUID to the clipboard): [guid]::NewGuid().ToString()

Warning: long post ahead ... As far as I can tell, Ketarin exhibits a characteristic which makes it extremely difficult for anyone other than the author to assist in maintaining the database. Specifically, if I define an application and choose to share it, I will be able to make future changes to the package and these changes will be automatically propagated to the online database. However, if I import an application that was originally defined by someone else then it seems to be impossible to make any changes. Ergo, the situation is that anonymous users cannot import and correct existing packages, even though anonymous users are trusted to share (upload) whatever they please in the first place. In my opinion, this is bad because the only recourse is to either [a] upload a duplicate (albeit working) package, further cluttering the database contact whomsoever has the ability to modify or cull the detective package. In the latter case, it's not even clear who is doing the job. It's one thing to mark packages as "abandoned" but it's rather frustrating not to have the ability to import and subsequently fix anything. All of which leads to the online database accumulating yet more dead wood. If a submitter makes the mistake of deleting the original packages from the database, the same issue arises. For example, I submitted the "Thunderbird ESR (tete009)" package. It was removed from my database at one point. I later added it with the intention of marking it as obsolete because tete009 has stopped producing ESR builds. Of course, I can import the package but any changes I make will no longer propagate. Hence, it is impossible for me to flag the package as obsolete! In my most recent submissions, I have started entering my email address in the Notes field in the vague hope that, should someone discover an issue with one of my packages before I do, they might contact me. There has to be a better way ... IMHO, before going so far as putting in the hard work of creating a web application - essentially constituting a brand new application - the existing framework could be improved. I have some ideas which I'd like to put forward: Move away from the notion of purely anonymous submissions in Ketarin and encourage the notion of maintainership (at the very least, an email address should be mandatory as a unique identifier) (*) Have the backend database support a specific field to indicate that the application is abandoned/broken/obsolete and a method for a user to flag an package as such - directly from within Ketarin. Any user should be allowed to do this but not anonymously. When a package is marked as such, ensure that the maintainer is notified. For instance, an automated cron job that sends an email. Further, the Ketarin client could alert the maintainer somehow. The maintainer should have the opportunity to correct the package within a given period of time e.g. 30 days. If the maintainer is responsive and does correct the package, the Ketarin client should allow him to update the package and remove the flag that indicates it as being abandoned or broken If the flag does not change within the grace period, the backend should automatically delete the package (again, a cron job). The maintainer should retain the right to remove his or her entry (which doesn't stop people from forking/re-submitting the package) Automatic deletions may appear contentious but I don't think it would be a problem. For one thing, even if the maintainer fails to respond in the grace period, he/she would be free to re-submit the application at any later time from the local database Also, if the maintainer really has abandoned a package, any other user should be free to submit a newer/forked version. With the current system, this leads to duplication but this problem would be curtailed by automatic time-based deletion of abandoned packages. Other situations that might arise would be eased by deprecating the currently anonymous nature of the database. For example, let's say that someone has already submitted a package that I have defined. Perhaps I consider my approach to be better (due to safer regexes, improved metadata, silent installation support or whatever). If the email address of the submitter is known then I can contact the author saying "hey, would you mind incorporating these improvements?". For this kind of thing, the idea of having a web interface starts to look attractive, allowing these discussions to occur in the open. Something along the lines of the AUR (Arch User Repository) might be a good fit. Disclaimer: these are merely my ideas and do not constitute an expectation or demand that they should be implemented! I'm merely someone who finds Ketarin extremely useful and would love to see the quality of the online database improve. * shawn's idea of tying to a forums account seems like a good one