| === maco is now known as maco2 | ||
| === maco2 is now known as maco | ||
| dholbach | good morning | 07:10 |
|---|---|---|
| nigelb | dholbach: so, me and persia made a call on whether to keep team subscribed or not. We've decided to keep the team subscribed always so as to keep patch review as an activity | 13:25 |
| nigelb | Also, a few other reasons, but most compelling was that. | 13:26 |
| nigelb | Now, how do I announce the thing? send a mail to the mailing list or just update documentation (well, its already updated) | 13:26 |
| dholbach | update documentation and update the blueprint that it's sorted out | 13:52 |
| dholbach | as part of the generall outreach we'll let people know | 13:52 |
| * dholbach takes the dog for a walk | 13:53 | |
| bdmurray | I don't understand why the team should continue to be subscribed one the required work is done. | 15:31 |
| nigelb | bdmurray: define work is done | 15:32 |
| bdmurray | the patch was reviewed | 15:32 |
| nigelb | actually originally, I wanted the team unsub'd because I didn't know LP was smart enough to do negation on tags | 15:33 |
| nigelb | but the complication is patch reviewed would mean a lot of things | 15:33 |
| bdmurray | but what other active work is required of the team for these bugs | 15:34 |
| nigelb | the team being subscribed helps with numbers | 15:34 |
| nigelb | Hold on, I had 2 reasons which I gave persia, let me dig that up | 15:35 |
| nigelb | (a) gives an option for folks to opt out per bug | 15:36 |
| nigelb | (b) someones we have 2 tasks on linux bug and we get sub'd which I manually remove, if we have no unsub option, it would be very difficult to remove those bugs off the work queue | 15:36 |
| nigelb | bdmurray: ^ | 15:37 |
| nigelb | thoughts? | 15:37 |
| bdmurray | While it is possible to search for bugs w/o a tag that is not a default search in Launchpad at all | 15:42 |
| bdmurray | so if you go to the reviewers team page you'd have to craft a special query to figure out the ones you are really interested | 15:42 |
| bdmurray | and if more tags to exclude are created your query will be wrong | 15:42 |
| nigelb | well, the query is already in the workflow | 15:42 |
| nigelb | and we can update the query if needbe | 15:43 |
| bdmurray | the query is in the workflow in the wiki? | 15:47 |
| nigelb | yep | 15:47 |
| bdmurray | having specially crafted queries or cases makes it that much harder for people to participate | 15:47 |
| nigelb | https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow | 15:47 |
| bdmurray | I really strongly believe that participation should be as easy as possible | 15:48 |
| nigelb | This isn't that tough, this is easier in fact | 15:48 |
| nigelb | lol, the best part.... a few months back we both had the same discussion | 15:48 |
| nigelb | only this time its reversed. I wanted to unsub then and you wanted to keep the team subscribed | 15:49 |
| bdmurray | I don't think a starting point of https://bugs.edge.launchpad.net/~ubuntu-reviewers/+subscribedbugs is easier than | 16:05 |
| bdmurray | https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers&field.tag=patch%20-patch-needswork%20-patch-forwarded-upstream%20-patch-forwarded-debian%20-patch-accepted-upstream%20-patch-accepted-debian%20-patch-rejected-upstream%20-patch-rejected-debian%20-patch-rejected&field.tags_combinator=ALL | 16:05 |
| nigelb | so you're saying we should use the long query? | 16:06 |
| * nigelb is confused | 16:06 | |
| hyperair | tinyurl ftw | 16:07 |
| bdmurray | no, we should not use the long query and the team should be unsubscribed after any "reviewed" tags are added to the bug report | 16:09 |
| bdmurray | that way somebody could go to bug.launchpad.net/~ubuntu-reviewers and click on subscribed bugs and have what they need | 16:09 |
| bdmurray | not have to go to the wiki page every time to make sure their bug query is right | 16:10 |
| nigelb | I have only 2 words, deja vu | 16:14 |
| nigelb | Now, the itch I have with unsubscription is this | 16:14 |
| nigelb | I'd like reviewing patches be promoted as an activity. A daily target of 15 bugs to be reviwed gets us a long way generally | 16:15 |
| nigelb | so, I'd like to be able to ask 5 random folks to help with 3 bugs and show them the workflow | 16:15 |
| nigelb | now we have the unsubcription thing, we'd have a little bit of issue because someone in the team has to unsubscribe | 16:16 |
| nigelb | not doing that at all and using lp queries help us ease that requirement to participate in the activity | 16:16 |
| bdmurray | just as there is a script to subscribe the team there could be one that unsubscribes the team | 16:19 |
| nigelb | ok, in that case I dont mind | 16:19 |
| nigelb | btw, looking at bugs.launchpad.net/~ubuntu-reviewers would show all tasks, easier way is to do the uery | 16:20 |
| nigelb | bdmurray: is there a way to give me *all* the action on bugs which we are subscribed? | 16:21 |
| nigelb | i mean mails for all the action | 16:22 |
| bdmurray | I don't think so but would need to look into it. | 16:22 |
| nigelb | it would be nice to know who's doing what | 16:23 |
| bdmurray | the only easy way to do that would be to allow all e-mail from launchpad to the mailing list which might fill some inboxes | 16:24 |
| nigelb | ouch | 16:24 |
| nigelb | is there a chance of being able to create a collect maling list into which we can collect this and then evaluate the data later like with bugsquad? | 16:25 |
| bdmurray | That'd require some more research | 16:26 |
| nigelb | in that case, just ignore me. I was being too hopeful. | 16:27 |
| bdmurray | there are only 13 subscribers so maybe they'd be cool with it or able to filter it easily | 16:27 |
| nigelb | no, the thing is either send all the mails or no mails from bugs. right now a lot of people dont subscribe to the list | 16:28 |
| nigelb | and I'd really like to have a place to send communication | 16:29 |
| nigelb | bdmurray: Monday is the opening for cleansweep | 16:54 |
| nigelb | I was thinking if you can subscribe the reviewers to all the bugs without the date criteria but not add patch tag | 16:54 |
| nigelb | then we can just keep dropping it into buckets | 16:55 |
| nigelb | and then unsubscribe the team | 16:55 |
| bdmurray | wouldn't that fill up bugs.launchpad.net/~ubuntu-reviewers ? | 16:56 |
| nigelb | oh grr, I thought of that when were planning to work with the queries | 16:57 |
| nigelb | in that case, nothing would show up in the query | 16:57 |
| nigelb | and we'd be working on the subscribed bugs one by one | 16:57 |
| nigelb | now things are getting complicated | 16:58 |
| nigelb | bdmurray: now I'm totaly confused on the subscribe team vs unsubscribe team :/ | 16:59 |
| nigelb | can you give me a day to think and write you a mail about my conclusions? | 17:01 |
| === yofel_ is now known as yofel | ||
| effie_jayx | is there a way to find out why a patch won't apply..? I am getting an error like | 18:40 |
| effie_jayx | make: *** [debian/stamp-patched] Error 1 | 18:40 |
| effie_jayx | Is there a way to see a verbose output | 18:40 |
| persia | effie_jayx: I often just try applying the patch myself manually. The other option is to start a local build (debuild -b) and then see if the output is lying around as a result. | 21:38 |
| effie_jayx | persia: thanks I found the issue by trying to apply it manually | 21:44 |
| effie_jayx | fixed, not the change is trivial | 21:44 |
| effie_jayx | persia: the patch is cdbs and it is not needed, so I deactivated the patch. but I wonder if the source was patched already | 21:46 |
| effie_jayx | or if that is never the case | 21:46 |
| effie_jayx | sorry If I don't make much sense | 21:46 |
| persia | I'd need more context to be certain, but I believe the best practice is to try to look at the relevant code where you applied the patch, and compare agaisnt the version where the patch author applied the patch. | 21:47 |
| effie_jayx | the patch was not needed since upstream code had the changes | 21:48 |
| effie_jayx | therefore when I tried to apply I couldn't. upstream had taken the changes | 21:48 |
| effie_jayx | package is ontv, the patch is a small fix for python hashtags that are hardcoded to python 2.5 | 21:49 |
| effie_jayx | pacakge FTBFS and I think I found a way to make it work | 21:50 |
| effie_jayx | now I think I could send the patch to debian and wait for a sync don't you think? | 21:50 |
| effie_jayx | it is a tiny bit | 21:51 |
| persia | If the patch is already upstream, no need to send the patch to Debian: if you want to be helpful to Debian, just file a bug on the Debian package with a note that it's fixed upstreeam and a pointer to the upstream commit. | 21:53 |
| effie_jayx | persia: and with ubuntu what do I do? request for a merge or wait till debian fixes and sync? | 21:55 |
| persia | Depends on how much you want to do: that the bug is fixed is a good thing :) If you want it definitely fixed in Ubuntu, you might wait, or you might pull the upstream patch and apply. Given that it's before DIF, it makes more sense to wait to me. | 21:57 |
| persia | After DIF, applying patches is more useful. | 21:58 |
| effie_jayx | persia: thanks :) | 22:00 |
| effie_jayx | persia: I checked debians source package and it seems fine there, they do need the patch, by checking http://ftp.debian.org/debian/pool/main/o/ontv/ontv_3.0.0-4.dsc | 22:30 |
| effie_jayx | now Iam confused | 22:30 |
| persia | Which part is confusing? | 22:30 |
| effie_jayx | I pullt the source via grab-merge, to see if the merge was still needed. | 22:30 |
| effie_jayx | ontv | 22:30 |
| effie_jayx | I no issues in the report | 22:31 |
| effie_jayx | I double checked with changelogs and chekcing the source | 22:31 |
| effie_jayx | and it seems fine | 22:31 |
| effie_jayx | I tried building the dsc and got FTBFS | 22:31 |
| effie_jayx | the only patch there fails to apply during build because it is not needed in the source code (Which I did not touch) | 22:32 |
| effie_jayx | I deactivate the patch and all builds in ubuntu, but checking the source package from debian. they do need the patch to fix the reference to python 2.5 | 22:33 |
| effie_jayx | and this is confusing becasue I thought the source code dir stayed untouched | 22:35 |
| effie_jayx | persia: does that make sense? | 22:37 |
| persia | There may be some irregularities in how the patching is done. | 22:37 |
| persia | You might want to run lsdiff against the diff.gz | 22:37 |
| persia | Beyond that, I'd have to pull the package and dig, and I don't have a good environment for that right now (but ought have one in a couple hours) | 22:38 |
| effie_jayx | persia: lsdiff shows nothing | 22:39 |
| effie_jayx | lsdiff ontv_3.0.0-3ubuntu2.diff.gz | 22:39 |
| effie_jayx | well I guess I will check back on this later | 22:39 |
| effie_jayx | the way it is it FTBFS and I have commented on mom | 22:40 |
| effie_jayx | but you cleared me from my confusion | 22:40 |
| effie_jayx | source stays untouched | 22:41 |
| persia | lsdiff -z is needed for .gz files. | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!