[12:06] <asac> fta: there?
[12:06] <fta> asac, yep but not for long
[12:07] <asac> fta: ho ;) ... great
[12:07] <asac> fta: so debian folks go nuts ... ;)
[12:08] <asac> fta: they said they cant wait longer for chromium ... and then after discussing they said that a security team guy of debian wants to maintain it
[12:08] <asac> actually he wanted to take it over
[12:08] <asac> i suggested that he joins your team
[12:09] <asac> and told him to chat with you and me about what the rules would be in a branch
[12:09] <asac> err in our bzr branch
[12:10] <asac> fta: anyway. first step would be to upload this weekend.
[12:11] <asac> fta: which a debian developer needs to do at first, but after that and applying for Dm status in debian for that package you can upload to debian directly and then sync to ubuntu
[12:11] <asac> i just wanted to ask if uploading to debian directly is ok with you
[12:11] <fta> *sigh*
[12:12] <fta> more bureaucracy
[12:12] <asac> fta: but after that you get a guy that said he can deal with the security mess for chromium ;)
[12:13] <asac> and not pain because debian starts to build their own chromium way of packaging
[12:13] <asac> or something stupid like that
[12:14] <fta> well, the problem i see here is that if that security guy works on it, it will be in the beta part, he won't maintain head and dev
[12:14] <asac> fta: is that a problem?
[12:14] <asac> i mean in general i see that its better if he could help everywhere
[12:15] <asac> but isnt help on one side an improvment?
[12:15] <fta> that means even more merges between the branches
[12:16] <fta> help is good, i just feel i won't be able to keep track, that's it
[12:16] <asac> fta: well. what i think what he will do is a) keep his own branch
[12:16] <asac> for stable package maintenance and do cherry picks
[12:16] <asac> or
[12:16] <asac> he would just do release management ... in the sense that he uploads beta or stable releases that are done anyway
[12:17] <asac> e.g. we do all stable/beta bumps in our branches anyway, dont we?
[12:17] <asac> so he could take some version he thinks is good and upload that and do the paperwork for debian security team at least
[12:17] <asac> then we can check if he does good work and use the same tags as he does (so no need to figure exactly what to upload)
[12:18] <fta> ok, i have no strong feeling about all that, it's meant to happen anyway so be it
[12:18] <asac> i think he should come here and you can talk about what would be possible/not possible.
[12:19] <asac> fta: ok. you said you have not much time today? when should i get him here?
[12:21] <asac> fta: by the way. did you ever hear if chromium linux is supposed to be on stable for 5
[12:21] <fta> nope
[12:22] <asac> this beta madness really .... ;)
[12:22] <asac> but welll thats how it is.
[12:24] <asac> fta: let me know when i should get giuseppe in here ;)
[13:21] <asac> Derevko: hey ;)
[13:21] <Derevko> hi
[13:21] <asac> fta: ^^ ... he is debian peer i spoke about
[13:22] <asac> we were talking about what to release to debian usually
[13:22] <asac> Derevko: so currently beta channel is the best we have
[13:22] <asac> Derevko: that means if my suggestion makes sense we would look in the releaseblog what was last announced
[13:23] <asac> and consider packaging that
[13:23] <Derevko> asac: yes, I agree
[13:23] <asac> however, the problem then begins ... we dont know what the releases you see on that RELEASE url
[13:23] <asac> were about.
[13:23] <asac> they could a) be experiments/improvments etc.
[13:23] <Milos_SD> Hi. When will dom.ipc.plugins.enabled start working on Firefox 3.7 from this PPA? :(
[13:23] <asac> or b) reression fixes for that push
[13:23] <asac> regression fixes for that push ;)
[13:23] <asac> so thats where i am still in the dark ;)
[13:24] <asac> we could assume that regression fixes would be annonuced
[13:24] <asac> I will take the action to check that with the chromium folks
[13:24] <asac> Derevko: so ok; whats last on beta release bog?
[13:24] <asac> 5.0.342.9
[13:25] <asac> so if my theory is riht, we should be able to find that on the beta branch
[13:25] <asac> hmm
[13:25] <asac> i think we should make fta do release commits for all versions if thats a good scheme
[13:27] <asac> great. launchpad gives internal server error
[13:27]  * asac branches
[13:28] <asac> hmm.
[13:28] <asac> fta: i think the tagging could be improved
[13:29] <asac> fta: this is what i see with bzr log --include-merges on .beta branh
[13:29] <asac> http://paste.ubuntu.com/421645/
[13:29] <asac> so there you seemed to have merged the packaging for the .9 release
[13:29] <asac> from .head
[13:29] <asac> (so seems they release .9 everywhere)
[13:29] <asac> up to beta
[13:30] <asac> anyway.. i think the .head commit should be something like ...0ubuntu1~head ... then we could have tagged the real commit on .beta branch like 0ubuntu1~beta
[13:30] <asac> e.g. in a release commit after the .beta merge
[13:31] <asac> Derevko: so atm i think its the latest .beta packaging ... which is the upstream version we have on release blog
[13:32] <asac> Derevko: we could maintain a downstream branch from .beta ... and whenever we pick something merge it don
[13:32] <asac> down
[13:33] <asac> as we might need to change Maintainer: etc. though in the end we could do tha ton the real branches ... but hav eto sync with fta as his bot might need to get fixed to do the versioning etc. right
[13:33]  * asac talks too much
[13:33] <asac> feels like swamping Derevko ... maybe play around and build the branch ;)
[13:44] <Derevko> asac: I was under the impression that lp:chromium-browser was the main branch from where the Ubuntu lucid packages (and so also the Debian packages will?) were built, but perhaps I'm wrong.
[13:45] <asac> Derevko: do you have that branched? please paste bzr info inside
[13:46] <asac> let me see
[13:46] <asac> thats .head indeed
[13:46] <asac> checking out
[13:47] <Derevko> asac: http://paste.debian.net/70437/plain/70437
[13:47] <asac> Derevko: yeah. seems thats currently the case
[13:47] <asac> Derevko: so we need to talk to him
[13:48] <asac> as long as we have a single branch thats fine. but imo that should be .beta
[13:48] <fta> sorry, i was off (and i'm back just for ~10min)
[13:48] <asac> no problem
[13:48] <asac> fta: can you explain why you release beta releases from .head?
[13:48] <fta> i tag and release in .head,
[13:49] <fta> then i merge in the beta branch just for the beta ppa
[13:49] <asac> and if you release _all_ beta releases from .head or if there might be a beta release from .beta for some circumstances
[13:49] <asac> fta: what do you do if they do a cherry pick release on beta channel
[13:49] <asac> and dev etc. have already moved on?
[13:49] <asac> just a retroactive release?
[13:49] <fta> well, it tried many things, releasing from beta then merging back to head, or the opposite
[13:50] <asac> fta: why do you need to merge back beta releases?
[13:50] <asac> i would think its just one commit on the beta branch after the merge
[13:50] <fta> changelog mostly
[13:50] <asac> true. so ok
[13:50] <asac> for the case i metntioned you could probably just branch out an old revision
[13:50] <asac> do the release there
[13:50] <asac> merge back into .head?
[13:50] <asac> and into .beta ;)
[13:51] <asac> (for ppa)
[13:51] <asac> i guess something like that hasnt happened yet?
[13:51] <fta> i'm constantly improving .head, but head is sometimes/often ahead, so it's a merge vs cherry pick fight
[13:52] <fta> one way or another, i have to merge one and either cherry-pick or revert the other
[13:52] <fta> (by revert, i don't mean uncommit, just commit a reversed patch)
[13:53] <fta> rollback
[13:53] <asac> fta: so to understand when head has moved away, you branch out the old versoin that was closest? do the release there and merge that back into .head?
[13:53] <asac> wouldnt that make senes?
[13:53] <asac> we do that for firefox when that moved ahead and it works quite well
[13:53] <asac> (though chromium is a bit of a different situation with there super volatile versions ;))
[13:54] <fta> nope, i bzr diff from the previous release, and drop everything that is too far ahead
[13:54] <asac> fta: in the branch?
[13:54] <fta> yes
[13:54] <asac> so the brnach goes backwards sometimes?
[13:54] <fta> that's what your paste is showing
[13:54]  * asac reads opens it again
[13:54] <fta> not really, it recommit the changes on top just after the release
[13:55] <fta> -it+I
[13:55] <asac> fta: why not doing it like i suggested? that would be kind of a logical way.
[13:55] <asac> its kind of not nice changelog wise, yes. but it works i think ;)
[13:55] <fta> it's not perfect, but that's the best way i could find to manage 3 channels in parallel with less differences
[13:56] <fta> as i said, the master branch is .head
[13:56] <fta> no merge in there
[13:56] <asac> so for the last beta release we could hav branches 512
[13:56] <asac> we bake a beta release there. then just merge it back because of changelog and also merge that into the .beta branch
[13:57] <asac> preparing the release is a manual operation anyway
[13:57] <asac> its just a retroactive mini branch
[13:57] <fta> it's possible, it's just not the way i did the last 4~5 releases
[13:57] <asac> yeah. maybe think about it ... i think thats less hazzle that way
[13:58] <asac> anyway i think i know what to do then
[13:58] <asac> for upload we release just the last version announced ;)
[13:58] <asac> easy enough
[13:58] <asac> then when something is in stable releases we only upload that what was announced either as regression fix or a security update
[13:59] <asac> now we have to find out what that is ;)
[13:59] <asac> also we hope that regression fixes are announced ;)
[13:59] <asac> and that those bumps without announce (if there are any) usually is for adding new stuff
[14:00] <fta> just to clarify, when i fix a bug, i do it in .head so it's immediately available to the crowd, then it will be in the next release if it's not urgent otherwise i create an incremental release immediately
[14:00] <fta> (i have to run now)
[14:00] <asac> fta: ok. so you decide what you backout based on importance? e.g. you dont revert all?
[14:01] <asac> thanks
[14:01] <asac> ttyl
[14:02] <asac> Derevko: so that makes some sense.
[14:02] <asac> Derevko: at least for now ... pick the tag associated with the release we want
[14:02] <asac> e.g. branch that ... then change the debian/control as we need and upload ;)
[14:03] <asac> then next time ther eis a release we want, merge that tag to that branch and upload
[14:03] <asac> maybe we should collapse changelogs
[14:03] <asac> then we can at some point think about how to do the debian packaging in the branch so it becomes upstream there
[14:04] <fta> you should branch one of those: http://paste.ubuntu.com/421663/
[14:04] <asac> (in the .head branc)
[14:04] <asac> yeah
[14:06] <asac> Derevko: add fta, me, you as the uploders and the chromium alioth mailinig list as maintainer ;)
[14:06] <asac> Derevko: are you good at perl?
[14:07] <asac> i messed up the licensecheck.pl thing ... e.g. there is a sort problem ... so generating licenseinfo updates is bad to read in diff
[14:07] <asac> never had time to fix it ;)
[14:09] <asac> my @values = values %{$$data{$dir}{$license}};
[14:09] <asac> i think that need to be sorted
[14:10] <Derevko> asac: no sorry
[14:11] <asac> heh. np
[14:31] <Milos_SD> Hi. When will dom.ipc.plugins.enabled start working on Firefox 3.7 from this PPA?
[16:40] <chrisccoulson> Milos_SD - i will fix that tomorrow if nobody has done that before then
[16:40] <chrisccoulson> oh
[16:40] <chrisccoulson> he didn't hang around ;)
=== nikolam_ is now known as nikolam
[19:01] <fta> asac, i can teach you
[19:01] <fta> asac, by what do you want to sort the hash?
=== nikolam_ is now known as nikolam
[21:07] <BUGabundo> even|ng