[02:59] <wallyworld> kelvinliu: no rush, here's a small juju run fix for the new actions UX https://github.com/juju/juju/pull/11978
[05:01] <hpidcock> kelvinliu: when you get a chance, no rush https://github.com/juju/juju/pull/11979
[05:02] <kelvinliu> looking
[08:52] <stickupkid> are we always required to have a metadata in a charm?
[08:56] <stickupkid> do we have any documentation about what a charm is, at it's raw basic form?
[08:56] <stickupkid> so i can crib from it
[09:47] <stickupkid> achilleasa, https://github.com/juju/charm/pull/318
[09:48] <stickupkid> if I can't find it, then it might help if I write what I found
[09:59] <achilleasa> approved; you also need to land against V2
[10:00] <achilleasa> ah... nvm it's charm not bundlechanges... doh!
[10:20] <achilleasa> stickupkid: https://github.com/juju/bundlechanges/pull/67
[10:20] <achilleasa> with lots of extra tests :D
[10:24] <stickupkid> achilleasa, https://github.com/juju/bundlechanges/pull/67/files#diff-f447f119094ea333680948095a672515R769
[10:24] <stickupkid> can't you using thisSet.Difference()?
[10:24] <stickupkid> or are you wanting to exit early?
[10:28] <achilleasa> difference allocates and populates a new map. Given that the comparison process for the grouping is pretty much O(n^2), I opted for early exit plus 1 less allocation
[10:28] <achilleasa> though in principle it shouldn't matter much as the number of endpoints is usually small
[10:29] <stickupkid> achilleasa, i'd say, lets use difference and if performance is an issue swap to that
[10:29] <stickupkid> premature optimisation etc
[10:33] <achilleasa> ok, let me amend the last commit
[10:38] <stickupkid> ok, why does GUIArgs change when doing the exposed related stuff?
[10:40] <achilleasa> it seems that the general pattern is that we add new fields to guiargs as well
[10:40] <achilleasa> question is whether that is being used now by the new gui or not
[10:40] <stickupkid> GUIArgs are dead aren't they
[10:40] <stickupkid> ?
[10:40] <stickupkid> jam, will know
[10:41] <achilleasa> not sure :D
[10:41] <achilleasa> so I just add extra things to be consistent
[10:44] <stickupkid> considering we're bumping bundlechanges, we should consider if GUIArgs is required anymore?
[10:45] <achilleasa> as this is V3, we can land this if it looks OK and I can raise it in standup. If we don't need it we can kill it in master
[11:15] <stickupkid> achilleasa, got one for you https://github.com/juju/charm/pull/319
[11:15] <stickupkid> achilleasa, this encompases the changes we discussed yesterday (dropping the ch: prefix for urls)
[11:16] <stickupkid> * when using String()
[12:01] <achilleasa> stickupkid: you bumped the application facade to V13 on develop right? (to add CharmOrigin)
[13:27] <stickupkid> erm...
[13:27] <stickupkid> yeah
[15:48] <stickupkid> achilleasa, no idea why they didn't just go with https://github.com/juju/charm/pull/319#discussion_r485717169
[15:49] <stickupkid> achilleasa, they would have been named as well to make it much more readable
[15:56] <achilleasa> I bet this will come back and bite us some time in the future and we will have to use versioned URLs...
[16:08] <stickupkid> achilleasa, we have 3 already
[16:08] <stickupkid> haha
[16:37] <jam> stickupkid, achilleasa : 'username@" wouldn't work there, because that would be "who am I connecting to the store as" not "who owns this charm".
[16:38] <achilleasa> jam: couldn't that simply be another query param? e.g. &author=foo
[16:39] <jam> achilleasa, it certainly could, though in the end we're moving to the Snap model where the namespace itself doesn't show off the author
[16:39] <jam> eg, it isn't jameinel/juju it is just 'juju' and the owner is off in the details of the project