irc meeting 27 November



Hi all,

Attached is the - slightly edited - transcription of our irc meeting of
last Thursday.

Have fun!

-- 
Reinout van Schouwen
<diegoe> xan: chpe: barisione: cosimoc: reinouts: uws: alp: kalikiana1: ping pong
<reinouts> diegoe: hi
<xan> diegoe, hello
<chpe> hi
<diegoe> heya heya
 meeting in some minutes?
<xan> yes
<diegoe> we are missing marco who is in india

<diegoe> right
 he said he might not be here, but I bet that was just a white lie to make an impressive appearance out of nowhere
<reinouts> anyway, first item on the agenda is: - discuss pending decision for cookies implementation (Xan has some
 doubts worth discussing)

<xan> hrm, right, I think I'm basically were I was last time we talked about this. So maybe I can just promise to upload what I have to webkit's bugzilla, pose the questions there, and hope someone will take a look at it
<diegoe> xan and danw landed the soup part of the cookies
 we now have two backends: sqlite and txt, both following mozilla formats
<xan> yes, and the ephy patch is pretty straightforward, so it's really blocking on webkit
 I'm more worried about webkit in general though, alp said he'd release something on the 10th with most stuff in and it's almost december and nothing happened, so maybe we can talk about that?
<diegoe> yes, that remains to be a problem
 kov got webinspector landed
--> pierlux (~plbeaud jalfrezi collabora co uk) has joined #epiphany
<reinouts> so does anyone know what alp is up to in the first place?
<pierlux> no, he suddenly reappeared today to submit a ridicoulously small fix... zecke seems to be doing a lot lately though!
--> zecke (~ich 92 117 14 201) has joined #epiphany
<xan> I think he mentioned he wanted to make a temporary fork in fd to push stuff faster or something? I think we should just do that ourselves
<reinouts> xan: yes I remember that
 if anyone has the right permissions, please do it
<diegoe> xan: can we do that *right now*?
 iirc you have fdo access, if not, who shall we ping?
<xan> diegoe, I lost my fd account when they all broke, didn't ping daniel yet to activate it
 but it doesn't have to be in fd
<diegoe> gitorious?
<xan> grandma's git server works just as well

<xan> if there's a way to not fork it I'd rather not do it though, at least I'm not particular looking forward to reintegrate all the stuff in the future
<reinouts> xan: wasn't one of the advantages of a dvcs that reintegrating patches became easier? :s
<diegoe> xan: that would be a problem if the gtk+ part would be in high activity in upstream
<diegoe> reinouts: it's far better, but still not magic sadly
<xan> reinouts, what diegoe said
<diegoe> xan: but since the gtk+ part is not...
<reinouts> but if we're just blocking on webkit now, we're certainly not going to have a 2.26 w/webkit

<xan> diegoe, well, from the little I follow it seems they fancy moving huge chunks of stuff around, renaming, etc
<pierlux> xan: indeed, constant refactoring keeps the code nice :D
<diegoe> still that's really unhealthy to the patches waiting anyway
 so the problem remains
<reinouts> zecke: temporary fork to push patches we need
<diegoe> either we fight in updating the single patches, or the repo we create

<xan> pierlux, and forking harder. I'm not complaining though :)
<zecke> With forking you are not resolving the problem. The issue is that there is no agreement on how to create the API
 this will not be different if the code is hosted somewhere else
<xan> hum, if we host it we make the rules...
<pierlux> and most of us seems to agree: let's have new API!
<diegoe> thing is that we haven't been able to get people to accept the API and hence nobody has used it
 no new api = no new api new users
<xan> the way I see it the problem is that webkit is supposed to be API stable, so stuff with new API is hard to push, and at the same time there's no one around to actually review it
 you can't really have both things at the same time

<zecke> no the problem for me and other reviewers is: We can technically judge the implementation. We can not judge if the API is gtk'ish or smart... sure I can review all API patches today and let them in, but it only makes limited sense to do so
<reinouts> In the mean time everyone is waiting for everyone else and we're not getting code in people's hands to play with
<zecke> xan: with your fork. would you add whatever patch I propose?
<xan> zecke, we need to start somewhere
<pierlux> as if we'd need to make a 2.0 version already, with a lot of API changes, which keeping the 1.0 branch for the early adopters...
<xan> no, we'd have meetings like the one we had some weeks ago
<pierlux> s/which/while
<diegoe> the 'control' would stay inside the ephy/webkit interest team, since we have this megalomaniac view that we are the main users of it
<xan> zecke, I don't want to commit *everything*, it just seems that we can't get anything in, that needs fixing
<zecke> xan: where are the results of the API discussions? If you can point me, mjs, eseidel... to _results_  we are all happy to review the patches
<diegoe> like xan says, we want to put stuff that we really need to move forward, not just anything
<pierlux> diegoe: indeed, there are other users interesting in API changes :)
<diegoe> if you all agree, we can take zecke's invitation and re-review the patch you agreed on the last meeting
<xan> zecke, so if we discuss it among ourselves and put a summary of the decision in the bug that's OK? I think we did just that for the bug I'm talking about
 let me find it...
<diegoe> zecke: http://live.gnome.org/Epiphany/Meetings/20081023 <- some notes on that meeting
<pierlux> zecke: we all agreed that the the popup window patch was wanted and "reviewed" API in that meeting http://live.gnome.org/Epiphany/Meetings/20081023
<xan> right, https://bugs.webkit.org/show_bug.cgi?id=19130


<xan> also I think the idea that only API that is final should be committed is a bit insane. Even GTK+ has a big fat warning that code between stable releases is subject to change. So, of course we should discuss things before, but if after using it you decide you should change it it's not big deal IMHO
<reinouts> sounds reasonable, yes
<diegoe> I agree with that, you should promise stability on released stuff, not in trunk
 otherwise you can never get people to test stuff unless they download and apply patches
<zecke> Two things: I'm happy to review any API that has been discussed (mailinglist preferred, e.g. a post of a irc meeting), I wouldn't mind if we add a new subdirectory with new API (webkit2 or for other experiments)
 regarding releases: well, I don't want to step on alp's toes and I don't even know how he is releasing tarballs
<xan> Sending the discussions to the list sounds good to me

<xan> well, that does it for me, unless someone wants to say something I guess we can move to the next point?
<diegoe> so the final decision is?
<xan> have IRC discussions about new API and send summary to the webkit list
<zecke> my attempt (besides work and uni) is to spend at least one day a week on webkit
<xan> and zecke will review patches instead of having a life
<reinouts> but will a temporary fork be created?
<pierlux> zecke: releasing tarballs shouldn't be more complex than making "make dist", if the autoconf stuff is well done :)
<xan> reinouts, doesn't seem necessary with this plan, let's see how it goes
<reinouts> ok
<diegoe> regarding the 'fork', instead of 'fork' perhaps we could have a 'patches repo'?
 just for testing, not for serious work or forking
 or better not?
* diegoe thinking git goodness
<xan> well, alp used to have a gazillion branches around, anybody can do the same I guess :)

<diegoe> :)
* diegoe takes notes
<reinouts> next point from diegoe's agenda: - gossip from the review round held days after ephy meeting    http://live.gnome.org/Epiphany/Meetings/20081023

<reinouts> ok so from that page
<xan> the meeting for the popup patch?
 or what?
<reinouts> jonner found a missing reference bug in ?FrameLoaderClient; the bug is only exposed by the patch, so a separate bug report/fix was proposed and jonner said he'd do it 
<diegoe> I mean, besides the minutes, anything important from that day to let us know?

<reinouts> - push the patches (I have Alp's cat kidnapped, he will cooperate),
 that the review round "pre approved"
<reinouts> so do we have this point covered with the previous discussion?
<xan> I think so
<reinouts> anyone else?
<diegoe> yep
<reinouts> last point:  - discuss ephy roadmap
<xan> Ephy Roadmap: 1. Finish the goddamn port. 2. There is no point 2. End of Roadmap.
<diegoe> everyone saw the email about that to ddl?
<xan> ?
<diegoe> very much I think
 this time rt is asking for the 2.26 roadmap and a long term rm
<xan> it seems we'll miss 2.26 again... maybe if we manage to move forward we could release a beta of the webkit port or something alongside 2.26
<reinouts> IMHO we need ephy/webkit to raise people's enthusiasm again
 even if it's not 100% functional
<diegoe> yes
 we need to raise some of that thing
 an actual website could help
<xan> diegoe, if you want to add some bluesky stuff to the long term roadmap one cool thing we talked with Company was native swfdec integration
<diegoe> to webkit?
<xan> yes
 you can put it like "New revolutionary technology to make web browsers crash 1000% less on average"
<diegoe> i think they expect stuff for ephy only
 and honestly i think it's a bit of crack
<diegoe> I would like to fix the location bar
<xan> well, it allowed some interesting things, but shrug, you are right, it's about ephy
<diegoe> (again)
<xan> diegoe, oohhh, right
<diegoe> and have some way to install extensions
<xan> diegoe, sqlite 
<diegoe> inram's code is painfully slow
<xan> diegoe, man, do you think we could have a hackaton and try to get that done? 
 would be nice to do it for 2.26
<diegoe> yes, sure
<xan> ok, harass me on jabber
 like you know how to do
<reinouts> pick a date?
<xan> a date?
<reinouts> for the hackathon
<diegoe> this saturday?
<xan> ok, I think I'm free
 ok, so the roadmap is finish the port and a potential bonus feature that might come in 2.26 but that we won't mention to cover our backs
 right? :)
<diegoe> we have to mention the new stuff
 :p
 that's the idea
 so, for 2.26: beta of webkit?
 sqlite backend?
 regarding the location bar, i have some gtk+ bugs, but i need someone cooler than me to give them some light to the eyes of gtk guys
<reinouts> chpe, your opinion?
<diegoe> and your plans :-)
<chpe> I have no plans for 2.26
<diegoe> xan: then it's on our hands to make 2.26 kick ass?
<xan> diegoe, :)
 ok, is there anything else?
<diegoe> don't think so
 we can hack now
<xan> good, who puts the summary online?
<diegoe> http://live.gnome.org/Epiphany/Meetings/20081127



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]