#ubuntu-reviews 2010-05-17
<dholbach> good morning
<nigelbabu> dholbach: hola :)
<dholbach> hey nigelb
<dholbach> just updating all the blueprints :)
<nigelbabu> Just saw that
<nigelbabu> I did some ground work for cleansweep and potential actions that we could do
<dholbach> nice
<nigelbabu> http://people.ubuntu.com/~nigelbabu/operation-cleansweep
<nigelbabu> just see how far fetched they are ;)
<nigelbabu> vish: re:strace
<nigelbabu> I said that because he didn't even bother to copy-paste from the documentation, which worries me :/
<vish> nigelb: hi.. ooh :s
<nigelbabu> thats the reason why I gave -1 overall
<nigelbabu_> dholbach: Im at work right now but perhaps we can have a chat in around 1.5 to 2 hours
<dholbach> sounds good to me
<dholbach> I'll be quite busy until then
<nigelbabu_> I'd like to get blueprint for cleansweep ready.  So much to do :)
<vish> dholbach: hi.. ;)
<dholbach> hey vish
 * vish had fun time getting lost in Brussels with dholbach :)
<dholbach> vish: yeah, I had a great time too :)
<nigelb> dholbach: hey, so you're ready for the planning?
<dholbach> nigelb: give me a few mins
<dholbach> nigelb: ok, better now :)
<dholbach> nigelb: sorry for keeping you waiting
<BlackZ> hey dholbach
<dholbach> hey BlackZ
<dholbach> BlackZ: sorry, didn't get to your mail yet
<dholbach> all a bit hectic trying to catch up with stuff
<vish> dholbach: hi.. for Bug #566996 i had subscribed the main sponsors after i had mentioned it to pitti who mentioned that and since the change is simple enough , with no regressions...
<ubot3> Malone bug 566996 in humanity-icon-theme "Humanity in KDE does not display volume icons." [Low,Fix committed] https://launchpad.net/bugs/566996
 * vish was hoping to get that uploaded as sru soonish ;)
<dholbach> you can just subscribe "ubuntu-sponsors"
<dholbach> maybe you can prod somebody in #ubuntu-desktop
<vish> righto.. neat
<vish> ty
<effie_jayx> hey all
<effie_jayx> been checking the patches left but mayority are kinda hard to test, is there going to be another patch day, new commers like me could use some help at times, or just asking here is enough
<cyphermox> effie_jayx, don't hesitate to ask here, there's usually someone who can answer questions
<nigelb> dholbach: sorry, I lost power.  a huge thunderstom hit me
<dholbach> nigelb: is everything OK now?
<nigelb> yep. better
<dholbach> do you want to have a quick chat now?
<nigelb> yep :)
<dholbach> awesome
<dholbach> skype or here on irc?
<nigelb> anything is fine.
<dholbach> ok, so about the cleansweep tag
<dholbach> bdmurray said that it's very costly because it will send a mail out for 2000+ bugs
<maco> yipes
<dholbach> so including duplicates, multiple subscribers it's probably going to be like 10000 mails, very likely more than that
<nigelb> ok, so how do we keep track?
<maco> O_O
<dholbach> I think we should work on the moving target instead
<dholbach> also: we can't be sure somebody just removes the tag in error
<nigelb> In that case, dont tag, just subscribe ~ubuntu-reviewers to the subset that we're usually interested it
<nigelb> s/it/in
<dholbach> ok, I think that should be fine
<nigelb> and so we know all the subscribed open bugs are the part of the moving target
<dholbach> ok, so the code for the "meter" should be fine
 * dholbach has a look at your list of other stuff that needs doing
<nigelb> can you make the meter show all the subscribed bugs not in any of the bucket? I haven't looked into the code
<dholbach> already_reviewed_patches = int(ubuntu.searchTasks(has_patch=True,
<dholbach>                             status=open_status,
<dholbach>                             tags=reviewed_tags,
<dholbach>                             tags_combinator='Any')._wadl_resource.representation['total_size'])
<dholbach> this should be it
<dholbach> (that's the negation)
<nigelb> awesome :)
<nigelb> Also, can you add code to the meter to show the number of bugs left?
<nigelb> that way I can give uwn a place to access the remaining number (I've talked to them about it at UDS)
<dholbach> sure
<nigelb> I'll talk to stephan over the week about documentation
<nigelb> we'll work on clearing everything by weekend :)
<dholbach> I'll make a note to do that
<nigelb> we can rotate blogging responsibilities amoung the team so each person gets to do a weekly report
<dholbach> sounds good to me
<nigelb> I'll get to work on osme graphics
<dholbach> osme graphics?
<nigelb> um, some ;)
<dholbach> ah ok :)
<dholbach> awesome
<dholbach> this is going to be sweet
<nigelb> and I've kept daily target at 15 bugs
<nigelb> its not *very* hard, but its not going to be easy
<dholbach> we need to keep it on everybody's radar
<nigelb> yes, perhaps remind everyone to just do one patch per day
<dholbach> we'll work something out
<nigelb> :)
<dholbach> is there anything else that needs clarification?
<nigelb> the subscription thing...we keep the team subscribed is what I vote for
<nigelb> I wish persia was here.  we were scheudled to argue about it ;)
<dholbach> haha
<dholbach> we can start an email conversation
<dholbach> alright - I'll try to put some more work into this tomorrow
<nigelb> persia and email - I'd rather not.  I'll catch him when he comes on line
<dholbach> ok :)
<dholbach> I'll call it a day for today - I need to sort out a few other things still
<nigelb> I'll get to work on my action items tonight and we'll see what progress we've made tomorrow :)
<dholbach> have a great day and thanks a bunch!
<dholbach> awesome
<nigelb> have a good night :)
<dholbach> you too
<dholbach> bye!
<nigelb> effie_jayx: no, we wont have a patch day
<nigelb> but if you have a qestion you can ask here.  we idle here all the time, someone should get back to you
<persia> nigelb: Hey.  Sorry about that: I had some equipment issues.
<nigelb> persia: oh yay! you're back on :)
<persia> nigelb: So, what's the topic that you've carefully not emailed me about?
<nigelb> persia: ok, so we have a scheduled argument pending :D
<persia> Do you want to have it tonight, or tomorrow sometime?
<nigelb> im ok anytime :)
<persia> OK.  Let's start now, and if either of us gets tired, we can postpone :)
<nigelb> haha
<nigelb> ok, so arguments for subscription
<nigelb> (a) gives an option for folks to opt out per bug
<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
<nigelb> ok, oppose those, I'll think of a few more in the mean time :D
<persia> (b) is enough to convince me: it indicates that subscription is a useful differentiator for worklist queries.
<nigelb> aha :)
<persia> (a) seems useless to me, as most folks aren't subscribed to the mailing list.
<nigelb> not mailing list
<persia> Right.
<nigelb> I mean opt out of review per bug
<nigelb> like a responsible core-dev is on it and he feels we don't need to work on it
<persia> My main critique of having a team was that we ought come up with a reason why a team was more useful than tag management.
<nigelb> the main usefulness is (b0
<nigelb> (b)
<persia> Right.
 * nigelb is surprised we ended early.
<nigelb> Also, my client is giving you a green color, used to be red.
<persia> Now, to question that: is subscription to achieve that goal better than a tag-based workflow?
<persia> Funny.  My interaction with my client changed, but the actual IRC client hasn't been modified in weeks.
<nigelb> tag based workflow is good, but not perfect.
<nigelb> We have a lot of corner cases where bug is at user level but fix is at kernel level.
<nigelb> Can't really modify the script to ignore them, need manual intervention
<nigelb> well, not a lot, but around 5 or 6 at least
<persia> so, if we didn't have subscription, the script would just add tags.  Removing a tag can be done by anyone.  Unsubscribing a team is a restricted activity.
<persia> So the actual work is *exactly* the same: it's just a decision whether the mechanism is unsubscribe or remove a tag.
<persia> That said, script implementaiton is easier if it's subscription-based :)
<nigelb> I like that idea.  That way there would be an identity around the team :)
<nigelb> Perhaps we should go in that direction. Especially since I have a task assigned to create an identiy around the team
<persia> See, that's the reason I suggested consideration of alternate methods.
<persia> I think that associating identity with the reviewers is a bad thing: I think we'll get more reviewers with less conflict if reviewing is an activity engaged in by other groups that have identity (various development teams, bug control, etc.)
<nigelb> So, we unsubscribe the team if the patch tag is changed to any of the patch* tags
<nigelb> ok, I'm confused.
<nigelb> So we promote review as an activity?
<persia> I think that would result in faster growth and sustainable size.
<persia> Because otherwise people may ask "Are you a bug triager or a patch reviewer?".  I'd like to avoid that question.  I don't think any of the answers help us.
<nigelb> So, we don't go into the subscription issue because that would mean not being in the team would block contribution?
<persia> Unless we believe there is sufficient value in the subscription to make that cost affordable :)
<persia> (b) above is a very strong argument.
<nigelb> Someday, you'll talk in simple english.
<nigelb> Half the time I go 'ok, what the heck is he trying to say?'
<persia> So, there is a cost to 1) having an identity for the team, rather than it being an activity, and 2) using subscription because this is a restricted activity.
<persia> There are benefits to each of identity and use of subscription for workflow management.
<nigelb> I'd rather have it an activity.  Then we can say, folks, review one patch per day.
<persia> The benefits need to outweigh the costs in order for either of those choices to be the correct choice.
<persia> That was what I was thinking :)
<nigelb> And people would be happy to.  Being in team, etc would irritate devs who just want to help for one or 2 bugs
<nigelb> Our progress needs to be onnly 12 bugs per day or more, we should be well on way to target.  I've kept target at 15 bugs per day for now.
<nigelb> So, we'll make the final call as no identity for team but as activity?
<persia> 15 seems like a good number.  high enough that we can miss a few days, but low enough that most people won't be bothered to do the math to notice it's wrong.
<persia> That's my preference, if you're comfortable with that model.
<nigelb> I already planned stuff around it :)
<persia> Note that I think patch review is *important*, but I just don't think we want folk who self-identify *as* reviewers, but instead encourage devs & triagers to review.
<nigelb> Like sponsors right?
<persia> My experience with the dev/triager identity differentiation is not positive: in the beginning, devs triaged, and triagers were proto-devs, but now I'm unsure if many devs even look at bugs at all
<nigelb> Except for package set folks
<persia> Hrm?  Without exception.  I know of some packageset folks who work within a packageset, but don't use LP as an input source for things to do.
<nigelb> I see the Desktop Team very active on bugs though
<persia> Yes.  Many developers are very active in bugs.
<persia> Just not all of them.
<nigelb> That way.  Yeah.
<persia> I don't know if this is related to the separation of identity, or just a result of the volume of work to be done, but I suspect it to be a combination of the two.
<nigelb> I think its both.  I haven't triaged bugs for long.  Its mostly lack of time.
<nigelb> When I get time, I only triage patches or look for bugs to fix.
<nigelb> And I'm not a dev yet, so I can imagine what the devs go through
<persia> Makes sense.
<persia> Well, some of them *do* still triage, which is a good thing.
<nigelb> What I do get around to is helping other triagers in -bugs when they're stuck.
<persia> Anyway, it feels to me like we both have had separate paths to similar conclusions since we scheduled our discussion, and so had already reached consensus :)
<nigelb> hehe
<persia> Have a good night, and good luck.  From the bits I heard here and there at UDS, it sounds like you've signed up for a good bundle of work, but the results ought be fantastic.
<nigelb> Yes, and bundle is actually an understatement.
<persia> heh
<nigelb> I'm going to withdraw from a few teams this cycle though.  Some stuff just needs to go.
<persia> I know how that is :)
<nigelb> :)
#ubuntu-reviews 2010-05-18
<dholbach> good morning
#ubuntu-reviews 2010-05-19
<dholbach> good morning
<effie_jayx> dholbach: hello sir
<dholbach> hey effie_jayx
#ubuntu-reviews 2010-05-20
<dholbach> good morning
<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
<nigelb> Also, a few other reasons, but most compelling was that.
<nigelb> Now, how do I announce the thing? send a mail to the mailing list or just update documentation (well, its already updated)
<dholbach> update documentation and update the blueprint that it's sorted out
<dholbach> as part of the generall outreach we'll let people know
 * dholbach takes the dog for a walk
<bdmurray> I don't understand why the team should continue to be subscribed one the required work is done.
<nigelb> bdmurray: define work is done
<bdmurray> the patch was reviewed
<nigelb> actually originally, I wanted the team unsub'd because I didn't know LP was smart enough to do negation on tags
<nigelb> but the complication is patch reviewed would mean a lot of things
<bdmurray> but what other active work is required of the team for these bugs
<nigelb> the team being subscribed helps with numbers
<nigelb> Hold on, I had 2 reasons which I gave persia, let me dig that up
<nigelb> (a) gives an option for folks to opt out per bug
<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
<nigelb> bdmurray: ^
<nigelb> thoughts?
<bdmurray> While it is possible to search for bugs w/o a tag that is not a default search in Launchpad at all
<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
<bdmurray> and if more tags to exclude are created your query will be wrong
<nigelb> well, the query is already in the workflow
<nigelb> and we can update the query if needbe
<bdmurray> the query is in the workflow in the wiki?
<nigelb> yep
<bdmurray> having specially crafted queries or cases makes it that much harder for people to participate
<nigelb> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow
<bdmurray> I really strongly believe that participation should be as easy as possible
<nigelb> This isn't that tough, this is easier in fact
<nigelb> lol, the best part.... a few months back we both had the same discussion
<nigelb> only this time its reversed.  I wanted to unsub then and you wanted to keep the team subscribed
<bdmurray> I don't think a starting point of https://bugs.edge.launchpad.net/~ubuntu-reviewers/+subscribedbugs is easier than
<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
<nigelb> so you're saying we should use the long query?
 * nigelb is confused
<hyperair> tinyurl ftw
<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
<bdmurray> that way somebody could go to bug.launchpad.net/~ubuntu-reviewers and click on subscribed bugs and have what they need
<bdmurray> not have to go to the wiki page every time to make sure their bug query is right
<nigelb> I have only 2 words, deja vu
<nigelb> Now, the itch I have with unsubscription is this
<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
<nigelb> so, I'd like to be able to ask 5 random folks to help with 3 bugs and show them the workflow
<nigelb> now we have the unsubcription thing, we'd have a little bit of issue because someone in the team has to unsubscribe
<nigelb> not doing that at all and using lp queries help us ease that requirement to participate in the activity
<bdmurray> just as there is a script to subscribe the team there could be one that unsubscribes the team
<nigelb> ok, in that case I dont mind
<nigelb> btw, looking at bugs.launchpad.net/~ubuntu-reviewers would show all tasks, easier way is to do the uery
<nigelb> bdmurray: is there a way to give me *all* the action on bugs which we are subscribed?
<nigelb> i mean mails for all the action
<bdmurray> I don't think so but would need to look into it.
<nigelb> it would be nice to know who's doing what
<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
<nigelb> ouch
<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?
<bdmurray> That'd require some more research
<nigelb> in that case, just ignore me.  I was being too hopeful.
<bdmurray> there are only 13 subscribers so maybe they'd be cool with it or able to filter it easily
<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
<nigelb> and I'd really like to have a place to send communication
<nigelb> bdmurray: Monday is the opening for cleansweep
<nigelb> I was thinking if you can subscribe the reviewers to all the bugs without the date criteria but not add patch tag
<nigelb> then we can just keep dropping it into buckets
<nigelb> and then unsubscribe the team
<bdmurray> wouldn't that fill up bugs.launchpad.net/~ubuntu-reviewers ?
<nigelb> oh grr, I thought of that when were planning to work with the queries
<nigelb> in that case, nothing would show up in the query
<nigelb> and we'd be working on the subscribed bugs one by one
<nigelb> now things are getting complicated
<nigelb> bdmurray: now I'm totaly confused on the subscribe team vs unsubscribe team :/
<nigelb> can you give me a day to think and write you a mail about my conclusions?
<effie_jayx> is there a way to find out why a patch won't apply..? I am getting an error like
<effie_jayx> make: *** [debian/stamp-patched] Error 1
<effie_jayx> Is there a way to see a verbose output
<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.
<effie_jayx> persia: thanks I found the issue by trying to apply it manually
<effie_jayx> fixed, not the change is trivial
<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
<effie_jayx> or if that is never the case
<effie_jayx> sorry If I don't make much sense
<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.
<effie_jayx> the patch was not needed since upstream code had the changes
<effie_jayx> therefore when I tried to apply I couldn't. upstream had taken the changes
<effie_jayx> package is ontv, the patch is a small fix for python hashtags that are hardcoded to python 2.5
<effie_jayx> pacakge FTBFS and I think I found a way to make it work
<effie_jayx> now I think I could send the patch to debian and wait for a sync don't you think?
<effie_jayx> it is a tiny bit
<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.
<effie_jayx> persia: and with ubuntu what do I do? request for a merge or wait till debian fixes and sync?
<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.
<persia> After DIF, applying patches is more useful.
<effie_jayx> persia: thanks :)
<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
<effie_jayx> now Iam confused
<persia> Which part is confusing?
<effie_jayx> I pullt the source via grab-merge, to see if the merge was still needed.
<effie_jayx> ontv
<effie_jayx> I no issues in the report
<effie_jayx> I double checked with changelogs and chekcing the source
<effie_jayx> and it seems fine
<effie_jayx> I tried building the dsc and got FTBFS
<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)
<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
<effie_jayx> and this is confusing becasue I thought the source code dir stayed untouched
<effie_jayx> persia: does that make sense?
<persia> There may be some irregularities in how the patching is done.
<persia> You might want to run lsdiff against the diff.gz
<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)
<effie_jayx> persia: lsdiff shows nothing
<effie_jayx> lsdiff ontv_3.0.0-3ubuntu2.diff.gz
<effie_jayx> well I guess I will check back on this later
<effie_jayx> the way it is it FTBFS and I have commented on mom
<effie_jayx> but you cleared me from my confusion
<effie_jayx> source stays untouched
<persia> lsdiff -z is needed for .gz files.
#ubuntu-reviews 2010-05-21
<jono> nigelb, ping?
<persia> Might be a bit early yet (5:00 local time there)
<nigelb> jono: pong
<jono> hey nigelb
<nigelb> hello :)
<nigelb> ugh, I hate bugs with 25 differnt tasks just because its the same problem but they all have different solutions :?
<nigelb> :/
<nigelb> hyperair: hey, got a min to review a patch for indicator thingy?
<hyperair> nigelb: not at the moment. maybe this weekend.
<hyperair> nigelb: what's it about anyway/
<nigelb> hyperair: that big bug with lots of duplications and some 100 tasks about icons having a color aroudn them
<hyperair> that's no indicator, that's notification area!
<nigelb> oh, yeah, that one
<nigelb> whatever, ayatana territory :D
<hyperair> lol
<hyperair> not really. ayatana is gearing towards purging the notification area
<hyperair> nigelb: what app is the patch for anyway?
<hyperair> nigelb: and does it work?
<nigelb> I think it should be rejected, I wanted your thoughts ;)
<nigelb> bug 403135
<nigelb> best of luck reading the comments :D
<persia> Actually, the "ugly colors around the icons in the notification area" class of bugs should be fixed in the individual applications.
<persia> It's just adding appropriate alpha-channel hinting to the icons used for the notification area.  Most of these should be sent upstream.
<persia> Trying to hack around it in the notification implementation is not ideal.
<nigelb> yes, because each of them have a separate fix and not one magical fix for every application
<nigelb> Most of the fixes are in individual apps. This patch is from upstream I think but I totally cannot figure out their repos
<nigelb> So, I figured out a way for Project Cleansweep to make a worklist, finally
<nigelb> On one hand, we have the usual subscription, adding a patch tag and subscribing us.
<nigelb> So, we'd want the same script subscribing us to the same subset without adding a patch tag and without the date.
<nigelb> Just run it once and all the subscribed bugs will be the ones we have to clear out
<persia> I think that's risky, because lots of old bugs have the patch tag.
<nigelb> Well, I'm getting to that ;)
<nigelb> Let me get the query
<nigelb> https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-reviewers&field.tag=-patch-needswork -patch-forwarded-upstream -patch-forwarded-debian -patch-accepted-upstream -patch-accepted-debian -patch-rejected-upstream -patch-rejected-debian -patch-rejected&field.tags_combinator=ALL
<nigelb> That ^ should work
<persia> That mixes new and old bugs.
<nigelb> so all bugs that are not in buckets
<persia> Which means that you don't have a nice line in the sand to target.
<nigelb> Unfortunately, it was decided to draw a line in sand
<hyperair> persia: actually banshee's notif-area upstream has the appropriate alpha-hinting, but for some reason it doesn't work in lucid.
<nigelb> Instead, I'll be counting everything after a particular date.
<nigelb> So, we know how many new came in
<hyperair> persia: considering that the same code works perfectly in karmic for most of these apps, i'm thinking there's a regression happening in gtk+, or the theme engines
<hyperair> persia: or even gnome-panel
<persia> hyperair: Ah, yeah, that would be a regression.
<hyperair> persia: and it's been happening over and over for years.
<hyperair> persia: every time we have a new ubuntu release, this regression happens again, and gets fixed somewhere along the line.
<hyperair> just that lucid was unfortunate enough to not get a fix
<persia> nigelb: I think that's extra work for you, and not as visible to others, but if you like.  Were I doing it, I'd modify the script to add the "cleansweep" tag and not subscribe anyone, and tell cleansweepers to remove the cleansweep tag when they hit the bug./
<hyperair> i don't know who or what fixes it, or even why it occurs.
<hyperair> we have cleansweepers?
<hyperair> and wasn't cleansweep a trademarked name by some windows product or something...
<nigelb> persia: I thought of that first.  But that would generate a tremendous amoutn of mail.  At least 1500 bugs with a bunch of subscribers and dups, etc
<xnox> hyperair, we are in totally different business =) unless that trademark is owned by Microsoft.....
<nigelb> hyperair: Norton
<hyperair> xnox: there we go. Norton.
<xnox> =(
<nigelb> well, this is not a product name
<hyperair> shouldn't we change the name to avoid violating the trademark?
<nigelb> Its a Project Name
<hyperair> it isn't?
<hyperair> it's the same isn't it, for trademarks?
<hyperair> if i went and created a team called firefox, that had not relations to mozilla firefox, mozilla would scream.
<nigelb> Oh grr
<nigelb> lets think of that later
<nigelb> Now, workflow
<nigelb> persia: That line, i.e. the new bugs with patches can be measured using a script.
<persia> Yes, but while it can be measured, it cannot easily be seen.
<nigelb> I'll ask dholbach to make an image for us that changes every day like the meter
<persia> So there's no way for anyone to know how close they are to target except by reading whatever posts you choose to make.
<nigelb> Showing the stats is also on my worklist items.  I'm still the processing of figuring out how
<nigelb> *in the process of
<nigelb> dholbach made a meter image, I'm thinking of making multiple meters with different numbers, so all those should be satisifed and it can be displayed on some blog for the project, etc
<nigelb> or everyone can display it
<nigelb> Well, at least I figured out why colors changed.  My client restarted.
<nigelb> persia: will you be around later in the night?
<persia> My intention is to not be (I want to get up early), but I may well :)
<nigelb> persia: I'd like you to be around when I talk to brian today, it would be nice if you were there or I'll just take the talk to mail.
<persia> Hrm.  We've a awkwardness here.  I'm not sure if I'll be around at that point, so I can't usefully inform you if you can send mail or not, which forces you to not send mail, just in case, which then makes you unhappy (regardless of whether I'm around later).
<persia> I'll suggest you just send mail, if you're likely to do that anyway, as this will be easier.  If you and I both happen to be around later, the discussion can be based on the mail.  If not, then the mail can stand alone.
<nigelb> Ok.
<persia> And I don't have to feel like I should stay up, and you don't have to wonder if I will :)
<nigelb> I'll be staying for a very simple reason, I fell asleep in the afternoon and jumped up thinking its morning, so I doubt if I'll sleep at usual time.
<persia> heh.  I know how that goes.
<persia> At least for me, it happens that way more often this time of year because of the weather.
<nigelb> Yeah, weather is awesome here too.  A little bit rainy, so kind of cool.  Very pleant to hear the rain and sleep :)
<duanedesign> nigelb: was going to put start putting together some information for the Development FG. Are there any other links other thank what is in the topic that might be good?
<duanedesign> than*
<nigelb> duanedesign: I'm working on updating the docs, so you can start linking up by next week
<duanedesign> nigelb: that'll be perfect. Thank you
<nigelb> :)
<nigelb> duanedesign: also, think of the apport hook writing project which I'm starting to coordinate
<nigelb> The idea is to get hooks for as many main applications as possible, especially the ones against which bugs are reported
<nigelb> You must've seen mails in the bugsquad list
<duanedesign> nigelb: i will! All that stufff would be perfect to get the development FG connected up better with the community.
<nigelb> duanedesign: yep.  so now you have 2 activity which the community wants help.  If you guys want to take over the apport project I'd be happy with that too.
<duanedesign> ill update the councils 'bug' on this and get feesback. Thank you
<duanedesign> feedback*
<nigelb> ok :)
<nigelb> BlackZ: if you see a new bug with a patch attached, you need not tag it patch and subscribe reviewers.  It will be done automatically
<nigelb> and if its not, let me know.  we'll have to look at what happened there
<BlackZ> OK nigelb
