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!
> >
>

Reply via email to