IRC logs for #baserock for Saturday, 2015-12-19

*** gtristan has quit IRC05:40
*** gtristan has joined #baserock06:05
gtristanpedroalvarez, around ?08:15
gtristanI got sufficiently annoyed, and have created this wrapper:
gtristanThat should work better than just naked "git review" or annoyingly creating a branch for each and every individual commit08:20
gtristanOr worse, cloning separate trees (!) for each commit08:21
*** gtristan has quit IRC08:45
*** gtristan has joined #baserock09:50
gtristanFinal version of script, fwiw:
*** locallycompact has joined #baserock11:30
pedroalvarezheh, spotted this in #gerrit before opening #baserock12:12
pedroalvarezthat wrapper is nice12:12
gtristannod, I just stepped into there asking some info12:12
gtristanbut I have a feeling it's a groupie channel, and the gerrit developers (if those exist) do not hang out there12:13
pedroalvarezso, after googling, I think it's possible to push one commit using git... this might be useful for your script12:14
* pedroalvarez goes to hunt more info12:14
gtristanI looked for it, but couldnt find anything12:14
pedroalvarezbecause you are aware that you can push to gerrit using `git push .... ` ?12:15
gtristanthis guys says "its not possible"
radiofreegood stuff gtristan12:15
gtristanothers in #git seem to indicate that there is a possibility to use "plumbing" commands to create git objects and such12:16
gtristanon the other hand, the advantage of having a checkout with the current script, is you have that way to resolve conflicts on the fly12:16
pedroalvarezgit push <remotename> <commit SHA>:<remotebranchname>12:17
gtristanhmmm, interesting12:17
pedroalvarezSo something like: `git push gerrit SHA:refs/for/master/my-topic-branch`12:18
pedroalvareznot tested! :)12:18
pedroalvarezI guess it doesn't do what we want, but worth a try12:18
gtristanI think it's a very typical issue, first link I found was
gtristanwhere the guy proposes making branches for each not-interdependent-commit12:20
pedroalvarezmy suggestion seems to send commits up to that SHA12:20
gtristanI think so yes12:20
gtristannot exactly like: git format-patch | eat-that-gerrit.sh12:21
gtristanradiofree, thanks btw, I felt bad for losing my cool and thought I aught to try something more productive12:22
gtristannote also, I found this:
gtristanwhich provides "git-cherry-copy"12:24
gtristanbut it also touches the local branch state to do it12:24
pedroalvarezinteresting too12:26
gtristanI think gerrit is not merging anymore btw12:35
pedroalvarezgtristan: I think that sending different individual commits for review, that modify the same file gnome-all.lorry might create more merge conflicts12:35
gtristanfor example: has been "merge pending" for a whole day12:35
gtristanpedroalvarez, yes that is true, but inconsequential I think12:36
pedroalvarezgtristan: that patch hastn't been submitted12:36
gtristani.e. you can choose which ones you want to approve, and once they are applied, if there is a conflict, I can always just fix it12:36
gtristaneh ?12:36
pedroalvarezhas been only 2+ ed12:37
gtristanpedroalvarez, it says "Submitted, Merge Pending"12:37
gtristanalso, I didnt know there was any difference from +2 & submitted either :-/12:37
pedroalvarezohh! that's true12:37
gtristanwhile it's confusing, it's re-assuring to know that 1 + 1 != 2... in gerrit12:39
pedroalvarezwell, that patch is merged now12:39
pedroalvarezwe have been having problems in our infra12:39
pedroalvarezour DB has been down for some time.. :/12:40
pedroalvarezand we didn't even notice12:40
pedroalvarezstoryboard also failed, that's why I decided to redeploy it12:40 now doesn't boot...12:40
pedroalvarezIt hasn't been a good week12:40
* gtristan noticed that12:40
pedroalvarezI hope this gerrit problem is just because of that12:41
gtristanwe have to avoid spamming gerrit with 10X the same comment in one minute12:41
* gtristan ducks12:41
gtristananyway, it has looked like a hard week12:42
gtristanit's a good thing we finally have an updated storyboard12:42
gtristanI dont know if anyone gets email notifications for:!/story/5 ?12:43
gtristanalso, looking at openstack:!/project/71912:44
gtristantheir stories actually have status !12:44
gtristanat least active/merged/invalid12:45
gtristanwould be awesome if we could have that too :D12:45
gtristan2 most important bugs fixed: email notifications and issue status12:45
pedroalvarezgtristan: have you received notifications?12:47
pedroalvarezwe are running the same version, we have that too:!/project/212:48
pedroalvarezthe UX is still a bit confusing, but they are trying hard :)12:48
gtristannot yet12:48
gtristanI am the last to comment on that bug12:48
pedroalvarezthe email notifications is on an early stage12:49
gtristanand I'm not sure if commenting on it automatically adds me to the CC list for that bug12:49
gtristanor how to add myself12:49
pedroalvarezit's only enabled for story changes, which means that you will only receive an email if the title or description of a story changes12:49
gtristanok, so I can see in "project 2" there are statuses12:49
pedroalvarezto receive an email you need to be subscribed to a story, and enabled email notifications12:50
gtristanBut I'll reiterate my question at the end of issue 5: How do I mark it as closed ? or "merged" ?12:50
gtristanalso odd that events timeline only shows N entries at a time, and starts at the beginning12:51
gtristanyou have to dig deep to find the most recent comments12:51
pedroalvarezgiven that all of them have been resolved, the status now is merged:!/project/112:52
* gtristan searches for the "Subscribe" button12:52
pedroalvarezthe star icon12:52
pedroalvarezstoryboard devs will be interested on all of this feedback12:52
gtristandamn, tasks again12:53
gtristanthat's not reassuring :-S12:53
* gtristan wishes he could use storyboard without any tasks at all - taskless mode12:53
pedroalvarezthere is usually a task always.12:55
pedroalvarezif a bug, debug why this is happening12:55
pedroalvarez(for example)12:55
pedroalvarezbut I understand the point12:55
gtristanThere are a couple of points12:56
gtristanOne is, when a bug is reported, half of the time, you dont know what task may be involved to fix it, only that there is something to address "somehow"12:56
gtristanThat is less important than the second point12:56
gtristanwhich is that, it seems the policy on how tasks are managed is poor12:57
gtristanI.e., Any user can just delete a task12:57
gtristanso you can have some kind of commit war where some user/dev disagree on what needs to be done, or anyone can just modify a task, renaming it's description12:59
pedroalvarezat least a way to ban users :)13:00
pedroalvarez(just in case)13:00
gtristanone user can resolve a bug reported by another user, without being the "product owner"13:00
gtristanat least:!/story/5 accurately shows that I deleted a task from the list13:01
pedroalvarezbearing in mind that sometimes, users that report the bugs don't care about what happens after reporting13:02
* gtristan thinks, reporter & developer should be allowed to close bugs, but not other unrelated parties, while anyone should be allowed to re-open a closed bug, claiming it still needs attention for some reason13:03
pedroalvarezso, only the people with merge power, should be able to mark tasks as merged13:04
pedroalvarezideally, you could say what commit solves one task, and then storyboard could mark the task as merged whenever that commit is merged13:05
pedroalvarez(with a url to gerrit patch, or github, or whatever)13:05
gtristanYou should definitely include the commit log in the comment while closing the bug yes13:05
gtristanand include the story ID in the commit message13:05
gtristanI think linking to gerrit is less important (in any case it's linked by our manditory commit-ID field)13:06
gtristanstoryboard should not automatically pretend to know what to do with a bug just because of a commit, either13:07
gtristanthere can be many separate commits which happen over the course of one bug's resolution13:07
* SotK reads scrollback13:11
pedroalvarezhehe, sorry for not discussing on #storyboard :)13:12
SotKI believe the idea is that there should be a 1:1 mapping of task to commit (where completion of the task requires a code change)13:15
SotKso a bug which needs several commits would have several tasks13:15
gtristanfeels like management overhead13:16
gtristanalso, missing a declarative way to really decide that an issue is closed13:16
gtristanit's not automatically closed because the currently-under-review patches have landed13:16
gtristanand again, you can delete a task, so it's all very fragile13:17
SotKsurely an issue is closed when all tasks to fix it are done?13:17
gtristanSomeone files bug, Developer creates a patch hoping to address it, User points out that that is not sufficient13:18
gtristanBug should not ever be in the "closed" category until it's explicitly decided upon13:19
gtristanIssues can also be open for a long time before a patch is ever created, or a strategy for addressing it has been even thought of13:20
gtristanIf currently the developer who presumes to have fixed the bug closes the task, sure, the bug becomes "merged", doesnt seem SO bad... but then the effected user who still has a problem, NEEDS to reopen the bug, that user is not equipped to decide what "task" should be added to the "Merged" issue13:21
SotKSo the user creates a task "Investigate why this is still broken" and leaves a comment describing how to reproduce the issue (or edits the description)13:23
gtristanthat doesnt really work with the 1:1 patch/task relationship which it was apparently thought up for13:23
* SotK might have been unclear with "1:1 mapping", each task should be a single commit, but a task could also be something unrelated to code13:24
gtristanalso, it's a lot more complicated, with presumably no added value, comparing to a simple approach: One bug <---> One status <---> History of comments13:24
SotKthe idea is that one story can track a bug that affects multiple projects13:27
gtristanSotK, that's easy to do with dependencies, and dependencies are *damn cool* as well13:30
gtristanbecause when you are subscribed to emails for one story, you will receive notifications for another story which "blocks" it13:30
gtristanalso, since they are all "stories", they all have their own history of comments13:31
gtristannot just a metadata of a task name13:31
gtristanmuch more flexible in what you can accomplish13:31
gtristanActually baserock story 5 is an excellent example of how this fails13:32
gtristanthat should really be a milestone tracking bug which depends on many individual bugs13:32
gtristanin which the details of each bug can be discussed13:32
gtristaninstead you just have nobody making useful comments13:33
gtristanBut the 'task' to "move a lot of stuff from /usr/etc -> /etc" should have had more discussion in it's own separate issue13:33
gtristanthat is now possible because the bug (or lack thereof) which was for definitions version 7 makes it easier to change the default configure commands13:34
* gtristan has since deleted that task from story 513:34
gtristanOf course, with dependencies it works both ways, with "tasks" you have to duplicate them13:38
gtristanWhen more than one issue is solved by the same "task"13:38
gtristanor not solved necessarily, but that task was necessary to get closer to closing 2 separate macro issues13:39
*** gtristan has quit IRC13:50
*** gtristan has joined #baserock14:09
SotKYeah, some way of linking multiple stories together would be good I think14:12
SotKthat way story 5 could have easily been a collection of smaller stories that are related, rather than one story with a ridiculous number of tasks14:14
*** locallycompact has quit IRC15:21
*** radiofree has quit IRC15:34
*** radiofree has joined #baserock15:34
* persia reads backscroll19:08
persiaThere are gerrit integration scripts for Storyboard: I do not know if they are installed in the Baserock infrastructure.19:09
persiaIn terms of ridiculous numbers of tasks: to me the unrepresented concept is that of the "epic".  I have seen too much confusion and abuse for om various dependency models to be confident anyone has a good model for representing interdependence at a story level.19:11
persias/for om/from/19:11
gtristanpersia, I have never seen any confusion about that actually, it's quite frequent that say, bug in application foo cannot (or should not) be address until feature in library bar (tracked in the same bug tracker) has landed, also developer of application foo gets an email because blocking bug in library bar's status changes19:19
gtristanThat, and milestone trackers19:19
gtristanthose are the only 2 ways I've seen inter-bug dependencies used19:19
gtristani.e. generic milestone bug depends on 10 or 15 bugs, blockers for a general release, or such19:20
gtristanI think I get what you mean by the "epic", that would be what I'm calling a milestone bug I guess19:24
gtristanbut I disagree that there should be a different "type" for an "epic", "story" and a "task"19:25
gtristanA task which is a part of another story which may be a part of another epic... might itself *depend* on another epic for moving forward19:25
gtristan"before going ahead with this patch -> that project should be complete"19:26
gtristanat which point, it makes little sense to complicate the whole thing by differentiating between tasks, stories and epics19:27
gtristanthe following however is... um... the biggest problem:19:29
gtristan<pedroalvarez> it's only enabled for story changes, which means that you will only receive an email if the title or description of a story changes19:29
gtristani.e. regarding emails, that's sort of a really hard blocker for a usable bug tracking IMO19:30
persiaThat is just a matter of which templates a deployer has enabled.19:36
persiaThe problem with abusing a flat system to conflate epics, stories, and tasks is that it makes it hard to have a canonical URI for an overview: most systems that try this seem to generate "metabugs" with different closer semantics than other bugs.19:38
persiaOne of the best dependency systems I have seen is in savane, but even that ends up with implementation-local customary semantics to work around the data model.19:39
gtristanHonestly, inter-bug dependencies I can live without, they are nice to have, though.19:47
gtristanIf you go with a container like system; where one epic "contains" stories which in turn "contain" tasks, then you have limited yourself, because multiple epics cannot depend on the same story, and multiple stories cannot depend on the same task19:48
gtristanwhile implementation-wise, it's easier to just not differentiate and say "everything is a bug", and additionally, you dont shoot yourself in the foot by adding those limitations19:48
gtristanbut thats beside the point, I can live without dependencies if at least bugs can easily link to eachother (i.e. mentioning "depends on story 123" turns "story 123" into a link automagically)19:50
gtristanMore importantly; closing of tasks should certainly not cause a story to be closed automagically; this removes the important moment of pause; where a developer says "Ok, have I implemented everything required for this bug, really ? is it really time to explicitly mark this bug as CLOSED ?"19:51
gtristanA taskless storyboard with story status would be just fine19:52
persiaWhy can't multiple stories depend on the same task, or multiple epics deep bd on the same story?20:20
gtristanpersia, well, not how it's currently implemented, I dont see how that's possible20:21
gtristantasks seem to be some items that are "contained" by a given story, is there a way for more than one story to share the same task ?20:22
gtristanthat I'm missing ?20:22
persiaThere currently exists no implementation, but in my dream world, each story also contains a machine-readable description of the required behaviours, which can provide information on whether the set of merged tasks is complete.20:23
gtristanhaha, yes we are looking at it totally differently20:24
persiaI do not know enough about the internals to know if the data model needs adjustment.  I agree the JavaScript UI does not expose that sort of thing.20:24
gtristanI am thinking "We need something RIGHT NOW to actually handle bug tracking properly for a project like Baserock", we are overdue20:24
gtristanPie in the sky, what story board could be one day, is another topic :D20:24
persiaI once had that opinion, but others chose to do it right, and avoid migrations.  This seems a common theme in Baserock, so everything takes a while, but the results tend to be impressive.20:26
gtristanmeanwhile, we have an undocumented project with 65 bugs filed, and when somebody comments on it, the owner of that bug does not receive an email20:26
persiaMy interest in Storyboard extends outside Baserock, so much of my participation in the discussion is aligned with my opinions about the long-term model, and more examples of organisations moving toward that goal.20:27
gtristanSure, my only interest is fixing the problem with documentation development of baserock20:29
persiaYes.  The current situation is not good.  As I said before, I was one of the pragmatic folk that requested Mantis some long time ago.  It needs consensus and operations buy-in, not just pragmatism.20:29
*** edcragg has joined #baserock22:13

Generated by 2.14.0 by Marius Gedminas - find it at!