| codfection | knome, thanks for replying, yes I would to contribute in development (coding) area | 12:03 |
|---|---|---|
| codfection | like* | 12:03 |
| knome | codfection, have you read this? http://xubuntu.org/contribute/development/ | 13:11 |
| knome | codfection, i know it's a bit scarce, but it gives an idea what we're ding | 13:11 |
| knome | *doing | 13:11 |
| knome | codfection, and you'll likely want to be in touch with bluesabre, ochosi and/or Unit193 - they can help you forward with development stuff | 13:12 |
| knome | or krytarik, whose client is not here right now | 13:13 |
| codfection | thanks a lot knome | 14:26 |
| knome | no worries | 14:35 |
| knome | and if you have any general questions, feel free to ask here | 14:35 |
| knome | and specific questions too - other people than those that i mentioned might be able to help as well | 14:36 |
| knome | (me included) | 14:36 |
| flocculant | knome: hopefully we'll get dates on burndown, release schedule had dates so I added them to roadmap | 17:31 |
| knome | flocculant, yes, that'll do it - thanks | 19:45 |
| flocculant | cool | 19:45 |
| flocculant | knome: 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 |
| knome | no | 20:11 |
| knome | it looks for the umbrella blueprint | 20:11 |
| knome | which is set to xubuntu-z-roadmap (you can figure that out because it actually loads all the stuff) | 20:11 |
| knome | it just doesn't look at the blueprints all the time | 20:11 |
| knome | i don't remember how scarcely it checks this - it might be once a day or once a week | 20:12 |
| knome | this 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 calls | 20:13 |
| knome | or figure out when we need to do the calls.. | 20:13 |
| flocculant | so why not do it when the cache updates? | 20:25 |
| knome | because we have no idea when the launchpad cache updates | 20:25 |
| knome | that's the problem | 20:25 |
| flocculant | mmm | 20:26 |
| flocculant | obviously not making sense here :) | 20:26 |
| knome | probably not ;) | 20:26 |
| flocculant | Work item data from Launchpad. The cache was last updated at Mon, 28 Nov 2016 20:00:12 +0000. | 20:26 |
| knome | right. | 20:26 |
| flocculant | it says | 20:26 |
| knome | that's the work items cache | 20:26 |
| knome | that's updated hourly | 20:26 |
| knome | ...but it's a different API call | 20:26 |
| flocculant | right - so why not check that different call? | 20:27 |
| knome | because it "costs" | 20:27 |
| flocculant | who? | 20:27 |
| knome | time | 20:27 |
| knome | and processing power | 20:27 |
| flocculant | of something owned by canonical? | 20:28 |
| knome | so if we did that hourly, then the site would be sluggish hourly | 20:28 |
| knome | something paid by canonical, but that's not the point | 20:28 |
| flocculant | do it less often then | 20:28 |
| knome | ...i am ;) | 20:28 |
| ochosi | codfection: 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 touch | 20:28 |
| flocculant | just more often than it is at the moment :p | 20:28 |
| knome | hah | 20:28 |
| knome | well, i'd rather just make the switch to internally-managed stuff | 20:29 |
| knome | there is some code for that ready, but time has been scarce | 20:29 |
| flocculant | and how do you intend to manage internally - and how will it work with lp stuff it needs to read? | 20:29 |
| knome | anyway, it just doesn't make sense to check something more than once a day that changes maybe twice a cycle | 20:29 |
| flocculant | like bugs for instance | 20:29 |
| knome | those will still be updated with cronjobs, but at least then there's less to update | 20:30 |
| knome | and since at that point we need some authorization, we can let authorized people press a button that updates the bug on request | 20:30 |
| knome | authorized probably bound to ~xubuntu-team | 20:30 |
| flocculant | so - more work for people so that machines don't need to? | 20:31 |
| knome | nope. | 20:31 |
| knome | the same work - you need to add the work items to launchpad now | 20:31 |
| knome | in the future, you'd just add them to the tracker | 20:31 |
| flocculant | anyway | 20:31 |
| flocculant | this is probably something that the team should have some input on | 20:32 |
| flocculant | personally I don't see a gain :) | 20:32 |
| flocculant | I really don't see the point I guess :) | 20:33 |
| knome | i don't understand why the team would be opposed to something that makes things work more smoothly | 20:33 |
| flocculant | not sure how this makes it more smooth? | 20:33 |
| knome | for example, the dates on the burndown would be updated instantly | 20:33 |
| flocculant | well | 20:34 |
| knome | and there could be a more user-friendly form to add the dates | 20:34 |
| knome | and the work items | 20:34 |
| knome | etc. | 20:34 |
| knome | (and tbh that's what i'm going to do) | 20:34 |
| flocculant | well whatever | 20:34 |
| flocculant | obviously my input is wasted as you appear to have made up your mind that we'll change something again | 20:35 |
| knome | it'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 know | 20:35 |
| flocculant | the tracker is awesome | 20:35 |
| flocculant | love it - actually makes something easier | 20:36 |
| knome | people 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 |
| knome | again, the process to add work items and dates and whatever would be very similar - but everything would be handled internally in the tracker | 20:37 |
| flocculant | yea | 20:37 |
| knome | eg. no more work for you, but you get benefits | 20:37 |
| flocculant | I'd love to know how re-inventing the wheel here AND linking to lp bugs is going to work | 20:37 |
| knome | we're not reinventing the wheel | 20:38 |
| flocculant | yes you are | 20:38 |
| knome | the launchpad work items feature is not really a work items feature | 20:38 |
| knome | it's a text box you can edit | 20:38 |
| knome | all the work item handling stuff is done by our tracker and the ubuntu tracker | 20:38 |
| flocculant | that's one small facet of it isn't it | 20:38 |
| flocculant | if the bug bp works like it does now - then that's my only argument :) | 20:39 |
| knome | in the first stage of the migration, probably so | 20:40 |
| flocculant | if your argument is based on making canonical infrastructure work more - then I don't care about that :) | 20:40 |
| knome | the biggest problem with launchpad managing the work items data is that it doesn't make a difference between the different work items | 20:40 |
| flocculant | first stage? | 20:40 |
| knome | what that means is that once it's "validated" that the user and work item status is an approved user/state, it's just text | 20:41 |
| flocculant | is this actually written down anywhere for team to read? | 20:41 |
| knome | so we have no way to track what happens to that exact work item | 20:41 |
| knome | so we have to load and parse all of the data again and again | 20:41 |
| knome | no, but so far nobody has been interested in reading such documents | 20:42 |
| flocculant | but that doesn't actually hurt us does it? | 20:42 |
| knome | it does. | 20:42 |
| flocculant | how? | 20:42 |
| knome | for example, on the burndown, there are sometimes those obviously wrong days | 20:43 |
| flocculant | knome: also - I'm not arguing for the sake of it here - I really want to understand what we'd gain :) | 20:43 |
| knome | that's just one of the symptoms | 20:43 |
| knome | if we had the data in our own DB, we could store the daily data about every single item | 20:43 |
| flocculant | see this is where I get confused | 20:43 |
| knome | on the history tab, the dates when the items are completed are the best guesses | 20:43 |
| knome | if 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 issue | 20:44 |
| flocculant | because all of the real data IS on launchpad surely? the bugs, the package changes etc etc | 20:44 |
| knome | there is no way to ask launchpad to tell what the work item status was yesterday | 20:44 |
| knome | or if a bug status was open or closed any given day | 20:45 |
| knome | we know the *last* day when a bug was closed, but if it has been reopened and reclosed, we again only know the last day | 20:45 |
| flocculant | so you are looking purely at the data that we physically input on any given blueprint currently? | 20:45 |
| knome | mostly, yes | 20:46 |
| knome | we want to be linked to launchpad with the bugs anyway | 20:46 |
| knome | but again, that's a lot less API calls than what we are doing now | 20: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 |
| flocculant | which 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 |
| knome | that we'll still have to fetch from launchpad | 20:47 |
| knome | well, not "have to" but "want to" | 20:47 |
| flocculant | for example - the blueprints don't really get updated promptly - just when someone remembers something is DONE or POSTPONED | 20:48 |
| flocculant | consequently anything on the tracker about 'that' is wrong | 20:48 |
| knome | yes | 20:48 |
| flocculant | as far as the Timeline goes - does it actually matter if it's not precise? | 20:49 |
| knome | but 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 |
| flocculant | still people would do it eventually | 20:49 |
| flocculant | :) | 20:49 |
| knome | in that case the question is do we need the timeline anyway? | 20:50 |
| knome | let me give you another example | 20:50 |
| knome | on how it's stupid that launchpad doesn't track work items as items but a textbox | 20:50 |
| knome | consider we'd have an item [flocculant] Pick noce: DONE | 20:50 |
| knome | (typo intentional) | 20:50 |
| flocculant | :) | 20:50 |
| knome | now, it's done today | 20:50 |
| knome | one week from now | 20:50 |
| knome | you go to fix the typo | 20:51 |
| knome | the second you do that, we have no way of knowing it's the same work item | 20:51 |
| knome | because items aren't items, they are just text | 20:51 |
| flocculant | on the tracker | 20:51 |
| knome | no, on launchpad | 20:51 |
| knome | on the tracker, they are actually items | 20:51 |
| flocculant | obviously if you subscribe you could follow the change | 20:51 |
| knome | ...but as they are not items on LP, they aren't "really" items on the tracker either | 20:52 |
| knome | yes, for humans that's easy | 20:52 |
| knome | but the tracker has no way to verify that | 20:52 |
| knome | it can't know that it's the same item, ever | 20:52 |
| flocculant | ok | 20:52 |
| flocculant | I can understand that point | 20:52 |
| knome | so basically if we track items on the tracker internally | 20:52 |
| knome | we could then change anything to anything | 20:52 |
| knome | and all of the items' history would follow along | 20:52 |
| flocculant | yep | 20:53 |
| knome | as it would have an internal ID that was always the same | 20:53 |
| flocculant | I get that | 20:53 |
| knome | that's one more symptom of getting the work item data from LP | 20:53 |
| knome | bugs are a bit easier as they have bug numbers that act as consistent ID's | 20:53 |
| flocculant | ok - but QA uses the tracker in a more global way - not just what's written - but changes to status for example | 20:54 |
| flocculant | how do we intend to keep that if the bug bp is some internal thing? | 20:54 |
| knome | there 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 |
| knome | 1) keep doing the bug blueprint as we do now, and getting the bug statuses as we do now | 20:55 |
| knome | simple, right? | 20:55 |
| flocculant | mmm | 20:55 |
| knome | so one concept in between: tags | 20:56 |
| knome | currently, work items are either development, qa, bugs, artwork or whatever | 20:56 |
| knome | if we save data internally, one work item can have multiple tags, concerning both artwork and qa for example | 20:56 |
| knome | so now: | 20:56 |
| knome | 2) add a work item within a tag (or two) and tell the tracker it's a bug #N | 20:56 |
| knome | the tracker keeps updating the bug data from LP periodically | 20:57 |
| knome | so in essence, just remove the bug blueprint handling and move it to the tracker - but keep on reading the bug DATA from LP | 20:57 |
| flocculant | at which point we are surely back at the reason you want to move away? calls to the lp api thing | 20:58 |
| knome | in 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 |
| knome | then we need to make another API call to ask what's up with those bugs | 20:59 |
| knome | if the bug numbers were saved internally, we'd do with one API call for *all* bugs in *any* blueprints | 20:59 |
| knome | or in our case, in any *tags* really, as we wouldn't have the blueprints | 20:59 |
| flocculant | the whole thing just sounds like robbing peter to pay paul to me :p | 21:00 |
| knome | nah. the "less API calls" is just a side-benefit really | 21:00 |
| knome | and it makes the code much more clean - eg. less prone to errors and network failures and what not | 21:00 |
| flocculant | so what's the main benefit to us as a team then? | 21:01 |
| knome | in our discussion, i've pointed out several | 21:01 |
| knome | one more that we haven't talked a lot yet is the UI | 21:01 |
| flocculant | mmm - none of those sound like big things to me though :) | 21:01 |
| knome | the new UI will let you change statues with a few clicks instead of typing text manually as i said | 21:01 |
| flocculant | knome: well the UI I'm sure we're likely to agree :D | 21:01 |
| knome | it also lets you add work items to *any* tag (currently: blueprint) from the same URL | 21:02 |
| knome | basically just type the work item description, select a tag and assignee and you're done | 21:02 |
| knome | none of the benefits alone are huge - but combined, they make a difference | 21:04 |
| flocculant | knome: right | 21:06 |
| flocculant | sorry for hassling you :) | 21:06 |
| knome | no worries | 21:06 |
| flocculant | as you know - I'm not good with change for change sake :p | 21:07 |
| knome | sure | 21:07 |
| flocculant | akxwi-dave: something I forgot to mention - 16.04.2 hits mid January | 21:07 |
| knome | flocculant, http://temp.knome.fi/xubuntu/.tracker/tracker-new-items.png | 21:09 |
| knome | flocculant, when you click "new": http://temp.knome.fi/xubuntu/.tracker/tracker-new-items-edit.png | 21:10 |
| flocculant | knome: that looks pretty much how I expected it too look :) | 21:10 |
| knome | http://temp.knome.fi/xubuntu/.tracker/tracker-new-items-tags.png | 21:10 |
| flocculant | :D | 21:10 |
| knome | multiple tags - clickable - so click on one of them and you see all items for that tag | 21:11 |
| flocculant | knome: so ... start of a cycle, someone has to start a new cycle blueprint currently | 21:12 |
| knome | yes | 21:12 |
| knome | and all sub-blueprints | 21:12 |
| flocculant | they can copy paste pretty much the base from the last one - edit a few lines and bob's your uncle | 21:12 |
| knome | with internal stuff, you just add a row in the "releases" tab (similar to this) and we're set | 21:12 |
| flocculant | now they'll need to input each one - leave kbd, click buttons | 21:13 |
| knome | we can write a code snippet that copies all not-finished work items from release X to Y | 21:13 |
| knome | that's actually really easy with the all internal stuff... | 21:13 |
| flocculant | without actually doing one - I can't tell which would be quicker | 21:14 |
| flocculant | but I'm not convinced from what I do from cycle to cycle :) | 21:14 |
| flocculant | s/with what | 21:14 |
| knome | the code snippet would allow you to do it by selecting source and destination cycles, then click "go" | 21:14 |
| flocculant | ok | 21:14 |
| knome | it would *totally* be faster | 21:15 |
| knome | and less prone to human errors | 21:15 |
| flocculant | Decide on milestone participation | 21:15 |
| knome | right, so things you always want to do even if they are done | 21:15 |
| flocculant | gets' copied and changed from done to todo | 21:15 |
| knome | hmm. | 21:15 |
| knome | we could allow a batch input of work items | 21:15 |
| flocculant | how would having to type the whole thing out each time be quicker? | 21:16 |
| flocculant | obv things from dev perspective are different cycle to cycle | 21:16 |
| knome | similar to the textbox in LP, but once entered, tracked like real work items | 21:16 |
| flocculant | but artwork for instance - do the wallpaper - same for every cycle | 21:16 |
| knome | fwiw, i basically type that out every cycle :P | 21:16 |
| knome | but i can see QA being a bit more draggy with that | 21:17 |
| flocculant | hah - well I copy/paste and edit done to todo :) | 21:17 |
| knome | so we'll just allow some sort of CSV input, no worries with that | 21:17 |
| flocculant | well | 21:17 |
| knome | one more cool thing we can do at some point is to add a feature that takes a meeting minute url | 21:17 |
| flocculant | on the other hand there are tasks that the only change is x to y to z and flopping done/todo back and forth | 21:18 |
| knome | and greps all the action items there | 21:18 |
| knome | and saves them as work items :P | 21:18 |
| flocculant | could there be a set of always have these items? | 21:18 |
| flocculant | ha ha | 21:18 |
| knome | i'd probably do that with the CSV input | 21:18 |
| knome | so basically just keep a wikipage with the items you want | 21:18 |
| knome | and do one copy-paste per cycle | 21:19 |
| flocculant | and then things we put in whiteboard - where will they live? | 21:19 |
| knome | that's a good question with no good answer yet | 21:19 |
| flocculant | yea - that would work - csv doodah | 21:19 |
| knome | but there are definitely ways to save that kind of information | 21:19 |
| knome | say, every tag can have a description = blueprint can have a whiteboard | 21:20 |
| knome | then just show them nicely somewhere | 21:20 |
| knome | eg. a "tag summary page" | 21:20 |
| knome | i've used the whiteboard mostly for adding stuff that is related to a specific work item | 21:21 |
| knome | so for me, it would be much more useful if every WORK ITEM could have an extendable description | 21:21 |
| knome | (and that's doable...) | 21:21 |
| knome | but again, we can allow tag-based descriptions too | 21:22 |
| flocculant | I 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 announcement | 21:22 |
| knome | so maybe those could be in the wiki or sth too | 21:22 |
| flocculant | so wouldn't ever get DONE - what would be the point :0 | 21:23 |
| flocculant | :0 | 21:23 |
| flocculant | oh boo | 21:23 |
| flocculant | :) | 21:23 |
| knome | well, what i mean is basically anywhere that is within the same domain/UI as the tracker | 21:23 |
| knome | but they STILL can be in the tag description :P | 21:23 |
| flocculant | because the wiki's a nightmare and the xubuntu one I don't like :p | 21:23 |
| knome | why don't you like the xubuntu one? | 21:24 |
| flocculant | can't remember offhand | 21:24 |
| knome | sigh :)= | 21:24 |
| flocculant | I tend to shy away from it lol | 21:24 |
| knome | well, we're moving towards it :P | 21:24 |
| knome | so if you don't like it, open the mouth now and we can potentially do something about it :P | 21:25 |
| flocculant | why do you think most of the qa stuff is on dev pages .... | 21:25 |
| knome | i have no idea ;P | 21:26 |
| flocculant | knome: there are obviously differences between the 2 wiki's - quirks if you like - but I was having trouble doing things last time | 21:26 |
| knome | if it's related to media management - i understand :P | 21:26 |
| flocculant | can't remember exactly what - some plugin needed or something | 21:26 |
| knome | aha | 21:26 |
| knome | well, the next time you bump into it, let me know... | 21:26 |
| flocculant | yup | 21:27 |
| flocculant | won't be 2016 ... | 21:27 |
| flocculant | I know I was doing the release note - or trying to | 21:28 |
| knome | right, some includes... | 21:28 |
| knome | maybe | 21:28 |
| knome | we'll figure it out | 21:28 |
| flocculant | nah - that doesn't work on the u.w either :p | 21:28 |
| knome | it does... but it's wonky :P | 21:29 |
| flocculant | too wonky for me to worry about :) | 21:29 |
| knome | maybe | 21:29 |
| knome | but 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 before | 21:29 |
| flocculant | yup | 21:30 |
| flocculant | I know that :) | 21:30 |
| knome | (along with doing fun/educative projects) | 21:30 |
| knome | educative for me that is :P | 21:30 |
| flocculant | I suspect what we're really talking about *here* are the corner-cases | 21:30 |
| knome | nothing 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 :P | 21:31 |
| flocculant | yea - always good to keep the head working for sure :) | 21:31 |
| flocculant | ha ha ha | 21:31 |
| knome | (especially when it's accidental - and yes, that has happened) | 21:31 |
| flocculant | well - as always good to talk to you about something like this - but I only sat here for 5 minutes 90 minutes ago lol | 21:32 |
| * flocculant wanders off for the night | 21:33 | |
| knome | ;) | 21:35 |
| knome | nighty | 21:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
