Bug 1222392 - TECH DEBT: migrate all javascript projects to zanata server's github repo
Summary: TECH DEBT: migrate all javascript projects to zanata server's github repo
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Zanata
Classification: Retired
Component: Maintainability
Version: 3.7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.7
Assignee: Patrick Huang
QA Contact: Damian Jansen
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-18 06:48 UTC by Patrick Huang
Modified: 2015-07-22 02:19 UTC (History)
5 users (show)

Fixed In Version: 3.7.0-SNAPSHOT (git-jenkins-zanata-server-github-pull-requests-3667)
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-22 02:19:49 UTC
Embargoed:


Attachments (Terms of Use)

Description Patrick Huang 2015-05-18 06:48:17 UTC
Right now we have zanata-assets lives in luke's personal github repo.
user profile page lives in pahuang's personal github repo.
zanata-spa as a standalone repo

Ideally migrate all to under zanata-server repo. At the very least we should find a way to make sure we have a streamline process of integrating these repo's build artifact into zanata server build process.

Comment 1 Patrick Huang 2015-05-22 05:15:25 UTC
https://github.com/zanata/zanata-server/pull/825

Comment 2 David Mason 2015-06-01 01:57:05 UTC
I definitely agree that we should have a streamlined process to integrate the editor into the server.

I strongly disagree with moving the editor code into the zanata-server repository. We get some major benefits from having the editor as a separate module:

 - contributors can work on the editor without the need to download all the server code or go through the complex setup process to build and deploy the server.
 - contributors can easily figure out how to build the editor when it is not buried somewhere in the server repository hierarchy.
 - we are likely to package the editor as a standalone client some time, so it should be separate for that purpose.
 - the editor on its own can build quickly, so contributors can be productive with it.

Comment 3 Luke Brooker 2015-06-01 02:17:33 UTC
To me, the ultimate version of this would be, a separate repo that can access the real API.

Comment 4 David Mason 2015-06-01 03:13:34 UTC
(In reply to Luke Brooker from comment #3)
> To me, the ultimate version of this would be, a separate repo that can
> access the real API.

This is the ultimate, as long as we can get the real API to be easy and fast to set up and deploy.

Right now, I would not want to stop a developer who is great with Angular from contributing to the editor because they could not jump through all the hoops to get the server running.

There may be a way to record a load of requests and responses from the real server and use those, although that could never cover every permutation of requests and timing, so the effort may be better spend making server setup easier or making sure the fake server behaves identically to the real server. If we want to get really meta, we could make something that talks to both at once and reports on what the fake server is not doing that it should.

Comment 5 Damian Jansen 2015-06-01 04:12:38 UTC
Verified at d5b52603d50f42457624cfed20e4773c2e10c35e


Note You need to log in before you can comment on or make changes to this bug.