quality/tickets

Fork 0

Fix blocker bug tracker page and replace it with a static HTML page #296

New issue

Closed

opened 2012-06-12 19:52:18 +00:00 by adamwill · 8 comments

adamwill commented

2012-06-12 19:52:18 +00:00

Owner

https://fedoraproject.org/wiki/Current_Release_Blockers - which generates a useful view of blocker bugs from Bugzilla - has been broken since the recent Bugzilla upgrade. At minimum we need to fix up the script that generates it, and have it run by something other than jlaska's personal wiki account. 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.

johannbg commented

2012-06-12 21:01:52 +00:00

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.

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.

adamwill commented

2012-06-12 21:04:30 +00:00

Author

Owner

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?

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?

tflink commented

2012-06-12 23:48:33 +00:00

Owner

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

johannbg commented

2012-06-13 06:23:49 +00:00

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

tflink commented

2012-06-13 08:26:32 +00:00

Owner

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.

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.

adamwill commented

2012-06-13 11:27:35 +00:00

Author

Owner

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.

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.

johannbg commented

2012-06-13 13:17:51 +00:00

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

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

tflink commented

2013-03-04 18:11:03 +00:00

Owner

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

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