Bug#522733: Debian Developer's Reference: FR instead of EN / broken links
On Thu, Apr 16, 2009 at 08:23:28AM +0200, Raphael Hertzog wrote: > Can we get this fix applied soon ? I've been bugged multiple times already > about the broken links. That document is important to many and we should > not let the situation rot for so long. Even a temporary hack is ok until > you have a complete solution. Sure, done. I don't know why I didn't commit that patch when I first saw it. Should I leave the bug open? -- Matt http://ftbfs.org/ -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, Apr 15, 2009 at 05:41:17PM -0700, Don Armstrong wrote: >On Wed, 15 Apr 2009, Steve McIntyre wrote: >>b. Stop linking directly to the images, and go via redirects. Could >> maybe be a central cgi, maybe even with intelligence to redirect >> to good/close/fast/up-to-date mirrors. Could work, but needs >> implementing. :-) > >This sounds like a good idea, but there would still need to be logic >to detect which mirrors had actually managed to get up to date... and >that bit is probably a bit complicated. Yup, that's exactly what I mean. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Hi! * Steve McIntyre [2009-04-15 15:36:57 CEST]: > We then prune most of the old ISO images so we don't waste too much > space - older images can be recreated in the future using jigdo if > necessary. To the best of my knowledge that would depend on snapshot.debian.net being functional because once we release we also prune out the old packages that would be required to build the old images. > We currently potentially have a window of a few hours of breakage, as > the web pages that point directly to the old images stay around for > quite a while. Even if they are updated directly in $VCS as we do a > release, the website is only rebuilt periodically from cron. It's not that big of a deal to trigger a manual rebuild of the webpages if one of the webmasters is contacted and around for the time, it doesn't need to wait for the periodically rebuild from cron. Involving a webmaster also solves the problems that we had at lenny release with respect to not-tested commits resulting in build problems and not only delaying the issue until the next periodically cron run but the one after the problem got noticed and fixed. > 2. Possible solutions > >a. Stop linking directly to the images, and go through a set of > symlinks instead. Potentially messy, and people may get mixed > sets. Probably difficult to set up on mirrors too? Yeah, symlinking from hell might solve the issue of broken links but raise a lot of other issues indeed - I guess broken links are rather a much lower issue than those. >b. Stop linking directly to the images, and go via redirects. Could > maybe be a central cgi, maybe even with intelligence to redirect > to good/close/fast/up-to-date mirrors. Could work, but needs > implementing. :-) Sounds like a path that would work very well; but yes, requires work. >c. Do things in stages: > > * Copy the old release to the archive area a few days before > release. Add a warning to users that a new build is due, and > they should be careful that their downloaded images are all > from one version. > > * Once that archive copy is live, update the links to point to > the archive copy and push the new website. > > * On the day of release, release as normal and update the web > pages in $VCS to point to the new release in "release". Remove > the "new build due" warning and add "new build just happened". > After the website is built, new users will see the new images. > > * A few days/weeks later, prune the images in the old tree under > "archive". No current pages should be looking here, so we're > just dealing with stragglers. Staging is usually a quite save approach but requires better coordination which seems to have been problematic the last releases from what I perceived. I though would be happy to be proven wrong. ;) So long! Rhonda -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: contributors.debian.org (aka a home for contributors)?
On Sat, Apr 11, 2009 at 03:03:37PM +0200, Frank Lin PIAT wrote: > Currently, the wiki has a lot of wiki-user homepages. There are two > issues related to those wiki pages: > > 1. Wiki pages and homepages share the main namespace which cause false >positive in search results... (yes some user choose some ambiguous >names like root, Aim, DebianLiveUser, Mac, netbug) Is that possible to not search on wiki users pages by default ? > 2. Putting personal data under an open source license sounds weird. >Allowing to modify and redistribute those data is... not something >we want. (We discovered this issue as we were preparing the >re-licensing of the wiki). > > The initial plan was to simply move those pages to wiki.d.org/User/ and > leave those pages copyrighted to their owners. However there is an > alternative: > > What about moving those homepages to something like: >http://contibutors.debian.org ?? > > Pros: > * Every Debian contributor would have an (easy) to edit a homepage. > (Raphael Hertzog mentioned that DM/NM might experiment using wiki > homepage so applicant list their contributions) > * It is possible to write a macro to generate a Portfolio[1] > * The wiki could be used as a "weak" openid provider for other services. > (esp. for users that don't have alioth account yet). > > Cons: > * What about debian-community.org? Do we integrate some of the services > together, etc.. Cons: * Yet another place to look information for : there are already dozens or more websites where information is spread. That really makes entry of new contributors harder. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
Gerfried Fuchs wrote: >> We then prune most of the old ISO images so we don't waste too much >> space - older images can be recreated in the future using jigdo if >> necessary. > > To the best of my knowledge that would depend on snapshot.debian.net > being functional because once we release we also prune out the old > packages that would be required to build the old images. nope; that's what e.g. http://us.cdimage.debian.org/jigdo-area/*/snapshot/ is for. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#351746: possture syncopated virescence styptic
patiala hastened tractate oaats -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, Apr 15, 2009 at 08:16:13PM +0200, Luk Claes wrote: > Steve McIntyre wrote: > > On Wed, Apr 15, 2009 at 07:14:52PM +0200, Luk Claes wrote: > >> Steve McIntyre wrote: > >>> Hi folks, > >>> > >>> At the moment we have problems when we do releases including new > >>> CD/DVD images, as you'll see from mailing list complaints about broken > >>> links each time. Simon Paillard and I had some discussion about this > >>> today on #debian-www and I've come up with a workflow that will > >>> improve things, I think (see 2c below). Please feel free to point out > >>> what I've missed... :-) > >>> > >>> 1. The Problem > >>> > >>> We generate new CDs and DVDs for each point release. These are > >>> published in the release area of cdimage.debian.org[1]. The image > >>> filenames and the top-level directory are versioned for clarity, and > >>> we add a "current" symlink in the debian-cd directory that points to > >>^^^ > >>> the most recent version. We move old trees of images into the archive > >>> area[2] as each new build is published, We then prune most of the old > >>> ISO images so we don't waste too much space - older images can be > >>> recreated in the future using jigdo if necessary. > >>>d. Other ideas? > >> Can't we link to the 'current' images on the webpages? > > > > We do, but the image names themselves change from one release to the > > next too. > > Well then it should probably use an existing tag (like > current_release_lenny which contains '5.0.1') that needs to be updated > for the point release anyway IMHO. Someone added 3 extra tags which is > not very maintainable IMHO. > > Note that it's easy to convert 5.0.1 to 501 in eperl... In the past there were ocasionally several days between the release and the CD image release, so you can't use the tag for the former for the latter. Haven't checked whether that is still the case. Also using the tag in the URL doesn't give you any advantages, you still have the same rebuild window... Gruesse, -- Frank Lichtenheld www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Peças para impressoras e plotters.
Printertec Ltda Tel: (31) 3524-6667 - Fax: (31) 3524-6677 www.printertec.com.br Se não quiser mais receber este e-mail, clique aqui.
