*** tosky has quit IRC | 00:00 | |
*** whoami-rajat has joined #storyboard | 01:09 | |
*** dangtrinhnt has quit IRC | 02:02 | |
openstackgerrit | Merged openstack-infra/storyboard-webclient master: Clear task title field on saving a new task https://review.openstack.org/634557 | 02:14 |
---|---|---|
*** dangtrinhnt has joined #storyboard | 02:28 | |
*** EduUrban06 has joined #storyboard | 03:12 | |
*** EduUrban06 has quit IRC | 03:58 | |
*** scherbatsky has joined #storyboard | 05:05 | |
*** ianychoi_ has joined #storyboard | 05:24 | |
*** ianychoi has quit IRC | 05:28 | |
*** scherbatsky has quit IRC | 05:41 | |
*** udesale has joined #storyboard | 06:07 | |
*** smera has quit IRC | 07:30 | |
*** cmoura has quit IRC | 07:59 | |
*** cmoura has joined #storyboard | 08:00 | |
*** dtantsur|afk is now known as dtantsur | 08:03 | |
*** dtantsur is now known as dtantsur|mtg | 08:03 | |
*** tosky has joined #storyboard | 08:29 | |
*** jpich has joined #storyboard | 08:58 | |
*** udesale has quit IRC | 10:57 | |
*** ianychoi_ is now known as ianychoi | 11:20 | |
*** hritvi has joined #storyboard | 12:18 | |
*** udesale has joined #storyboard | 12:38 | |
*** TheJulia_sick is now known as TheJulia | 13:05 | |
*** jamesmcarthur has joined #storyboard | 13:45 | |
*** hritvi has quit IRC | 13:52 | |
*** jamesmcarthur has quit IRC | 14:18 | |
*** jamesmcarthur has joined #storyboard | 14:35 | |
*** kshitija has joined #storyboard | 14:35 | |
*** jamesmcarthur has quit IRC | 14:36 | |
*** jamesmcarthur_ has joined #storyboard | 14:36 | |
*** mkarray has joined #storyboard | 14:55 | |
*** udesale has quit IRC | 15:37 | |
*** dtantsur|mtg is now known as dtantsur|afk | 15:50 | |
*** scherbatsky has joined #storyboard | 17:11 | |
*** jpich has quit IRC | 17:37 | |
*** jamesmcarthur_ has quit IRC | 17:50 | |
*** jamesmcarthur has joined #storyboard | 17:50 | |
*** jamesmcarthur has quit IRC | 17:50 | |
*** jamesmcarthur has joined #storyboard | 17:51 | |
*** jtomasek has quit IRC | 18:06 | |
*** cmoura has quit IRC | 18:38 | |
*** jamesmcarthur has quit IRC | 18:50 | |
*** jamesmcarthur has joined #storyboard | 18:51 | |
diablo_rojo | SotK, fungi we want to meet today? | 18:52 |
fungi | i'm happy to meet. seems we have some developments on the attachments front, and also a flood of bug fixes pouring in from prospective outreachy candidates | 18:53 |
* diablo_rojo can go update the agenda | 18:53 | |
fungi | and also SotK wrote some thoughts on improving the private/secrity story model | 18:53 |
fungi | and we have ndsu capstone folk working on something for storyboard too | 18:54 |
*** jamesmcarthur has quit IRC | 18:55 | |
* diablo_rojo adds things to agenda | 18:55 | |
*** EduUrban06 has joined #storyboard | 19:01 | |
diablo_rojo | SotK, agenda is up to date | 19:02 |
*** ivy has joined #storyboard | 19:04 | |
SotK | o/ | 19:09 |
SotK | sorry I'm late | 19:09 |
fungi | np | 19:09 |
*** tosky has quit IRC | 20:00 | |
*** tosky has joined #storyboard | 20:01 | |
mkarray | I didn't quite follow your last remark in the meeting Sotk | 20:04 |
mkarray | In regards to "that sounds good to me, though I'd be tempted to also make the fulltext-based searching available via the query syntax" | 20:04 |
SotK | I think it'd be useful to be able to do something like `project:openstack-infra/storyboard AND q:something` where q is a fulltext search term like it currently is | 20:11 |
SotK | maybe you were already planning for that to be valid | 20:11 |
mkarray | Ah yes, I do mean to include that :) | 20:11 |
mkarray | What I could use some input on though, is it worth adding both features? | 20:12 |
mkarray | If someone already knows what they want to look for, should we still provide them with all possible browsable items? | 20:13 |
*** scherbatsky has quit IRC | 20:14 | |
*** cmoura has joined #storyboard | 20:14 | |
SotK | I think its worth allowing both, not sure on the best UI for it though | 20:19 |
SotK | Probably suggesting options but also allowing the user to just type what they want | 20:21 |
mkarray | If you all don't think they are mutually exclusive then that is fine with me. I was just worried the UI would be cluttered | 20:22 |
persia | mkarray: While there exist storyboard installations that aren't paired with gerrit, my recommendation is to select a behaviour similar to the gerrit searchbox UI: it's not perfect, but it ought be familiar to most folk using Storyboard (as most guides recommend installation along with a gerrit). | 20:22 |
fungi | and also it's far from the worst rich search implementation syntax i've had to work with over the years | 20:30 |
*** jamesmcarthur has joined #storyboard | 20:30 | |
fungi | it's pretty close to lucene, really | 20:30 |
fungi | clarkb: do you happen to know if gerrit's search implementation is actually compliant with (or even uses) lucene's lexer? | 20:31 |
fungi | i see apache lucene's reference implementation of that is a javacc library, so wouldn't surprise me too much | 20:32 |
fungi | as gerrit is also implemented i java | 20:32 |
clarkb | The message field uses lucene on the backend iirc but the status:open project:foo does not | 20:32 |
clarkb | it might be a strict subset but the query language developed prior to gerrits use of lucene | 20:33 |
*** EduUrban06 has quit IRC | 20:54 | |
*** ivy has quit IRC | 21:06 | |
*** zbr|ssbarnea has joined #storyboard | 21:08 | |
fungi | yeah, i knew it used lucene for index management, just didn't know whether you know if the search syntax is lucene-compliant | 21:08 |
*** zbr has quit IRC | 21:10 | |
*** kshitija has quit IRC | 21:14 | |
*** whoami-rajat has quit IRC | 21:18 | |
*** jamesmcarthur has quit IRC | 21:24 | |
*** jamesmcarthur has joined #storyboard | 21:24 | |
mkarray | Another problem that comes with implementing this syntax, is how we deal with identifying users | 21:26 |
mkarray | The whole point is to make api functionality apparent in the ui, but right now there is no way of figuring things out like assignee_id and creator_id | 21:27 |
mkarray | I recall this discussion leaning towards using emails as id's. so assignee_id:mkarray@email.com | 21:28 |
*** jamesmcarthur has quit IRC | 21:28 | |
mkarray | If you are all okay with this implementation this is fine, but it does seem a bit strange to me personally | 21:29 |
*** EduUrban06 has joined #storyboard | 22:09 | |
fungi | there are a couple of obvious options: | 22:29 |
*** EduUrban06 has quit IRC | 22:30 | |
fungi | one is to require a guaranteed unique identifier (account id number, e-mail address, openid url), the other is to accept that an identifier may match more than one user and decide how we want to act (include results which match both? pick one based on some heuristic?) | 22:31 |
fungi | right now we query with a unique identifier and the webclient presents the possible matches to the user to choose one | 22:32 |
fungi | so if there are two users with the exact same display name and you enter than name in the search box, right now it's going to show you two identical-looking entries and you get to guess at random between the two which you want to query, then it will feed the account id number for the one you selected into the query | 22:34 |
fungi | the way gerrit handles this, by comparison, is to display the e-mail address along with the name in its tab completion, so when you select between multiple matching names you can differentiate them by their corresponding e-mail addresses (or if no e-mail address is provided, it shows the account id number next to those names) | 22:36 |
fungi | the assumption there is that no two accounts will have the same e-mail address (which is not always a valid assumption, but gerrit happens to include a unique constraint on e-mail addresses for accounts to make it so) | 22:37 |
SotK | we also have a unique constraint on emails, so can rely on the same assumption | 22:39 |
fungi | ((or rather it should, but instead of enforcing it at the database layer it tries to enforce that in its service and misses a few uncommon code paths which can allow duplicate accounts with the same address to slip in... but that's because they've made some poor life choices)) | 22:40 |
SotK | and yeah, I think that the webclient can be made to handle translating the readable thing entered into something that the api can use without making the user type ID numbers | 22:40 |
fungi | (((gerrit, i mean, not storyboard)) | 22:40 |
fungi | ) | 22:40 |
fungi | but to continue with the gerrit reference comparison, api calls which allow you to query by user require a unique identifier but allow you to use any of the several possible unique identifiers interchangeably, they don't bother to implement a solution for querying by a non-unique user identier except in the specific method that searches for users, and that is defined to return a list of zero or more user | 22:44 |
fungi | objects which include their respective unique identifier details | 22:44 |
*** cmoura has quit IRC | 22:45 | |
fungi | this allows client implementations to accept non-unique identifiers and then prompt for disambiguation before feeding the choice into an actual query by corresponding unique identifier | 22:46 |
fungi | it does however mean that, for example, if you want to search for changes proposed by a specific user you can either use a client to perform fuzzy searching for specific accounts to help you build your query, but otherwise if you want to write the query in its entirety you need to actually know a guaranteed unique identifier for an account | 22:48 |
fungi | (e-mail address, account id number, ...) | 22:48 |
fungi | they could have chosen to let you put non-unique account identifiers as search terms in those sorts of queries, but then they would have needed to make additional presentation choices to disambiguate the results when that non-unique identifier matched multiple accounts | 22:50 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!