>> What is the difference between writing a script and maintaining that >> and writing an simple app and maintaining that? >> > > Tons, in particular the number of libraries it depends on and the security > of exposing it to the net. I understand that. But given that we currently use a lot of TG apps and this one uses only python-geoip, python-sqlite, I am not too convinced about this argument on risks. It is really possible to make it secure when we are using similar other apps. >> >> >> 3. Currently, in freemedia, we open the form for a day or two and >> >> >> close it for the rest of the month. This creates a problem for us. We >> >> >> want to keep the form opened for NA for a longer time, EMEA for lesser >> >> >> time and so on. In this app, there is a python-sqlite wrapper around >> >> >> trac which enables us to differentiate between the regions and >> >> >> close/open the form for a region on demand. >> >> > >> >> > Why not have multiple forms? >> >> >> >> We have to disable/enable each form using puppet. We have to do it each month. >> >> it will not be possible. >> >> >> > >> > Of course it would be. You write a script to generate your pages, change >> > a 1 to a 0. >> >> But I don't have time, not energy to login to puppet every time >> someone tells me to do the changes. So will puppet access be given to >> current freemedia admins so that they can run the scripts? >> > > So why not have puppet pull from an external resource like the wiki? We > do this in Fedora regularly. >> >> > why not just use a spreadsheet or something? >> >> >> >> And how do we present the data to the requesters? >> > >> > how do you do it now? >> >> Wiki. And requesters have to go through the long list of hundreds of >> links. That is not the ideal way, is it? >> > > I'd assume each vendor has a link, will the webapp be getting rid of > vendors? If not then they still have to go through a long list, if it's a > search thing, why not break out the vendors? The problem of breaking out the vendors, which is already there, is that it is not neat and neither maintainable. >> I saw some thread that we were worried about actually losing our >> users. One of the reasons for that low offline availability. It is not >> that Fedora is not available offline. It is. But the information is >> presented so clumsily that nobody uses that option. >> > > So reorganize the information. We discussed and worked on it for months and agreed that the current method/wiki format is not working properly for us. > Perhaps it would help if you could clearly > outline the problems and solutions you're trying to solve. Sure. How many do you want? I shall list five for now but I can bring up lot more if required. We have accumulated our problems for one and a half years now. Problem 1: Wiki information is not very convenient for the end users. We can use tables to make the data more arranged but that breaks the page too easily. Again, the admins of freemedia/distribution are already overworked and does not want to spend more time on creating and maintaining the tables and wiki pages. We want a easy and sustainable way of maintaining the list and present them. Problem 2: http://lists.fedoraproject.org/pipermail/advisory-board/2010-February/007985.html Problem 3: For freemedia, we need keep the form opened differentially for different region. Multiple forms are a way, but again, we will be moving to more clumsier way of making a list of those forms in the wiki. Also, in case something needs to be changed, I have to open all those htmls and edit them manually. Problem 4: It is really a pain to organise all the information according to countries and continents and maintain them. A better way to have a country code and look up those entries dynamically from geoip information. Problem 5: In the wiki, there is no way to temporarily disable a vendor so that it does not come up in the result. We have to delete it and again reinsert it. -- Regards, Susmit. ============================================= http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
