[almighty] Names and Definitions

[Max Rydahl Andersen]

>> 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.

Could we in future use GitHub and jira as our backend for issues ? I 
doubt it. Could we make it so we could sync more data between the 
systems ? Sure - but I think we can get more done and be more useful to 
users if we do not try and treat the remote issue trackers as backends.

By definition - if they are remote issues they are *not* in a backend, 
if they are in our backend they are not remote issues.

/max

>
>>
>>
>>
>> On Mon, Sep 26, 2016 at 3:07 PM, Andrew Lee Rubinger <alr at redhat.com>
>> wrote:
>>
>>> Something I'd like to iron out sooner than later are common terms 
>>> and
>>> definitions, because getting to a mutual understanding about what 
>>> we're
>>> referring to starting to be pretty relevant. :)
>>>
>>> Alongside the discussions we had on this list last week, could I ask 
>>> the
>>> UXD team to take the lead on moderating the definitions and 
>>> relationships
>>> among the following constructs?  A graphical representation of
>>> relationships where appropriate would be wonderful.
>>>
>>> * "Almighty System" - An instance of Almighty.  Contains all 
>>> "Almighty
>>> User" accounts and "Almighty Projects".
>>> * "Almighty Project" - A top-level container for an application 
>>> shared
>>> among users/teams.  May hold N "Codebases", has issue tracking, 
>>> build and
>>> deployment environments.  Eventually will have realtime 
>>> communications.
>>> * "Codebase" - Basically a repository.  Can be N in a "Project"
>>> * "Environment" - Target for running builds or deployments
>>> * "Almighty User" - My account
>>> * "Workspace" - The WebIDE view of an "Almighty Project".  Contains 
>>> the
>>> "Codebases", each of which may require its own Stack to be 
>>> built/tested.
>>> * "Stack" - Runtime to build a codebase or deploy its resultant
>>> artifacts.  In practice, equates to an image which may be run as a
>>> container.  NOTE: currently Che, as I understand it, has one Stack 
>>> per
>>> Workspace.  We'll need to address that in order to support opening, 
>>> for
>>> instance, a Java codebase and a Node codebase in the same workspace.
>>> * Other important concepts I've missed here
>>>
>>> The terms definitions I'm using here are placeholders and could 
>>> likely do
>>> with something else that's descriptive and not so overloaded.  The
>>> definitions are also up for debate -- everything is open to review 
>>> now, but
>>> let's try to get things at this level to gel quickly.
>>>
>>> S,
>>> ALR
>>>
>>> --
>>> Red Hat Developer Programs Architecture
>>> @ALRubinger
>>>
>>> _______________________________________________
>>> almighty-public mailing list
>>> almighty-public at redhat.com
>>> https://www.redhat.com/mailman/listinfo/almighty-public
>>>
>>>
>>
>>
>> --
>> Len DiMaggio (ldimaggi at redhat.com)
>> JBoss by Red Hat
>> 314 Littleton Road
>> Westford, MA 01886  USA
>> tel:  978.392.3179
>> cell: 781.472.9912
>> http://www.redhat.com
>> http://community.jboss.org/people/ldimaggio
>>
>>
>>
>
> -- 
> Red Hat Developer Programs Architecture
> @ALRubinger


> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public


/max
http://about.me/maxandersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160926/9b5c5dc3/attachment.htm>