Release notes preparations...

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Release notes preparations...

Konstantin Boudnik-2
Gents,

this has triggered the recollection of the release notes conversation we had
the other day. Looks like the ticket queue isn't getting pruned in time of the
release, so the changes like that are happening postfactum. This is either
leads to more load on the RM, or might be error-prone.

I want to share some of the RM best practices that I have observed and used
myself in other projects (Bigtop, Hadoop, etc.). JIRA cleaning/pruning is
normally one of the steps _leading_ to release. It helps to narrow down the
scope of the work that still is needed to be done before the release could be
cut. Once the scope is decided and all JIRAs considered for later are moved to
the consequent release, JIRA software allow you to generate the release notes
file, that can be included into the release itself. This provide a necessary
connection between the source code in the release and the issues addressed by
it. Once the release is published, the RM needs to officially _release_ the
version in the JIRA software. At this point, the number of unfinished ticket
against that version should be exactly 0. It is just a matter of the
house-keeping and a good engineering practice. And it helps to keep down the
amount of the mess.
 
Hope it makes sense.
  Cos

----- Forwarded message from "Pavel Tupitsyn (JIRA)" <[hidden email]> -----

Date: Tue, 9 Aug 2016 12:32:32 +0000 (UTC)
From: "Pavel Tupitsyn (JIRA)" <[hidden email]>
To: [hidden email]
Subject: [jira] [Updated] (IGNITE-2437) Zeppelin interperet doesn't import external dependencies


     [ https://issues.apache.org/jira/browse/IGNITE-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pavel Tupitsyn updated IGNITE-2437:
-----------------------------------
    Fix Version/s:     (was: 1.7)
                   1.8

> Zeppelin interperet doesn't import external dependencies
> --------------------------------------------------------
>
>                 Key: IGNITE-2437
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2437
>             Project: Ignite
>          Issue Type: Bug
>          Components: general
>    Affects Versions: 1.5.0.final
>         Environment: zeppelin 0.5.5
> ignite 1.5.0.final
>            Reporter: Konstantin Boudnik
>            Assignee: Andrey Gura
>             Fix For: 1.8
>
>
> After configuring Ignite's interpreter for Zeppelin, tried to run the following
> {code}
> %dep
> z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")
> %ignite
> import io.company._
> console>:23: error: object company is not a member of package io
>        import io.company._
> {code}
> same code works just fine in spark interpreter though.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

----- End forwarded message -----
Reply | Threaded
Open this post in threaded view
|

Re: Release notes preparations...

Pavel Tupitsyn
Cos, you are right.

More than 300 (!) tickets has been moved to 1.8 yesterday when I released
1.7 version in JIRA.

For what it's worth, I've added a step to vote verification:
https://cwiki.apache.org/confluence/display/IGNITE/Release+Process

Pavel

On Tue, Aug 9, 2016 at 9:37 PM, Konstantin Boudnik <[hidden email]> wrote:

> Gents,
>
> this has triggered the recollection of the release notes conversation we
> had
> the other day. Looks like the ticket queue isn't getting pruned in time of
> the
> release, so the changes like that are happening postfactum. This is either
> leads to more load on the RM, or might be error-prone.
>
> I want to share some of the RM best practices that I have observed and used
> myself in other projects (Bigtop, Hadoop, etc.). JIRA cleaning/pruning is
> normally one of the steps _leading_ to release. It helps to narrow down the
> scope of the work that still is needed to be done before the release could
> be
> cut. Once the scope is decided and all JIRAs considered for later are
> moved to
> the consequent release, JIRA software allow you to generate the release
> notes
> file, that can be included into the release itself. This provide a
> necessary
> connection between the source code in the release and the issues addressed
> by
> it. Once the release is published, the RM needs to officially _release_ the
> version in the JIRA software. At this point, the number of unfinished
> ticket
> against that version should be exactly 0. It is just a matter of the
> house-keeping and a good engineering practice. And it helps to keep down
> the
> amount of the mess.
>
> Hope it makes sense.
>   Cos
>
> ----- Forwarded message from "Pavel Tupitsyn (JIRA)" <[hidden email]>
> -----
>
> Date: Tue, 9 Aug 2016 12:32:32 +0000 (UTC)
> From: "Pavel Tupitsyn (JIRA)" <[hidden email]>
> To: [hidden email]
> Subject: [jira] [Updated] (IGNITE-2437) Zeppelin interperet doesn't import
> external dependencies
>
>
>      [ https://issues.apache.org/jira/browse/IGNITE-2437?page=
> com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Pavel Tupitsyn updated IGNITE-2437:
> -----------------------------------
>     Fix Version/s:     (was: 1.7)
>                    1.8
>
> > Zeppelin interperet doesn't import external dependencies
> > --------------------------------------------------------
> >
> >                 Key: IGNITE-2437
> >                 URL: https://issues.apache.org/jira/browse/IGNITE-2437
> >             Project: Ignite
> >          Issue Type: Bug
> >          Components: general
> >    Affects Versions: 1.5.0.final
> >         Environment: zeppelin 0.5.5
> > ignite 1.5.0.final
> >            Reporter: Konstantin Boudnik
> >            Assignee: Andrey Gura
> >             Fix For: 1.8
> >
> >
> > After configuring Ignite's interpreter for Zeppelin, tried to run the
> following
> > {code}
> > %dep
> > z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")
> > %ignite
> > import io.company._
> > console>:23: error: object company is not a member of package io
> >        import io.company._
> > {code}
> > same code works just fine in spark interpreter though.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
> ----- End forwarded message -----
>
Reply | Threaded
Open this post in threaded view
|

Re: Release notes preparations...

Konstantin Boudnik-2
Great! Thanks for updating the page! I've noticed that we are still using
unsecure md5 and sha1, but i guess this is a topic for a different time ;)

Cheers,
  Cos

On Wed, Aug 10, 2016 at 12:26PM, Pavel Tupitsyn wrote:

> Cos, you are right.
>
> More than 300 (!) tickets has been moved to 1.8 yesterday when I released
> 1.7 version in JIRA.
>
> For what it's worth, I've added a step to vote verification:
> https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
>
> Pavel
>
> On Tue, Aug 9, 2016 at 9:37 PM, Konstantin Boudnik <[hidden email]> wrote:
>
> > Gents,
> >
> > this has triggered the recollection of the release notes conversation we
> > had
> > the other day. Looks like the ticket queue isn't getting pruned in time of
> > the
> > release, so the changes like that are happening postfactum. This is either
> > leads to more load on the RM, or might be error-prone.
> >
> > I want to share some of the RM best practices that I have observed and used
> > myself in other projects (Bigtop, Hadoop, etc.). JIRA cleaning/pruning is
> > normally one of the steps _leading_ to release. It helps to narrow down the
> > scope of the work that still is needed to be done before the release could
> > be
> > cut. Once the scope is decided and all JIRAs considered for later are
> > moved to
> > the consequent release, JIRA software allow you to generate the release
> > notes
> > file, that can be included into the release itself. This provide a
> > necessary
> > connection between the source code in the release and the issues addressed
> > by
> > it. Once the release is published, the RM needs to officially _release_ the
> > version in the JIRA software. At this point, the number of unfinished
> > ticket
> > against that version should be exactly 0. It is just a matter of the
> > house-keeping and a good engineering practice. And it helps to keep down
> > the
> > amount of the mess.
> >
> > Hope it makes sense.
> >   Cos
> >
> > ----- Forwarded message from "Pavel Tupitsyn (JIRA)" <[hidden email]>
> > -----
> >
> > Date: Tue, 9 Aug 2016 12:32:32 +0000 (UTC)
> > From: "Pavel Tupitsyn (JIRA)" <[hidden email]>
> > To: [hidden email]
> > Subject: [jira] [Updated] (IGNITE-2437) Zeppelin interperet doesn't import
> > external dependencies
> >
> >
> >      [ https://issues.apache.org/jira/browse/IGNITE-2437?page=
> > com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Pavel Tupitsyn updated IGNITE-2437:
> > -----------------------------------
> >     Fix Version/s:     (was: 1.7)
> >                    1.8
> >
> > > Zeppelin interperet doesn't import external dependencies
> > > --------------------------------------------------------
> > >
> > >                 Key: IGNITE-2437
> > >                 URL: https://issues.apache.org/jira/browse/IGNITE-2437
> > >             Project: Ignite
> > >          Issue Type: Bug
> > >          Components: general
> > >    Affects Versions: 1.5.0.final
> > >         Environment: zeppelin 0.5.5
> > > ignite 1.5.0.final
> > >            Reporter: Konstantin Boudnik
> > >            Assignee: Andrey Gura
> > >             Fix For: 1.8
> > >
> > >
> > > After configuring Ignite's interpreter for Zeppelin, tried to run the
> > following
> > > {code}
> > > %dep
> > > z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")
> > > %ignite
> > > import io.company._
> > > console>:23: error: object company is not a member of package io
> > >        import io.company._
> > > {code}
> > > same code works just fine in spark interpreter though.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.4#6332)
> >
> > ----- End forwarded message -----
> >
Reply | Threaded
Open this post in threaded view
|

Re: Release notes preparations...

Konstantin Boudnik-2
BTW, I see another issue with not pruning the tickets _before_ the release is
made. Right now, there's a bunch of tickets still marked to be fixed in say
1.6, which should've been moved to 1.7 at the time of 1.6 being released.

Also, 1.4 release is still marked as active in JIRA. Unfortunately, I can not
fix this issue as I lack the admin permissions on the project.

Cos

On Wed, Aug 10, 2016 at 07:44AM, Konstantin Boudnik wrote:

> Great! Thanks for updating the page! I've noticed that we are still using
> unsecure md5 and sha1, but i guess this is a topic for a different time ;)
>
> Cheers,
>   Cos
>
> On Wed, Aug 10, 2016 at 12:26PM, Pavel Tupitsyn wrote:
> > Cos, you are right.
> >
> > More than 300 (!) tickets has been moved to 1.8 yesterday when I released
> > 1.7 version in JIRA.
> >
> > For what it's worth, I've added a step to vote verification:
> > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> >
> > Pavel
> >
> > On Tue, Aug 9, 2016 at 9:37 PM, Konstantin Boudnik <[hidden email]> wrote:
> >
> > > Gents,
> > >
> > > this has triggered the recollection of the release notes conversation we
> > > had
> > > the other day. Looks like the ticket queue isn't getting pruned in time of
> > > the
> > > release, so the changes like that are happening postfactum. This is either
> > > leads to more load on the RM, or might be error-prone.
> > >
> > > I want to share some of the RM best practices that I have observed and used
> > > myself in other projects (Bigtop, Hadoop, etc.). JIRA cleaning/pruning is
> > > normally one of the steps _leading_ to release. It helps to narrow down the
> > > scope of the work that still is needed to be done before the release could
> > > be
> > > cut. Once the scope is decided and all JIRAs considered for later are
> > > moved to
> > > the consequent release, JIRA software allow you to generate the release
> > > notes
> > > file, that can be included into the release itself. This provide a
> > > necessary
> > > connection between the source code in the release and the issues addressed
> > > by
> > > it. Once the release is published, the RM needs to officially _release_ the
> > > version in the JIRA software. At this point, the number of unfinished
> > > ticket
> > > against that version should be exactly 0. It is just a matter of the
> > > house-keeping and a good engineering practice. And it helps to keep down
> > > the
> > > amount of the mess.
> > >
> > > Hope it makes sense.
> > >   Cos
> > >
> > > ----- Forwarded message from "Pavel Tupitsyn (JIRA)" <[hidden email]>
> > > -----
> > >
> > > Date: Tue, 9 Aug 2016 12:32:32 +0000 (UTC)
> > > From: "Pavel Tupitsyn (JIRA)" <[hidden email]>
> > > To: [hidden email]
> > > Subject: [jira] [Updated] (IGNITE-2437) Zeppelin interperet doesn't import
> > > external dependencies
> > >
> > >
> > >      [ https://issues.apache.org/jira/browse/IGNITE-2437?page=
> > > com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> > >
> > > Pavel Tupitsyn updated IGNITE-2437:
> > > -----------------------------------
> > >     Fix Version/s:     (was: 1.7)
> > >                    1.8
> > >
> > > > Zeppelin interperet doesn't import external dependencies
> > > > --------------------------------------------------------
> > > >
> > > >                 Key: IGNITE-2437
> > > >                 URL: https://issues.apache.org/jira/browse/IGNITE-2437
> > > >             Project: Ignite
> > > >          Issue Type: Bug
> > > >          Components: general
> > > >    Affects Versions: 1.5.0.final
> > > >         Environment: zeppelin 0.5.5
> > > > ignite 1.5.0.final
> > > >            Reporter: Konstantin Boudnik
> > > >            Assignee: Andrey Gura
> > > >             Fix For: 1.8
> > > >
> > > >
> > > > After configuring Ignite's interpreter for Zeppelin, tried to run the
> > > following
> > > > {code}
> > > > %dep
> > > > z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")
> > > > %ignite
> > > > import io.company._
> > > > console>:23: error: object company is not a member of package io
> > > >        import io.company._
> > > > {code}
> > > > same code works just fine in spark interpreter though.
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v6.3.4#6332)
> > >
> > > ----- End forwarded message -----
> > >
Reply | Threaded
Open this post in threaded view
|

Re: Release notes preparations...

Pavel Tupitsyn
Cos, I tried to give you admin rights, but you already have them.

1.4 released.
All non-closed issues with fix version < 1.8 moved to 1.8.

Pavel.

On Wed, Aug 10, 2016 at 10:27 PM, Konstantin Boudnik <[hidden email]> wrote:

> BTW, I see another issue with not pruning the tickets _before_ the release
> is
> made. Right now, there's a bunch of tickets still marked to be fixed in say
> 1.6, which should've been moved to 1.7 at the time of 1.6 being released.
>
> Also, 1.4 release is still marked as active in JIRA. Unfortunately, I can
> not
> fix this issue as I lack the admin permissions on the project.
>
> Cos
>
> On Wed, Aug 10, 2016 at 07:44AM, Konstantin Boudnik wrote:
> > Great! Thanks for updating the page! I've noticed that we are still using
> > unsecure md5 and sha1, but i guess this is a topic for a different time
> ;)
> >
> > Cheers,
> >   Cos
> >
> > On Wed, Aug 10, 2016 at 12:26PM, Pavel Tupitsyn wrote:
> > > Cos, you are right.
> > >
> > > More than 300 (!) tickets has been moved to 1.8 yesterday when I
> released
> > > 1.7 version in JIRA.
> > >
> > > For what it's worth, I've added a step to vote verification:
> > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process
> > >
> > > Pavel
> > >
> > > On Tue, Aug 9, 2016 at 9:37 PM, Konstantin Boudnik <[hidden email]>
> wrote:
> > >
> > > > Gents,
> > > >
> > > > this has triggered the recollection of the release notes
> conversation we
> > > > had
> > > > the other day. Looks like the ticket queue isn't getting pruned in
> time of
> > > > the
> > > > release, so the changes like that are happening postfactum. This is
> either
> > > > leads to more load on the RM, or might be error-prone.
> > > >
> > > > I want to share some of the RM best practices that I have observed
> and used
> > > > myself in other projects (Bigtop, Hadoop, etc.). JIRA
> cleaning/pruning is
> > > > normally one of the steps _leading_ to release. It helps to narrow
> down the
> > > > scope of the work that still is needed to be done before the release
> could
> > > > be
> > > > cut. Once the scope is decided and all JIRAs considered for later are
> > > > moved to
> > > > the consequent release, JIRA software allow you to generate the
> release
> > > > notes
> > > > file, that can be included into the release itself. This provide a
> > > > necessary
> > > > connection between the source code in the release and the issues
> addressed
> > > > by
> > > > it. Once the release is published, the RM needs to officially
> _release_ the
> > > > version in the JIRA software. At this point, the number of unfinished
> > > > ticket
> > > > against that version should be exactly 0. It is just a matter of the
> > > > house-keeping and a good engineering practice. And it helps to keep
> down
> > > > the
> > > > amount of the mess.
> > > >
> > > > Hope it makes sense.
> > > >   Cos
> > > >
> > > > ----- Forwarded message from "Pavel Tupitsyn (JIRA)" <
> [hidden email]>
> > > > -----
> > > >
> > > > Date: Tue, 9 Aug 2016 12:32:32 +0000 (UTC)
> > > > From: "Pavel Tupitsyn (JIRA)" <[hidden email]>
> > > > To: [hidden email]
> > > > Subject: [jira] [Updated] (IGNITE-2437) Zeppelin interperet doesn't
> import
> > > > external dependencies
> > > >
> > > >
> > > >      [ https://issues.apache.org/jira/browse/IGNITE-2437?page=
> > > > com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> > > >
> > > > Pavel Tupitsyn updated IGNITE-2437:
> > > > -----------------------------------
> > > >     Fix Version/s:     (was: 1.7)
> > > >                    1.8
> > > >
> > > > > Zeppelin interperet doesn't import external dependencies
> > > > > --------------------------------------------------------
> > > > >
> > > > >                 Key: IGNITE-2437
> > > > >                 URL: https://issues.apache.org/jira
> /browse/IGNITE-2437
> > > > >             Project: Ignite
> > > > >          Issue Type: Bug
> > > > >          Components: general
> > > > >    Affects Versions: 1.5.0.final
> > > > >         Environment: zeppelin 0.5.5
> > > > > ignite 1.5.0.final
> > > > >            Reporter: Konstantin Boudnik
> > > > >            Assignee: Andrey Gura
> > > > >             Fix For: 1.8
> > > > >
> > > > >
> > > > > After configuring Ignite's interpreter for Zeppelin, tried to run
> the
> > > > following
> > > > > {code}
> > > > > %dep
> > > > > z.load("/usr/lib/ignite/libs/ignite-cache-objects.jar")
> > > > > %ignite
> > > > > import io.company._
> > > > > console>:23: error: object company is not a member of package io
> > > > >        import io.company._
> > > > > {code}
> > > > > same code works just fine in spark interpreter though.
> > > >
> > > >
> > > >
> > > > --
> > > > This message was sent by Atlassian JIRA
> > > > (v6.3.4#6332)
> > > >
> > > > ----- End forwarded message -----
> > > >
>