=== gnomefreak76 is now known as gnomefreak [05:50] ara: http://iso.qa.ubuntu.com/qatracker/result/3833/442, the test case instructions say I should see a pop-up about incomplete language support and I didn't === meanburrito920_ is now known as Guest92203 === zul_ is now known as zul === bladernr__ is now known as bladernr_ === yofel_ is now known as yofel === RoAk is now known as RoAkSoAx [17:58] * mok0 is here [18:05] The meeting of the backporters team will be in 55 minutes [18:05] at 19:00 UTC [19:00] mok0: that would be now :-) [19:00] Yep [19:00] Should I msg ppl? [19:01] good idea! [19:02] Besides us, only 4 are on IRC atm [19:03] Hello [19:03] Hi ScottK, now we are 3 [19:03] Let's just vote NCommander will do all the work and end the meeting. [19:03] Hehe [19:04] Let's wait a couple of minutes to see if anyone else shows up [19:04] atlas still compiling over here... [19:05] OK, these are the things I'd like to discuss: [19:06] - General review of backports status [19:06] - Review of backports queues [19:06] - How to do backports with the new source package format [19:06] - LP update sometime late in the karmic cycle destroyed many components, f.ex. bzr, and fixes are still not available. [19:06] - The required "sponsoring" from the archive-admin team destroys my workflow and is demotivating. [19:06] -- My bzr backport is stuck at bug 533042 [19:07] Launchpad bug 533042 in hardy-backports "Backport subvertpy_0.6.9-1 from karmic" [Wishlist,Confirmed] https://launchpad.net/bugs/533042 [19:07] ... perhaps too much for 1 meeting :-) [19:08] Comments? [19:08] let's start with the first :-) [19:09] OK, so the queue is spread over several projects in LP [19:09] Is there any priority here? [19:09] may I ask first who is actually working on the backports queue? [19:09] I'm asking because I know that I'm not [19:10] Well, that's where I started [19:10] As a new member, I was looking for somewhere to start. [19:10] Personally, I think the bzr backport is the most important one atm [19:11] It is quite straightforward, but does require backporting som new packages [19:12] However, I don't think the workflow of "processing backport requests" is satisfactory [19:12] It is much too random [19:12] We need to be quite aggressive trying to keep old distros up to date [19:13] I've just read the wiki page, some parts indicate that a PPA will be involved in the future, and further at the bottom, the PPA seems to be already part of the process [19:13] link? [19:13] https://help.ubuntu.com/community/UbuntuBackports [19:14] Oh, yes, that's a mega-document [19:15] Too bad jdong is not here [19:16] I suspect the reason for having multiple lp projects is that different members review requests for their 'pet' version only [19:16] ok, yeah I guessed that [19:16] I think the problem is that nobody has a pet version [19:16] ;-) [19:17] Which is why I sent around the email [19:17] It seems that devs loose interest in a distro once it has been released [19:17] that is a major problem I think [19:18] Even hardy is poorly supported. [19:18] given 288 open bugs for just hardy-backports only, I think it's fairly obvious that the team currently doesn't meet its goals [19:19] Indeed [19:19] well, hardy seems to be the toughest release, it has most of the reports [19:20] intrpid with 143, jaunty with 95, karmic 'only' 57 [19:20] I have a hardy box (virtual) and ran into the problem that it can't fetch LP branches [19:20] sorry? what do you mean with that? [19:21] On my hardy box, I could not do: bzr branch lp:blahblah [19:21] ah, the bzr backport. I see [19:21] I had to get the newest bzr [19:21] Also ubuntu-dev-tools has lots of bugs, but that doesn't hit many ppl [19:22] well, I think a first step could be to stage all necessary packages in the PPA, and then talk to the archive admins to copy from there [19:22] (because it uses the new launchpadlib) [19:22] I agree. [19:22] but that's a specific problem which can be handled [19:22] we were discussing a more general one before [19:23] which I don't really see an approach for [19:23] However, having to be sponsored by the archive admins is annoying [19:23] It interrupts my workflow, and I tend to forget what I was doing [19:23] as said, using a PPA as staging area seems appropriate to me. [19:23] yeah, perhaps [19:23] the archive admins can then batch-process accumulated packages [19:24] Do we have a central ppa for such things? [19:24] perhaps we should issue a call for help in the forums and/or the fridge? [19:24] Help for..? [19:24] testing? [19:24] according to the documentation, that would be https://edge.launchpad.net/~ubuntu-backporters/+archive/ppa [19:25] it doesn't look very used, though [19:25] OK, and so, as members of the team, we can all upload to that I suppose? [19:26] AFAIUI yes [19:26] I'm cool with that... wonder what the archive-admins say. [19:27] I still think it's a bit of a detour [19:28] well, sort-of yes. but I feel that's the easiest way to provide test packages [19:28] It is double work [19:28] We could just as well upload directly to the archive [19:28] it would be awesome to have a 'backport this' button on launchpad that creates an backport in ones private ppa [19:28] heh yes [19:29] what's the problem with uploading directly to the archive? [19:29] I remember that I did that once or twice. but that was ages ago [19:29] I was told it was preferred not to [19:29] it isn't. but in some cases inevitable [19:29] Apparently the archive-admins have a script [19:30] it's mainly the same reason why syncs should be uploaded, although it's technically possible [19:30] the archive admin's script is way safer than manually fiddling with the changes file [19:31] Well, yes, but then the backport archive is not as sensitive [19:31] we have fewer "customers" [19:32] IIRC, the 'script' was created specifically for backporters, because at that time, jdong wasn't a motu yet, but still was proposing backports. going via bugreports and that script was perfectly adequate at that time [19:32] I see [19:32] Looking at bug 533042 [19:32] Launchpad bug 533042 in hardy-backports "Backport subvertpy_0.6.9-1 from karmic" [Wishlist,Confirmed] https://launchpad.net/bugs/533042 [19:32] as far as I understand your 'complaint' is that you feel the latency caused by the archive admins is too high? [19:33] you can see that it's stuck [19:33] yes exactly [19:33] That one is trivial [19:33] ah, I thought you were talking about bzr for hardy [19:33] this is a dependency, it needs to go in first [19:33] do we have a list of all pending packages for hady-backports? [19:33] build-dep [19:34] well, but in that case, using the PPA seems ideal to me [19:34] there you can testbuild and stage all related package, and then ask the archive admin to batch process them [19:34] yeah I suppose [19:35] so you wait only one time, not n times for n build-dependencies [19:35] In that case, I could just point them to the bazaar team's PPA :-) [19:36] I think that those packages don't follow the backports package naming policy [19:36] Probably... but the ones in the ppa wouldn't do that either [19:37] moreover, perhaps the bazaar folks could be integrated into the backports process? as in, they get authority to request or even upload to -backports directly ro something? [19:37] hm, that's a good point [19:37] well, removing the ~ppaN suffix seems straight forward [19:37] What I was doing was getting the same versions from karmic, lucid... and so on, that they had in their ppa [19:38] Then I test built them all, and tested that they worked [19:38] Then I filed bugs [19:38] Now I am waiting... [19:38] And I still have to go and check once in a while to see if things went right [19:39] That is very disruptive to my workflow, since I have other things to do than Ubuntu [19:39] you have my sympathy. I'm not sure what's the best way to proceed, though [19:39] I spent half a day checking all the bzr stuff, but now I have forgotten everything I did ... :-( [19:40] So it's extra energy needed to go back every time and check again [19:40] I'd much rather edit the changelog and get it over with [19:41] I wonder why the bug you've quoted about talks about subverty only [19:41] and does not open task for every package involved in that backport. that would make the actual problem more visibl [19:41] e [19:41] doesn't it say it's a dependency of bzr and other packages will follow? [19:42] OK, so perhaps we should end the meeting by discussing the issue of the source pacakge format. [19:43] ok [19:43] We are going to have problems backporting from lucid [19:43] ah, because of source format 3? [19:43] Yes [19:43] Packages wont build [19:43] in hardy, yes [19:43] I think in later releases, that should do, no? [19:44] I'm not sure [19:44] Other packages have problems b/c of debhelper [19:44] and so, we really ought to backport the latest version of that to the whole line [19:44] that seems to me valid candidates for direct uploads, where those changes need to be reverted [19:45] yes [19:45] I've done it a few times to packages installed locally here [19:46] It's not very difficult to change it [19:46] It's just work [19:46] We should be able to backport almost everything from lucid to karmic [19:47] There are not any major transitions I am aware of [19:47] so, my priorities are hardy and karmic [19:47] I may be biased because I'm familiar with debian's backports.org, but I really don't see much problems in direct uplodas [19:48] neither do I [19:48] in backports.org, all uploads are direct [19:48] I do think users are properly warned when activating backports [19:48] And furthermore, the number of bugs against backported packages is very low [19:49] AFAIR, ubuntu's backports are not have NotAutomatic: yes [19:49] If there are any at all [19:49] which I consider a great feature of backports.org [19:49] I am not really familiar with it [19:49] perhaps we should propose it [19:50] Sure [19:50] it basically prevents packages from being automatically updated to the version in backports [19:50] in debian, you'll have to issue 'apt-get install -t lenny-backports $foo' to install a package from bpo [19:50] That's in apt.conf, right? [19:50] no, that's in the Release file on the mirrors [19:51] I see [19:51] compare http://backports.org/backports.org/dists/lenny-backports/Release with http://archive.ubuntu.com/ubuntu/dists/hardy-backports/Release [19:51] aha [19:51] however with that turned on, I fear that synaptics will be terribly confused, and so are our users [19:51] Yeah that may be a problem [19:52] Unless the gui knows how to deal with it [19:52] Actually it may, I am not sure [19:52] ah, now I see another problem with using the PPA: it gets only built on i386 and amd64. so our powerpc and arm users are left in the cold with that [19:52] which I think is fair for staging packages, but not for 'official' backports [19:53] That another issue, yes [19:53] it seems we're running out of time, 7 minutes left [19:53] Heh, yes [19:54] can we perhaps summarize? we badly lack manpower, our processes seem to complex for the amount of requests [19:54] complex in the sense: too much overhead [19:54] We do lack manpower, and it is a bit disappointing that it wasn't possible to drum up the team [19:55] I was thinking that perhaps we could arrange a session once a week or so, and take a look at the queues, distribute the work and get going [19:55] but we need to be more than 2 ppl [19:55] perhaps some sort of motu school session or something could help with recruiting? [19:56] Perhaps [19:56] That would need a senior member of the team though :-) [19:56] indeed [19:57] ... and perhaps we need to revise the workflow, but that also needs participation of more ppl than 2 in the discussion [19:57] I'd need to familarize myself with backports again, I have to admit that I havn't processed a single request since years now [19:57] Heh [19:58] I have been doing quite some backporting for my local machines [19:58] perhaps we manage to catch jdong or ScottK and ask them for their opinion on the matter [19:58] Yes [19:59] ideally, we can come up on a 'backport triaging and processing howto for backport team members' or something [19:59] I suppose they will go and read the transscript of the meeting [19:59] good idea [20:00] ok. let's hope they'll read it [20:00] In principle, jdongs wiki page has most of the information, but it is aimed at both users and developers [20:00] yes, that can probably be split [20:00] I think so [20:00] there is really too much information there [20:00] do you have some time left to write some minutes of the last hour? [20:01] Yes, it should be split in documents for 1) users 2) testers 3) developers [20:01] oh, that's sounds good [20:01] I haven't thought about testers, but they are important as well [20:01] I guess it's basically users who want to take the trouble of reporting bugs [20:02] I haven't seen any bug reports from testers thoug [20:02] h [20:02] I think that's more a role description [20:02] you cannot really seperate users from testers from developers [20:02] What did you mean, if I have some time left? [20:03] s/left// :-) [20:03] Well, some ppl just want to know how to activate the archive [20:04] that's easy: convert bug to support request :-) [20:04] A few of them will also want to request backports [20:04] A few of them are willing to test and report back [20:04] ... and a handful of devs need to know the howtos :-) [20:05] anyway, time's up, I need to see after my wife now :-) [20:05] OK thanks for showing up siretart`!! [20:05] sure thing. thanks for your work on reviving ubuntu backports :-) [20:05] Thanks :-) See you later! === Keybuk_ is now known as Keybuk === Pendulum_ is now known as Pendulum === mc44_ is now known as mc44 === duanedes1gn is now known as duanedesign === lan3y is now known as Laney