| *** gtristan has quit IRC | 05:40 | |
| *** gtristan has joined #baserock | 06:05 | |
| gtristan | pedroalvarez, around ? | 08:15 |
|---|---|---|
| gtristan | I got sufficiently annoyed, and have created this wrapper: http://fpaste.org/303087/45051319/ | 08:20 |
| gtristan | That should work better than just naked "git review" or annoyingly creating a branch for each and every individual commit | 08:20 |
| gtristan | Or worse, cloning separate trees (!) for each commit | 08:21 |
| *** gtristan has quit IRC | 08:45 | |
| *** gtristan has joined #baserock | 09:50 | |
| gtristan | Final version of script, fwiw: http://fpaste.org/303117/52231614/ | 10:54 |
| *** locallycompact has joined #baserock | 11:30 | |
| pedroalvarez | heh, spotted this in #gerrit before opening #baserock | 12:12 |
| pedroalvarez | that wrapper is nice | 12:12 |
| gtristan | nod, I just stepped into there asking some info | 12:12 |
| gtristan | but I have a feeling it's a groupie channel, and the gerrit developers (if those exist) do not hang out there | 12:13 |
| pedroalvarez | so, after googling, I think it's possible to push one commit using git... this might be useful for your script | 12:14 |
| * pedroalvarez goes to hunt more info | 12:14 | |
| gtristan | I looked for it, but couldnt find anything | 12:14 |
| pedroalvarez | because you are aware that you can push to gerrit using `git push .... ` ? | 12:15 |
| gtristan | this guys says "its not possible" http://stackoverflow.com/questions/13878904/git-cherry-pick-to-another-branch | 12:15 |
| radiofree | good stuff gtristan | 12:15 |
| gtristan | others in #git seem to indicate that there is a possibility to use "plumbing" commands to create git objects and such | 12:16 |
| gtristan | on the other hand, the advantage of having a checkout with the current script, is you have that way to resolve conflicts on the fly | 12:16 |
| pedroalvarez | git push <remotename> <commit SHA>:<remotebranchname> | 12:17 |
| gtristan | hmmm, interesting | 12:17 |
| pedroalvarez | So something like: `git push gerrit SHA:refs/for/master/my-topic-branch` | 12:18 |
| pedroalvarez | not tested! :) | 12:18 |
| pedroalvarez | I guess it doesn't do what we want, but worth a try | 12:18 |
| gtristan | I think it's a very typical issue, first link I found was http://stackoverflow.com/questions/19768959/how-to-review-a-specific-commit-on-git | 12:20 |
| gtristan | where the guy proposes making branches for each not-interdependent-commit | 12:20 |
| pedroalvarez | my suggestion seems to send commits up to that SHA | 12:20 |
| gtristan | I think so yes | 12:20 |
| gtristan | not exactly like: git format-patch | eat-that-gerrit.sh | 12:21 |
| gtristan | :) | 12:21 |
| gtristan | radiofree, thanks btw, I felt bad for losing my cool and thought I aught to try something more productive | 12:22 |
| gtristan | note also, I found this: https://github.com/lennartcl/gitl | 12:23 |
| gtristan | which provides "git-cherry-copy" | 12:24 |
| gtristan | but it also touches the local branch state to do it | 12:24 |
| pedroalvarez | interesting too | 12:26 |
| gtristan | I think gerrit is not merging anymore btw | 12:35 |
| pedroalvarez | gtristan: I think that sending different individual commits for review, that modify the same file gnome-all.lorry might create more merge conflicts | 12:35 |
| gtristan | for example: https://gerrit.baserock.org/#/c/1616/... has been "merge pending" for a whole day | 12:35 |
| gtristan | pedroalvarez, yes that is true, but inconsequential I think | 12:36 |
| pedroalvarez | gtristan: that patch hastn't been submitted | 12:36 |
| gtristan | i.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 it | 12:36 |
| gtristan | eh ? | 12:36 |
| pedroalvarez | has been only 2+ ed | 12:37 |
| gtristan | pedroalvarez, it says "Submitted, Merge Pending" | 12:37 |
| pedroalvarez | 1616? | 12:37 |
| gtristan | also, I didnt know there was any difference from +2 & submitted either :-/ | 12:37 |
| pedroalvarez | ohh! that's true | 12:37 |
| pedroalvarez | ffs | 12:38 |
| gtristan | while it's confusing, it's re-assuring to know that 1 + 1 != 2... in gerrit | 12:39 |
| pedroalvarez | well, that patch is merged now | 12:39 |
| pedroalvarez | we have been having problems in our infra | 12:39 |
| pedroalvarez | our DB has been down for some time.. :/ | 12:40 |
| pedroalvarez | and we didn't even notice | 12:40 |
| pedroalvarez | storyboard also failed, that's why I decided to redeploy it | 12:40 |
| pedroalvarez | paste.baserock.org now doesn't boot... | 12:40 |
| pedroalvarez | It hasn't been a good week | 12:40 |
| * gtristan noticed that | 12:40 | |
| gtristan | yes | 12:41 |
| pedroalvarez | I hope this gerrit problem is just because of that | 12:41 |
| gtristan | we have to avoid spamming gerrit with 10X the same comment in one minute | 12:41 |
| * gtristan ducks | 12:41 | |
| gtristan | ;-) | 12:41 |
| gtristan | anyway, it has looked like a hard week | 12:42 |
| gtristan | it's a good thing we finally have an updated storyboard | 12:42 |
| gtristan | I dont know if anyone gets email notifications for: https://storyboard.baserock.org/#!/story/5 ? | 12:43 |
| gtristan | also, looking at openstack: https://storyboard.openstack.org/#!/project/719 | 12:44 |
| gtristan | their stories actually have status ! | 12:44 |
| gtristan | at least active/merged/invalid | 12:45 |
| gtristan | would be awesome if we could have that too :D | 12:45 |
| gtristan | 2 most important bugs fixed: email notifications and issue status | 12:45 |
| pedroalvarez | gtristan: have you received notifications? | 12:47 |
| pedroalvarez | we are running the same version, we have that too: https://storyboard.baserock.org/#!/project/2 | 12:48 |
| pedroalvarez | the UX is still a bit confusing, but they are trying hard :) | 12:48 |
| gtristan | not yet | 12:48 |
| gtristan | But | 12:48 |
| gtristan | I am the last to comment on that bug | 12:48 |
| pedroalvarez | the email notifications is on an early stage | 12:49 |
| gtristan | and I'm not sure if commenting on it automatically adds me to the CC list for that bug | 12:49 |
| gtristan | or how to add myself | 12:49 |
| 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 changes | 12:49 |
| gtristan | ok, so I can see in "project 2" there are statuses | 12:49 |
| pedroalvarez | to receive an email you need to be subscribed to a story, and enabled email notifications | 12:50 |
| gtristan | But I'll reiterate my question at the end of issue 5: How do I mark it as closed ? or "merged" ? | 12:50 |
| gtristan | also odd that events timeline only shows N entries at a time, and starts at the beginning | 12:51 |
| gtristan | you have to dig deep to find the most recent comments | 12:51 |
| pedroalvarez | given that all of them have been resolved, the status now is merged: https://storyboard.baserock.org/#!/project/1 | 12:52 |
| * gtristan searches for the "Subscribe" button | 12:52 | |
| pedroalvarez | the star icon | 12:52 |
| pedroalvarez | storyboard devs will be interested on all of this feedback | 12:52 |
| gtristan | aha | 12:52 |
| gtristan | damn, tasks again | 12:53 |
| gtristan | that's not reassuring :-S | 12:53 |
| * gtristan wishes he could use storyboard without any tasks at all - taskless mode | 12:53 | |
| pedroalvarez | there is usually a task always. | 12:55 |
| pedroalvarez | if a bug, debug why this is happening | 12:55 |
| pedroalvarez | (for example) | 12:55 |
| pedroalvarez | but I understand the point | 12:55 |
| gtristan | There are a couple of points | 12:56 |
| gtristan | One 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 |
| gtristan | That is less important than the second point | 12:56 |
| gtristan | which is that, it seems the policy on how tasks are managed is poor | 12:57 |
| gtristan | I.e., Any user can just delete a task | 12:57 |
| gtristan | so 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 description | 12:59 |
| pedroalvarez | at least a way to ban users :) | 13:00 |
| pedroalvarez | (just in case) | 13:00 |
| gtristan | one user can resolve a bug reported by another user, without being the "product owner" | 13:00 |
| gtristan | at least: https://storyboard.baserock.org/#!/story/5 accurately shows that I deleted a task from the list | 13:01 |
| pedroalvarez | bearing in mind that sometimes, users that report the bugs don't care about what happens after reporting | 13: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 reason | 13:03 | |
| pedroalvarez | so, only the people with merge power, should be able to mark tasks as merged | 13:04 |
| pedroalvarez | ideally, you could say what commit solves one task, and then storyboard could mark the task as merged whenever that commit is merged | 13:05 |
| pedroalvarez | (with a url to gerrit patch, or github, or whatever) | 13:05 |
| gtristan | You should definitely include the commit log in the comment while closing the bug yes | 13:05 |
| gtristan | and include the story ID in the commit message | 13:05 |
| gtristan | I think linking to gerrit is less important (in any case it's linked by our manditory commit-ID field) | 13:06 |
| gtristan | storyboard should not automatically pretend to know what to do with a bug just because of a commit, either | 13:07 |
| gtristan | there can be many separate commits which happen over the course of one bug's resolution | 13:07 |
| * SotK reads scrollback | 13:11 | |
| pedroalvarez | hehe, sorry for not discussing on #storyboard :) | 13:12 |
| SotK | I 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 |
| SotK | so a bug which needs several commits would have several tasks | 13:15 |
| gtristan | feels like management overhead | 13:16 |
| gtristan | also, missing a declarative way to really decide that an issue is closed | 13:16 |
| gtristan | it's not automatically closed because the currently-under-review patches have landed | 13:16 |
| gtristan | and again, you can delete a task, so it's all very fragile | 13:17 |
| SotK | surely an issue is closed when all tasks to fix it are done? | 13:17 |
| gtristan | Someone files bug, Developer creates a patch hoping to address it, User points out that that is not sufficient | 13:18 |
| gtristan | Bug should not ever be in the "closed" category until it's explicitly decided upon | 13:19 |
| gtristan | Issues can also be open for a long time before a patch is ever created, or a strategy for addressing it has been even thought of | 13:20 |
| gtristan | If 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" issue | 13:21 |
| SotK | So 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 |
| gtristan | that doesnt really work with the 1:1 patch/task relationship which it was apparently thought up for | 13: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 code | 13:24 | |
| gtristan | also, it's a lot more complicated, with presumably no added value, comparing to a simple approach: One bug <---> One status <---> History of comments | 13:24 |
| SotK | the idea is that one story can track a bug that affects multiple projects | 13:27 |
| gtristan | SotK, that's easy to do with dependencies, and dependencies are *damn cool* as well | 13:30 |
| gtristan | because when you are subscribed to emails for one story, you will receive notifications for another story which "blocks" it | 13:30 |
| gtristan | also, since they are all "stories", they all have their own history of comments | 13:31 |
| gtristan | not just a metadata of a task name | 13:31 |
| gtristan | much more flexible in what you can accomplish | 13:31 |
| gtristan | Actually baserock story 5 is an excellent example of how this fails | 13:32 |
| gtristan | that should really be a milestone tracking bug which depends on many individual bugs | 13:32 |
| gtristan | in which the details of each bug can be discussed | 13:32 |
| gtristan | instead you just have nobody making useful comments | 13:33 |
| gtristan | But the 'task' to "move a lot of stuff from /usr/etc -> /etc" should have had more discussion in it's own separate issue | 13:33 |
| gtristan | that is now possible because the bug (or lack thereof) which was for definitions version 7 makes it easier to change the default configure commands | 13:34 |
| * gtristan has since deleted that task from story 5 | 13:34 | |
| gtristan | Of course, with dependencies it works both ways, with "tasks" you have to duplicate them | 13:38 |
| gtristan | When more than one issue is solved by the same "task" | 13:38 |
| gtristan | or not solved necessarily, but that task was necessary to get closer to closing 2 separate macro issues | 13:39 |
| *** gtristan has quit IRC | 13:50 | |
| *** gtristan has joined #baserock | 14:09 | |
| SotK | Yeah, some way of linking multiple stories together would be good I think | 14:12 |
| SotK | that way story 5 could have easily been a collection of smaller stories that are related, rather than one story with a ridiculous number of tasks | 14:14 |
| *** locallycompact has quit IRC | 15:21 | |
| *** radiofree has quit IRC | 15:34 | |
| *** radiofree has joined #baserock | 15:34 | |
| * persia reads backscroll | 19:08 | |
| persia | There are gerrit integration scripts for Storyboard: I do not know if they are installed in the Baserock infrastructure. | 19:09 |
| persia | In 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 |
| persia | s/for om/from/ | 19:11 |
| gtristan | persia, 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 changes | 19:19 |
| gtristan | That, and milestone trackers | 19:19 |
| gtristan | those are the only 2 ways I've seen inter-bug dependencies used | 19:19 |
| gtristan | i.e. generic milestone bug depends on 10 or 15 bugs, blockers for a general release, or such | 19:20 |
| gtristan | I think I get what you mean by the "epic", that would be what I'm calling a milestone bug I guess | 19:24 |
| gtristan | but I disagree that there should be a different "type" for an "epic", "story" and a "task" | 19:25 |
| gtristan | A task which is a part of another story which may be a part of another epic... might itself *depend* on another epic for moving forward | 19:25 |
| gtristan | "before going ahead with this patch -> that project should be complete" | 19:26 |
| gtristan | at which point, it makes little sense to complicate the whole thing by differentiating between tasks, stories and epics | 19:27 |
| gtristan | the 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 changes | 19:29 |
| gtristan | i.e. regarding emails, that's sort of a really hard blocker for a usable bug tracking IMO | 19:30 |
| persia | That is just a matter of which templates a deployer has enabled. | 19:36 |
| persia | The 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 |
| persia | One 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 |
| gtristan | Honestly, inter-bug dependencies I can live without, they are nice to have, though. | 19:47 |
| gtristan | If 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 task | 19:48 |
| gtristan | while 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 limitations | 19:48 |
| gtristan | but 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 |
| gtristan | More 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 |
| gtristan | A taskless storyboard with story status would be just fine | 19:52 |
| persia | Why can't multiple stories depend on the same task, or multiple epics deep bd on the same story? | 20:20 |
| gtristan | persia, well, not how it's currently implemented, I dont see how that's possible | 20:21 |
| gtristan | tasks 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 |
| gtristan | that I'm missing ? | 20:22 |
| persia | There 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 |
| gtristan | haha, yes we are looking at it totally differently | 20:24 |
| persia | I 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 |
| gtristan | I am thinking "We need something RIGHT NOW to actually handle bug tracking properly for a project like Baserock", we are overdue | 20:24 |
| gtristan | Pie in the sky, what story board could be one day, is another topic :D | 20:24 |
| persia | I 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 |
| gtristan | meanwhile, we have an undocumented project with 65 bugs filed, and when somebody comments on it, the owner of that bug does not receive an email | 20:26 |
| persia | My 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 |
| gtristan | Sure, my only interest is fixing the problem with documentation development of baserock | 20:29 |
| persia | Yes. 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 #baserock | 22:13 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!