I'd like to kindly ask all Foreman committers to set the release version in
the linked redmine issue after they merge the PR. In past, Dominic used to do
it, unless it was set by the reviewer. Please correct me if I'm wrong but I
think it's not going to happen any further.
I think it's very helpful to users and devs to easily find out, what Foreman
version contains the fix, just by looking at redmine issue. Therefore I'd like
to continue with this but I'd appreciate if we I'm not the only one who set
it.
After PR is merged, the last existing version should be set to "Release"
field, atm it's 1.16.0. If you merged something that you believe should be
cherry-picked into last stable version, set that as a release, e.g. "1.15.2".
Meaning of Release field is "the lowest Foreman version that contains the
fix".
I'll try to remind reviewers when I see it unset unless I get negative
reactions here. I'm going over all issues merged after 1.15 branching and
setting 1.16.0 where appropriate.
In case it helps the workflow for Foreman, the Katello plugin has a
workflow that goes like:
when a PR is merged, the attached issue is set to an empty release (if
on the Backlog, where the "Backlog" is an actual Redmine release that
issues are set to)
an empty release effectively means the issue is untriaged [1]
in a weekly meeting, issues from various untriaged states [2] are
examined
during this triage, issues that are closed and untriaged (no release)
are targeted at either the current release (e.g. 3.5.0) or an open z-stream
(e.g. 3.4.2)
In this way, as a group, issues are analyzed and determined where they
should be targeted. We also don't lose track of issues that were on the
backlog but got fixed.
···
On Wed, Jun 14, 2017 at 3:50 PM, Marek Hulán wrote:
Hello
I’d like to kindly ask all Foreman committers to set the release version in
the linked redmine issue after they merge the PR. In past, Dominic used to
do
it, unless it was set by the reviewer. Please correct me if I’m wrong but I
think it’s not going to happen any further.
I think it’s very helpful to users and devs to easily find out, what
Foreman
version contains the fix, just by looking at redmine issue. Therefore I’d
like
to continue with this but I’d appreciate if we I’m not the only one who set
it.
After PR is merged, the last existing version should be set to "Release"
field, atm it’s 1.16.0. If you merged something that you believe should be
cherry-picked into last stable version, set that as a release, e.g.
“1.15.2”.
Meaning of Release field is “the lowest Foreman version that contains the
fix”.
I’ll try to remind reviewers when I see it unset unless I get negative
reactions here. I’m going over all issues merged after 1.15 branching and
setting 1.16.0 where appropriate.
Is this something we could think about automating in similar way the PR is
set by theforeman-bot ?
···
On Wed, 14 Jun 2017 at 20:50, Marek Hulán wrote:
Hello
I’d like to kindly ask all Foreman committers to set the release version in
the linked redmine issue after they merge the PR. In past, Dominic used to
do
it, unless it was set by the reviewer. Please correct me if I’m wrong but I
think it’s not going to happen any further.
I think it’s very helpful to users and devs to easily find out, what
Foreman
version contains the fix, just by looking at redmine issue. Therefore I’d
like
to continue with this but I’d appreciate if we I’m not the only one who set
it.
After PR is merged, the last existing version should be set to "Release"
field, atm it’s 1.16.0. If you merged something that you believe should be
cherry-picked into last stable version, set that as a release, e.g.
“1.15.2”.
Meaning of Release field is “the lowest Foreman version that contains the
fix”.
I’ll try to remind reviewers when I see it unset unless I get negative
reactions here. I’m going over all issues merged after 1.15 branching and
setting 1.16.0 where appropriate.
As long as it won't override manually set release, that could work. I'm not
sure if we distinguish between core and plugin in prprocessor but I suppose
few "ifs" would do.
I'm OK with manual setting too since I open the redmine issue prior merge
anyway to check the PR is linked to correct one and it implements the whole
issue.
···
--
Marek
On středa 14. června 2017 22:05:28 CEST Sean O’Keeffe wrote:
Is this something we could think about automating in similar way the PR is
set by theforeman-bot ?
I’d like to kindly ask all Foreman committers to set the release version
in
the linked redmine issue after they merge the PR. In past, Dominic used to
do
it, unless it was set by the reviewer. Please correct me if I’m wrong but
I
think it’s not going to happen any further.
I think it’s very helpful to users and devs to easily find out, what
Foreman
version contains the fix, just by looking at redmine issue. Therefore I’d
like
to continue with this but I’d appreciate if we I’m not the only one who
set
it.
After PR is merged, the last existing version should be set to "Release"
field, atm it’s 1.16.0. If you merged something that you believe should be
cherry-picked into last stable version, set that as a release, e.g.
“1.15.2”.
Meaning of Release field is “the lowest Foreman version that contains the
fix”.
I’ll try to remind reviewers when I see it unset unless I get negative
reactions here. I’m going over all issues merged after 1.15 branching and
setting 1.16.0 where appropriate.
> I'll try to remind reviewers when I see it unset unless I get negative
> reactions here. I'm going over all issues merged after 1.15 branching and
> setting 1.16.0 where appropriate.
>
Hello,
it took me a while to get back to it but it should be now complete.
