+1

>For us normally resolved issues will always have a development version as
>"Fix Versions" field, so the issue will only be closed when the version
>that includes that issue (bug, feature or whatever) actually gets released.

I think it should be optional as Davor suggested because you don't
always want to fix all open issues in the next release.

On Wed, Jun 29, 2016 at 10:58 PM, Amit Sela <[email protected]> wrote:
> +1
>
> On Wed, Jun 29, 2016 at 12:04 AM Lukasz Cwik <[email protected]>
> wrote:
>
>> +1
>>
>> On Tue, Jun 28, 2016 at 12:15 PM, Kenneth Knowles <[email protected]>
>> wrote:
>>
>> > +1
>> >
>> > On Tue, Jun 28, 2016 at 12:06 AM, Jean-Baptiste Onofré <[email protected]>
>> > wrote:
>> >
>> > > +1
>> > >
>> > > Regards
>> > > JB
>> > >
>> > >
>> > > On 06/28/2016 01:01 AM, Davor Bonaci wrote:
>> > >
>> > >> Hi everyone,
>> > >> I'd like to propose a simple change in Beam JIRA that will hopefully
>> > >> improve our issue and version tracking -- to actually use the "Fix
>> > >> Versions" field as intended [1].
>> > >>
>> > >> The goal would be to simplify issue tracking, streamline generation of
>> > >> release notes, add a view of outstanding work towards a release, and
>> > >> clearly communicate which Beam version contains fixes for each issue.
>> > >>
>> > >> The standard usage of the field is:
>> > >> * For open (or in-progress/re-opened) issues, "Fix Versions" field is
>> > >> optional and indicates an unreleased version that this issue is
>> > targeting.
>> > >> The release is not expected to proceed unless this issue is fixed, or
>> > the
>> > >> field is changed.
>> > >> * For closed (or resolved) issues, "Fix Versions" field indicates a
>> > >> released or unreleased version that has the fix.
>> > >>
>> > >> I think the field should be mandatory once the issue is
>> resolved/closed
>> > >> [4], so we make a deliberate choice about this. I propose we use "Not
>> > >> applicable" for all those issues that aren't being resolved as Fixed
>> > >> (e.g.,
>> > >> duplicates, working as intended, invalid, etc.) and those that aren't
>> > >> released (e.g., website, build system, etc.).
>> > >>
>> > >> We can then trivially view outstanding work for the next release [2],
>> or
>> > >> generate release notes [3].
>> > >>
>> > >> I'd love to hear if there are any comments! I know that at least JB
>> > >> agrees,
>> > >> as he was convincing me on this -- thanks ;).
>> > >>
>> > >> Thanks,
>> > >> Davor
>> > >>
>> > >> [1]
>> > >>
>> > >>
>> >
>> https://confluence.atlassian.com/adminjiraserver071/managing-versions-802592484.html
>> > >> [2]
>> > >>
>> > >>
>> >
>> https://issues.apache.org/jira/browse/BEAM/fixforversion/12335766/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
>> > >> [3]
>> > >>
>> > >>
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12319527&version=12335764
>> > >> [4] https://issues.apache.org/jira/browse/INFRA-12120
>> > >>
>> > >>
>> > > --
>> > > Jean-Baptiste Onofré
>> > > [email protected]
>> > > http://blog.nanthrax.net
>> > > Talend - http://www.talend.com
>> > >
>> >
>>

Reply via email to