codfectionknome, thanks for replying, yes I would to contribute in development (coding) area12:03
knomecodfection, have you read this? http://xubuntu.org/contribute/development/13:11
knomecodfection, i know it's a bit scarce, but it gives an idea what we're ding13:11
knomecodfection, and you'll likely want to be in touch with bluesabre, ochosi and/or Unit193 - they can help you forward with development stuff13:12
knomeor krytarik, whose client is not here right now13:13
codfectionthanks a lot knome 14:26
knomeno worries14:35
knomeand if you have any general questions, feel free to ask here14:35
knomeand specific questions too - other people than those that i mentioned might be able to help as well14:36
knome(me included)14:36
flocculantknome: hopefully we'll get dates on burndown, release schedule had dates so I added them to roadmap17:31
knomeflocculant, yes, that'll do it - thanks19:45
flocculantknome: though it doesn't - updated a short bit ago - does the tracker look for topic-foo-xubuntu - cos if so you called z xubuntu-z-roadmap, there being no topic-z 20:07
knomeit looks for the umbrella blueprint20:11
knomewhich is set to xubuntu-z-roadmap (you can figure that out because it actually loads all the stuff)20:11
knomeit just doesn't look at the blueprints all the time20:11
knomei don't remember how scarcely it checks this - it might be once a day or once a week20:12
knomethis is the main reason i'd like to steer away from using blueprints as the source - if we had all the information in an internal database, we wouldn't need to do "expensive" API calls20:13
knomeor figure out when we need to do the calls..20:13
flocculantso why not do it when the cache updates?20:25
knomebecause we have no idea when the launchpad cache updates20:25
knomethat's the problem20:25
flocculantobviously not making sense here :)20:26
knomeprobably not ;)20:26
flocculantWork item data from Launchpad. The cache was last updated at Mon, 28 Nov 2016 20:00:12 +0000.20:26
flocculantit says20:26
knomethat's the work items cache20:26
knomethat's updated hourly20:26
knome...but it's a different API call20:26
flocculantright - so why not check that different call?20:27
knomebecause it "costs"20:27
knomeand processing power20:27
flocculantof something owned by canonical? 20:28
knomeso if we did that hourly, then the site would be sluggish hourly20:28
knomesomething paid by canonical, but that's not the point20:28
flocculantdo it less often then20:28
knome...i am ;)20:28
ochosicodfection: hey! if you need any pointers lemme know. best starting place is usually a small bug that annoys you and that you are consequently motivated to fix. anyway, feel free to get in touch20:28
flocculantjust more often than it is at the moment :p20:28
knomewell, i'd rather just make the switch to internally-managed stuff20:29
knomethere is some code for that ready, but time has been scarce20:29
flocculantand how do you intend to manage internally - and how will it work with lp stuff it needs to read? 20:29
knomeanyway, it just doesn't make sense to check something more than once a day that changes maybe twice a cycle20:29
flocculantlike bugs for instance20:29
knomethose will still be updated with cronjobs, but at least then there's less to update20:30
knomeand since at that point we need some authorization, we can let authorized people press a button that updates the bug on request20:30
knomeauthorized probably bound to ~xubuntu-team20:30
flocculantso - more work for people so that machines don't need to? 20:31
knomethe same work - you need to add the work items to launchpad now20:31
knomein the future, you'd just add them to the tracker20:31
flocculantanyway 20:31
flocculantthis is probably something that the team should have some input on 20:32
flocculantpersonally I don't see a gain :)20:32
flocculantI really don't see the point I guess :)20:33
knomei don't understand why the team would be opposed to something that makes things work more smoothly20:33
flocculantnot sure how this makes it more smooth? 20:33
knomefor example, the dates on the burndown would be updated instantly20:33
knomeand there could be a more user-friendly form to add the dates20:34
knomeand the work items20:34
knome(and tbh that's what i'm going to do)20:34
flocculantwell whatever20:34
flocculantobviously my input is wasted as you appear to have made up your mind that we'll change something again20:35
knomeit's not whatever - i see what you're saying, and i can see that it's hard to see how things could be better, but i know20:35
flocculantthe tracker is awesome 20:35
flocculantlove it - actually makes something easier 20:36
knomepeople in the team have agreed for a long time that launchpad is slow etc. - not only related to the tracker-related thigns - so why not steer away from it?20:36
knomeagain, the process to add work items and dates and whatever would be very similar - but everything would be handled internally in the tracker20:37
knomeeg. no more work for you, but you get benefits20:37
flocculantI'd love to know how re-inventing the wheel here AND linking to lp bugs is going to work20:37
knomewe're not reinventing the wheel20:38
flocculantyes you are 20:38
knomethe launchpad work items feature is not really a work items feature20:38
knomeit's a text box you can edit20:38
knomeall the work item handling stuff is done by our tracker and the ubuntu tracker20:38
flocculantthat's one small facet of it isn't it20:38
flocculantif the bug bp works like it does now - then that's my only argument :)20:39
knomein the first stage of the migration, probably so20:40
flocculantif your argument is based on making canonical infrastructure work more - then I don't care about that :)20:40
knomethe biggest problem with launchpad managing the work items data is that it doesn't make a difference between the different work items20:40
flocculantfirst stage?20:40
knomewhat that means is that once it's "validated" that the user and work item status is an approved user/state, it's just text20:41
flocculantis this actually written down anywhere for team to read? 20:41
knomeso we have no way to track what happens to that exact work item20:41
knomeso we have to load and parse all of the data again and again20:41
knomeno, but so far nobody has been interested in reading such documents20:42
flocculantbut that doesn't actually hurt us does it?20:42
knomeit does.20:42
knomefor example, on the burndown, there are sometimes those obviously wrong days20:43
flocculantknome: also - I'm not arguing for the sake of it here - I really want to understand what we'd gain :)20:43
knomethat's just one of the symptoms20:43
knomeif we had the data in our own DB, we could store the daily data about every single item20:43
flocculantsee this is where I get confused20:43
knomeon the history tab, the dates when the items are completed are the best guesses20:43
knomeif we had the data in our own DB, we could tell people something is closed 3 times but (re)opened 4, to know it's a recurring issue20:44
flocculantbecause all of the real data IS on launchpad surely? the bugs, the package changes etc etc20:44
knomethere is no way to ask launchpad to tell what the work item status was yesterday20:44
knomeor if a bug status was open or closed any given day20:45
knomewe know the *last* day when a bug was closed, but if it has been reopened and reclosed, we again only know the last day20:45
flocculantso you are looking purely at the data that we physically input on any given blueprint currently?20:45
knomemostly, yes20:46
knomewe want to be linked to launchpad with the bugs anyway20:46
knomebut again, that's a lot less API calls than what we are doing now20:46
knome(and having less API calls isn't the only reason - it's also simpler code to run if we have most of the data internally)20:46
flocculantwhich is what's confusing me I suspect - as I'm looking more 'globally' - not just what we input, but what occurs on bugs/packages ...20:46
knomethat we'll still have to fetch from launchpad20:47
knomewell, not "have to" but "want to"20:47
flocculantfor example - the blueprints don't really get updated promptly - just when someone remembers something is DONE or POSTPONED20:48
flocculantconsequently anything on the tracker about 'that' is wrong20:48
flocculantas far as the Timeline goes - does it actually matter if it's not precise?20:49
knomebut what if changing the status was two clicks on the tracker instead of going to launchpad and manually editing the work item box - then wait an hour for it to be updated on the tracker - instead of being instant?20:49
flocculantstill people would do it eventually20:49
knomein that case the question is do we need the timeline anyway?20:50
knomelet me give you another example20:50
knomeon how it's stupid that launchpad doesn't track work items as items but a textbox20:50
knomeconsider we'd have an item [flocculant] Pick noce: DONE20:50
knome(typo intentional)20:50
knomenow, it's done today20:50
knomeone week from now20:50
knomeyou go to fix the typo20:51
knomethe second you do that, we have no way of knowing it's the same work item20:51
knomebecause items aren't items, they are just text20:51
flocculanton the tracker20:51
knomeno, on launchpad20:51
knomeon the tracker, they are actually items20:51
flocculantobviously if you subscribe you could follow the change20:51
knome...but as they are not items on LP, they aren't "really" items on the tracker either20:52
knomeyes, for humans that's easy20:52
knomebut the tracker has no way to verify that20:52
knomeit can't know that it's the same item, ever20:52
flocculantI can understand that point20:52
knomeso basically if we track items on the tracker internally20:52
knomewe could then change anything to anything20:52
knomeand all of the items' history would follow along20:52
knomeas it would have an internal ID that was always the same20:53
flocculantI get that20:53
knomethat's one more symptom of getting the work item data from LP20:53
knomebugs are a bit easier as they have bug numbers that act as consistent ID's20:53
flocculantok - but QA uses the tracker in a more global way - not just what's written - but changes to status for example20:54
flocculanthow do we intend to keep that if the bug bp is some internal thing? 20:54
knomethere are (at least) two ways to go about that, and i have no idea which one we're going to use, but they are (in a simple form):20:55
knome1) keep doing the bug blueprint as we do now, and getting the bug statuses as we do now20:55
knomesimple, right?20:55
knomeso one concept in between: tags20:56
knomecurrently, work items are either development, qa, bugs, artwork or whatever20:56
knomeif we save data internally, one work item can have multiple tags, concerning both artwork and qa for example 20:56
knomeso now:20:56
knome2) add a work item within a tag (or two) and tell the tracker it's a bug #N20:56
knomethe tracker keeps updating the bug data from LP periodically20:57
knomeso in essence, just remove the bug blueprint handling and move it to the tracker - but keep on reading the bug DATA from LP20:57
flocculantat which point we are surely back at the reason you want to move away? calls to the lp api thing20:58
knomein version 1), we first need to do one API call to launchpad to ask which bugs are attached to the bugs blueprint (or any blueprint, tbh)20:59
knomethen we need to make another API call to ask what's up with those bugs20:59
knomeif the bug numbers were saved internally, we'd do with one API call for *all* bugs in *any* blueprints20:59
knomeor in our case, in any *tags* really, as we wouldn't have the blueprints20:59
flocculantthe whole thing just sounds like robbing peter to pay paul to me :p21:00
knomenah. the "less API calls" is just a side-benefit really21:00
knomeand it makes the code much more clean - eg. less prone to errors and network failures and what not21:00
flocculantso what's the main benefit to us as a team then? 21:01
knomein our discussion, i've pointed out several21:01
knomeone more that we haven't talked a lot yet is the UI21:01
flocculantmmm - none of those sound like big things to me though :)21:01
knomethe new UI will let you change statues with a few clicks instead of typing text manually as i said21:01
flocculantknome: well the UI I'm sure we're likely to agree :D21:01
knomeit also lets you add work items to *any* tag (currently: blueprint) from the same URL21:02
knomebasically just type the work item description, select a tag and assignee and you're done21:02
knomenone of the benefits alone are huge - but combined, they make a difference21:04
flocculantknome: right21:06
flocculantsorry for hassling you :)21:06
knomeno worries21:06
flocculantas you know - I'm not good with change for change sake :p21:07
flocculantakxwi-dave: something I forgot to mention - 16.04.2 hits mid January21:07
knomeflocculant, http://temp.knome.fi/xubuntu/.tracker/tracker-new-items.png21:09
knomeflocculant, when you click "new": http://temp.knome.fi/xubuntu/.tracker/tracker-new-items-edit.png21:10
flocculantknome: that looks pretty much how I expected it too look :)21:10
knomemultiple tags - clickable - so click on one of them and you see all items for that tag21:11
flocculantknome: so ... start of a cycle, someone has to start a new cycle blueprint currently21:12
knomeand all sub-blueprints21:12
flocculantthey can copy paste pretty much the base from the last one - edit a few lines and bob's your uncle21:12
knomewith internal stuff, you just add a row in the "releases" tab (similar to this) and we're set21:12
flocculantnow they'll need to input each one - leave kbd, click buttons21:13
knomewe can write a code snippet that copies all not-finished work items from release X to Y21:13
knomethat's actually really easy with the all internal stuff...21:13
flocculantwithout actually doing one - I can't tell which would be quicker21:14
flocculantbut I'm not convinced from what I do from cycle to cycle :)21:14
flocculants/with what21:14
knomethe code snippet would allow you to do it by selecting source and destination cycles, then click "go"21:14
flocculantok 21:14
knomeit would *totally* be faster21:15
knomeand less prone to human errors21:15
flocculantDecide on milestone participation21:15
knomeright, so things you always want to do even if they are done21:15
flocculantgets' copied and changed from done to todo21:15
knomewe could allow a batch input of work items21:15
flocculanthow would having to type the whole thing out each time be quicker? 21:16
flocculantobv things from dev perspective are different cycle to cycle21:16
knomesimilar to the textbox in LP, but once entered, tracked like real work items21:16
flocculantbut artwork for instance - do the wallpaper - same for every cycle21:16
knomefwiw, i basically type that out every cycle :P21:16
knomebut i can see QA being a bit more draggy with that21:17
flocculanthah - well I copy/paste and edit done to todo :)21:17
knomeso we'll just allow some sort of CSV input, no worries with that21:17
knomeone more cool thing we can do at some point is to add a feature that takes a meeting minute url21:17
flocculanton the other hand there are tasks that the only change is x to y to z and flopping done/todo back and forth21:18
knomeand greps all the action items there21:18
knomeand saves them as work items :P21:18
flocculantcould there be a set of always have these items? 21:18
flocculantha ha 21:18
knomei'd probably do that with the CSV input21:18
knomeso basically just keep a wikipage with the items you want21:18
knomeand do one copy-paste per cycle21:19
flocculantand then things we put in whiteboard - where will they live? 21:19
knomethat's a good question with no good answer yet21:19
flocculantyea - that would work - csv doodah21:19
knomebut there are definitely ways to save that kind of information21:19
knomesay, every tag can have a description = blueprint can have a whiteboard21:20
knomethen just show them nicely somewhere21:20
knomeeg. a "tag summary page"21:20
knomei've used the whiteboard mostly for adding stuff that is related to a specific work item21:21
knomeso for me, it would be much more useful if every WORK ITEM could have an extendable description21:21
knome(and that's doable...)21:21
knomebut again, we can allow tag-based descriptions too21:22
flocculantI tend to use it for things that 'are' work items which get repeated that necessarily finish at the same time as we publish the final announcement21:22
knomeso maybe those could be in the wiki or sth too21:22
flocculantso wouldn't ever get DONE - what would be the point :021:23
flocculantoh boo21:23
knomewell, what i mean is basically anywhere that is within the same domain/UI as the tracker21:23
knomebut they STILL can be in the tag description :P21:23
flocculantbecause the wiki's a nightmare and the xubuntu one I don't like :p21:23
knomewhy don't you like the xubuntu one?21:24
flocculantcan't remember offhand21:24
knomesigh :)=21:24
flocculantI tend to shy away from it lol21:24
knomewell, we're moving towards it :P21:24
knomeso if you don't like it, open the mouth now and we can potentially do something about it :P21:25
flocculantwhy do you think most of the qa stuff is on dev pages ....21:25
knomei have no idea ;P21:26
flocculantknome: there are obviously differences between the 2 wiki's - quirks if you like - but I was having trouble doing things last time21:26
knomeif it's related to media management - i understand :P21:26
flocculantcan't remember exactly what - some plugin needed or something 21:26
knomewell, the next time you bump into it, let me know...21:26
flocculantwon't be 2016 ... 21:27
flocculantI know I was doing the release note - or trying to 21:28
knomeright, some includes...21:28
knomewe'll figure it out21:28
flocculantnah - that doesn't work on the u.w either :p21:28
knomeit does... but it's wonky :P21:29
flocculanttoo wonky for me to worry about :)21:29
knomebut i guess the thing i'm trying to do with all this tracker work is make things that are too wonky less wonky so people can access them and thus enable things that weren't possible before21:29
flocculantI know that :)21:30
knome(along with doing fun/educative projects)21:30
knomeeducative for me that is :P21:30
flocculantI suspect what we're really talking about *here* are the corner-cases21:30
knomenothing is better than doing something in FOSS first, with time and thought, then scoring a work project to do the same and almost copy-paste the solution and take the money :P21:31
flocculantyea - always good to keep the head working for sure :)21:31
flocculantha ha ha 21:31
knome(especially when it's accidental - and yes, that has happened)21:31
flocculantwell - as always good to talk to you about something like this - but I only sat here for 5 minutes 90 minutes ago lol21:32
* flocculant wanders off for the night 21:33

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!