Replying to [ticket:296 adamwill]:

We decided the best approach is probably to make it a standalone page (hosted on fedoraproject somewhere) rather than a wiki page; being a wiki page isn't giving us any advantages and just makes things more complicated.

First of all who are "We" and secondly could you elaborate a on how having this on the wiki is more complicated since there was a reason we put this on the wiki page in the first place and I'm interested into seeing if something new is being brought to the initial discussion.

The meeting - it's in the log:

http://meetbot.fedoraproject.org/fedora-meeting/2012-06-11/fedora-qa.2012-06-11-15.03.log.html

I don't think anyone said anything about there being a specific reason for it to be a wiki page during the meeting. What was the reason?

Replying to [comment:1 johannbg]:

could you elaborate a on how having this on the wiki is more complicated since there was a reason we put this on the wiki page in the first place and I'm interested into seeing if something new is being brought to the initial discussion.

The first thing that comes to mind is that we wouldn't have to deal with python-mediawiki or the wonderful awesomeness that is mediawiki table syntax.

My counter question would be how mediawiki syntax is any simple or flexible when compared to plain html + css - we're not talking about some dynamic application here, just a script that generates html instead of a wiki page. We would have more options for formatting and I also don't see much if any value in keeping revisions of the blocker bug page but there could be something that I'm missing.

If, at some point in the future, we come up with a good proposal for a more dynamic bug tracking app, it would be easier to extend the generated html.

Replying to [comment:2 adamwill]:

The meeting - it's in the log:

http://meetbot.fedoraproject.org/fedora-meeting/2012-06-11/fedora-qa.2012-06-11-15.03.log.html

I don't think anyone said anything about there being a specific reason for it to be a wiki page during the meeting. What was the reason?

Yeah I've been to busy to attend or followed up on all the meetings and will be for a another release cycle or two depending on the progress of the systemd migration process and the followed up clean up process that takes place when it's done.

The reason for it was consolidation as in we want(ed) the information for reporters to use be in the same place.

Mediawiki was the only option at that time with it's limitations as have been pointed out both in the present and we were aware of in the past.

There is nothing wrong with using some other solution but that means a lot of work moving things from the wiki into that new thing or coming up with a front end that keeps tap of all this stuff and presents it to reporters for easy accessing.

If I can recall correctly the only solution suggested at that time that held any potential water for success for the community, was the Fedora community app which at that time was in (very) early stages and which current status I'm unaware of. ( Reporters would just log in and all relevant information would be presented to them or within a grasp )

We did look at various testing platforms ( not only for this ) but they as well fell short one way or another...

Replying to [comment:4 johannbg]:

There is nothing wrong with using some other solution but that means a lot of work moving things from the wiki into that new thing or coming up with a front end that keeps tap of all this stuff and presents it to reporters for easy accessing.

If I can recall correctly the only solution suggested at that time that held any potential water for success for the community, was the Fedora community app which at that time was in (very) early stages and which current status I'm unaware of. ( Reporters would just log in and all relevant information would be presented to them or within a grasp )

We did look at various testing platforms ( not only for this ) but they as well fell short one way or another...

I wonder if there's been some miscommunication here. We're not proposing to change the test matrices or anything else on the wiki, just the blocker tracking page which is generally read-only. All the script would do is gather all the current release blocking bugs and generate HTML to display all of them in one place.

While I think that there could be some advantages in investigating a different test case management system in the future, I agree that it would require much more than 10 minutes at one QA meeting to come to an agreement on whether it was a good idea and which system to go with.

Johann: right, I think Tim described it correctly: this concerns only https://fedoraproject.org/wiki/Current_Release_Blockers , no other page. All that happens is that single page gets replaced by a single page of static HTML somewhere else within fedoraproject.org . Are you OK with that plan? Test cases and matrices will not be changed at all.

Ah ok somehow took it as there was some larger change in play here.

Yeah sure just make sure https://fedoraproject.org/wiki/Current_Release_Blockers redirects to the new url

Hrm, this should have been closed a while ago - this has been fixed since before the F18 cycle started up.

This ended up implemented as a web application - http://git.fedorahosted.org/cgit/blockerbugs.git