Meeting Log - 2008-12-01 - websites - Fedora Mailing-Lists

Monday, 1 December 2008

22:00 -!- ricky changed the topic of #fedora-meeting to: Fedora Websites - Who's
here?
22:00 -!- tw2113 [n=tw2113@fedora/tw2113] has joined #fedora-meeting
22:00 < tw2113> i'll attend just in case i have something to say
22:00 < ricky> Hey :-)
22:01 -!- rdieter [n=rdieter(a)ip68-110-20-4.om.om.cox.net] has joined #fedora-meeting
22:01 < ivazquez> Pong.
22:01 -!- stickster is now known as stickster_afk
22:01 -!- Sonar_Gal [n=Andrea@fedora/SonarGal] has joined #fedora-meeting
22:01 < ricky> giarc, ianweller, stiv2k, mizmo, anybody I missed: ping
22:03 -!- drago01 [n=linux(a)chello062178124130.3.13.univie.teleweb.at] has joined
#fedora-meeting
22:03 < ricky> Oookaaay then. 
22:04 < ricky> So this is the first meeting after the release - looks like
everything went pretty well, but we had a couple of catches
22:04 < ricky> get-fedora was a big success - thanks to everybody that helped with
that
22:04 < ricky> Next time around, it'll be ready earlier, so we'll have more
time to verify the information there.
22:05 -!- Evil_Sonar_Chick [n=Andrea@fedora/SonarGal] has quit Operation timed out
22:05 < ricky> Until recently, there were some incorrect file sizes left over from
the mockup.  Also, the PPC DVD link was wrong for a tiny bit after the release, until it
was reported/fixed
22:06 < ianweller> oh hi
22:06 < ricky> Another thing that needs to be standardized/documented is a process
for how l10n should transition before a release
22:07 < ricky> I'll try to start a wiki page with specific tasks/due dates for
every release
22:07 -!- llaumgui_ [n=llaumgui(a)cro34-2-82-226-153-125.fbx.proxad.net] has joined
#fedora-meeting
22:07 < ricky> Anybody have any suggestions for that or anything we could have
improved this release?
22:07 < ianweller> i think it worked out pretty well.
22:08 < ricky> Yup :-)
22:09 < giarc> seems like we had a lot fewer complaints on the site...which is
great
22:09 < ivazquez> And quite a few kudos.
22:09 < stiv2k> hello
22:09 < stiv2k> sorry
22:09 < stiv2k> my laptop froze
22:10 < ricky> Somebody suggested that we have a link to
http://fedoraproject.org/verify on the get-fedora pages.  I wonder where that should
go...
22:10 < ricky> Hopefully, we can make it fit in with the friendliness of the page,
if you know what I mean
22:11 -!- cmpahar [n=cmpahar(a)83.212.62.250] has joined #fedora-meeting
22:11 < ricky> Also, at least one person mentioned that they had to search for a
second to find the "show me all options" link.  Not sure if they were just too
used to the old layout or if there's something we should change
22:13 < ianweller> probably both good ideas.
22:13 < giarc> for verify, can we just put the link to it at the top, like this
page:
22:13 < giarc> http://fedoraproject.org/en/get-fedora-all
22:14 < ianweller> the /verify link could go in the sidebar. "Verify your
ISOs!"
22:14 < ricky> I was thinking that it could go under resources
22:14 < giarc> ooh, i like that
22:14 < giarc> seems perfect
22:15  * ricky makes a note
22:15 < ricky> One other thing that was confusing was the process for translators
22:16 < ricky> I ended up making a completely separate copy of the repo -
fedora-web.test and doing all of the F10 updates there (and pointing translators to work
on that one)
22:16  * giarc ah, wondered why we ended up with two git repos
22:16 < stiv2k> ricky: hey btw you said you needed to show me something about the
git access yesterday??
22:16 < ricky> Then I switched the live repo with that one on release day
22:17 -!- fraggle_ [n=fraggle(a)bea13-2-82-239-143-199.fbx.proxad.net] has quit
"-ENOBRAIN"
22:17 < ricky> stiv2k: Yeah, I just wanted to walk you through making changes -
things aren't that pretty in fedora-web right now
22:17 < stiv2k> ricky: gotcha
22:18 < ricky> I'll probably be away after the meeting, but ping me sometime and
we can do that - maybe you can add the verify link then or something
22:18 < stiv2k> ricky: cool
22:19 < stiv2k> can I get the URL again? I'd like to take a look around
22:19 < giarc> using a branch for new .po files seems like it would work for next
time
22:19 < ricky> You can browse it over http at
http://git.fedorahosted.org/git/fedora-web.git, and you should be able to clone it with
git clone ssh://git.fedorahosted.org/git/fedora-web.git now
22:20 < ricky> giarc: I was trying to find any way to avoid ugly merges.  How would
the branches be laid out?
22:20 < stiv2k> Permission denied (publickey).
22:20 < stiv2k> fatal: The remote end hung up unexpectedly
22:20 < stiv2k> I think I am mising a client side cert
22:21 < ricky> The thing is - we usually end up having to make changes to the F9
website at the same time while we work on the F10 website :-/
22:21 < rsc> ricky: the "fatal: The remote end hung up unexpectedly"
happens very often
22:21 < ricky> stiv2k: Ah, you didn't upload an SSH public key to FAS
22:21 < giarc> if we git branch f11 and do work there, we can work in the master for
current work, f11 for new
22:21 < rsc> ricky: I often need 3-5 tries once the pull/clone works.
22:22 < ricky> rsc: That's very strange.  It should either just fail all the
time or work all the time
22:22 < rsc> ricky: broken load balancing?
22:22 < ricky> rsc: Nope, it goes straight to one machine
22:22 < rsc> ricky: broken firewalling?
22:23 < ricky> Nope, I haven't heard of any other hosted project developers
having this problem either :-/
22:23 < stiv2k> ricky: I'm trying to do it now but I'm slightly confused
22:23 < giarc> if we 'tag' a branch as live, we should be able to just
'update' the live site to the tag
22:23 < rsc> hm. Interesting.
22:23  * giarc does not have the git retry problem
22:24 < ricky> giarc: Maybe we can have a separate branch for each release and have
the website generated straight from that branch.
22:24 < giarc> yeah, that is what i am thinking
22:24 < ricky> Then during the release, we just change the branch in a script and it
gets updated.
22:24 < stiv2k> ricky: ah i think I got it now
22:24 < ricky> Transifex has full support for that, right?
22:24 < giarc> in svn, i make 'tags' from the branch when ready to release
22:25 < ricky> stiv2k: Once you upload the SSH public key, it'll take 1-2 hours
for it to sync
22:25 < giarc> and production 'sites' are always based on the tag, that way
we can add bug fixes to the branch if needed and re-tag
22:26 < rsc> giarc: but branches/tags on svn are the same.
22:26 < ricky> I'm not sure if untagging/retagging is the "git way" of
doing things
22:26 < giarc> yeah, but not in concept
22:26 < giarc> in concept, tags are immutable
22:26 < giarc> not sure either
22:27 -!- llaumgui_ [n=llaumgui(a)cro34-2-82-226-153-125.fbx.proxad.net] has quit "Au
revoir...."
22:27 < rsc> in concept. And in fact, it's a branch.
22:27 < giarc> yep
22:27 < ricky> Heh.
22:27 < giarc> but as long as it's treated as immutable, who cares?
22:27 < stiv2k> ricky: can I upload more than one key? I might want to use either of
my two laptops
22:27 < ricky> We can probably get away with doing everything in branches :-)
22:27 -!- cmpahar [n=cmpahar(a)83.212.62.250] has quit No route to host
22:27 < rsc> giarc: treated? I'm always commiting to tags :)
22:27 < giarc> yeah :-}
22:27 < giarc> well, then they are just branches
22:27 < ricky> stiv2k: Yup, just concatenate them together (just like an
authorized_keys file)
22:27 < rsc> giarc: I can't see any read-only ability in svn.
22:28 < giarc> there is none
22:28 < giarc> unless you deny access to your tags dir
22:28 < rsc> which is nearly impossible.
22:28 < rsc> (svn+ssh e.g.)
22:28 < ricky> SCMs sure are confusing :-)
22:28 < rsc> (I'm SVN admin for > 1 year at work now)
22:28 < giarc> sure,it's just policy
22:28 < giarc> 3+
22:28 < giarc> here
22:29 < giarc> and it's just policy, as i said
22:29 < giarc> not read-only
22:29 < rsc> rules are there to get broken
22:30 < giarc> ok, your right. do you have any ideas how to solve the translation /
multi repo issue from this release
22:30 < rsc> why not as before? Two repos?
22:30 < rsc> or SVN with branches.
22:31 < rsc> and choose stable/devel branch.
22:31 < giarc> so, in 3 release we have 4 repos?
22:31 < ricky> Here are my thoughts now:
22:31 < rsc> can't we kill the old one?)
22:31 < giarc> that does not seem right...
22:31 < ricky> The current website gets generated from the master branch
22:31 < rsc> at least SVN has the advantage, that we don't mirror the whole
repository everywhere.
22:31 < rsc> (fedora-web.git > 50 MB here)
22:31 < ricky> Before a release (say before the F11 release), we make a F10 branch,
and point the script that generates the website at that
22:32 < ricky> Then we do all F11 development in master, and repoint the script when
we're ready to release
22:32 -!- ezq [n=ezq(a)200-127-101-170.cab.prima.net.ar] has quit "Ex-Chat"
22:32 < ricky> That way, the master branch always contains what translators should
concentrate on
22:32 < giarc> that would work, but i would just make an f11 branch, then you only
need to change the script once
22:32 < giarc> oh, yeah, there is that
22:32 < rsc> ricky: but maybe not in git? Because otherwise we're blowing up the
stuff to download heavily.
22:33 < ricky> How often do you need to reclone the entire repo?
22:33 < giarc> ( once per release per machine as i update them :-)
22:34 < rsc> a few times a year, when I don't know how to solve the conflicts or
the stuff I broke.
22:35 < rsc> anyway, does git really understand the meaning of branching or tagging?
Whatever branches were, didn't feel for me like branches.
22:35 < ricky> I guess we can look at clearing the history whenever it blows up
22:35 < ricky> rsc: What about it felt wrong?
22:35 < rsc> ricky: merging and so on. But maybe it's just git.
22:36 < rsc> ricky: merging mail/conflicts and similar stuff.
22:36 -!- ezq [n=ezq(a)200-127-101-170.cab.prima.net.ar] has joined #fedora-meeting
22:36 < rsc> ricky: but I would like more to see the *.po automagically updated if
some of the relevant source data changes.
22:36 < ricky> Yeah - I forget that waaay too often
22:36 -!- ezq [n=ezq(a)200-127-101-170.cab.prima.net.ar] has left #fedora-meeting []
22:36 < ricky> Maybe we can put that into a commit hook or something.
22:37 < rsc> it's not you, it's a general problem, I think.
22:37 < ricky> All right, so I think we finally have a system planned out that will
avoid merging as much as possible :-D
22:38 < ricky> I'll work on putting that into motion soon
22:38 < ricky> One other thing that we might want to work on is bugging translators
before releases :-)
22:38 < rsc> and people to re-read that.
22:38 < ricky> We should make it a goal to not lose any translations in newer
releases.  This time around, we dropped quite a few :-/
22:39 -!- tw2113 is now known as tw-work
22:39 -!- tw-work [n=tw2113@fedora/tw2113] has left #fedora-meeting ["I was raided by
the FBI and all I got to keep was this lousy quit message!"]
22:39 < giarc> rsc, sorry, 'and people to re-read that' ... what do you
mean?
22:39 < giarc> i did not follow what i should be re-reading :-}
22:40 < rsc> giarc: the translations should get re-read by others.
22:40 < giarc> ah, ok
22:40 < rsc> I don't know how this is for other languages, but some of them are
lousy.
22:40 < ricky> Ah, yeah.
22:40 < giarc> how do we 'poke' them now?
22:40 < rsc> mailinglist IIRC.
22:40 < ricky> I usually just sent one big email to fedora-trans-list
22:40 < rsc> Can't we send the translation request to the individual translation
lists?
22:41 < giarc> ah, so a post commit hook script to mail them our changes would
perhaps be a good idea
22:41 < ricky> Good idea
22:41 < stiv2k> ricky: I don't know exactly what you meant by
"concatenating" the RSA keys
22:41 < rsc> ricky: AFAIK there's a -de translation list for German ones.
22:41 < ricky> stiv2k: Basically just put them in a file on separate lines and
upload that
22:41 < rsc> ricky: so there should be others as well?
22:41 < stiv2k> ricky: ah
22:41 < ricky> Yeah, we can look up all of the l10n lists
22:41 < ricky> I wonder if that's what docs does
22:42 < giarc> ricky, can't he just use the same key on the other machine as
well ?
22:42 < rsc> ricky: no, they even don't do that.
22:42 < rsc> ricky: but they really *should* do that.
22:42 < ricky> giarc: If he wants to, yeah
22:42 < rsc> IMHO the l10n lists per language are more and better consumed rather
the fedora-trans-list (if I speak for myself)
22:42 < stiv2k> ricky: can I retrieve the one I already uploaded? my other machine
is off :S
22:43 < ricky> rsc: You might want to suggest that to them too next time - I never
thought about that
22:43 < ricky> stiv2k: You don't currently have one stored
22:43 < stiv2k> ricky: I uploaded it... you said it might take a while to sync so
maybe it's not in there yet
22:44 < ricky> stiv2k: Are you sure it worked?  It's showing up blank in the db
22:44 < rsc> ricky: if I remember that the next time, yes.
22:44 < stiv2k> oh
22:44 < stiv2k> ricky: *shrug*
22:44 < ricky> (It goes to the db immediately, but takes 1-2 hours to sync to the
machines)
22:44 < stiv2k> i will try it again
22:44 -!- MEP [n=MEP(a)host59-220-dynamic.2-79-r.retail.telecomitalia.it] has joined
#fedora-meeting
22:44 < giarc> do we have anything else on our agenda?
22:44 < stiv2k> do I need a GPG key id
22:45 < ricky> I think people have been too busy with the release to work on the
tasks list, so not many updates there
22:45 < rsc> ricky: is there a reason, that we've a KDE, a PPC, a GNOME but no
x86_64 special page?
22:45 < ricky> stiv2k: You don't have to, but if you have one, it's nice to
include
22:46 < giarc> hmmm...good question ; oversight?
22:46 < stiv2k> ricky: I'm not sure I have one, probably not...although I think
the SSH RSA key went through this time
22:46 < ricky> Pretty much because i386 will work the most
22:46 -!- constanton [n=tmac(a)athedsl-4510554.home.otenet.gr] has joined #fedora-meeting
22:46 -!- che [n=rkastl@redhat/che] has joined #fedora-meeting
22:46 < ricky> stiv2k: Yup, it went through
22:46 < rsc> or is 64 bit hidden to avoid issues at newbies?
22:47 < ricky> Yeah, it's only on the "all options" page
22:47 < rsc> ricky: yes, most. Except I need KVM for 64 bit VMs ;)
22:47 < ricky> rsc: I don't think most newbies need that :-)
22:47 < rsc> hehe
22:47 < rsc> the verify page dropped out of /get-fedora AFAIK, but that was
addressed, right?
22:47 < rsc> (sorry, was on the phone, wenn the meeting started)
22:47 < giarc> seems to have been
22:47 < ricky> Yeah, we plan to add that back under the resources
22:48 < giarc> adding under resouces
22:48 < rsc> ah one point, I got these days.
22:48 < stiv2k> yes maybe I will get to do that >:]
22:48 -!- ClausReheis [n=ClausReh@fedora/ClausReheis] has joined #fedora-meeting
22:48 < drago01> well we should offer the 64bit versions when the user is already
using a 64bi os (check user agent)
22:48 < rsc> several security websites/teams claimed, that we've no visible link
to a security section.
22:48 < rsc> drago01: no. That even causes issues with the static pages...
22:48 -!- constanton [n=tmac(a)athedsl-4510554.home.otenet.gr] has left #fedora-meeting []
22:49 < rsc> drago01: we would have to handle that using mod_rewrite which consumes
much more ressources rather what we currently have.
22:49 < giarc> drago01, we have decided in the past to avoid guessing via the
user-agent
22:49 < rsc> (correct me, but the fp.o servers serving the pages had heavy load
during the release time)
22:49 < ricky> The vast majority of people don't even need x86_64 (but
mistakenly think that they do)
22:50 < drago01> well if the hw supports it there is no reason to use i386 (it
should die die die)
22:50 < ricky> We could do that type of guessing with javascript, but it's not
that pretty, and l10n + javascript is usually annoying
22:50 < ricky> drago01: There actually is :-)
22:50 < rsc> so can we add maybe at ressources a link to our security pages or so?
22:50 < ricky> x86_64 is more memory-intensive, not to mention disk space with
multilib
22:50 < rsc> drago01: x86_64 has currently tooo many issues and problems.
22:50 < ricky> We actually had problems on release day because one of our proxy
servers was x86_64 instead of i686
22:50 < rsc> drago01: I've opened up several 64 bit specific bug reports since
my workstation is x86_64-
22:51 < ricky> Thankfully, it didn't cause any downtime :-)
22:51 < ricky> So security links:
22:52 < ricky> The two security-related pages we have are
http://fedoraproject.org/verify and http://fedoraproject.org/keys
22:52 < rsc> drago01: and thinking of proprietary software, which users will
*definately* install (Nvidia, ATI, Flash, acroread), there are other nice problems.
22:52 < drago01> I am using 64 bit on my servers, desktop and laptop no issues that
are arch specific .. the memory/diskspace is the only valid one but newer hw have enough
to deal with that
22:52 < ricky> We're already planning to linnk /verify on the get-fedora pages
22:52 < ricky> Do you think most users need info from /keys?
22:52 < rsc> ricky: AFAIK the claims were related to the security team itself or to
the updates with security infos
22:53 < rsc> ricky: let me maybe re-verify until the next meeting.
22:53 < drago01> rsc: nvidia, ati = no problem there are 64bit builds for years...
flash is there now and acroread just works
22:53 < ricky> rsc: Ahh, OK
22:53  * giarc will read the log, but needs to head in a few
22:53 < ricky> drago01: We may have to reevaluate our choice as support changes, but
at this point, i686 is the safest bet for users that don't know exactly what they
want
22:53 < rsc> drago01: x86_64 flash is still broken. i386 works more or less. ATI and
xorg 1.5 was sucking. Acroread only works with i386 compat libs same as flash.
22:53 < ricky> giarc: Thanks for coming!
22:54 < giarc> thanks for all your hard work!
22:54 < giarc> get-fedora worked out great
22:54 -!- giarc [i=hidden-u(a)gnat.asiscan.com] has quit "Leaving"
22:54 < ricky> drago01: Users that understand the reasons for running x86_64 can get
it at the "show all options" page
22:54 < rsc> drago01: things are getting better, but other third party software
still breaks on x86_64, I'm seeing this nearly daily - unluckily. Even with
non-mentioned software here.
22:54 < drago01> rsc: ati does not suck less on i686
22:55 < rsc> even the ERP system has more x86_64 bugs rather ix86 ones :(
22:55 < rsc> maybe let's wait another few releases...users are mostly even not
able to understand the difference of 32/64 bit.
22:55 < drago01> rsc: there is no reason why any software that does not ship any
kernel level components to work any different with multilib on x86_64 than on i386
22:56 < ricky> Hmm.  Thinking about security updates - if we can get them from an
RSS feed from bodhi or something, we already have the code to format/display it (no
translations, though) :-)
22:56 < rsc> drago01: theoretically. The ipmitool maintainer is still looking, why
I'm generating more core dumps as he needs e.g.
22:56 < ricky> drago01: There's always laziness :-)
22:57 < rsc> ricky: let me check for the next meeting what they exactly were
expecting.
22:57 < ricky> rsc: Sure thing, thanks for bringing it up
22:57 -!- wjd [n=wjd(a)static24-89-99-53.regina.accesscomm.ca] has quit Read error: 110
(Connection timed out)
22:57 < stiv2k> ricky: is there a web based package browser? other distros have them
like packages.ubuntu.com
22:57 < drago01> and with dropping ram prices (you can get laptops with 8gb ram now)
i686 should be dead soon (even vista64 is started to be shipped more often due to that)
22:57 < ricky> Right now, we don't have anything package browser targetted at
users (only targetted at packagers)
22:57 < rsc> stiv2k: not that detailed, as ubuntu/debian.
22:58 < ricky> **targeted
22:58 < rsc> drago01: PAE works like a charm. And I've also lots of x86_64
incompatible Enterprise software, which refuses to work with multilib.
22:58 < rsc> drago01: especially perl on multilib is horrible.
22:58 < ricky> I think there have been mentions of projects to make one, but I'm
not sure what the status on that is
22:58 < stiv2k> ricky: any plans to make one for users? just an idea.
22:58 < stiv2k> oh
22:59 < ricky> That has been brought up before - sounds like a cool python project
for anybody that's interested :-)
22:59 < drago01> PAE does not solve the issue that a single app is limited to 2GB
(on x86_64 even 32bit apps can access up to 4gb)
22:59 < rsc> drago01: right. But for x86_64 incompatible software the only
solution.
22:59 < ricky> It'd be nice to have something very simple to start with -
something like a web-based repoquery
23:00 < rsc> drago01: I'm trying to get *anything* to x86_64 at work, but I see,
that there's too much old proprietary stuff out there, which does not work but is
needed.
23:00 -!- pingou_laptop [n=Pingou@fedora/pingou] has quit Remote closed the connection
23:00  * ricky might run x86_64 on this machine next time around - but I'm also
sticking with PAE for now :-)
23:00 < rsc> and if multilib also doesn't help, I need a plain ix86...mostly.
23:00 < ricky> rsc is scaring me away from x86_64 more and more :-P
23:00 < rsc> ricky: it works, as long as you've no proprietary software :)
23:01 < ricky> Ah, cool :-)
23:01 < ricky> Well, we've reached the hour mark, so I'll close it up
23:01 < rsc> are we payed by time?
23:01 < ricky> We got a bunch of things to improve for next release though - thanks
for all of the ideas!
23:01 < stiv2k> :D
23:01 < ricky> Heh
23:02  * ricky isn't sure if there's another meeting in here at this time
23:02 < ricky> But anyway, thanks for coming, everybody :-)  See you later!

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Meeting Log - 2008-12-01