Hi!
I noticed a few links on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines are broken due to the wiki migration. Look out for strings like "[wiki:Self:Packaging/" to find them.
I might have fixed those myself, but if you guys protect that area with ACLs then you need to fix things like this yourself.
Cu knurd
On Sun, 2008-08-03 at 13:42 +0200, Thorsten Leemhuis wrote:
Hi!
I noticed a few links on http://fedoraproject.org/wiki/Packaging/ReviewGuidelines are broken due to the wiki migration. Look out for strings like "[wiki:Self:Packaging/" to find them.
I might have fixed those myself, but if you guys protect that area with ACLs then you need to fix things like this yourself.
Thanks for the heads-up, they should all be fixed now.
As an aside, someone recently complained to me that they were unable to "fix a bug" in the guidelines. When I inquired further, I discovered that the bug they wanted to fix was not a bug at all, but rather, a change that would have caused a lot of broken packages if it was adopted.
This is exactly why we have ACLs on the guidelines. Unfortunately, it also means that people with good intentions who really do find easy-fix bugs like these broken links can't just fix it themselves, but IMHO, it is a small price to pay.
~spot
Tom "spot" Callaway wrote:
This is exactly why we have ACLs on the guidelines. Unfortunately, it also means that people with good intentions who really do find easy-fix bugs like these broken links can't just fix it themselves, but IMHO, it is a small price to pay.
Is there an easy way to create the fix, but have the wiki store it in a potential update queue - ie for approval/application ? That would mean the wiki reviewer get's to be instantly useful, yet not be able to do unexpected things to the "needing fixes" pages. We'd probably require a detailed description of the potential change along with the change itself.
DaveT.
On Sun, 2008-08-03 at 23:23 +1000, David Timms wrote:
Tom "spot" Callaway wrote:
This is exactly why we have ACLs on the guidelines. Unfortunately, it also means that people with good intentions who really do find easy-fix bugs like these broken links can't just fix it themselves, but IMHO, it is a small price to pay.
Is there an easy way to create the fix, but have the wiki store it in a potential update queue - ie for approval/application ? That would mean the wiki reviewer get's to be instantly useful, yet not be able to do unexpected things to the "needing fixes" pages. We'd probably require a detailed description of the potential change along with the change itself.
Well, the closest thing that I know of is to put something in the "Notes" page for the corresponding item under Packaging/, but its not quite the same.
Sounds like an interesting idea for a MediaWiki plugin.
~spot
On Sunday 03 August 2008 15:28:33 Tom "spot" Callaway wrote:
On Sun, 2008-08-03 at 23:23 +1000, David Timms wrote:
Is there an easy way to create the fix, but have the wiki store it in a potential update queue - ie for approval/application ? That would mean the wiki reviewer get's to be instantly useful, yet not be able to do unexpected things to the "needing fixes" pages. We'd probably require a detailed description of the potential change along with the change itself.
Well, the closest thing that I know of is to put something in the "Notes" page for the corresponding item under Packaging/, but its not quite the same.
Sounds like an interesting idea for a MediaWiki plugin.
There is the FlaggedRevs extension which allows to mark special revisions as stable: https://fedorahosted.org/fedora-infrastructure/ticket/583
Regards, Till
On 03.08.2008 15:12, Tom "spot" Callaway wrote:
As an aside, someone recently complained to me that they were unable to "fix a bug" in the guidelines. When I inquired further, I discovered that the bug they wanted to fix was not a bug at all, but rather, a change that would have caused a lot of broken packages if it was adopted.
This is exactly why we have ACLs on the guidelines.
Sorry, but to me that sounds like a lame excuse.
A lot of wikis (including wikipedia) show that the benefits from being open to all heavily outweighs the disadvantage that someone can add something wrong to a page. The guidelines in fact were open in the early Extras days and I'd say they benefited from that a lot.
But sure, it happens that someone adds things to a page that are wrong or misleading. No big deal, just manage it wiki style: let two or three people subscribe to the pages in question and let them watch for changes closely. If something bad happens just revert it. Done.
Another solution: have two versions -- one locked and one open for editing; then people can enhance the latter easily and all you have to do now and then is to diff the two pages with tools like meld and merge the changes over. Done.
Cu knurd
On Sun, 2008-08-03 at 15:48 +0200, Thorsten Leemhuis wrote:
Another solution: have two versions -- one locked and one open for editing; then people can enhance the latter easily and all you have to do now and then is to diff the two pages with tools like meld and merge the changes over. Done.
The Discussion tab would be perfect for this, however I'm not sure if mediawiki allows the main page to be locked but the discussion tab to be open.
packaging@lists.fedoraproject.org