Meeting Log - 2008-12-01

Mon Dec 1 23:03:15 UTC 2008

22:00 -!- ricky changed the topic of #fedora-meeting to: Fedora Websites - Who's here?
22:00 -!- tw2113 [n=tw2113 at 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 at 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 at fedora/SonarGal] has joined #fedora-meeting
22:01 < ricky> giarc, ianweller, stiv2k, mizmo, anybody I missed: ping
22:03 -!- drago01 [n=linux at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at athedsl-4510554.home.otenet.gr] has joined #fedora-meeting
22:46 -!- che [n=rkastl at 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 at 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 at 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 at 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 at 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 at 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-websites-list/attachments/20081201/dca41f45/attachment.sig>