Difference between revisions of "Platform-releng/Migration To GitHub"

Revision as of 01:24, 11 March 2021

This page is meant to capture ideas, concerns, evaluations, experimentations... that can help the Platform project in moving to GitHub.

Attract more contributors by using a more known workflow on a popular Platform

Moving to GitHub is an opportunity but also has drawbacks:

GitHub code review is not perceived by some committers as good as Gerrit
GitHub issue tracker is not perceived by some committers as usable at the scale of Platform project (lack of depends on/blocks/clone relations, difficulty to list attachements, linked patches...)
The process for contributing to Eclipse project via GitHub is currently cumbersome and not productive enough for new contributors (Signed-Off-By requirement cause a lot of noisy descripton and some contributions are abandoned)
... [Please add more missing items] ...

Generally

For each repository

[Sravan] Excellent idea. this also eliminates use of comparator. Here are the steps we are doing now.

Calculate qualifier based on last commit timestamp in UTC(in Eastern time for features)
Build the bundle with the usual process.
Check if we have this particular bundle with same version along with qualifier in the existing comparator repository(called baseline. Do not get confused here there are multiple baselines used across releng. lets call this as comparator baseline)
If not that is the end of building the bundle.
If exists, dissemble all the class files in the newly built bundle and from the comparator baseline.
Compare the all the files(including disassembled class files) in the bundle ignoring signing changes.
If changes are found throw comparator error
Replace newly built bundle with the bundle from comparator baseline. Note this happens always even when we don't have any comparator errors.

Here are some bugs recently I handled in this area bug 571840

Another thing to note here is when we change compiler, there will be changes to generated class files. How can we report these issues?

@@ Line 37: / Line 37: @@
 == Build Process ==
 * Only build the bundle that was changed and not build the whole IDE
+[Sravan] Excellent idea. this also eliminates use of comparator. Here are the steps we are doing now.
+# Calculate qualifier based on last commit timestamp in UTC(in Eastern time for features)
+# Build the bundle with the usual process.
+# Check if we have this particular bundle with same version along with qualifier in the existing comparator repository(called baseline. Do not get confused here there are multiple baselines used across releng. lets call this as comparator baseline)
+# If not that is the end of building the bundle.
+# If exists, dissemble all the class files in the newly built bundle and from the comparator baseline.
+# Compare the all the files(including disassembled class files) in the bundle ignoring signing changes.
+# If changes are found throw comparator error
+# Replace newly built bundle with the bundle from comparator baseline. Note this happens always even when we don't have any comparator errors.
+Here are some bugs recently I handled in this area
+{{bug|571840}}
+Another thing to note here is when we change compiler, there will be changes to generated class files. How can we report these issues?
 == Other noteworthy items ==