for the sake of "transparency" I am going to provide my (personal) point of view on the issue you are raising:
Lack of Unit Tests
That was already tracked in
this issue and I would suggest that you open an issue as this one if you spot some area in the code that are not well covered. That will make it easier to prioritize and involve contributors.
Use of branches and forked repos
The repositories/branches you mentions are all temporary. Please let me know if there are some repositories that we do not plan to merge because that's something that need to be fixed!
Reduce quality standards to do something quick for some event
Quality is tracked by our QE team. There hasn't been any particular high rate of regressions in the last period. In the contrary there have been some great improvements. Of course Che 7 workspaces are not covered by QE yet but this is still considered a "tech preview" so that's normal. But before and that's the problem we need to have been doing code reviews for every, we haven't broke
Major code developed in github repositories non belonging to eclipse org
Again, this has been used for initial development of "tech preview" features. I don't see any issue with it. We need to get rid of these repositories before releasing Che 7 as beta.
Tracking upstream Che related issues outside eclipse/che
I agree with you on that one. We need to be more careful with that. Asking the issue author to move it upstream or adding a comment on the issue may be enough for now.
I am going to repeat myself but...it has been used for initial development of "tech preview" features and I don't see any issue with it.
And about your proposals:
Repository with zero number of unit test is not an option
We should definitely avoid merging code without unit tests in master. But 1) we cannot enforce such a rule on forks or branches where preliminary work has just been started 2) code reviewers should be flexible enough and merge a PR even if it's not perfect (i.e. a new contributors PR, a urgent fix etc...) 3) quality is not about unit tests only: there can be awful code covered by awful unit tests and brilliant code with no unit test and I would rather merge the latter.
Yes, this is the plan. We need to get that done for Che 7 beta.
Abandon the practice to hide code development in nonEclipse repositories
As long as we track the issues in eclipse/che and cross-reference them in the PRs done in other repositories I am ok with it. And for initial development I don't see why we should avoid using non eclipse repositories if that makes sense for some reasons: we are not sure of what CQs need to be created yet, we have requested CQs but have not approvals, we want to prototype something without breaking the rest etc...
Keep the practice of features-branches
Contributors should be free to do whatever they want. I am against any hard rule on that.
Your other suggestions are kind of duplicata of others so I am not going to comment on them...
Hi
I would like to discuss some practices and issues that I think reduce the overall quality and transparency of development.
1. The code in some repositories is suffering from a low number of tests that is not cover functionality.
Example [1] or [2]
What I can see it's mostly GO-based. But I think if we look closer we can find more.
2. We hiding issues(problem) with CQ process or undesired to keep code in branches in forked repositories [1] or [3]
3. Sometimes we ready to reduce our quality standards because we want to do something quick for some event [4]
and package it back as configuration [5] [6] [7] [8]
But this concrete case with [4] [9] make me fill that it's up to external company manager to decide should we have a priority to put the code back to upstream.
My proposal
1. Repository with zero number of unit test is not an option. POC it's a good time to at least start write testing, later can be too late.
2. We must move all code to
https://github.com/eclipse/che-* repositories and abandon the practice to hide code development in nonEclipse repositories and referencing it as an image in master.
3. I know it's pain, but I see no other way. Keep the practice of features-branches for the code that is not ready to merge in master because of some other reason.
4. We should increase transparency of code development for the community with a clear process:
BTW with new Type A/Type B process it should no be SOOOO painful. If it's not the case then I think we should identify a concrete problem and fix it instead of running away from it.
Links
--
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/che-dev
