Here is a RFR for fedora distribution app[0]. If more information is required, please let me know.
----------------------------------------------------------------------------- Project Sponsor ----------------------------------------------------------------------------- Name: Susmit Shannigrahi
Fedora Account Name: susmit
Group: freemedia
Infrastructure Sponsor: ----------------------------------------------------------------------------- Secondary Contact info -----------------------------------------------------------------------------
Name: Neville A. Cross
Fedora Account Name: yn1v
Group: freemedia ----------------------------------------------------------------------------- Project Info -----------------------------------------------------------------------------
Project Name: Fedora Distribution Application
Target Audience: 1. Anyone who may be requesting a fedora disk from freemedia. 2. Anyone who want to locate a vendor. 3. Admin members who want to enroll/remove vendors. 4. Freemedia admin members. 5. vendors.
Expiration/Delivery Date (required):
Prototype is ready. Can be deployed as soon as a sponsor is found. May be in a month. http://publictest15.fedoraproject.org:8888/
Description/Summary: This application will integrate all the different methods of offline fedora distribution. This will also address several issues that came up while operating the freemedia and distribution project. This will make finding or managing the vendors easy. Lastly, it will replace the existing freemedia front-end and make filing ticket a one step process.
Project plan (Detailed): 1. Currently we keep the vendor list in the wiki.[1][2] These are hard to maintain. And it is also hard for people to find out a suitable vendor. The proposed app is geoip aware one which returns the most appropriate results based on location. This will reduce the load on freemedia as there are vendors who offer the disk from less than half-a-dollar. 2. It is a pain to maintain the wiki list and verify each and every vendor. We plan to notify each vendor upon a new release. We also want to let them have an account so that they can update their accounts themselves. 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. 4. There are countries which have their own freemedia program (brazil for example). They want us to redirect requesters to their sites. Currently, we need to add a redirect manually everytime we want to do that. We also address it here.
Should you need more info, please let me know.
Goals: Integrate all the offline sources of fedora. And present them to the uses in a neat and convenient way.
Specific resources needed: Infrastructure sponsor. Additional Info (Optional): None
[0] https://fedorahosted.org/fedora-distribution/ [1]http://fedoraproject.org/wiki/Distribution/OnlineVendors [2] http://fedoraproject.org/wiki/Distribution/LocalVendors
Here is a RFR for fedora distribution app[0]. If more information is required, please let me know.
----------------------------------------------------------------------------- Project Sponsor ----------------------------------------------------------------------------- Name: Susmit Shannigrahi
Fedora Account Name: susmit
Group: freemedia
Infrastructure Sponsor: ----------------------------------------------------------------------------- Secondary Contact info -----------------------------------------------------------------------------
Name: Neville A. Cross
Fedora Account Name: yn1v
Group: freemedia ----------------------------------------------------------------------------- Project Info -----------------------------------------------------------------------------
Project Name: Fedora Distribution Application
Target Audience: 1. Anyone who may be requesting a fedora disk from freemedia. 2. Anyone who want to locate a vendor. 3. Admin members who want to enroll/remove vendors. 4. Freemedia admin members. 5. vendors.
Expiration/Delivery Date (required):
Prototype is ready. Can be deployed as soon as a sponsor is found. May be in a month. http://publictest15.fedoraproject.org:8888/
Description/Summary: This application will integrate all the different methods of offline fedora distribution. This will also address several issues that came up while operating the freemedia and distribution project. This will make finding or managing the vendors easy. Lastly, it will replace the existing freemedia front-end and make filing ticket a one step process.
Project plan (Detailed): 1. Currently we keep the vendor list in the wiki.[1][2] These are hard to maintain. And it is also hard for people to find out a suitable vendor. The proposed app is geoip aware one which returns the most appropriate results based on location. This will reduce the load on freemedia as there are vendors who offer the disk from less than half-a-dollar. 2. It is a pain to maintain the wiki list and verify each and every vendor. We plan to notify each vendor upon a new release. We also want to let them have an account so that they can update their accounts themselves. 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. 4. There are countries which have their own freemedia program (brazil for example). They want us to redirect requesters to their sites. Currently, we need to add a redirect manually everytime we want to do that. We also address it here.
Should you need more info, please let me know.
Goals: Integrate all the offline sources of fedora. And present them to the uses in a neat and convenient way.
Specific resources needed: Infrastructure sponsor. Additional Info (Optional): None
[0] https://fedorahosted.org/fedora-distribution/ [1]http://fedoraproject.org/wiki/Distribution/OnlineVendors [2] http://fedoraproject.org/wiki/Distribution/LocalVendors -- Regards, Susmit.
============================================= http://www.fedoraproject.org/wiki/user:susmit ============================================= Sent from Calcutta, WB, India
On Tue, 23 Feb 2010, susmit shannigrahi wrote:
Description/Summary: This application will integrate all the different methods of offline fedora distribution. This will also address several issues that came up while operating the freemedia and distribution project. This will make finding or managing the vendors easy. Lastly, it will replace the existing freemedia front-end and make filing ticket a one step process.
Project plan (Detailed):
- Currently we keep the vendor list in the wiki.[1][2] These are hard
to maintain. And it is also hard for people to find out a suitable vendor. The proposed app is geoip aware one which returns the most appropriate results based on location. This will reduce the load on freemedia as there are vendors who offer the disk from less than half-a-dollar.
How is maintaining it in an app going to be so much easier then maintaining it in the wiki?
- It is a pain to maintain the wiki list and verify each and every
vendor. We plan to notify each vendor upon a new release. We also want to let them have an account so that they can update their accounts themselves.
You still have to verify vendors and notify them.
- 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?
- There are countries which have their own freemedia program (brazil
for example). They want us to redirect requesters to their sites. Currently, we need to add a redirect manually everytime we want to do that. We also address it here.
Should you need more info, please let me know.
Goals: Integrate all the offline sources of fedora. And present them to the uses in a neat and convenient way.
I get that building websites is fun and all but I just don't see why we would host this. This seems completely a workflow issue. You're still entering in and validating data either way.
Perhaps I don't understand what this app does? If you're tracking vendors why not just use a spreadsheet or something?
-Mike
On Tue, Feb 23, 2010 at 10:29 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Tue, 23 Feb 2010, susmit shannigrahi wrote:
Description/Summary: This application will integrate all the different methods of offline fedora distribution. This will also address several issues that came up while operating the freemedia and distribution project. This will make finding or managing the vendors easy. Lastly, it will replace the existing freemedia front-end and make filing ticket a one step process.
Project plan (Detailed):
- Currently we keep the vendor list in the wiki.[1][2] These are hard
to maintain. And it is also hard for people to find out a suitable vendor. The proposed app is geoip aware one which returns the most appropriate results based on location. This will reduce the load on freemedia as there are vendors who offer the disk from less than half-a-dollar.
How is maintaining it in an app going to be so much easier then maintaining it in the wiki?
It is database driven. So entering data and presenting them don't need wiki edits.
- It is a pain to maintain the wiki list and verify each and every
vendor. We plan to notify each vendor upon a new release. We also want to let them have an account so that they can update their accounts themselves.
You still have to verify vendors and notify them.
Currently, we don't or can't do that because it is so much manual work.
- 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.
- There are countries which have their own freemedia program (brazil
for example). They want us to redirect requesters to their sites. Currently, we need to add a redirect manually everytime we want to do that. We also address it here.
Should you need more info, please let me know.
Goals: Integrate all the offline sources of fedora. And present them to the uses in a neat and convenient way.
I get that building websites is fun
Do you follow the freemedia list? If not, please have a look at the archive. I didn't do this for fun.
Perhaps I don't understand what this app does? If you're tracking vendors why not just use a spreadsheet or something?
And how do we present the data to the requesters?
On Tue, 23 Feb 2010, susmit shannigrahi wrote:
On Tue, Feb 23, 2010 at 10:29 PM, Mike McGrath mmcgrath@redhat.com wrote:
On Tue, 23 Feb 2010, susmit shannigrahi wrote:
Description/Summary: This application will integrate all the different methods of offline fedora distribution. This will also address several issues that came up while operating the freemedia and distribution project. This will make finding or managing the vendors easy. Lastly, it will replace the existing freemedia front-end and make filing ticket a one step process.
Project plan (Detailed):
- Currently we keep the vendor list in the wiki.[1][2] These are hard
to maintain. And it is also hard for people to find out a suitable vendor. The proposed app is geoip aware one which returns the most appropriate results based on location. This will reduce the load on freemedia as there are vendors who offer the disk from less than half-a-dollar.
How is maintaining it in an app going to be so much easier then maintaining it in the wiki?
It is database driven. So entering data and presenting them don't need wiki edits.
scripts.
- It is a pain to maintain the wiki list and verify each and every
vendor. We plan to notify each vendor upon a new release. We also want to let them have an account so that they can update their accounts themselves.
You still have to verify vendors and notify them.
Currently, we don't or can't do that because it is so much manual work.
Scripts.
- 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.
- There are countries which have their own freemedia program (brazil
for example). They want us to redirect requesters to their sites. Currently, we need to add a redirect manually everytime we want to do that. We also address it here.
Should you need more info, please let me know.
Goals: Integrate all the offline sources of fedora. And present them to the uses in a neat and convenient way.
I get that building websites is fun
Do you follow the freemedia list? If not, please have a look at the archive. I didn't do this for fun.
Perhaps I don't understand what this app does? If you're tracking vendors why not just use a spreadsheet or something?
And how do we present the data to the requesters?
how do you do it now?
-Mike
Let me be clear first.
I am not much concerned about what admins do. I am more concerned about how easy we make it for the "customer" when he requests media.
How is maintaining it in an app going to be so much easier then maintaining it in the wiki?
It is database driven. So entering data and presenting them don't need wiki edits.
scripts.
- It is a pain to maintain the wiki list and verify each and every
vendor. We plan to notify each vendor upon a new release. We also want to let them have an account so that they can update their accounts themselves.
You still have to verify vendors and notify them.
Currently, we don't or can't do that because it is so much manual work.
Scripts.
What is the difference between writing a script and maintaining that and writing an simple app and maintaining that?
- 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?
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 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.
On Tue, 23 Feb 2010, susmit shannigrahi wrote:
Let me be clear first.
I am not much concerned about what admins do. I am more concerned about how easy we make it for the "customer" when he requests media.
How is maintaining it in an app going to be so much easier then maintaining it in the wiki?
It is database driven. So entering data and presenting them don't need wiki edits.
scripts.
- It is a pain to maintain the wiki list and verify each and every
vendor. We plan to notify each vendor upon a new release. We also want to let them have an account so that they can update their accounts themselves.
You still have to verify vendors and notify them.
Currently, we don't or can't do that because it is so much manual work.
Scripts.
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.
- 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?
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. Perhaps it would help if you could clearly outline the problems and solutions you're trying to solve.
-Mike
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.
- 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...
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.
On Wed, 24 Feb 2010, susmit shannigrahi wrote:
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.
Unfortunately you don't have to be convinced, we do. There's a time coming, sooner then we'd like to admit, where our tg1 / python stack won't be so well supported.
> 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.
So use a database then.
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.
What do the end users see now? I thought they used the free media form.
Problem 2: http://lists.fedoraproject.org/pipermail/advisory-board/2010-February/007985...
That's not a problem, that's a question.
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.
so use a database.
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.
a script can't do that?
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.
I think you're missing my point about the vendor information. You can actually store pages on the wiki via the API. For example:
wget -qO- 'https://fedoraproject.org/w/index.php?title=Infrastructure/Server/publictest...'
Pretend that was tab delimited or whatever. If you don't like the wiki format, don't use wikiformat. But realize it's got to be in some format, all your problems don't magically go away becuase you're not using wiki markup.
-Mike
On Wed, Feb 24, 2010 at 8:19 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 24 Feb 2010, susmit shannigrahi wrote:
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.
Unfortunately you don't have to be convinced, we do. There's a time coming, sooner then we'd like to admit, where our tg1 / python stack won't be so well supported.
This is not a tg1. I would like to understand the problem here. Do you want it in php/mysql? You name it in any language that you want, I shall ensure you have it.
>> 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.
So use a database then.
And how do we pull the data from the database and present it? PHP is not the ideal one, so how do we show it?
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.
What do the end users see now? I thought they used the free media form.
No. They need to see the relevant vendor listing when they want to buy and relevant form when they want to request.
Problem 2: http://lists.fedoraproject.org/pipermail/advisory-board/2010-February/007985...
That's not a problem, that's a question.
Not actually. he, along with other things, points out why such a wiki list is not a very good idea.
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.
so use a database.
And how do I fetch it to wiki?
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.
a script can't do that?
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.
I think you're missing my point about the vendor information. You can actually store pages on the wiki via the API. For example:
wget -qO- 'https://fedoraproject.org/w/index.php?title=Infrastructure/Server/publictest...'
Pretend that was tab delimited or whatever. If you don't like the wiki format, don't use wikiformat. But realize it's got to be in some format, all your problems don't magically go away becuase you're not using wiki markup.
Storing is not that much a problem. Presentation is. How do we present the data with the api? I can even use mwclient and write to a page, but that does not help either.
On Wed, 24 Feb 2010, susmit shannigrahi wrote:
On Wed, Feb 24, 2010 at 8:19 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 24 Feb 2010, susmit shannigrahi wrote:
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.
Unfortunately you don't have to be convinced, we do. There's a time coming, sooner then we'd like to admit, where our tg1 / python stack won't be so well supported.
This is not a tg1. I would like to understand the problem here. Do you want it in php/mysql? You name it in any language that you want, I shall ensure you have it.
My problem is I'm trying to do a cost benefit here, there is a cost for us to host a webapp, I'm trying to identify something that costs less for you so we don't say no to you. I'm also trying to understand the benefit.
From where I sit the free media program is shipping CD's today. When we
agree to host an app like this we're agreeing to do it long after you're gone.
The map app is a good example, we've have several map outages because it wasn't properly maintained. Eventually it got back online. It's not about tg1 vs tg2. It's about wondering who is going to maintain this app after you're gone.
> >> 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.
So use a database then.
And how do we pull the data from the database and present it? PHP is not the ideal one, so how do we show it?
Databases existed before webapps, that's why I keep saying scripts.
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.
What do the end users see now? I thought they used the free media form.
No. They need to see the relevant vendor listing when they want to buy and relevant form when they want to request.
Give us a use case on what the user currently does (start at the very begining, tell us what URL's to go to and what stuff to hit.
Problem 2: http://lists.fedoraproject.org/pipermail/advisory-board/2010-February/007985...
That's not a problem, that's a question.
Not actually. he, along with other things, points out why such a wiki list is not a very good idea.
ah, so problem 2: is really just problem 1: restated?
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.
so use a database.
And how do I fetch it to wiki?
the database or the wiki, not both.
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.
a script can't do that?
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.
I think you're missing my point about the vendor information. You can actually store pages on the wiki via the API. For example:
wget -qO- 'https://fedoraproject.org/w/index.php?title=Infrastructure/Server/publictest...'
Pretend that was tab delimited or whatever. If you don't like the wiki format, don't use wikiformat. But realize it's got to be in some format, all your problems don't magically go away becuase you're not using wiki markup.
Storing is not that much a problem. Presentation is. How do we present the data with the api? I can even use mwclient and write to a page, but that does not help either.
Depends on to who.
-Mike
On Wed, 24 Feb 2010, susmit shannigrahi wrote:
On Wed, Feb 24, 2010 at 8:19 AM, Mike McGrath mmcgrath@redhat.com wrote:
On Wed, 24 Feb 2010, susmit shannigrahi wrote:
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.
Unfortunately you don't have to be convinced, we do. There's a time coming, sooner then we'd like to admit, where our tg1 / python stack won't be so well supported.
This is not a tg1. I would like to understand the problem here. Do you want it in php/mysql? You name it in any language that you want, I shall ensure you have it.
Couple of other questions, how many vendors are we talking about?
-Mike
infrastructure@lists.fedoraproject.org
-
Mike McGrath -
susmit shannigrahi