[almighty] Names and Definitions

[Andrew Lee Rubinger]

On Tue, Sep 27, 2016 at 3:46 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 26 Sep 2016, at 21:54, Andrew Lee Rubinger wrote:
>
> On Mon, Sep 26, 2016 at 3:51 PM, Max Rydahl Andersen <manderse at redhat.com>
>
> wrote:
>
> P.S. I noticed your reference to bug tracking - will this be an external
> system (bugzilla, JIRA, git, etc.) or something that we will build in?
> Yes. :P
> It's our own view of the issue-tracking world, so it's internal.
> Additionally we will be using other systems as extensible backends and
> data
> providers.
> to be clear - almighty notion of remote issues is explicitly kept simple
> so we do *not* need to treat them as backends, but mainly data providers.
>
> Let's wait for Aslak on that. I'm not sold. :)
> Example use case: writing/editing an issue. Done internally and would need
> to be propagated back. I view this as "under review" not a conclusion yet.
>
> creating a basic issue in the remote system - sure.
> updating basic status and description - sure.
>
That's a write operation.  Write operations infer some contract.  That's
enough for me to believe it's possible we need an SPI model to fulfill it.

But again I think this discussion is one we'll need to continue from
several angles to come at a conclusion.  We haven't reached it yet. :)

> creating and editing full blown issues as complete as jira or bugzilla has
> it ? No.
>
Hey, Strawman, nobody said that. :P

> Again, if you want full two-way sync then you are *not* talking about
> what we have
> called remote issues since day one.
>
"I never said that." - Donald Trump (he did, but I didn't)

> The "remote" part is first class concept - it is an issue that is not
> "owned" or managed by almighty directly and we want to include in overall
> plan - it will/can have different comment thread, different assignee etc.
> than the actual issue remotely.
>
> Having a different backend for storing actual issues != having support for
> remote work items.
>
> Lets at least make sure we keep those concepts/concerns separate so we are
> clear on what usecases we are trying to solve.
>
+1, the concepts we need to support with regards to remote systems are what
draws up the contract.  And even a small contract means some SPI in my view.

Let's break this discussion off this thread; it's its own topic. :)

S,
ALR


> /max
> http://about.me/maxandersen
>



-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160927/5f170abc/attachment.htm>