On Mon, Jun 1, 2020 at 3:40 PM Thomas Heigl <tho...@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 <mgrigo...@apache.org> > wrote: > > > On Mon, Jun 1, 2020 at 1:10 PM Thomas Heigl <tho...@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 <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! > > > > > > > > > > > > > > >
