Hi
Sadly this is not true for all projects.
There were severe synchronization problems between Eclipse and
GitHub that could not be resolved from the Eclipse end and so GitHub
support was discontinued; for some projects this was with extreme
prejuduce, for other it just happens to still work.
Thus https://github.com/eclipse/qvtd/network became a 404, while
https://github.com/eclipse/ocl/network remains.
(The 404 is perhaps better than the VERY stale content that was
available.)
Regards
Ed Willink
On 30/03/2016 08:08, Stefan Xenos
wrote:
You don't strictly need the official project to be on
github in order to fork it there. I do most of my work on a JDT
core fork hosted on github, and the fact that the original is on
eclipse.org
hasn't been a blocker.
Isnt one of the key advantages of Github vs Eclipse
that you can fork a repo in the first place and then
produce a commit and a pull request. In Eclipse you can
only keep private copies of the Git repo on your local
machine/private repo but no public copies at Eclipse….
christian
I’m been working with several GitHub-hosted projects,
and I’m not a fan. My 2¢:
- Reviewing sends out reams of email messages:
Github sends an email immediately on each
comment, and there’s no way to batch your
changes. The only workaround is to have your
team members turn off notifications and post a
final message where you name them individually
to say ‘finished my code review’.
- There’s no way to indicate summary
disagreement that other reviewers can see like
Gerrit’s -1 or -2.
- It results in people ignoring review
comments from others, only to discover that
the author has decided to rework the
approach based on the comments.
- There’s a tradeoff in how you update a pull
request (PR; a changeset in Gerrit terms). You
can use “—amend” and force up a new version,
which at least marks the previous commits as
stale, though the review comments still show.
Or you can put your changes in new commits, so
that changes are easily discerned, but then
newcomers to the PR walk through the historical
record.
- And beware that Travis doesn’t re-evaluate
updates to a PR
- When you merge a PR, it’s not clear what is
actually committed to the log message.
- Opaque identifiers in commit messages (e.g.,
“Closes #105”) seem to reference issues, but
sometimes PRs?
What I do like:
- Markdown almost everywhere; I really wish we
had this in Bugzilla and Gerrit
- Being able to search the repository is great.
- Being able to see more code above and below in
the PR is helpful.
- Being able to drag in images/screenshots is
great.
Brian.
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
USt-IdNr. DE207665352
-------------------------------------------------------------
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
IMPORTANT: Membership in this list is generated by processes
internal to the Eclipse Foundation. To be permanently removed
from this list, you must contact emo@xxxxxxxxxxx
to request removal.
_______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
|
