Re: go repos concerns
Fede, Drasko and Jeremy,
thanks all for the comments and review. I will point you all to the fact that we did hash on this problem for some time in the working group meetings. At the time, it was decided that each WG could feel free to implement as they see fit for this first implementation. In the core WG we wanted libraries in different repo for the ability to share/modify them like we do in Java. For others like in the Applications WG, you all wanted a single repo.
At that time, we all acknowledged that different approaches was going to create issues where duplication would occur in some cases (which we said was the responsibility of the maintainers to keep up with changes) and create complexity of many repo in other cases.
So while I follow and appreciate the discussion here, I fail to see any new evidence or arguments being introduced. So are we all asking to open up this decision to new review? And if we are reopening the discussion, are people wishing to change their original view point?
If we are just going to open this discussion to rehash the same issues and people are still holding to their same opinions, I am not sure of the value in doing so. Instead, I'd like to have the teams make a little more progress in developing their respective Go services and then start to look at the issue again with more evidence of why we need to move in a particular direction.
Am I missing something?
From: edgex-golang-bounces@... <edgex-golang-bounces@...> on behalf of Jeremy Phelps <jphelps@...>
Sent: Monday, December 18, 2017 9:01 AM
To: Fede Claramonte
Subject: Re: [Edgex-golang] go repos concerns
Hi Fede,These are actually all really good points, I appreciate you bringing them up. I agree that we need to discuss this as there are some cases where it could cause us some troubles.
1) Each time a repo changes we all will need to update the vendor folder manually. I think it will be wearisome and error-prone.
2) Another problem is to know if a change in any module (e.g. core-domain-go) breaks some other module. We will need to manually compile all the dependent modules to make sure we will not break any other module.
3) Previous point will be also influence how CI is implemented, it will need to launch several jobs after a change to test if it breaks some other module.
On Mon, Dec 18, 2017 at 8:40 AM, Fede Claramonte <fclaramonte@...> wrote: