Re: EXT: Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow
On Wed, 6 Mar 2019 07:33:01 -0600 Derek Foreman wrote: > On Wed, 6 Mar 2019 at 04:49, Ray, Ian (GE Healthcare) wrote: > > > > > > > > > On 6 Mar 2019, at 11.28, Pekka Paalanen wrote: > > > > > > Going once, going twice... > > > > > > Any objections? More acks? > > Acked-by: Derek Foreman > > Personally, I really see no harm in pushing this during code freeze, > since it's not code. :) Nice, this was the final nail I was looking for, pushed: 15cba8b..808bca8 master -> master And merge requests are enabled now! Thanks, pq > > > Let's say I'll push this and enable MRs on Friday if there are no > > > further comments. More acks and I might do it sooner. :-) > > > > > > > > > > LGTM > > > > Acked-by: Ian Ray > > > > > > > Thanks, > > > pq > > > > > > > > > On Wed, 27 Feb 2019 12:35:09 +0200 > > > Pekka Paalanen wrote: > > > > > >> From: Pekka Paalanen > > >> > > >> The experience from Weston shows that the Gitlab merge request based > > >> workflow > > >> works really well. Recently there have also been issues with the mailing > > >> list > > >> that have made the email based workflow more painful than it used to be. > > >> Those > > >> issues might have been temporary or occasional, but they probably are > > >> only > > >> going to increase. > > >> > > >> The MR workflow is different, it has its issues > > >> (https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/74) and we > > >> likely lose the explicit Reviewed-by etc. tags from commit messages, but > > >> it is > > >> also much easier to work with: no more whitespace damaged patches, lost > > >> email, > > >> setting up git-send-email; we gain automated CI before any human > > >> reviewer even > > >> looks at anything, and people can jump in to an ongoing discussion even > > >> if they > > >> weren't subscribed before. > > >> > > >> If you still want email, you can subscribe to that selectively(!) in > > >> Gitlab > > >> yourself. > > >> > > >> This text has been copied from Weston's CONTRIBUTING.md of the 5.0.91 > > >> release > > >> and slightly altered for Wayland. > > >> > > >> Fixes: https://gitlab.freedesktop.org/wayland/wayland/issues/49 > > >> > > >> v2: fixed two left-over mentions of Weston > > >> > > >> Signed-off-by: Pekka Paalanen > > >> v1 Reviewed-by: Simon Ser > > >> Reviewed-by: Daniel Stone > > >> --- > > >> CONTRIBUTING.md | 147 > > >> 1 file changed, 72 insertions(+), 75 deletions(-) > > >> > > >> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > > >> index 686ed63..dcc9f56 100644 > > >> --- a/CONTRIBUTING.md > > >> +++ b/CONTRIBUTING.md > > >> @@ -4,8 +4,46 @@ Contributing to Wayland > > >> Sending patches > > >> --- > > >> > > >> -Patches should be sent to **wayland-devel@lists.freedesktop.org**, using > > >> -`git send-email`. See [git documentation] for help. > > >> +Patches should be sent via > > >> +[GitLab merge > > >> requests](https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.html). > > >> +Wayland is > > >> +[hosted on freedesktop.org's > > >> GitLab](https://gitlab.freedesktop.org/wayland/wayland/): > > >> +in order to submit code, you should create an account on this GitLab > > >> instance, > > >> +fork the core Wayland repository, push your changes to a branch in your > > >> new > > >> +repository, and then submit these patches for review through a merge > > >> request. > > >> + > > >> +Wayland formerly accepted patches via `git-send-email`, sent to > > >> +**wayland-devel@lists.freedesktop.org**; these were > > >> +[tracked using > > >> Patchwork](https://patchwork.freedesktop.org/project/wayland/). > > >> +Some old patches continue to be sent this way, and we may accept small > > >> new > > >> +patches sent to the list, but please send all new patches through > > >> GitLab merge > > >> +requests. > > >> + > > >> + > > >> +Formatting and separating commits > > >> +- > > >> + > > >> +Unlike many projects using GitHub and GitLab, Wayland has a > > >> +[linear, 'recipe' style > > >> history](http://www.bitsnbites.eu/git-history-work-log-vs-recipe/). > > >> +This means that every commit should be small, digestible, stand-alone, > > >> and > > >> +functional. Rather than a purely chronological commit history like this: > > >> + > > >> +connection: plug a fd leak > > >> +plug another fd leak > > >> +connection: init fds to -1 > > >> +close all fds > > >> +refactor checks into a new function > > >> +don't close fds we handed out > > >> + > > >> +we aim to have a clean history which only reflects the final state, > > >> broken up > > >> +into functional groupings: > > >> + > > >> +connection: Refactor out closure allocation > > >> +connection: Clear fds we shouldn't close to -1 > > >> +connection: Make wl_closure_destroy() close fds of undispatched > > >> closures > > >> + > > >> +This ensures that the final patch series only
Re: EXT: Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow
On Wed, 6 Mar 2019 at 04:49, Ray, Ian (GE Healthcare) wrote: > > > > > On 6 Mar 2019, at 11.28, Pekka Paalanen wrote: > > > > Going once, going twice... > > > > Any objections? More acks? Acked-by: Derek Foreman Personally, I really see no harm in pushing this during code freeze, since it's not code. :) Thanks, Derek > > > > Let's say I'll push this and enable MRs on Friday if there are no > > further comments. More acks and I might do it sooner. :-) > > > > > > LGTM > > Acked-by: Ian Ray > > > > Thanks, > > pq > > > > > > On Wed, 27 Feb 2019 12:35:09 +0200 > > Pekka Paalanen wrote: > > > >> From: Pekka Paalanen > >> > >> The experience from Weston shows that the Gitlab merge request based > >> workflow > >> works really well. Recently there have also been issues with the mailing > >> list > >> that have made the email based workflow more painful than it used to be. > >> Those > >> issues might have been temporary or occasional, but they probably are only > >> going to increase. > >> > >> The MR workflow is different, it has its issues > >> (https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/74) and we > >> likely lose the explicit Reviewed-by etc. tags from commit messages, but > >> it is > >> also much easier to work with: no more whitespace damaged patches, lost > >> email, > >> setting up git-send-email; we gain automated CI before any human reviewer > >> even > >> looks at anything, and people can jump in to an ongoing discussion even if > >> they > >> weren't subscribed before. > >> > >> If you still want email, you can subscribe to that selectively(!) in Gitlab > >> yourself. > >> > >> This text has been copied from Weston's CONTRIBUTING.md of the 5.0.91 > >> release > >> and slightly altered for Wayland. > >> > >> Fixes: https://gitlab.freedesktop.org/wayland/wayland/issues/49 > >> > >> v2: fixed two left-over mentions of Weston > >> > >> Signed-off-by: Pekka Paalanen > >> v1 Reviewed-by: Simon Ser > >> Reviewed-by: Daniel Stone > >> --- > >> CONTRIBUTING.md | 147 > >> 1 file changed, 72 insertions(+), 75 deletions(-) > >> > >> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md > >> index 686ed63..dcc9f56 100644 > >> --- a/CONTRIBUTING.md > >> +++ b/CONTRIBUTING.md > >> @@ -4,8 +4,46 @@ Contributing to Wayland > >> Sending patches > >> --- > >> > >> -Patches should be sent to **wayland-devel@lists.freedesktop.org**, using > >> -`git send-email`. See [git documentation] for help. > >> +Patches should be sent via > >> +[GitLab merge > >> requests](https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.html). > >> +Wayland is > >> +[hosted on freedesktop.org's > >> GitLab](https://gitlab.freedesktop.org/wayland/wayland/): > >> +in order to submit code, you should create an account on this GitLab > >> instance, > >> +fork the core Wayland repository, push your changes to a branch in your > >> new > >> +repository, and then submit these patches for review through a merge > >> request. > >> + > >> +Wayland formerly accepted patches via `git-send-email`, sent to > >> +**wayland-devel@lists.freedesktop.org**; these were > >> +[tracked using > >> Patchwork](https://patchwork.freedesktop.org/project/wayland/). > >> +Some old patches continue to be sent this way, and we may accept small new > >> +patches sent to the list, but please send all new patches through GitLab > >> merge > >> +requests. > >> + > >> + > >> +Formatting and separating commits > >> +- > >> + > >> +Unlike many projects using GitHub and GitLab, Wayland has a > >> +[linear, 'recipe' style > >> history](http://www.bitsnbites.eu/git-history-work-log-vs-recipe/). > >> +This means that every commit should be small, digestible, stand-alone, and > >> +functional. Rather than a purely chronological commit history like this: > >> + > >> +connection: plug a fd leak > >> +plug another fd leak > >> +connection: init fds to -1 > >> +close all fds > >> +refactor checks into a new function > >> +don't close fds we handed out > >> + > >> +we aim to have a clean history which only reflects the final state, > >> broken up > >> +into functional groupings: > >> + > >> +connection: Refactor out closure allocation > >> +connection: Clear fds we shouldn't close to -1 > >> +connection: Make wl_closure_destroy() close fds of undispatched > >> closures > >> + > >> +This ensures that the final patch series only contains the final state, > >> +without the changes and missteps taken along the development process. > >> > >> The first line of a commit message should contain a prefix indicating > >> what part is affected by the patch followed by one sentence that > >> @@ -45,7 +83,7 @@ We won't reject patches that lack S-o-b, but it is > >> strongly recommended. > >> > >> When you re-send patches, revised or not, it would be very good to > >> document the > >> changes compared to the previous revision
Re: EXT: Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow
> On 6 Mar 2019, at 11.28, Pekka Paalanen wrote: > > Going once, going twice... > > Any objections? More acks? > > Let's say I'll push this and enable MRs on Friday if there are no > further comments. More acks and I might do it sooner. :-) > > LGTM Acked-by: Ian Ray > Thanks, > pq > > > On Wed, 27 Feb 2019 12:35:09 +0200 > Pekka Paalanen wrote: > >> From: Pekka Paalanen >> >> The experience from Weston shows that the Gitlab merge request based workflow >> works really well. Recently there have also been issues with the mailing list >> that have made the email based workflow more painful than it used to be. >> Those >> issues might have been temporary or occasional, but they probably are only >> going to increase. >> >> The MR workflow is different, it has its issues >> (https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/74) and we >> likely lose the explicit Reviewed-by etc. tags from commit messages, but it >> is >> also much easier to work with: no more whitespace damaged patches, lost >> email, >> setting up git-send-email; we gain automated CI before any human reviewer >> even >> looks at anything, and people can jump in to an ongoing discussion even if >> they >> weren't subscribed before. >> >> If you still want email, you can subscribe to that selectively(!) in Gitlab >> yourself. >> >> This text has been copied from Weston's CONTRIBUTING.md of the 5.0.91 release >> and slightly altered for Wayland. >> >> Fixes: https://gitlab.freedesktop.org/wayland/wayland/issues/49 >> >> v2: fixed two left-over mentions of Weston >> >> Signed-off-by: Pekka Paalanen >> v1 Reviewed-by: Simon Ser >> Reviewed-by: Daniel Stone >> --- >> CONTRIBUTING.md | 147 >> 1 file changed, 72 insertions(+), 75 deletions(-) >> >> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md >> index 686ed63..dcc9f56 100644 >> --- a/CONTRIBUTING.md >> +++ b/CONTRIBUTING.md >> @@ -4,8 +4,46 @@ Contributing to Wayland >> Sending patches >> --- >> >> -Patches should be sent to **wayland-devel@lists.freedesktop.org**, using >> -`git send-email`. See [git documentation] for help. >> +Patches should be sent via >> +[GitLab merge >> requests](https://docs.gitlab.com/ce/gitlab-basics/add-merge-request.html). >> +Wayland is >> +[hosted on freedesktop.org's >> GitLab](https://gitlab.freedesktop.org/wayland/wayland/): >> +in order to submit code, you should create an account on this GitLab >> instance, >> +fork the core Wayland repository, push your changes to a branch in your new >> +repository, and then submit these patches for review through a merge >> request. >> + >> +Wayland formerly accepted patches via `git-send-email`, sent to >> +**wayland-devel@lists.freedesktop.org**; these were >> +[tracked using >> Patchwork](https://patchwork.freedesktop.org/project/wayland/). >> +Some old patches continue to be sent this way, and we may accept small new >> +patches sent to the list, but please send all new patches through GitLab >> merge >> +requests. >> + >> + >> +Formatting and separating commits >> +- >> + >> +Unlike many projects using GitHub and GitLab, Wayland has a >> +[linear, 'recipe' style >> history](http://www.bitsnbites.eu/git-history-work-log-vs-recipe/). >> +This means that every commit should be small, digestible, stand-alone, and >> +functional. Rather than a purely chronological commit history like this: >> + >> +connection: plug a fd leak >> +plug another fd leak >> +connection: init fds to -1 >> +close all fds >> +refactor checks into a new function >> +don't close fds we handed out >> + >> +we aim to have a clean history which only reflects the final state, broken >> up >> +into functional groupings: >> + >> +connection: Refactor out closure allocation >> +connection: Clear fds we shouldn't close to -1 >> +connection: Make wl_closure_destroy() close fds of undispatched closures >> + >> +This ensures that the final patch series only contains the final state, >> +without the changes and missteps taken along the development process. >> >> The first line of a commit message should contain a prefix indicating >> what part is affected by the patch followed by one sentence that >> @@ -45,7 +83,7 @@ We won't reject patches that lack S-o-b, but it is >> strongly recommended. >> >> When you re-send patches, revised or not, it would be very good to document >> the >> changes compared to the previous revision in the commit message and/or the >> -cover letter. If you have already received Reviewed-by or Acked-by tags, you >> +merge request. If you have already received Reviewed-by or Acked-by tags, >> you >> should evaluate whether they still apply and include them in the respective >> commit messages. Otherwise the tags may be lost, reviewers miss the credit >> they >> deserve, and the patches may cause redundant review effort. >> @@ -54,78 +92,37 @@ deserve, and
