[RFR] Infrastructure sponsor needed for Fedora Distribution App.

[Mike McGrath]

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.html
>

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/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.

	-Mike