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 <mgrigo...@apache.org> wrote: > Hi, > > On Sun, May 31, 2020 at 2:17 PM Andrea Del Bene <an.delb...@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! > > >
