Freso: did you check to see if your admin privs on jira work?
2015-09-11 25429, 2015
Leo_Verto
ah, found a working one
2015-09-11 25439, 2015
ruaok
Leo_Verto, LordSputnik: Freso and I also discussed that we should probably rejigger the IRC channels we have.
2015-09-11 25403, 2015
LordSputnik
ruaok: yeah, we've mentioned that idea a couple of times in #bb-devel too
2015-09-11 25412, 2015
Leo_Verto
Mhm, I mentioned an idea I had for that during the last meeting
2015-09-11 25417, 2015
LordSputnik
What have you been thinking?
2015-09-11 25428, 2015
ruaok
one suggestion was to have: #musicbrainz and #metabrainz-devel
2015-09-11 25441, 2015
ruaok
and #bookbrainz
2015-09-11 25402, 2015
LordSputnik
That sounds good to me
2015-09-11 25415, 2015
ruaok
even then I wonder if bookbrainz makes a lot of sense.
2015-09-11 25417, 2015
Leo_Verto
my idea was to keep one channel per major project for internal discussions and direct general help to #metabrainz
2015-09-11 25431, 2015
ruaok
the idea is to concentrate the devlopment in one place.
2015-09-11 25432, 2015
Leo_Verto
I thought to keep the -devel channels though it might be cleaner without that
2015-09-11 25436, 2015
Leo_Verto
ah
2015-09-11 25436, 2015
LordSputnik
ruaok: It doesn't right now, but it probably will eventually
2015-09-11 25451, 2015
ruaok
LordSputnik: exactly.
2015-09-11 25454, 2015
Leo_Verto
the opposite of my idea then :P
2015-09-11 25405, 2015
ruaok
as we get too much noise in one channel, we create a separate channel.
2015-09-11 25416, 2015
ruaok
#musicbrainz is clearly needed
2015-09-11 25443, 2015
ruaok
but #critiquebrainz would be dead and empty. clearly something we need to change, but in the short term another solution might be good.
2015-09-11 25412, 2015
LordSputnik
Mhmm, I think the more people looking at development talk, the better
2015-09-11 25412, 2015
ruaok
#metabrainz -- discussion on general metabrainz projects except musicbrainz, #musicbrainz for musicbrainz and #metabrainz-devel for metabrainz development.
2015-09-11 25434, 2015
ruaok
LordSputnik: exactly. hence only one devel channel for all things.
2015-09-11 25451, 2015
ruaok
besides Freso pointed out that we have a lot of shared things in common.
2015-09-11 25400, 2015
Leo_Verto
hmm, a single devel channel would be a lot of noise though
2015-09-11 25402, 2015
ruaok
perhaps not code, but hosting, community, concepts, etc.
2015-09-11 25419, 2015
LordSputnik
Leo_Verto: we're already all in #mb-devel though :P
2015-09-11 25421, 2015
ruaok
Leo_Verto: it has the potential to become noisy, yes.
2015-09-11 25439, 2015
ruaok
but even if combine bookbrainz-devel and muscbrainz-devel, its still not too noisy.
2015-09-11 25450, 2015
LordSputnik
Leo_Verto: and I don't think it'd hinder us talking about BB development
2015-09-11 25456, 2015
ruaok
and once it does become too noisy, you break our a new channel.
2015-09-11 25408, 2015
Leo_Verto
yeah, it will make it more difficult to filter relevant backlog though
2015-09-11 25421, 2015
ruaok
the main idea behind this is not have 6 dead -devel channels were people are constantly popping asking if the project is dead.
2015-09-11 25426, 2015
Leo_Verto
heh
2015-09-11 25405, 2015
LordSputnik
Leo_Verto: perhaps that just means we should focus more on posting important stuff on the mailing list to save the need to search IRC backlog?
2015-09-11 25421, 2015
Leo_Verto
yeah, that might work
2015-09-11 25446, 2015
LordSputnik
I'll mention this in the mailing list progress update this week, so we can all agree on something
2015-09-11 25450, 2015
Leo_Verto
we could also get the bot to parse our already used <BANG> </BANG> tags and link meeting chatlogs on the mailing list :P
"Add-ons are always free for community and open-source licenses." :D
2015-09-11 25416, 2015
Leo_Verto
supports JIRA server 6.0+
2015-09-11 25415, 2015
LordSputnik
mind you, the latest iteration of OpenID appears to be built on top of OAuth 2.0
2015-09-11 25455, 2015
Leo_Verto
yeah, saw that
2015-09-11 25408, 2015
Leo_Verto
though I don't think it'd work with just an OAuth2 provider, would it?
2015-09-11 25432, 2015
ruaok
I think we need to carefully examine our security needs and possible motivations for someone to attack us or our users.
2015-09-11 25445, 2015
ruaok
do we have needs that go beyond,
2015-09-11 25411, 2015
Gentlecat
we use oauth2 and it works fine as far as I can see
2015-09-11 25414, 2015
ruaok
not exposing passwords in out net communications?
2015-09-11 25424, 2015
ruaok
*our
2015-09-11 25453, 2015
ruaok
and why would someone attack us? or try to take over someone's jira account?
2015-09-11 25401, 2015
ruaok
to steal their bugs so they can fix them before someone else?
2015-09-11 25408, 2015
LordSputnik
ruaok: so you think we could use HTTPS encrypted basic auth?
2015-09-11 25411, 2015
Gentlecat
plenty of other services do too: google, facebook, microsoft. you name it
2015-09-11 25425, 2015
ruaok
so, the oauth bearer token thing doesn't seem like a big problem for us.
2015-09-11 25444, 2015
ruaok
LordSputnik: I would rather use what we have and know works.
2015-09-11 25404, 2015
ruaok
and oauth2 seems to fit the bill and work "well enough".
2015-09-11 25412, 2015
Leo_Verto
as long as we keep our HTTPS setup up to date and don't make any gross configuration mistakes, we should be fine :P
2015-09-11 25408, 2015
ruaok
and maybe we just keep our own install of jira.
2015-09-11 25414, 2015
Leo_Verto
hmm, I kinda agree with Ben though, what we primarily need is authentication, not authorisation, and while OAuth 2 can apparently handle both in recent versions, OpenID might be easier for us to work with
2015-09-11 25419, 2015
ruaok
that may just be the right thing to do. esp if we have a dedicated sysadmin
2015-09-11 25404, 2015
LordSputnik
ruaok: what's preventing us allowing basic authentication to MeB over HTTPS?
2015-09-11 25413, 2015
LordSputnik
because that would also work with JIRA
2015-09-11 25418, 2015
Gentlecat
Leo_Verto: another issue is that we'll need to support two systems instead of one
ruaok: Or #musicbrainz , #metabrainz , and #bookbrainz
2015-09-11 25453, 2015
ruaok
Leo_Verto: yeah, once I get the gateways deployed properly, I want to remove the diffie helllman bit.
2015-09-11 25456, 2015
Leo_Verto
okay, I'll have to leave now but from what I've read so far, OpenID would probably suit us best, if it can be set up in all relevant systems
2015-09-11 25409, 2015
ariscop joined the channel
2015-09-11 25421, 2015
Leo_Verto
see ya
2015-09-11 25424, 2015
ruaok
Leo_Verto: I really don't want to setup yet another piece of technology. the idea to remove things.
2015-09-11 25436, 2015
Freso
Leo_Verto | I'm sure that's a feature we don't want to port, isn't it? :P -- I didn't make a ticket for it anyway. :)
2015-09-11 25455, 2015
LordSputnik
ruaok: yeah, actually, thinking about this, it's probably best to keep hosting JIRA as you suggested. I don't think there's a way that we can hook up MB accounts with Atlassian Cloud
2015-09-11 25407, 2015
Freso
Leo_Verto | do we have to use OAuth 2? -- Maybe not, but we already have an OAuth2 endpoint on mb.o which is used by AcousticBrainz, AcoustID, MB Picard, CritiqueBrainz, ..., replacing it would be a *lot* of work and break backwards compatibility with software relying on it, and adding an alternative is one more thing that needs to be kept maintained.
2015-09-11 25444, 2015
Freso
ruaok | and why would someone attack us? or try to take over someone's jira account? -- E-mail address harvesting comes to mind.
2015-09-11 25449, 2015
LordSputnik
ruaok: so do you have a plan for SSO with MB-hosted JIRA?
2015-09-11 25405, 2015
Freso
LordSputnik: Not if it can be helped.
2015-09-11 25442, 2015
LordSputnik is trying to work out which message that was aimed at... basic auth?
2015-09-11 25416, 2015
Freso
As ruaok said, we really, really want to host/support fewer things. Which likely means that if hosted JIRA won't work with OAuth2 SSO, we're probably more likely to look for another ticket tracker that we won't have to host and which will support it.
2015-09-11 25445, 2015
Freso
Nowhere in those cards do we have SSO on the MB-hosted JIRA instance.
2015-09-11 25426, 2015
LordSputnik
Freso: But then we lose all of the existing tickets
2015-09-11 25435, 2015
Freso
LordSputnik: Yes.
2015-09-11 25447, 2015
Freso
Unless we import them to the new system.
2015-09-11 25401, 2015
Freso
This would not be the first time we've changed ticket tracking software.
2015-09-11 25430, 2015
LordSputnik
So we'd be looking for a cloud hosted ticket tracker with OAuth2 support *and* allowing import from JIRA
2015-09-11 25442, 2015
LordSputnik
I don't suppose there are too many solutions for that
2015-09-11 25404, 2015
Freso
Most systems have some kind of importing, JIRA allows to export. If need be, some kind of translation can go on between Jira's export and the expected format for import.
2015-09-11 25442, 2015
LordSputnik
Freso: Do we really need SSO for the ticketing system, if it's something we previously haven't had
2015-09-11 25452, 2015
Freso
LordSputnik: Yes.
2015-09-11 25416, 2015
Freso
We also haven't previously had SSO for wiki or forums, but that doesn't mean it hasn't been needed.
2015-09-11 25409, 2015
Freso
We really, really want "One Account to Rule Them All" so people don't have to juggle multiple accounts to contribute meaningfully to M(e)B.
2015-09-11 25401, 2015
LordSputnik
I don't think you'll find a ticket tracker with all those criteria. Especially one free for open source
2015-09-11 25443, 2015
Freso
It doesn't necessarily have to be free.
2015-09-11 25413, 2015
Freso
Also, "all those criteria"? Primary criteria are "supports SSO with OAuth2" and "not hosted by MeB". The rest can be taken from there.
2015-09-11 25428, 2015
LordSputnik
I still think it'll be difficult to find an issue tracker that allows OAuth2.0. In fact, after reading more about JIRA, it doesn't support any form of external account sign in - those REST API articles Leo posted earlier are for logging into JIRA via the API with JIRA credentials. So it doesn't even support OAuth 1
I didn't realize that plugin supported OAuth2 previously...
2015-09-11 25417, 2015
Freso
Even if it didn't, supporting OpenID != "doesn't support any form of external account sign in"
2015-09-11 25442, 2015
LordSputnik
Freso: well, that is a plugin, and it doesn't work with the cloud
2015-09-11 25408, 2015
Freso
Jira also supports at least LDAP, which is what was previously the plan for SSO, prior to luks' OAuth2 implementation.
2015-09-11 25405, 2015
LordSputnik
So, perhaps a viable plan would be to upgrade our own JIRA to the latest version, then trial that plugin and see if it'll work for us
2015-09-11 25455, 2015
LordSputnik
ruaok: I think no matter what we eventually decide to do with SSO, if nothing is blocking the JIRA upgrade, perhaps we could proceed with that? I'd be happy to help if I can :)
2015-09-11 25412, 2015
ruaok
LordSputnik: the issue with the jira update is a privacy concern that we haven't settled.
2015-09-11 25421, 2015
ruaok
there are email addresses and thus only an contractor can really work on that.
