[RFR] Infrastructure sponsor needed for Fedora Distribution App.

Wed Feb 24 03:00:37 UTC 2010

On Wed, Feb 24, 2010 at 8:19 AM, Mike McGrath <mmcgrath at 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.html
>>
>
> 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/publictest1&action=raw'
>
> 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.

-- 
Regards,
Susmit.

=============================================
http://www.fedoraproject.org/wiki/user:susmit
=============================================
Sent from Calcutta, WB, India