| Re: [gef-dev] GEF4 0.3.0 vs. 1.0.0, GitHub migration |
Hi,
we tried to follow a Gerrit-like workflow of the following steps:
1. Create a pull request
2. Some inline comments were added
3. The branch of the pull request was modified (e.g. rebase, or maybe adding new modifications)
4. At this point, the inline comments were missing
5. The request can be added with a fast-forward merge
Note, that step 3. usually requires a force push, as the contributor already pushed this into his own public branch on Github (the one the PR is created from).
What works:
* Create a pull request
* Add inline comments
* Add extra commits to the pull request
* At this point, the comments are still available
* The pull request merge might require a merge commit at this point
For external contributions, the first version is closer to what I imagine is worth (at least if inline comments are removed), as that would provide a history for the contribution itself; however, if the Github PRs would provide more contributions (e.g. its easier), it could make Github preferable.
Oh, and one final thought (albeit minor): in Gerrit, you can send all comments from a reviewer in a single message (basically, they are transactioned); in case of Github, every comment will be sent separately.
I hope, this was more understandable.
Cheers,
Zoltán
-- Zoltán Ujhelyi
Technology Expert
IncQueryLabs Ltd.
> On 22 Jan 2016, at 22:55, Wienand, Matthias <matthias.wienand@xxxxxxxxx> wrote:
>
> Hi all,
>
> thanks to everyone for the good work :-)
>
> +1 for contributing GEF4 1.0.0 to Neon with M6. Some features are missing in the Zest and Dot components, however, the implementation of which should not break the API, and we should be able to address some of the them for M6.
>
> @Zoltán, could you elaborate on the GitHub issue, please? As far as I know, pull requests can be reviewed, discussed, and the code can be further modified if needed, before completing the change. In order to prevent merges, we could enforce rebasing onto the "original" branch, or would this complicate/interfere with the process?
>
> Best regards,
> Matthias
>
> 2016-01-22 20:56 GMT+01:00 Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxxxxxxxx>:
> Hi,
>
> first of all, thank you for your great work. I myself still have not lived up to my promise to fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=433529, so I feel somewhat guilty, about making you do the extra work with 0.3.0. Sorry. :)
>
> If you feel the codebase is mature enough, lets go for 1.0.
> ——
>
> About Github vs Gerrit: I have worked with both on different projects for some time, and the thing is, both suggest very different workflows. Gerrit asks everything to be reviewed, and then the final, cleaned-up version goes into the repository; in case of Github pull requests you add new commits to the branch (otherwise all comments for the previous branch will be lost), thus a series of commits gets merged.
>
> I personally like the Gerrit approach better, but it requires some time getting used to. I guess, this is why most of my collegues like Github better (and so probably other possible contributors as well).
>
> In short: I have mixed feelings, but am ok with both. Furthermore, it seems I am not the one doing most work, so the preference shouldn’t be mine. :)
>
> Cheers,
> Zoltán
> -- Zoltán Ujhelyi
>
> Technology Expert
> IncQueryLabs Ltd.
>
> > On 22 Jan 2016, at 17:33, Alexander Nyßen <nyssen@xxxxxxxxx> wrote:
> >
> > Hi team,
> >
> > first, as Neon M5 is coming nearer (February 1st) its time to finalize our decision about whether we are going to contribute GEF4 1.0.0 or 0.3.0 to Neon (we had decided to postpone the final decision up to M5). Matthias and I have worked very intensively on cleaning up our provisional API (compared to 0.2.0 we have touched almost all of it to some extent) and I am quite satisfied with our progress. With the adoption of JavaFX properties (see 484774), which we finalized this week, we have completed the last major API change that was on the list, except for the refactoring of the Cloudio and Zest JFace APIs, which should have to be polished up to M6. While some minor adjustments may still be needed in other places as well, the API should now be in quite a good shape already. As such, I would like to contribute 1.0.0 for Neon, opening up our provisional API, for two reasons:
> >
> > 1) I think it is time for a clear signal to our adopters that GEF4 has reached a certain maturity and that we want people to start adopting it. Those that have already started to adopt it gave us valuable feedback that helped to improve the code base a lot. Even if we decide to come up with a 2.0.0 release for Neon +1 (which I would like to do), I would not like to postpone this signal by another year.
> > 2) I want to be able to guarantee strict semantic versioning to our adopters, using API tooling. Up to now, this is not possible, because no API is yet published. This leads to problems: our 0.2.0 release is e.g. not compatible to our 0.1.0 release because we broke provisional API, yet the versioning indicates compatibility; we did not contribute it 0.2.0 to the simrel repo for Mars.1 because of this, which caused some confusion). I would rather contribute a 2.0.0 release directly after the 1.0.0 than violating OSGi compatibility.
> >
> > Therefore, if nobody objects, I would plan to open up the API (and change our bundle versions from 0.3.0 to 1.0.0) after M5, so that we could finalize it up to M6 as planned (i.e we could contribute a 0.3.0 with M5 and then switch to 1.0.0 for M6).
> >
> > Second, we had discussed earlier about a potential Gerrit adoption. The idea behind this discussion was to ease things for our contributors. With the (not very convincing) experiences I have made with Gerrit so far and the current „opening up“ of the foundation with respect to GitHub, I would alternatively propose a migration to GitHub. Compared to Gerrit, GitHub IMHO makes it much easier for adopters to contribute (I have experienced that myself with Xtext and other non-Eclipse projects). As GitHub issues can now also be used in alternative to Bugzilla, a nicer integration could be used, and our HIPP infrastructure should still be usable as well. Also, as we support building up standalone graphical applications (independent of Eclipse UI) with GEF4, GitHub could be a better place to broaden our community. While the foundation wants projects to migrate on an all-or-nothing basis, I would like to rule out if there is the possibility of an exception, as I would rather leave GEF 3.x and the related issues on the Eclipse.org infrastructure. But I want your opinions first.
> >
> > Comments are thus welcome!
> >
> > Cheers
> > Alexander
> > --
> > Dr. Alexander Nyßen
> > Dipl.-Inform.
> > Principal Engineer
> >
> > Telefon: +49 (0) 231 / 98 60-202
> > Telefax: +49 (0) 231 / 98 60-211
> > Mobil: +49 (0) 151 / 17396743
> >
> > http://www.itemis.de
> > alexander.nyssen@xxxxxxxxx
> >
> > itemis AG
> > Am Brambusch 15-24
> > 44536 Lünen
> >
> > Rechtlicher Hinweis:
> >
> > Amtsgericht Dortmund, HRB 20621
> >
> > Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
> >
> > Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
> >
> >
> >
> > _______________________________________________
> > gef-dev mailing list
> > gef-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> > https://dev.eclipse.org/mailman/listinfo/gef-dev
>
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gef-dev
>
>
>
> --
> Matthias Wienand
> Fachinformatiker
>
> Telefon: +49 231 9860 202
> Telefax: +49 231 9860 211
> Mobil: +49 152 26802283
>
>
> matthias.wienand@xxxxxxxxx
> http://www.xing.com/profile/Matthias_Wienand2
> http://www.itemis.de
>
>
> itemis AG
> Niederlassung Lünen
> Am Brambusch 15-24
>
> 44536 Lünen
>
>
> Rechtlicher Hinweis:
> Amtsgericht Dortmund, HRB 20621
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
> Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino
>
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gef-dev
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/gef-dev
Matthias Wienand Fachinformatiker Telefon: +49 231 9860 202 Telefax: +49 231 9860 211 Mobil: +49 152 26802283 matthias.wienand@xxxxxxxxx http://www.xing.com/profile/Matthias_Wienand2 http://www.itemis.de itemis AG Niederlassung Lünen Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer Fiorentino