-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Last year we were working on getting Zikula packaged and stood up as the CMS solution for the Docs Project. Fast forward to today and we still don't have Zikula up but we do have Publican handling the public front-end for us.
So do we still need to work towards getting Zikula up and running or should we be working to get the kinks worked out of Publican?
What do we loose by staying with Publican? What do we gain?
What feedback have you received about the Publican front-end?
- --Eric
While looking at bugs assigned to the Docs team a saw at least 3 bugs that talked about Publican being a temp solution. It seems that at least a few people outside of Docs are not that happy with what Publican provides.
I am not saying this is a reason to move to Zikula, but that if we stay with Publican we need to look over each bug and figure out if we can do something about it to make the user experience better.
Zach Oglesby https://fedoraproject.org/wiki/User:Zoglesby
On Thu, Jun 3, 2010 at 7:43 PM, Eric "Sparks" Christensen sparks@fedoraproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Last year we were working on getting Zikula packaged and stood up as the CMS solution for the Docs Project. Fast forward to today and we still don't have Zikula up but we do have Publican handling the public front-end for us.
So do we still need to work towards getting Zikula up and running or should we be working to get the kinks worked out of Publican?
What do we loose by staying with Publican? What do we gain?
What feedback have you received about the Publican front-end?
- --Eric
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMB+nBAAoJEDbiLlqcYamxRo0QAJS2owSS0oVY3Nwty3NzZwXo 4kPeOa6dkg6v4e4NoY2YEu5e1K0CTHx4aSfHWaG56zkrGn2K/PpraIBZuadHbWBB jq8xpLt4ZXuH8H5+6nl+4gn7ajrTyRyZ2KfouYPRPm7rrp8EaHLcYdKcgOhoUTyI /DQfvECgff/5e4dnMvwtGDA56Np+36gXtRyh9GPBc1GELoaE4tTKq+GhRHOa/4gR /klz6YMtuUbVtdGhSCXWbx5AKHVSoo9tOmOB3SW505jrn8AEGz6HEu0i4qPanY/q FM9XRx+4FBS/u8RpoPSgpRFX/klEwQ9OtmGt25Fb0YgHo6lE9oZLczpZEJYCZbgg vVrOf/7lXBRrqdQ+eDdz5PRkWg9uKIyEi/NhoB3G3u/u+XzRUlpOr32m0PJSOZXU 4yOJM4CMF9ChON3Bg2kSUnhOmbGyXKCb18RQdV9qZaJLhIyeYzGu/tq8a5yMAOmP Ec0PW0GrDaULBCjUPytagtiadkn2BR1TFBqp2V14orLmM6jbJfVVI+GvYtlp6N89 a9ZnHtn4JK7fn1fy8kWjj97+PKLGUB/XvRlkGsDbO1vipdzhdo2WA9hcjZO71c1F XWSSeG4SExhGBAASogjhcJxQzv7BxvC4XyCN5U3+OOEHvfRjRFjQVlMoWALZZccT q1EDr4licZACMCsFVikv =aPn6
-----END PGP SIGNATURE-----
docs mailing list docs@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/03/2010 05:13 PM, Zach Oglesby wrote:
While looking at bugs assigned to the Docs team a saw at least 3 bugs that talked about Publican being a temp solution. It seems that at least a few people outside of Docs are not that happy with what Publican provides.
Can you give us the bug numbers because I'm not sure that I've seen the tickets. I know of a couple of implementation bugs that are being worked right now but they didn't give me heartburn over keeping Publican.
- --Eric
On Thu, Jun 03, 2010 at 06:38:17PM -0400, Eric Sparks Christensen wrote:
On 06/03/2010 05:13 PM, Zach Oglesby wrote:
While looking at bugs assigned to the Docs team a saw at least 3 bugs that talked about Publican being a temp solution. It seems that at least a few people outside of Docs are not that happy with what Publican provides.
Can you give us the bug numbers because I'm not sure that I've seen the tickets. I know of a couple of implementation bugs that are being worked right now but they didn't give me heartburn over keeping Publican.
I don't consider myself "outside" but the most glaring problem we have now is what has been induced by changing the entire site structure:
* Broken links from Google that bring the user back to a front page
* An embedded search that brings users to Google, which doesn't work and often brings the user back... (etc.)
Some of this might change as Google re-indexes content, but we really do need to keep a careful eye on how the user experience of finding our docs content is working.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/04/2010 01:23 PM, Paul W. Frields wrote:
I don't consider myself "outside" but the most glaring problem we have now is what has been induced by changing the entire site structure:
Broken links from Google that bring the user back to a front page
An embedded search that brings users to Google, which doesn't work and often brings the user back... (etc.)
Some of this might change as Google re-indexes content, but we really do need to keep a careful eye on how the user experience of finding our docs content is working.
Yeah, that was a problem. It would be nice to know how often Google indexes the site, when the last changes could be made to the structure before a release, and if we could force a re-index.
Of course this is all Google-centric. There are other search engines. IF we continue to use Publican we wouldn't have to change the structure, correct?
- --Eric
On Fri, Jun 04, 2010 at 13:29:24 -0400, Eric Sparks Christensen sparks@fedoraproject.org wrote:
Yeah, that was a problem. It would be nice to know how often Google indexes the site, when the last changes could be made to the structure before a release, and if we could force a re-index.
Some of this is described here: http://www.googleguide.com/google_works.html
It looks like you could get some new stuff added using: http://www.google.com/addurl/?continue=/addurl
That isn't the same as reindexing existing stuff though. And I don't know if readding a link Google knows about triggers a reindex.
On Fri, Jun 04, 2010 at 01:13:32PM -0500, Bruno Wolff III wrote:
On Fri, Jun 04, 2010 at 13:29:24 -0400, Eric Sparks Christensen sparks@fedoraproject.org wrote:
Yeah, that was a problem. It would be nice to know how often Google indexes the site, when the last changes could be made to the structure before a release, and if we could force a re-index.
Some of this is described here: http://www.googleguide.com/google_works.html
It looks like you could get some new stuff added using: http://www.google.com/addurl/?continue=/addurl
That isn't the same as reindexing existing stuff though. And I don't know if readding a link Google knows about triggers a reindex.
I'm not sure either, but I did resubmit http://docs.fp.o a couple days before release day just for good measure.
On 06/05/2010 03:23 AM, Paul W. Frields wrote:
I don't consider myself "outside" but the most glaring problem we have now is what has been induced by changing the entire site structure:
Broken links from Google that bring the user back to a front page
An embedded search that brings users to Google, which doesn't work and often brings the user back... (etc.)
Some of this might change as Google re-indexes content, but we really do need to keep a careful eye on how the user experience of finding our docs content is working.
One of the new features of Publican 2.0 that I haven't mentioned yet is that it creates an XML sitemap for search engine bots to crawl. You can find d.fp.o.'s sitemap here:
http://docs.fedoraproject.org/Sitemap
I've fed this to Google, Yahoo, and Bing, and they're all slowly re-indexing the site. The map now contains a little over 2,000 URLs and at the time of writing, Google has crawled about 350 of them.
The dilemma we face is the decision of when to turn off the 404 redirect. For the sake of all the existing links scattered around the net (both on the Fedora Project site and off it), we'd want to postpone this as far as possible. On the other hand, any bot attempting to verify that link gets a page served up and probably concludes that the link is valid; I suspect that if these links 404ed, they'd start to evaporate from search results.
Given that existing links around the net are pointing to (at most recent) the F12 versions of docs, there will be no need to keep the 404 redirect in place past October; however, if we want to start allowing dead links to 404 out rather than poison search results, maybe we should bring that date forward? The sooner we do this, the sooner search will start working properly...
Cheers Rudi
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/05/2010 03:14 AM, Ruediger Landmann wrote:
One of the new features of Publican 2.0 that I haven't mentioned yet is that it creates an XML sitemap for search engine bots to crawl. You can find d.fp.o.'s sitemap here:
Awesome.
I've fed this to Google, Yahoo, and Bing, and they're all slowly re-indexing the site. The map now contains a little over 2,000 URLs and at the time of writing, Google has crawled about 350 of them.
I know that Google has some algorithm that figures out how often your site changes and then crawls more or less frequently. Not sure if we could work with Google on scheduling this more or less around the time of a release. Of course I'm guessing that we won't have this big re-structuring next time, either.
The dilemma we face is the decision of when to turn off the 404 redirect. For the sake of all the existing links scattered around the net (both on the Fedora Project site and off it), we'd want to postpone this as far as possible. On the other hand, any bot attempting to verify that link gets a page served up and probably concludes that the link is valid; I suspect that if these links 404ed, they'd start to evaporate from search results.
Isn't there a type of redirect (302?) that tells you that you are being redirected so you don't think the URL is valid?
Given that existing links around the net are pointing to (at most recent) the F12 versions of docs, there will be no need to keep the 404 redirect in place past October; however, if we want to start allowing dead links to 404 out rather than poison search results, maybe we should bring that date forward? The sooner we do this, the sooner search will start working properly...
Yeah, the sooner the better, IMO.
Cheers Rudi
- --Eric
Including Infrastructure team gurus on this email thread for additional expert advice and assistance. :-) Setting reply-to docs@ list.
On Sat, Jun 05, 2010 at 05:55:05AM -0400, Eric Sparks Christensen wrote:
On 06/05/2010 03:14 AM, Ruediger Landmann wrote:
One of the new features of Publican 2.0 that I haven't mentioned yet is that it creates an XML sitemap for search engine bots to crawl. You can find d.fp.o.'s sitemap here:
Awesome.
I've fed this to Google, Yahoo, and Bing, and they're all slowly re-indexing the site. The map now contains a little over 2,000 URLs and at the time of writing, Google has crawled about 350 of them.
I know that Google has some algorithm that figures out how often your site changes and then crawls more or less frequently. Not sure if we could work with Google on scheduling this more or less around the time of a release. Of course I'm guessing that we won't have this big re-structuring next time, either.
The dilemma we face is the decision of when to turn off the 404 redirect. For the sake of all the existing links scattered around the net (both on the Fedora Project site and off it), we'd want to postpone this as far as possible. On the other hand, any bot attempting to verify that link gets a page served up and probably concludes that the link is valid; I suspect that if these links 404ed, they'd start to evaporate from search results.
Isn't there a type of redirect (302?) that tells you that you are being redirected so you don't think the URL is valid?
I thought that 301 and 302 both do this, but 302 generally is used for temporary redirects, and 301 for permanent ones. So 301 would be the one you're thinking of here perhaps?
Given that existing links around the net are pointing to (at most recent) the F12 versions of docs, there will be no need to keep the 404 redirect in place past October; however, if we want to start allowing dead links to 404 out rather than poison search results, maybe we should bring that date forward? The sooner we do this, the sooner search will start working properly...
Yeah, the sooner the better, IMO.
I wonder how long you would need 301's in place before it's safe to remove them? Because I think Infrastructure's not keen on maintaining a big list of these.
On Mon, Jun 7, 2010 at 8:20 AM, Paul W. Frields stickster@gmail.com wrote:
Including Infrastructure team gurus on this email thread for additional expert advice and assistance. :-) Setting reply-to docs@ list.
On Sat, Jun 05, 2010 at 05:55:05AM -0400, Eric Sparks Christensen wrote:
On 06/05/2010 03:14 AM, Ruediger Landmann wrote:
One of the new features of Publican 2.0 that I haven't mentioned yet is that it creates an XML sitemap for search engine bots to crawl. You can find d.fp.o.'s sitemap here:
Awesome.
I've fed this to Google, Yahoo, and Bing, and they're all slowly re-indexing the site. The map now contains a little over 2,000 URLs and at the time of writing, Google has crawled about 350 of them.
I know that Google has some algorithm that figures out how often your site changes and then crawls more or less frequently. Not sure if we could work with Google on scheduling this more or less around the time of a release. Of course I'm guessing that we won't have this big re-structuring next time, either.
The dilemma we face is the decision of when to turn off the 404 redirect. For the sake of all the existing links scattered around the net (both on the Fedora Project site and off it), we'd want to postpone this as far as possible. On the other hand, any bot attempting to verify that link gets a page served up and probably concludes that the link is valid; I suspect that if these links 404ed, they'd start to evaporate from search results.
Isn't there a type of redirect (302?) that tells you that you are being redirected so you don't think the URL is valid?
I thought that 301 and 302 both do this, but 302 generally is used for temporary redirects, and 301 for permanent ones. So 301 would be the one you're thinking of here perhaps?
It's 301. RFC2616 has the details: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3
Given that existing links around the net are pointing to (at most recent) the F12 versions of docs, there will be no need to keep the 404 redirect in place past October; however, if we want to start allowing dead links to 404 out rather than poison search results, maybe we should bring that date forward? The sooner we do this, the sooner search will start working properly...
Yeah, the sooner the better, IMO.
I wonder how long you would need 301's in place before it's safe to remove them? Because I think Infrastructure's not keen on maintaining a big list of these.
I'm not aware of any specific time frame defined by the RFCs or other standards. Each site has a different policy for redirect maintenance. There are 3 basic options:
1. Watch the access logs for a majority of the access requests to use the new URL. When the pre-determined threshold is met, remove the redirect and accept that some users who still haven't updated their links will receive a 404 (Object Not Found).
2. Set a date-based transition period. After the specified date, either remove the redirect, or apply the logic #1 and bump out the cut off date accordingly.
3. Keep the redirect indefinitely, or until the maintenance costs are too cumbersome. Many organizations use this one, for better or worse.
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ Where open source multiplies: http://opensource.com _______________________________________________ infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
---Brett.
On Mon, Jun 7, 2010 at 10:44 AM, brett lentz wakko666@gmail.com wrote:
On Mon, Jun 7, 2010 at 8:20 AM, Paul W. Frields stickster@gmail.com wrote:
Including Infrastructure team gurus on this email thread for additional expert advice and assistance. :-) Setting reply-to docs@ list.
On Sat, Jun 05, 2010 at 05:55:05AM -0400, Eric Sparks Christensen wrote:
On 06/05/2010 03:14 AM, Ruediger Landmann wrote:
I'm not aware of any specific time frame defined by the RFCs or other standards. Each site has a different policy for redirect maintenance. There are 3 basic options:
- Watch the access logs for a majority of the access requests to use
the new URL. When the pre-determined threshold is met, remove the redirect and accept that some users who still haven't updated their links will receive a 404 (Object Not Found).
- Set a date-based transition period. After the specified date,
either remove the redirect, or apply the logic #1 and bump out the cut off date accordingly.
- Keep the redirect indefinitely, or until the maintenance costs are
too cumbersome. Many organizations use this one, for better or worse.
Number 3 is usually what I have dealt with and it becomes cumbersome way too soon for a volunteer group. I would go with a #2. Basically go with a D-day rated to a release. Since most of these changes occured at release time, we will do redirects until say F14 is released or F11 goes EOL.
On Sat, Jun 05, 2010 at 17:14:36 +1000, Ruediger Landmann r.landmann@redhat.com wrote:
The dilemma we face is the decision of when to turn off the 404 redirect. For the sake of all the existing links scattered around the net (both on the Fedora Project site and off it), we'd want to postpone this as far as possible. On the other hand, any bot attempting to verify that link gets a page served up and probably concludes that the link is valid; I suspect that if these links 404ed, they'd start to evaporate from search results.
Should code 301 be used for redirects to things that have moved? That code indicates that the redirect is permanent and that the new URL should be used going forward.
On 06/05/2010 11:38 PM, Bruno Wolff III wrote:
On Sat, Jun 05, 2010 at 17:14:36 +1000, Ruediger Landmannr.landmann@redhat.com wrote:
The dilemma we face is the decision of when to turn off the 404 redirect. For the sake of all the existing links scattered around the net (both on the Fedora Project site and off it), we'd want to postpone this as far as possible. On the other hand, any bot attempting to verify that link gets a page served up and probably concludes that the link is valid; I suspect that if these links 404ed, they'd start to evaporate from search results.
Should code 301 be used for redirects to things that have moved? That code indicates that the redirect is permanent and that the new URL should be used going forward.
Yes, absolutely. I've got a list from Google of incoming links, around which we can write a bunch of 301s. I'm working on this :)
Cheers Rudi
docs@lists.stg.fedoraproject.org