You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Thomas Heigl <th...@umschalt.com> on 2020/05/30 16:52:12 UTC

Questions regarding development workflow

Hi all,

Do we have any guidelines regarding the development workflow? E.g.

- How many approvals do I need for merging a PR?
- Who manages the changelog? Should a changelog entry be part of every PR?
- How do we decide what PRs to backport to older versions?

And are there CI builds for PRs? I would feel more confident clicking the
merge button if there was a CI status check connected to GitHub (and
possibly a Sonarqube check as well).

Thanks!

Thomas

Re: Questions regarding development workflow

Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Jun 1, 2020 at 3:40 PM Thomas Heigl <th...@umschalt.com> wrote:

> >
> > Now I checked the GitHub Actions docs (
> >
> https://help.github.com/en/actions/reference/events-that-trigger-workflows
> > )
> > and added support for Pull Requests.
> > Since we have .github/workflows only in master branch it won't trigger
> any
> > builds for 8.x, 7.x, ... If we want this then we have to downport it.
> >
>
> It's working now, thanks Martin!
>
> We should probably add caching for Maven dependencies. Fetching them every
> time slows down the build quite a bit:
>
>
> https://help.github.com/en/actions/language-and-framework-guides/building-and-testing-java-with-maven#caching-dependencies


+1


>
>
> Thomas
>
> On Mon, Jun 1, 2020 at 1:35 PM Martin Grigorov <mg...@apache.org>
> wrote:
>
> > On Mon, Jun 1, 2020 at 1:10 PM Thomas Heigl <th...@umschalt.com> wrote:
> >
> > > Thanks for the infos Andrea and Martin! I think that answers all my
> > > questions.
> > >
> > > The official CI tool is BuildBot but since recently we also added
> GitHub
> > > > Actions since it comes for free (i.e. any maintenance from us).
> > > > At the moment it builds only master branch but we can remove this
> > > > restriction and let it build all branches:
> > > >
> > > >
> > >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > > > I think this will be useful for PRs!
> > >
> > >
> > > @Martin: I just pushed to #436 but it did not trigger the CI build even
> > > after you removed the branch filter. The reason might be that I created
> > the
> > > PR from my own fork. I'll switch to creating branches directly in the
> > > Wicket repository for my next PR.
> > >
> >
> > Now I checked the GitHub Actions docs (
> >
> https://help.github.com/en/actions/reference/events-that-trigger-workflows
> > )
> > and added support for Pull Requests.
> > Since we have .github/workflows only in master branch it won't trigger
> any
> > builds for 8.x, 7.x, ... If we want this then we have to downport it.
> >
> >
> > >
> > > Best,
> > >
> > > Thomas
> > >
> > >
> > >
> > >
> > > On Mon, Jun 1, 2020 at 10:41 AM Martin Grigorov <mg...@apache.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Sun, May 31, 2020 at 2:17 PM Andrea Del Bene <
> an.delbene@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Thomas!
> > > > >
> > > > > On 30/05/20 18:52, Thomas Heigl wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > Do we have any guidelines regarding the development workflow?
> E.g.
> > > > > >
> > > > > > - How many approvals do I need for merging a PR?
> > > > > PR approvals on GitHub is a relatively new thing and there is no
> > strict
> > > > > rule about it. As empiric rule we try to get the approval from (at
> > > > > least) a couple of other commiters. But it also depends on the
> > > > > complexity of the PR, and for those who might have a bigger impact
> on
> > > > > framework it's good to involve other people on the @dev list.
> > > > >
> > > >
> > > > PRs are not mandatory.
> > > > I create PR only when I am not really sure about the solution I am
> > > > suggesting.
> > > > Even if you push something directly without a PR we will review it
> and
> > if
> > > > we see something we will comment on it either in GitHub or on dev@.
> > Once
> > > > we
> > > > agree on a better solution we may either push a new commit with an
> > > > improvement or revert the old one.
> > > >
> > > >
> > > > > > - Who manages the changelog? Should a changelog entry be part of
> > > every
> > > > > PR?
> > > > > PR should come with a Jira issue to track them. The change log is
> > > > > automatically generated during the release process using the 'Fix
> > > > > Version' parameter of the issues. For example this is the current
> > > change
> > > > > log for for the upcoming 8.9.0 version
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348154&styleName=&projectId=12310561
> > > > > > - How do we decide what PRs to backport to older versions?
> > > > > This is usually asked in the @dev list, depending on the importance
> > of
> > > > > the PR (ex: is a fix or a new feature?) and its feasibility (ex:
> can
> > be
> > > > > easily / safely back-ported?)
> > > > >
> > > >
> > > > If it is a new feature usually I commit it to the current stable
> branch
> > > > (i.e. 8.x at the moment) and the next dev branch (9.x).
> > > > If it is a fix then I also include the previous stable branch (7.x).
> > > > If it is a security related fix then the also 6.x. Once we release
> > 9.0.0
> > > > then 7.x becomes the security maintenance branch.
> > > >
> > > >
> > > > > >
> > > > > > And are there CI builds for PRs? I would feel more confident
> > clicking
> > > > the
> > > > > > merge button if there was a CI status check connected to GitHub
> > (and
> > > > > > possibly a Sonarqube check as well).
> > > > > If I remember correctly GitHub should provide some kind of support
> > for
> > > > > PRs CI, but I never explored this feature, maybe Martin did
> something
> > > > > about it.
> > > > >
> > > >
> > > > The official CI tool is BuildBot but since recently we also added
> > GitHub
> > > > Actions since it comes for free (i.e. any maintenance from us).
> > > > At the moment it builds only master branch but we can remove this
> > > > restriction and let it build all branches:
> > > >
> > > >
> > >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > > > I think this will be useful for PRs!
> > > >
> > > > Martin
> > > >
> > > >
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > Thomas
> > > > > >
> > > > > Your are welcome!
> > > > >
> > > >
> > >
> >
>

Re: Questions regarding development workflow

Posted by Thomas Heigl <th...@umschalt.com>.
>
> Now I checked the GitHub Actions docs (
> https://help.github.com/en/actions/reference/events-that-trigger-workflows
> )
> and added support for Pull Requests.
> Since we have .github/workflows only in master branch it won't trigger any
> builds for 8.x, 7.x, ... If we want this then we have to downport it.
>

It's working now, thanks Martin!

We should probably add caching for Maven dependencies. Fetching them every
time slows down the build quite a bit:

https://help.github.com/en/actions/language-and-framework-guides/building-and-testing-java-with-maven#caching-dependencies

Thomas

On Mon, Jun 1, 2020 at 1:35 PM Martin Grigorov <mg...@apache.org> wrote:

> On Mon, Jun 1, 2020 at 1:10 PM Thomas Heigl <th...@umschalt.com> wrote:
>
> > Thanks for the infos Andrea and Martin! I think that answers all my
> > questions.
> >
> > The official CI tool is BuildBot but since recently we also added GitHub
> > > Actions since it comes for free (i.e. any maintenance from us).
> > > At the moment it builds only master branch but we can remove this
> > > restriction and let it build all branches:
> > >
> > >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > > I think this will be useful for PRs!
> >
> >
> > @Martin: I just pushed to #436 but it did not trigger the CI build even
> > after you removed the branch filter. The reason might be that I created
> the
> > PR from my own fork. I'll switch to creating branches directly in the
> > Wicket repository for my next PR.
> >
>
> Now I checked the GitHub Actions docs (
> https://help.github.com/en/actions/reference/events-that-trigger-workflows
> )
> and added support for Pull Requests.
> Since we have .github/workflows only in master branch it won't trigger any
> builds for 8.x, 7.x, ... If we want this then we have to downport it.
>
>
> >
> > Best,
> >
> > Thomas
> >
> >
> >
> >
> > On Mon, Jun 1, 2020 at 10:41 AM Martin Grigorov <mg...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > On Sun, May 31, 2020 at 2:17 PM Andrea Del Bene <an...@gmail.com>
> > > wrote:
> > >
> > > > Hi Thomas!
> > > >
> > > > On 30/05/20 18:52, Thomas Heigl wrote:
> > > > > Hi all,
> > > > >
> > > > > Do we have any guidelines regarding the development workflow? E.g.
> > > > >
> > > > > - How many approvals do I need for merging a PR?
> > > > PR approvals on GitHub is a relatively new thing and there is no
> strict
> > > > rule about it. As empiric rule we try to get the approval from (at
> > > > least) a couple of other commiters. But it also depends on the
> > > > complexity of the PR, and for those who might have a bigger impact on
> > > > framework it's good to involve other people on the @dev list.
> > > >
> > >
> > > PRs are not mandatory.
> > > I create PR only when I am not really sure about the solution I am
> > > suggesting.
> > > Even if you push something directly without a PR we will review it and
> if
> > > we see something we will comment on it either in GitHub or on dev@.
> Once
> > > we
> > > agree on a better solution we may either push a new commit with an
> > > improvement or revert the old one.
> > >
> > >
> > > > > - Who manages the changelog? Should a changelog entry be part of
> > every
> > > > PR?
> > > > PR should come with a Jira issue to track them. The change log is
> > > > automatically generated during the release process using the 'Fix
> > > > Version' parameter of the issues. For example this is the current
> > change
> > > > log for for the upcoming 8.9.0 version
> > > >
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348154&styleName=&projectId=12310561
> > > > > - How do we decide what PRs to backport to older versions?
> > > > This is usually asked in the @dev list, depending on the importance
> of
> > > > the PR (ex: is a fix or a new feature?) and its feasibility (ex: can
> be
> > > > easily / safely back-ported?)
> > > >
> > >
> > > If it is a new feature usually I commit it to the current stable branch
> > > (i.e. 8.x at the moment) and the next dev branch (9.x).
> > > If it is a fix then I also include the previous stable branch (7.x).
> > > If it is a security related fix then the also 6.x. Once we release
> 9.0.0
> > > then 7.x becomes the security maintenance branch.
> > >
> > >
> > > > >
> > > > > And are there CI builds for PRs? I would feel more confident
> clicking
> > > the
> > > > > merge button if there was a CI status check connected to GitHub
> (and
> > > > > possibly a Sonarqube check as well).
> > > > If I remember correctly GitHub should provide some kind of support
> for
> > > > PRs CI, but I never explored this feature, maybe Martin did something
> > > > about it.
> > > >
> > >
> > > The official CI tool is BuildBot but since recently we also added
> GitHub
> > > Actions since it comes for free (i.e. any maintenance from us).
> > > At the moment it builds only master branch but we can remove this
> > > restriction and let it build all branches:
> > >
> > >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > > I think this will be useful for PRs!
> > >
> > > Martin
> > >
> > >
> > > > >
> > > > > Thanks!
> > > > >
> > > > > Thomas
> > > > >
> > > > Your are welcome!
> > > >
> > >
> >
>

Re: Questions regarding development workflow

Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Jun 1, 2020 at 1:10 PM Thomas Heigl <th...@umschalt.com> wrote:

> Thanks for the infos Andrea and Martin! I think that answers all my
> questions.
>
> The official CI tool is BuildBot but since recently we also added GitHub
> > Actions since it comes for free (i.e. any maintenance from us).
> > At the moment it builds only master branch but we can remove this
> > restriction and let it build all branches:
> >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > I think this will be useful for PRs!
>
>
> @Martin: I just pushed to #436 but it did not trigger the CI build even
> after you removed the branch filter. The reason might be that I created the
> PR from my own fork. I'll switch to creating branches directly in the
> Wicket repository for my next PR.
>

Now I checked the GitHub Actions docs (
https://help.github.com/en/actions/reference/events-that-trigger-workflows)
and added support for Pull Requests.
Since we have .github/workflows only in master branch it won't trigger any
builds for 8.x, 7.x, ... If we want this then we have to downport it.


>
> Best,
>
> Thomas
>
>
>
>
> On Mon, Jun 1, 2020 at 10:41 AM Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi,
> >
> > On Sun, May 31, 2020 at 2:17 PM Andrea Del Bene <an...@gmail.com>
> > wrote:
> >
> > > Hi Thomas!
> > >
> > > On 30/05/20 18:52, Thomas Heigl wrote:
> > > > Hi all,
> > > >
> > > > Do we have any guidelines regarding the development workflow? E.g.
> > > >
> > > > - How many approvals do I need for merging a PR?
> > > PR approvals on GitHub is a relatively new thing and there is no strict
> > > rule about it. As empiric rule we try to get the approval from (at
> > > least) a couple of other commiters. But it also depends on the
> > > complexity of the PR, and for those who might have a bigger impact on
> > > framework it's good to involve other people on the @dev list.
> > >
> >
> > PRs are not mandatory.
> > I create PR only when I am not really sure about the solution I am
> > suggesting.
> > Even if you push something directly without a PR we will review it and if
> > we see something we will comment on it either in GitHub or on dev@. Once
> > we
> > agree on a better solution we may either push a new commit with an
> > improvement or revert the old one.
> >
> >
> > > > - Who manages the changelog? Should a changelog entry be part of
> every
> > > PR?
> > > PR should come with a Jira issue to track them. The change log is
> > > automatically generated during the release process using the 'Fix
> > > Version' parameter of the issues. For example this is the current
> change
> > > log for for the upcoming 8.9.0 version
> > >
> > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348154&styleName=&projectId=12310561
> > > > - How do we decide what PRs to backport to older versions?
> > > This is usually asked in the @dev list, depending on the importance of
> > > the PR (ex: is a fix or a new feature?) and its feasibility (ex: can be
> > > easily / safely back-ported?)
> > >
> >
> > If it is a new feature usually I commit it to the current stable branch
> > (i.e. 8.x at the moment) and the next dev branch (9.x).
> > If it is a fix then I also include the previous stable branch (7.x).
> > If it is a security related fix then the also 6.x. Once we release 9.0.0
> > then 7.x becomes the security maintenance branch.
> >
> >
> > > >
> > > > And are there CI builds for PRs? I would feel more confident clicking
> > the
> > > > merge button if there was a CI status check connected to GitHub (and
> > > > possibly a Sonarqube check as well).
> > > If I remember correctly GitHub should provide some kind of support for
> > > PRs CI, but I never explored this feature, maybe Martin did something
> > > about it.
> > >
> >
> > The official CI tool is BuildBot but since recently we also added GitHub
> > Actions since it comes for free (i.e. any maintenance from us).
> > At the moment it builds only master branch but we can remove this
> > restriction and let it build all branches:
> >
> >
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> > I think this will be useful for PRs!
> >
> > Martin
> >
> >
> > > >
> > > > Thanks!
> > > >
> > > > Thomas
> > > >
> > > Your are welcome!
> > >
> >
>

Re: Questions regarding development workflow

Posted by Thomas Heigl <th...@umschalt.com>.
Thanks for the infos Andrea and Martin! I think that answers all my
questions.

The official CI tool is BuildBot but since recently we also added GitHub
> Actions since it comes for free (i.e. any maintenance from us).
> At the moment it builds only master branch but we can remove this
> restriction and let it build all branches:
>
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> I think this will be useful for PRs!


@Martin: I just pushed to #436 but it did not trigger the CI build even
after you removed the branch filter. The reason might be that I created the
PR from my own fork. I'll switch to creating branches directly in the
Wicket repository for my next PR.

Best,

Thomas




On Mon, Jun 1, 2020 at 10:41 AM Martin Grigorov <mg...@apache.org>
wrote:

> Hi,
>
> On Sun, May 31, 2020 at 2:17 PM Andrea Del Bene <an...@gmail.com>
> wrote:
>
> > Hi Thomas!
> >
> > On 30/05/20 18:52, Thomas Heigl wrote:
> > > Hi all,
> > >
> > > Do we have any guidelines regarding the development workflow? E.g.
> > >
> > > - How many approvals do I need for merging a PR?
> > PR approvals on GitHub is a relatively new thing and there is no strict
> > rule about it. As empiric rule we try to get the approval from (at
> > least) a couple of other commiters. But it also depends on the
> > complexity of the PR, and for those who might have a bigger impact on
> > framework it's good to involve other people on the @dev list.
> >
>
> PRs are not mandatory.
> I create PR only when I am not really sure about the solution I am
> suggesting.
> Even if you push something directly without a PR we will review it and if
> we see something we will comment on it either in GitHub or on dev@. Once
> we
> agree on a better solution we may either push a new commit with an
> improvement or revert the old one.
>
>
> > > - Who manages the changelog? Should a changelog entry be part of every
> > PR?
> > PR should come with a Jira issue to track them. The change log is
> > automatically generated during the release process using the 'Fix
> > Version' parameter of the issues. For example this is the current change
> > log for for the upcoming 8.9.0 version
> >
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348154&styleName=&projectId=12310561
> > > - How do we decide what PRs to backport to older versions?
> > This is usually asked in the @dev list, depending on the importance of
> > the PR (ex: is a fix or a new feature?) and its feasibility (ex: can be
> > easily / safely back-ported?)
> >
>
> If it is a new feature usually I commit it to the current stable branch
> (i.e. 8.x at the moment) and the next dev branch (9.x).
> If it is a fix then I also include the previous stable branch (7.x).
> If it is a security related fix then the also 6.x. Once we release 9.0.0
> then 7.x becomes the security maintenance branch.
>
>
> > >
> > > And are there CI builds for PRs? I would feel more confident clicking
> the
> > > merge button if there was a CI status check connected to GitHub (and
> > > possibly a Sonarqube check as well).
> > If I remember correctly GitHub should provide some kind of support for
> > PRs CI, but I never explored this feature, maybe Martin did something
> > about it.
> >
>
> The official CI tool is BuildBot but since recently we also added GitHub
> Actions since it comes for free (i.e. any maintenance from us).
> At the moment it builds only master branch but we can remove this
> restriction and let it build all branches:
>
> https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
> I think this will be useful for PRs!
>
> Martin
>
>
> > >
> > > Thanks!
> > >
> > > Thomas
> > >
> > Your are welcome!
> >
>

Re: Questions regarding development workflow

Posted by Martin Grigorov <mg...@apache.org>.
Hi,

On Sun, May 31, 2020 at 2:17 PM Andrea Del Bene <an...@gmail.com>
wrote:

> Hi Thomas!
>
> On 30/05/20 18:52, Thomas Heigl wrote:
> > Hi all,
> >
> > Do we have any guidelines regarding the development workflow? E.g.
> >
> > - How many approvals do I need for merging a PR?
> PR approvals on GitHub is a relatively new thing and there is no strict
> rule about it. As empiric rule we try to get the approval from (at
> least) a couple of other commiters. But it also depends on the
> complexity of the PR, and for those who might have a bigger impact on
> framework it's good to involve other people on the @dev list.
>

PRs are not mandatory.
I create PR only when I am not really sure about the solution I am
suggesting.
Even if you push something directly without a PR we will review it and if
we see something we will comment on it either in GitHub or on dev@. Once we
agree on a better solution we may either push a new commit with an
improvement or revert the old one.


> > - Who manages the changelog? Should a changelog entry be part of every
> PR?
> PR should come with a Jira issue to track them. The change log is
> automatically generated during the release process using the 'Fix
> Version' parameter of the issues. For example this is the current change
> log for for the upcoming 8.9.0 version
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348154&styleName=&projectId=12310561
> > - How do we decide what PRs to backport to older versions?
> This is usually asked in the @dev list, depending on the importance of
> the PR (ex: is a fix or a new feature?) and its feasibility (ex: can be
> easily / safely back-ported?)
>

If it is a new feature usually I commit it to the current stable branch
(i.e. 8.x at the moment) and the next dev branch (9.x).
If it is a fix then I also include the previous stable branch (7.x).
If it is a security related fix then the also 6.x. Once we release 9.0.0
then 7.x becomes the security maintenance branch.


> >
> > And are there CI builds for PRs? I would feel more confident clicking the
> > merge button if there was a CI status check connected to GitHub (and
> > possibly a Sonarqube check as well).
> If I remember correctly GitHub should provide some kind of support for
> PRs CI, but I never explored this feature, maybe Martin did something
> about it.
>

The official CI tool is BuildBot but since recently we also added GitHub
Actions since it comes for free (i.e. any maintenance from us).
At the moment it builds only master branch but we can remove this
restriction and let it build all branches:
https://github.com/apache/wicket/blob/99cdfa5d6cd1f359c855af21595ca4aa5137b6e1/.github/workflows/maven.yml#L5-L6
I think this will be useful for PRs!

Martin


> >
> > Thanks!
> >
> > Thomas
> >
> Your are welcome!
>

Re: Questions regarding development workflow

Posted by Andrea Del Bene <an...@gmail.com>.
Hi Thomas!

On 30/05/20 18:52, Thomas Heigl wrote:
> Hi all,
>
> Do we have any guidelines regarding the development workflow? E.g.
>
> - How many approvals do I need for merging a PR?
PR approvals on GitHub is a relatively new thing and there is no strict 
rule about it. As empiric rule we try to get the approval from (at 
least) a couple of other commiters. But it also depends on the 
complexity of the PR, and for those who might have a bigger impact on 
framework it's good to involve other people on the @dev list.
> - Who manages the changelog? Should a changelog entry be part of every PR?
PR should come with a Jira issue to track them. The change log is 
automatically generated during the release process using the 'Fix 
Version' parameter of the issues. For example this is the current change 
log for for the upcoming 8.9.0 version

https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348154&styleName=&projectId=12310561
> - How do we decide what PRs to backport to older versions?
This is usually asked in the @dev list, depending on the importance of 
the PR (ex: is a fix or a new feature?) and its feasibility (ex: can be 
easily / safely back-ported?)
>
> And are there CI builds for PRs? I would feel more confident clicking the
> merge button if there was a CI status check connected to GitHub (and
> possibly a Sonarqube check as well).
If I remember correctly GitHub should provide some kind of support for 
PRs CI, but I never explored this feature, maybe Martin did something 
about it.
>
> Thanks!
>
> Thomas
>
Your are welcome!