[00:00] jaredthane: ok. for that particular request, it is best to package it as part of the existing php5 package, so the typical "intro to packaging" guides aren't going to help you there - you would need to dig into the php5 package specifically and understand how it's put together [00:02] slangasek: okay, do any simple, useful examples come to mind? [00:02] not to me, sorry [00:02] everything I use is already packaged :) [00:06] jaredthane: for places to help out with Ubuntu that don't involve creating new packages from scratch, there's https://launchpad.net/ubuntu/+bugs?field.tag=bitesize [00:07] * Fujitsu thinks the world must be coming to an end. [00:08] The RM helping in #-motu... [00:08] slangasek: thanks [00:08] Fujitsu: it makes me feel all warm and fuzzy inside [00:08] :-) [00:09] Fujitsu: that's why he got a +1 from me when going for motu after a few hours ;) [00:09] sistpoty: Heh, yes. [00:10] Fujitsu: if it's upsetting your world view that much, I can go away again ;) [00:10] Please don't. [00:11] RM? [00:11] release manager [00:15] any vim people around? [00:16] * Fujitsu is a vimmer. [00:16] LaserJock: just ask ;) [00:16] !ask | LaserJock [00:16] LaserJock: Don't ask to ask a question. Just ask your question :) [00:16] I'm trying to fix a bug involving vim-latexsuite [00:16] :P [00:16] Aha. [00:16] yeah yeah yeah [00:16] I haven't used -latexsuite in a while. [00:17] vim can't find the files [00:17] it installs to /usr/share/vim/addons/ [00:17] but that's not in vim's path [00:17] /var/lib/addons/ is [00:18] I'm wondering if there's some policy that would help me decide what to do [00:18] I would think that /usr/share/ would be the FHS place to put it [00:19] That's where it should go. [00:19] LaserJock: AIUI, there's some kind of vim policy (at least in Debian) that newly-installed add-ons shouldn't be enabled by default, to not trigger disgruntlement of other users? [00:20] hmm [00:20] apparently it used to work [00:20] which has disgruntled many vim+TeX users [00:20] now that it doesn [00:20] It did previously work, yes... [00:21] slangasek: It doesn't do anything too evil. [00:21] now, there is the vim-addon-manager package [00:21] which allows you to turn things off and on [00:23] I can see that policy for vim-scripts because people will pick and choose [00:23] but vim-latexsuite only does one thing [00:24] but I see what you're saying about multiple users and turning on systemwide [00:39] ok, I got it figured out, phew [00:40] Fujitsu: would this be an "Invalid" bug then? [00:42] LaserJock: What is the problem? [00:42] that latexsuite is not enabled by default [00:42] Ah. [00:42] which is now the vim policy [00:43] Probably Invalid. [00:50] DaveMorris: debian/copyright could be a bit more verbose about upstream copyright (copy one of the source files copyright notice verbatim there) [00:57] anyone getting HTTP 403 on securitu.u.c? [00:57] security.ubuntu.com* [00:58] joejaxx: yup, expected, should be cleared up shortly. [00:59] ok [01:01] joejaxx: 163042. [01:01] ok [01:08] um which package provides merge-buildpackage? [01:09] it's part of MoM. No Freely-available source package currently provides it. [01:10] ah i see, <3 MoM [01:10] well, unless you count grab-merge.sh [01:11] grab-merge.sh is available at http://merges.ubuntu.com [01:11] autoreconf -i [01:11] configure.ac:7: error: possibly undefined macro: AC_ENABLE_SHARED [01:12] ideas? [01:13] probably autotoolage scew. [01:13] err, skew, but screw, too. [01:13] pwnguin: do you have libtool installed? [01:14] and which version of automake is installed? [01:14] apparently not [01:14] hi crimsun btw ;) [01:14] sistpoty: that's the trick [01:15] hi sistpoty [01:15] you're welcome... /me is fighting automake at work as well *g* [01:15] well, i thought apt-get build-dep would get the build deps [01:15] pwnguin: autotoolising stuff generally requires the libtool&automake&autoconf stack [01:15] (which means that I'm far from having tamed automake yet *g*) [01:15] theres already a package, but i thought i'd build from svn [01:21] ugh whats the best way to do the merge process with pbuilder? [01:21] configure: error: Your intltool is too old. You need intltool 0.35.0 or later. [01:21] i'd rather not be installing a ton of build-depends on my main system :P [01:21] LordKow: pbuilder has a "login" command. [01:22] yea but how do i transfer files to the pbuilder environment from outside? [01:22] maybe i'll just write the patch from the package source and let upstream handle the merge =/ [01:23] LordKow: Just copy them over? The chroot is under /var/cache/pbuilder/build/. [01:24] ah duh i could have just looked at the mount output from outside of the env to figure that out, thnx [01:27] LordKow: if you do this often it's a good idea to set up a --bindmount so that you can always share stuff from your outside world :) [01:27] uh oh, jdong applied for -dev [01:27] yea going through the pbuilder man right now [01:27] time for revenge on the backports!!one [01:28] * Hobbsee waves [01:28] ha, luckily I needn't ask questions any longer, otherwise my first question would've been: "jdong: but you're on crack!" ;) [01:28] crimsun: lol :) [01:28] evening [01:29] jdong: I hope you mean --bindmounts. [01:29] minghua: yeah, those thingies :) [01:31] jdong's +1 will likely be my last vote as an MC member, heh [01:32] so crimsun makes me feel guilty again for starting a wave of retirings :( [01:33] * jdong hugs crimsun [01:33] sistpoty: mine was scheduled way back in July [01:34] crimsun: ha, I've been thinking about it earlier, just didn't write a mail yet :P [01:34] yeah, Daniel and I are going to wrap up, and then I'll be sending off the e-mail. [01:35] jdong: remember: use this power for good [01:35] it's sad to see an experienced member go from -council [01:36] crimsun: you mean "with great power comes great responsibility"? :) [01:36] sistpoty: that was my thought, yes. [01:36] (the crack one( [01:36] !jdong | jdong [01:36] jdong: jdong: yes, but you're FULL OF CRACK! [01:36] haha [01:36] sistpoty: well, it has been quite something for the first round. Looking forward to better things from the next MC. Turnover can be healthy. [01:37] crimsun: surely you cant leave. [01:37] Hobbsee: sure, I would just need to find another job [01:37] crimsun: sure it can, and I really hope for it (and did so when resigning..) nonetheless it does make me sad [01:38] crimsun: more alsa? [01:38] haha [01:38] there's no webfrontend for requestsync ? [01:39] tarzeau: sure, LP and enter your wish by hand ;) [01:39] sistpoty: i thought of a input field like a command line for it [01:39] um do i really need to use the merge-buildpackage / merge-genpackage script... it looks like i should just be able to build the package like I would any other [01:40] tarzeau: no, it's the other way round: requestsync is the frontend for filing a bug (with a specific title and content) on launchpad [01:40] sistpoty: yes and i wanted to just have a frontend for requestsync [01:40] since installing it on debian sid is like horribly not possible [01:40] LordKow: have a look at the scripts. it has a particular option on it [01:40] LordKow: no, you don't. e.g., I just edit shell command history and proceed. [01:40] tarzeau: uh....why? [01:41] ubuntu-dev-tools depends on python-launchpad-bugs (>= 0.2.14); however: [01:41] * Hobbsee notes that with frontends, more idiots will file them, and then we'll all have to close them. [01:41] tarzeau: having not used it ever, I go with "please sync () from unstable ubuntu override ok" and adhere to the policies in the rest of the bug. worked for me in the past ;() [01:41] tarzeau: it's a script. just nuke it from the package. [01:41] Hobbsee: ok i try that [01:41] exec dpkg-buildpackage -S -v0.2.3-2ubuntu1 "$@" <-- thats all merge-buildpackage does... its specific for each package but its 1 command :P [01:42] LordKow: yes, and you need to use -v0.2.3-2ubuntu1 in it [01:42] and once my manual sync request will no longer get processed, I'll either make a rebellion or will shut up forever (probably the second *g*) [01:42] (does special things with the source changes. [01:42] meaning, preserving (displaying) the relevant upstream changelog entries is a matter of policy. [01:44] i read the part about requestsync at https://wiki.ubuntu.com/SyncRequestProcess [01:44] what's target release? hardy for example? [01:44] the development release. so hardy, yes. [01:45] crimsun, do you know if aclock.app is in the process of being merged or not? its a 5 second thing with the control file [01:45] make sure you use -s, it's the sponsorship section [01:45] Hobbsee: that script fails for some reason, and i've got no clue of python [01:45] ....right. [01:46] no clue of debugging either, it appears. "fails for some reason", no reason given. *sigh*. [01:46] LordKow: generally, check https://bugs.launchpad.net/ubuntu/+source/$source_package_name/ [01:46] tarzeau: i'm not psychic, sorry. [01:46] Traceback (most recent call last): File "./requestsync", line 119, in ? [01:46] "There are currently no open bugs." guess not, thanks [01:46] LordKow: if you don't see a bug report requesting a merge/sync, then generally, no, it's not in the process. [01:46] debiancomponent = debian_component(srcpkg) [01:46] File "./requestsync", line 75, in debian_component [01:46] raw_comp = out.split('|')[2].split('/') [01:46] IndexError: list index out of range [01:46] oh, requestsync is possibly broken now, with the rmadison change, too [01:47] crimsun, well then i shall start the process [01:47] LordKow: excellent. [01:47] ah, no, it's not. the old behaviour still works. [01:48] tarzeau: weird. [01:49] what about a bot that takes syncrequests right in here? ;) [01:49] tarzeau: because if you make it like that, people think it's acceptable to mass file sync requests. [01:49] and tend to not check the changes first. [01:49] requestsync is not to be abused. [01:50] i see [01:50] and because they're signed. [01:50] tarzeau: if you make it easy, even like having that shell sript in there, people seem to use logic like "well, i fthere's a new version in debian, who cares about any ubuntu changes, lets just drop them all" [01:51] i've wanted to request two new packages [01:51] and this syncing stuff is all done fully manually? [01:52] new pacakges are done automatically [01:52] stuff that has ubuntu changes getting synced is manual [01:52] i see [01:53] not even half-automatic? [01:53] obviously. it needs checking [01:53] well, they have a script that then goes and syncs [01:53] but someone has to check if teh changes are still required, etc [01:53] i see [01:54] which is why making this stuff easy to run is suboptimal - because people dont do the work required to check if stuff is needed, first. [01:54] https://bugs.launchpad.net/ubuntu/+source/aclock.app/+bug/163165 why is this invalid? [01:54] Launchpad bug 163165 in aclock.app "Please sync aclock.app 0.2.3-2 (universe) from Debian unstable (main)" [Undecided,Invalid] [01:55] 16 Nov 07 18:54 Marco Rodrigues aclock.app: status New Invalid [01:56] oh its been synched sweet [01:56] yep. :) [01:56] still not an "invalid" report though :P [01:56] well, it is [01:56] if it has been synched why is it still showing on MOM? [01:56] MoM is not definitive [01:57] That bug got the version number wrong. Is it verbatim output from requestsync? [01:58] I believe it's actually correct. [01:59] according to the hardy-changes list, that is. [01:59] https://lists.ubuntu.com/archives/hardy-changes/2007-November/001713.html [01:59] so the times seem to link up correctly [01:59] mom is not always updated [02:00] so at the time the sync was requested, the synced source had not been published via the hourly run [02:03] I see. [02:05] gn8 everyone [02:15] Heya gang [02:33] hm weird dependency problems with balsa and an up-to-date pbuilder env [02:33] cant even build the version in the repos [02:40] LordKow: have you set up your pbuilder to use universe? [02:40] you know... i may not have. i did at one point but i think i redid the pbuilder env [02:41] it's not enabled by default, so if you don't remember, you most probably didn't. [02:42] well thats the thing. i remember doing it the FIRST time but not after i redid pbuilder ;) [02:50] this build should be more successful :p [02:52] siretart: wrt bug #159085, I'm assuming the new version is ABI/API compatible with all the gutsy reverse-deps? [02:52] Launchpad bug 159085 in gutsy-backports "please backport xine-lib_1.1.8-2ubuntu2 from hardy" [Undecided,New] https://launchpad.net/bugs/159085 [02:55] jdong: That's surely not happening. A good portion of Universe rdepends on xine-lib :) [02:56] RAOF: well I don't know enough about the Xine release cycle to understand what a 0.0.1 bump constitutes... [02:56] and since siretart filed the report, I am assuming he knows what he's doing :D [02:56] jdong: Oh, I thought we had 1.6 in gutsy. Ah, whoops. Yeah :) [02:58] wow, this apbs thing takes bloody forever to build [02:58] * jdong considers enlisting his macbook to build too :D [03:00] * RAOF suddenly realises why he's getting an obsolete nouveau package. s/gutsy/hardy/! [03:03] TheMuso: you have any idea what's going on in bug 158706? [03:03] Launchpad bug 158706 in gnunet-gtk "gnunet-gtk crashed with SIGSEGV" [Undecided,Fix committed] https://launchpad.net/bugs/158706 [03:08] Is anyone actually doing the deluge-torrent merge/sync? Is bug #139518 having anything done to it? [03:08] Launchpad bug 139518 in deluge-torrent "Please sync deluge-torrent 0.5.6.2-1 from debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/139518 [03:09] No one appears to have committed to it, RAOF. [03:10] i.e., it's all yours [03:10] * RAOF updates the bug status. [03:11] bug 163261 [03:11] Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New] https://launchpad.net/bugs/163261 [03:13] LordKow: careful. Your _source.changes doesn't adhere to Ubuntu policy regarding including all debian/changelog entries between the most recent merged Debian source package and the current one. [03:17] um, which ones are missing? [03:18] 2.3.19-1 and 2.3.20-1 [03:18] note that I'm referring to https://bugs.edge.launchpad.net/ubuntu/+source/balsa/+bug/163261/comments/1 [03:18] Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New] [03:19] s/edge\.// if you aren't a member of the LP beta testing team [03:19] oh i forgot -v [03:19] (correct [03:19] they're there its just a screwd up changes file, let me rebuild [03:19] crimsun: does backport bug #163033 look sane to you? [03:19] Launchpad bug 163033 in gutsy-backports "alsa-driver-1.0.15 and assorted newly minted alsa goodies" [Undecided,New] https://launchpad.net/bugs/163033 [03:20] jdong: not particularly [03:20] do i need to rebuild the package or can i just comment and say "the changelog is complete, i just forgot -v in the changes"? [03:20] crimsun: that was my gut feeling. Can you briefly comment on the bug report why it's not a good idea? [03:21] <-- lazy :p [03:21] jdong: namely, what does symptoms does the reporter experience [that are fixed in 1.0.15 final] that the linux-backports-modules-$(uname -r) package in gutsy doesn't? [03:21] jdong: s/does// [03:21] $1, that is [03:22] crimsun: ah, so any missing alsa patches can be done via linux-backports-modules? [03:22] jdong: correct, and Tim's/Ben's slated to upload the latest shortly, which contains 1.0.15 final plus a dmic fix for certain Dells [03:23] crimsun: thanks for the info! [03:23] np [03:23] [not to mention it's of no real benefit to pull in the "changes" to alsa-base and linux-sound-base, which is really what backporting would achieve in light of the l-b-m updates] [03:24] agreed [03:26] who tends to libotr2? [03:26] no one. It's a direct sync from Debian. [03:26] or, technically, "MOTU" cares for it. [03:27] there's a backport request for hardy->gutsy on libotr and it has reverse-deps with gaim, kopete, and others and I wasn't sure of the compatibility [03:27] crimsun, does my new changes make ubuntu policy happy? see last comment :) [03:28] so, I guess, my question is if anyone here is familiar with libotr? :) [03:28] wow, from 3.0.0 (+cvs) to 3.1.0? ... [03:28] LordKow: looking now. === czessi_ is now known as Czessi [03:29] crimsun: the increment looks uneasy, and the person who filed the report is a fresh account so I'm inclined to just flat-out reject it unless someone familiar with otr can tell me this is safe. [03:30] hehe [03:30] well, when you're a MOTU, you get to test it, too! ;) [03:30] yes as a MOTU you are a massive tool [03:31] :D [03:31] 76 files changed, 6133 insertions(+), 5567 deletions(-) [03:31] gee.... not invasive at all [03:32] well, it may not be on the magnitude of, say, azureus or xserver-xgl... [03:33] xgl *may* be going away for hardy. [03:33] As drivers get good enough to make it more of a hinderance than a help. [03:33] that would be excellent. [03:34] with regard to bug 163261, do i need to attach the new dsc, orig src and diff? they are the same just re-signed [03:34] Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New] https://launchpad.net/bugs/163261 [03:34] (same as what is attached that is) [03:34] RAOF: let's hope that happens :) [03:35] LordKow: you were able to drop the *_DISABLE_DEPRECATED comments in {libbalsa,libinit_balsa,src}/Makefile.* ? [03:36] LordKow: (you wouldn't need to reupload a new source package. My comment regarding debuild -v is largely informative.) [03:37] was i able? MOM was. those were dropped upstream i believe [03:38] if they are legitimately dropped, please note that in debian/changelog [03:38] (bddebian was the latest to touch balsa and noted as much in the changelog) [03:39] What'd I do wrong now? [03:39] bddebian: hi. Nothing wrong. [03:39] :-) Hi crimsun [03:41] those DISABLE_DEPRECATED comments are there [03:42] i guess i dont quite understand what you are getting at. [03:42] LordKow: ok. Perhaps I'm being obtuse regarding the procedure. [03:42] wow pbuilder-satisfy-depends-dummy is REALLY slick! [03:42] well, i'd prefer to get the procedure 100% correct so ... what are you getting at? :P [03:43] LordKow: in the Ubuntu-specific changes listed in debian/changelog [in gutsy's balsa source package], note the top two (most recent) Ubuntu entries. [03:44] LordKow: because your merged source package [for hardy] will be a new upstream balsa version, you need to ensure that all Ubuntu-specific changes noted in the most recent source package are still relevant [03:45] LordKow: regardless if they are relevant, you need to note in the merged source package that either they have been dropped (and state a rationale) or they have been retained [03:48] * tonyyarusso googles [03:49] so what you are saying is... if i keep those comments in the makefiles (noted in 2.3.17-1ubuntu2 changes) i still need to report that I'm keeping the makefile comments, or remove them and mention that they were completely removed? [03:49] LordKow: correct [03:49] i thought the changelog was for changes only. im not changing anything by leaving those comments there am i? [03:50] LordKow: so that when you do something with it next release, you dont have to read 10 billion changelog entries, and wonder what you did, and why you did them, and if they're still relevant. [03:51] okay i'll go ahead and drop the comments and modify the changelog to mention those removals [03:54] yay gutsy-backports is all triaged [03:54] * jdong cringes at the look of feisty-backports [03:54] * Hobbsee goes to dump more crack in there, then. [03:54] er, what im saying is i'll keep the comments in the files :) [03:54] sorry confusing myself [04:09] " * Merge from debian unstable, remaining changes: - Keep our maintainers in debian/control and debian/control.in - Retain *_DISABLE_DEPRECATED comments" [04:09] LordKow: that's the idea. [04:09] if a person wondered about the comments they could search for DISABLE_DEPRECATED in the changelog and get there instantly [04:10] precisely. [04:10] now, how do you attach more than 1 file to a single comment... or include it as the comment? [04:11] i see [04:11] ;p [04:12] ok, 4 hours of backports triage for one night is quite enough [04:12] * jdong moves on to something else [04:14] jdong: now fix real bugs. [04:14] :) [04:14] haha [04:14] * jdong follows up on his gtkpod-aac bug [04:15] jdong: adding crack != fixing bugs. [04:16] okay hopefully the version i just uploaded to bug 163261 passes [04:16] Launchpad bug 163261 in balsa "New upstream release 2.3.20" [Undecided,New] https://launchpad.net/bugs/163261 [04:18] heh, I had forgotten that ESR uses [a ]Ubuntu[ base] [04:18] he, too, has been bitten by the atrocious HDA bugs [04:23] wait do I subscribe motu-uvf or u-u-s for a Universe SRU? [04:24] the latter [04:24] (hopefully you aren't pulling in an entirely new upstream version for an SRU!) [04:25] crimsun: lol not this time, this time it's a fairly small debdiff [05:05] whoo I think I wrangled another gtkpod-aac bug to the ground [05:05] * jdong hopes he didn't just jinx himself [05:08] should two pending SRU's on a package be combined into one? [05:12] generally, no. [05:13] if, however, the changes are orthogonal and well tested, then it's possible. [05:14] crimsun: so one should be verified/uploaded first, then the second one is done on top of that? [05:19] jdong: ideally, yes, but if the conditions are as described above, then it can be argued into one upload. [05:20] jdong: it all lies in how it's presented and how the changes are made : ) [05:21] crimsun: well, they are two independent bugs in gtkpod-aac. One involves reverting MP4 Group metadata handling to Feisty's version's behavior, another involves cherrypicking a SVN fix for not being able to add tracks to a local repository. [05:21] as I said, completely different :) [05:22] I'd say that's fairly safe to combine [05:22] no xserver-xgl-magnitude ones, though ; ) [05:23] they're both fairly small debdiffs and easily reviewable [05:29] arg. why does xmlGetProp() return attributes? [05:29] would it be so hard to name things according to the standard? =( [05:40] G*** ***** ****ING *******! [05:40] if shutil.move() errors out when a destination exists, I'm gonna impale myself [05:42] no phew it works [05:42] please save the cutting for the emo kids [05:45] WHOO! two birds one stone with gtkpod-aac :) [05:49] persia: hi [05:49] Hello s1024kb [05:50] persia: hey, you up for finishing some gtkpod-aac goodness with me or busy? :) [05:51] jdong: I actually don't have an iPod, nor do I use the package: what do you need? [05:51] persia: no iPod necessary, I just need some sponsorship on a Hardy upload and also a SRU [05:51] no iPod is needed even for verification [05:52] jdong: Is the bug in the sponsors queue? That's about third on my list of things right now, and I'd prefer to catch it then (if someone else doesn't first). [05:53] persia: yeah, I just wanted to make sure I didn't confuse the sponsor queue with my ambivalence [05:53] jdong: Ambivalence? [05:53] persia: I see you already got that 135178 doesn't need sponsoring anymore [05:54] persia: and I've opened #145506 for a Hardy sponsor [05:54] jdong: Ah. Yes, I was subscribed to that one from my last look, so received the notice when you requested it be dropped from the queue. [05:54] bug #145506 [05:54] Launchpad bug 145506 in gtkpod-aac "gtkpod-aac does not allow adding local tracks, claims iPod is not loaded (gutsy)" [Undecided,In progress] https://launchpad.net/bugs/145506 [05:54] persia: and I've opened bug #163283 that is a SRU containing the previous two fixes rolled in gutsy-proposed format [05:54] Launchpad bug 163283 in gtkpod-aac "[SRU/Gutsy]: Two patches for gtkpod-aac" [Undecided,New] https://launchpad.net/bugs/163283 [05:55] the ambivalence was deciding if those two patches should be handled in one or two SRU's, and crimsun swayed me towards one :) [05:55] I just wanted to verify that I didn't leave out any important information for the SRU [05:55] persia: i am in my last steps of my package merging, almost done, i want to ask you a question: from where (which file) i can find the changes of the debian version, and i can add them to the changelog of the last ubuntu version i should make now? [05:56] I'm generally in favor of having as few updates to a package as possible, with wrapped fixes. [05:56] jdong: So 145506 should be declined for gutsy? [05:56] persia: that is correct. 163283 should be the one going into gutsy [05:56] 145506 only needs to go into Hardy [05:57] s1024kb: The changes from the last Debian version are documented in debian/changelog in the last Debian version, and can be extracted with debdiff or interdiff between the Debian version the last Ubuntu version was based upon and the last Debian version. [05:58] jdong: Declined. I'll dig into the patches when I hit the queue (if they are still there). [05:58] persia: ok, thanks so much for your time :) [05:59] persia: thanks [05:59] jdong: No problems. I like to keep the queue clean, in the hopes that this inspires all the sponsors :) [05:59] hehe :) [06:08] I noticed that Launchpad's build servers don't use pbuilder. What is it that they do use? [06:09] LucidFox: sbuild [06:09] LucidFox: https://help.ubuntu.com/community/SbuildLVMHowto may be useful if you want to replicate that: such a setup has been working well for me. [06:09] (the wonderful, wonderful world of sbuild) [06:10] eww, this script has "race condition" written all over it [06:10] good thing I decided to not ship it in gutsy [06:12] persia: ah, you're here [06:13] LaserJock: Yes. Sorry: unexpected activities last night. prepping things for you is 2nd on my current todo list. [06:13] persia: I just had an idea about REVU wilst taking a shower [06:13] LaserJock: What's that? [06:14] well, I'm thinking perhaps a 2 step system could be employed and perhaps work with your mentoring thing [06:14] I was sort of thinking about how we do bugs [06:14] LaserJock: Could you expand? I've wary of mixing mentoring with other processes: I think that there are lots of people who do well without mentors. [06:15] so the 1st step would be "triage", basically going down a checklist similar to what you wrote -motu about [06:15] being lintian clean, basic things, and builds [06:16] then second step would be an actual thorough review for the acks [06:16] now, I was thinking that the 1st step would be a nice activity for the mentees in Step 2 of the mentoring program to do [06:17] I'm not sure if this is too complicated or red-tape laden though [06:17] LaserJock: There's nothing that stops non-motus from giving reviews via ORC now. [06:17] ORC/IRC [06:17] ScottK: no, but I was thinking in a more formal way [06:17] as in we have a triaged flag [06:17] that they can set [06:18] which would bump the priority [06:18] Right, but since the mentoring program is totally optional, I'm not sure how to work that. [06:18] well, it wouldn't be strictly tied to mentoring program [06:18] LaserJock: That makes some sense, and I like it. I'd like to do it much more like we do bugs, and ignore the relationship to the mentoring program. [06:18] I'm just thinking "MOTU Hopeful" here [06:18] Essentially, allow package check assignment, subscription, etc. [06:18] somebody who knows how to use pbuilder and lintian [06:19] persia: but I think it'd be an excellent excersice for Step 2 mentees [06:19] LaserJock: Right. I agree that most Contributors could likely do reviews, and that having a better mechanism for them to do so on the reviewing site would be nice. [06:20] None of the people who I've worked with through what I'd proposed as "Step 2" needed nay help figuring out what to do: they just needed a little help determining how to promote their activities, and how to build the basis for an application. [06:21] persia: well, I was thinking it'd be a good way for them to "show their stuff" and get a little reward for it [06:21] Rather, anyone who can generate a good candidate revision, do merges well, etc. can probably help review some of the packages. I believe there is some discussion about opening comments to all Contributors, if the ordering logic can be kept sane. [06:21] but if you don't think it'd be useful fine [06:22] well, but see I don't particularly like just opening comments [06:22] as it's a bit difficult to follow, IMO, when everybody's just adding comments [06:22] LaserJock: It's not that I don't think it would be useful, it's that I believe the appropriate time is between "stage 1" and "stage 2", and that many people won't require mentoring. [06:22] perhaps [06:23] I was just thinking it would work well with your mentoring scheme [06:23] I think comments can work, as long as it is clear that only reviewing comments are accepted. Social pressure can be brought to bear on people who aren't providing good reviews. [06:23] give them something to contribute to that a) makes a difference and b) helps us out [06:24]