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