You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Justin Leet <ju...@gmail.com> on 2018/08/15 15:01:54 UTC
[DISCUSS] Release cadence
Hi all,
In concert with the discuss thread on a potential 0.6.0 release, I'd also
like start a discussion about our release cadence. We've generally been
pretty relaxed around doing releases, and I'm curious what people's
thoughts are on adopting a somewhat more regular schedule.
Couple questions I think are relevant
1. Is this something we should work towards and, if we do, how do we want
to go about it?
- "Whenever someone feels like pushing out a discuss thread"?
- "Let's just start a discuss thread every X and if we want to release
we release"?
- "let's try to get a release out every X and what's on the bus is on
the bus"?
- Something else?
2. Assuming we do want to do more regular releases, what's the timeframe
we'd like to shoot for?
Personally, I'd like to just start a discuss thread regularly, with the
built-in expectation that not every thread should necessarily lead to a
release. I don't want to be forcing release overhead when there's not
enough to merit a release, but releasing more often than we often do now
would provide a lot of values to users.
In terms of timeframe, I tend to think a 2-3 month cadence for the threads
is reasonable. It's long enough to potentially accrue enough features to
merit a release, but short enough that when we pass on a release we're
probably fine just waiting for another cycle to come around. The last
release was ~2 months ago and we have a good amount of stuff here, but I
also don't expect two feature branches going in to be the norm.
I'd expect whatever comes out of this thread to also be relatively
informal. At least right now, I don't feel like we need a rigid schedule,
and I'd still like people to feel encouraged to propose a release,
particularly when there are a couple major features or critical fixes.
Alternatively, I would expect some of these discuss threads to conclude,
"We should do a release, but let's wait a couple waits for these tickets to
finish up" (e.g. like the Pcap query panel).
Justin
Re: [DISCUSS] Release cadence
Posted by Michael Miklavcic <mi...@gmail.com>.
Works for me, that would be great.
On Wed, Aug 15, 2018 at 12:22 PM Casey Stella <ce...@gmail.com> wrote:
> If you like, I can volunteer to kick off a discuss thread when I submit the
> board report.
>
> On Wed, Aug 15, 2018 at 2:21 PM Michael Miklavcic <
> michael.miklavcic@gmail.com> wrote:
>
> > I'm also a fan of the 2-3 month time frame for releases. And I agree it
> > fits nicely with our board report. That said, I think we should minimally
> > kick off a DISCUSS at least every 2 months per the recommendations above.
> > If it's warranted, great. If not, then we bring it up at a stated later
> > time for re-evaluation.
> >
> > Fwiw, some upcoming features post-0.6.0 that I'm seeing which are also
> > large-ish and will fit nicely into the next cycle (pending completion, of
> > course):
> >
> > 1. NiFi Metron parsers
> > 2. Profiler enhancements - bootstrapping, etc.
> > 3. Knox SSO
> >
> >
> >
> > On Wed, Aug 15, 2018 at 11:10 AM Casey Stella <ce...@gmail.com>
> wrote:
> >
> > > Strictly selfishly, I'd love for a release to happen quickly enough to
> > have
> > > something to announce to the board during the reports. Once every 2
> > months
> > > or when a sufficiently complicated change happens sounds like a
> sensible
> > > cadence.
> > >
> > > I very much support a "how do we get to 1.0" discussion, maybe as a
> > > separate thread?
> > >
> > > On Wed, Aug 15, 2018 at 11:56 AM Zeolla@GMail.com <ze...@gmail.com>
> > > wrote:
> > >
> > > > I'm a fan of a hybrid time/feature-based cadence. Something like
> > "When 3
> > > > months has passed since our last release, or a sufficiently
> complicated
> > > > change has been introduced to master (like merging a FB), a discuss
> > > thread
> > > > is started". I'm primarily thinking of what the upgrade path looks
> > like
> > > > (more on that in a "how do we get to 1.0" discuss).
> > > >
> > > > Jon
> > > >
> > > > On Wed, Aug 15, 2018 at 11:02 AM Justin Leet <ju...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > In concert with the discuss thread on a potential 0.6.0 release,
> I'd
> > > also
> > > > > like start a discussion about our release cadence. We've generally
> > > been
> > > > > pretty relaxed around doing releases, and I'm curious what people's
> > > > > thoughts are on adopting a somewhat more regular schedule.
> > > > >
> > > > > Couple questions I think are relevant
> > > > > 1. Is this something we should work towards and, if we do, how do
> we
> > > want
> > > > > to go about it?
> > > > >
> > > > > - "Whenever someone feels like pushing out a discuss thread"?
> > > > > - "Let's just start a discuss thread every X and if we want to
> > > release
> > > > > we release"?
> > > > > - "let's try to get a release out every X and what's on the bus
> is
> > > on
> > > > > the bus"?
> > > > > - Something else?
> > > > >
> > > > > 2. Assuming we do want to do more regular releases, what's the
> > > timeframe
> > > > > we'd like to shoot for?
> > > > >
> > > > > Personally, I'd like to just start a discuss thread regularly, with
> > the
> > > > > built-in expectation that not every thread should necessarily lead
> > to a
> > > > > release. I don't want to be forcing release overhead when there's
> not
> > > > > enough to merit a release, but releasing more often than we often
> do
> > > now
> > > > > would provide a lot of values to users.
> > > > >
> > > > > In terms of timeframe, I tend to think a 2-3 month cadence for the
> > > > threads
> > > > > is reasonable. It's long enough to potentially accrue enough
> features
> > > to
> > > > > merit a release, but short enough that when we pass on a release
> > we're
> > > > > probably fine just waiting for another cycle to come around. The
> > last
> > > > > release was ~2 months ago and we have a good amount of stuff here,
> > but
> > > I
> > > > > also don't expect two feature branches going in to be the norm.
> > > > >
> > > > > I'd expect whatever comes out of this thread to also be relatively
> > > > > informal. At least right now, I don't feel like we need a rigid
> > > schedule,
> > > > > and I'd still like people to feel encouraged to propose a release,
> > > > > particularly when there are a couple major features or critical
> > fixes.
> > > > > Alternatively, I would expect some of these discuss threads to
> > > conclude,
> > > > > "We should do a release, but let's wait a couple waits for these
> > > tickets
> > > > to
> > > > > finish up" (e.g. like the Pcap query panel).
> > > > >
> > > > > Justin
> > > > >
> > > > --
> > > >
> > > > Jon
> > > >
> > >
> >
>
Re: [DISCUSS] Release cadence
Posted by Casey Stella <ce...@gmail.com>.
If you like, I can volunteer to kick off a discuss thread when I submit the
board report.
On Wed, Aug 15, 2018 at 2:21 PM Michael Miklavcic <
michael.miklavcic@gmail.com> wrote:
> I'm also a fan of the 2-3 month time frame for releases. And I agree it
> fits nicely with our board report. That said, I think we should minimally
> kick off a DISCUSS at least every 2 months per the recommendations above.
> If it's warranted, great. If not, then we bring it up at a stated later
> time for re-evaluation.
>
> Fwiw, some upcoming features post-0.6.0 that I'm seeing which are also
> large-ish and will fit nicely into the next cycle (pending completion, of
> course):
>
> 1. NiFi Metron parsers
> 2. Profiler enhancements - bootstrapping, etc.
> 3. Knox SSO
>
>
>
> On Wed, Aug 15, 2018 at 11:10 AM Casey Stella <ce...@gmail.com> wrote:
>
> > Strictly selfishly, I'd love for a release to happen quickly enough to
> have
> > something to announce to the board during the reports. Once every 2
> months
> > or when a sufficiently complicated change happens sounds like a sensible
> > cadence.
> >
> > I very much support a "how do we get to 1.0" discussion, maybe as a
> > separate thread?
> >
> > On Wed, Aug 15, 2018 at 11:56 AM Zeolla@GMail.com <ze...@gmail.com>
> > wrote:
> >
> > > I'm a fan of a hybrid time/feature-based cadence. Something like
> "When 3
> > > months has passed since our last release, or a sufficiently complicated
> > > change has been introduced to master (like merging a FB), a discuss
> > thread
> > > is started". I'm primarily thinking of what the upgrade path looks
> like
> > > (more on that in a "how do we get to 1.0" discuss).
> > >
> > > Jon
> > >
> > > On Wed, Aug 15, 2018 at 11:02 AM Justin Leet <ju...@gmail.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > In concert with the discuss thread on a potential 0.6.0 release, I'd
> > also
> > > > like start a discussion about our release cadence. We've generally
> > been
> > > > pretty relaxed around doing releases, and I'm curious what people's
> > > > thoughts are on adopting a somewhat more regular schedule.
> > > >
> > > > Couple questions I think are relevant
> > > > 1. Is this something we should work towards and, if we do, how do we
> > want
> > > > to go about it?
> > > >
> > > > - "Whenever someone feels like pushing out a discuss thread"?
> > > > - "Let's just start a discuss thread every X and if we want to
> > release
> > > > we release"?
> > > > - "let's try to get a release out every X and what's on the bus is
> > on
> > > > the bus"?
> > > > - Something else?
> > > >
> > > > 2. Assuming we do want to do more regular releases, what's the
> > timeframe
> > > > we'd like to shoot for?
> > > >
> > > > Personally, I'd like to just start a discuss thread regularly, with
> the
> > > > built-in expectation that not every thread should necessarily lead
> to a
> > > > release. I don't want to be forcing release overhead when there's not
> > > > enough to merit a release, but releasing more often than we often do
> > now
> > > > would provide a lot of values to users.
> > > >
> > > > In terms of timeframe, I tend to think a 2-3 month cadence for the
> > > threads
> > > > is reasonable. It's long enough to potentially accrue enough features
> > to
> > > > merit a release, but short enough that when we pass on a release
> we're
> > > > probably fine just waiting for another cycle to come around. The
> last
> > > > release was ~2 months ago and we have a good amount of stuff here,
> but
> > I
> > > > also don't expect two feature branches going in to be the norm.
> > > >
> > > > I'd expect whatever comes out of this thread to also be relatively
> > > > informal. At least right now, I don't feel like we need a rigid
> > schedule,
> > > > and I'd still like people to feel encouraged to propose a release,
> > > > particularly when there are a couple major features or critical
> fixes.
> > > > Alternatively, I would expect some of these discuss threads to
> > conclude,
> > > > "We should do a release, but let's wait a couple waits for these
> > tickets
> > > to
> > > > finish up" (e.g. like the Pcap query panel).
> > > >
> > > > Justin
> > > >
> > > --
> > >
> > > Jon
> > >
> >
>
Re: [DISCUSS] Release cadence
Posted by Michael Miklavcic <mi...@gmail.com>.
I'm also a fan of the 2-3 month time frame for releases. And I agree it
fits nicely with our board report. That said, I think we should minimally
kick off a DISCUSS at least every 2 months per the recommendations above.
If it's warranted, great. If not, then we bring it up at a stated later
time for re-evaluation.
Fwiw, some upcoming features post-0.6.0 that I'm seeing which are also
large-ish and will fit nicely into the next cycle (pending completion, of
course):
1. NiFi Metron parsers
2. Profiler enhancements - bootstrapping, etc.
3. Knox SSO
On Wed, Aug 15, 2018 at 11:10 AM Casey Stella <ce...@gmail.com> wrote:
> Strictly selfishly, I'd love for a release to happen quickly enough to have
> something to announce to the board during the reports. Once every 2 months
> or when a sufficiently complicated change happens sounds like a sensible
> cadence.
>
> I very much support a "how do we get to 1.0" discussion, maybe as a
> separate thread?
>
> On Wed, Aug 15, 2018 at 11:56 AM Zeolla@GMail.com <ze...@gmail.com>
> wrote:
>
> > I'm a fan of a hybrid time/feature-based cadence. Something like "When 3
> > months has passed since our last release, or a sufficiently complicated
> > change has been introduced to master (like merging a FB), a discuss
> thread
> > is started". I'm primarily thinking of what the upgrade path looks like
> > (more on that in a "how do we get to 1.0" discuss).
> >
> > Jon
> >
> > On Wed, Aug 15, 2018 at 11:02 AM Justin Leet <ju...@gmail.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > In concert with the discuss thread on a potential 0.6.0 release, I'd
> also
> > > like start a discussion about our release cadence. We've generally
> been
> > > pretty relaxed around doing releases, and I'm curious what people's
> > > thoughts are on adopting a somewhat more regular schedule.
> > >
> > > Couple questions I think are relevant
> > > 1. Is this something we should work towards and, if we do, how do we
> want
> > > to go about it?
> > >
> > > - "Whenever someone feels like pushing out a discuss thread"?
> > > - "Let's just start a discuss thread every X and if we want to
> release
> > > we release"?
> > > - "let's try to get a release out every X and what's on the bus is
> on
> > > the bus"?
> > > - Something else?
> > >
> > > 2. Assuming we do want to do more regular releases, what's the
> timeframe
> > > we'd like to shoot for?
> > >
> > > Personally, I'd like to just start a discuss thread regularly, with the
> > > built-in expectation that not every thread should necessarily lead to a
> > > release. I don't want to be forcing release overhead when there's not
> > > enough to merit a release, but releasing more often than we often do
> now
> > > would provide a lot of values to users.
> > >
> > > In terms of timeframe, I tend to think a 2-3 month cadence for the
> > threads
> > > is reasonable. It's long enough to potentially accrue enough features
> to
> > > merit a release, but short enough that when we pass on a release we're
> > > probably fine just waiting for another cycle to come around. The last
> > > release was ~2 months ago and we have a good amount of stuff here, but
> I
> > > also don't expect two feature branches going in to be the norm.
> > >
> > > I'd expect whatever comes out of this thread to also be relatively
> > > informal. At least right now, I don't feel like we need a rigid
> schedule,
> > > and I'd still like people to feel encouraged to propose a release,
> > > particularly when there are a couple major features or critical fixes.
> > > Alternatively, I would expect some of these discuss threads to
> conclude,
> > > "We should do a release, but let's wait a couple waits for these
> tickets
> > to
> > > finish up" (e.g. like the Pcap query panel).
> > >
> > > Justin
> > >
> > --
> >
> > Jon
> >
>
Re: [DISCUSS] Release cadence
Posted by Casey Stella <ce...@gmail.com>.
Strictly selfishly, I'd love for a release to happen quickly enough to have
something to announce to the board during the reports. Once every 2 months
or when a sufficiently complicated change happens sounds like a sensible
cadence.
I very much support a "how do we get to 1.0" discussion, maybe as a
separate thread?
On Wed, Aug 15, 2018 at 11:56 AM Zeolla@GMail.com <ze...@gmail.com> wrote:
> I'm a fan of a hybrid time/feature-based cadence. Something like "When 3
> months has passed since our last release, or a sufficiently complicated
> change has been introduced to master (like merging a FB), a discuss thread
> is started". I'm primarily thinking of what the upgrade path looks like
> (more on that in a "how do we get to 1.0" discuss).
>
> Jon
>
> On Wed, Aug 15, 2018 at 11:02 AM Justin Leet <ju...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > In concert with the discuss thread on a potential 0.6.0 release, I'd also
> > like start a discussion about our release cadence. We've generally been
> > pretty relaxed around doing releases, and I'm curious what people's
> > thoughts are on adopting a somewhat more regular schedule.
> >
> > Couple questions I think are relevant
> > 1. Is this something we should work towards and, if we do, how do we want
> > to go about it?
> >
> > - "Whenever someone feels like pushing out a discuss thread"?
> > - "Let's just start a discuss thread every X and if we want to release
> > we release"?
> > - "let's try to get a release out every X and what's on the bus is on
> > the bus"?
> > - Something else?
> >
> > 2. Assuming we do want to do more regular releases, what's the timeframe
> > we'd like to shoot for?
> >
> > Personally, I'd like to just start a discuss thread regularly, with the
> > built-in expectation that not every thread should necessarily lead to a
> > release. I don't want to be forcing release overhead when there's not
> > enough to merit a release, but releasing more often than we often do now
> > would provide a lot of values to users.
> >
> > In terms of timeframe, I tend to think a 2-3 month cadence for the
> threads
> > is reasonable. It's long enough to potentially accrue enough features to
> > merit a release, but short enough that when we pass on a release we're
> > probably fine just waiting for another cycle to come around. The last
> > release was ~2 months ago and we have a good amount of stuff here, but I
> > also don't expect two feature branches going in to be the norm.
> >
> > I'd expect whatever comes out of this thread to also be relatively
> > informal. At least right now, I don't feel like we need a rigid schedule,
> > and I'd still like people to feel encouraged to propose a release,
> > particularly when there are a couple major features or critical fixes.
> > Alternatively, I would expect some of these discuss threads to conclude,
> > "We should do a release, but let's wait a couple waits for these tickets
> to
> > finish up" (e.g. like the Pcap query panel).
> >
> > Justin
> >
> --
>
> Jon
>
Re: [DISCUSS] Release cadence
Posted by "Zeolla@GMail.com" <ze...@gmail.com>.
I'm a fan of a hybrid time/feature-based cadence. Something like "When 3
months has passed since our last release, or a sufficiently complicated
change has been introduced to master (like merging a FB), a discuss thread
is started". I'm primarily thinking of what the upgrade path looks like
(more on that in a "how do we get to 1.0" discuss).
Jon
On Wed, Aug 15, 2018 at 11:02 AM Justin Leet <ju...@gmail.com> wrote:
> Hi all,
>
> In concert with the discuss thread on a potential 0.6.0 release, I'd also
> like start a discussion about our release cadence. We've generally been
> pretty relaxed around doing releases, and I'm curious what people's
> thoughts are on adopting a somewhat more regular schedule.
>
> Couple questions I think are relevant
> 1. Is this something we should work towards and, if we do, how do we want
> to go about it?
>
> - "Whenever someone feels like pushing out a discuss thread"?
> - "Let's just start a discuss thread every X and if we want to release
> we release"?
> - "let's try to get a release out every X and what's on the bus is on
> the bus"?
> - Something else?
>
> 2. Assuming we do want to do more regular releases, what's the timeframe
> we'd like to shoot for?
>
> Personally, I'd like to just start a discuss thread regularly, with the
> built-in expectation that not every thread should necessarily lead to a
> release. I don't want to be forcing release overhead when there's not
> enough to merit a release, but releasing more often than we often do now
> would provide a lot of values to users.
>
> In terms of timeframe, I tend to think a 2-3 month cadence for the threads
> is reasonable. It's long enough to potentially accrue enough features to
> merit a release, but short enough that when we pass on a release we're
> probably fine just waiting for another cycle to come around. The last
> release was ~2 months ago and we have a good amount of stuff here, but I
> also don't expect two feature branches going in to be the norm.
>
> I'd expect whatever comes out of this thread to also be relatively
> informal. At least right now, I don't feel like we need a rigid schedule,
> and I'd still like people to feel encouraged to propose a release,
> particularly when there are a couple major features or critical fixes.
> Alternatively, I would expect some of these discuss threads to conclude,
> "We should do a release, but let's wait a couple waits for these tickets to
> finish up" (e.g. like the Pcap query panel).
>
> Justin
>
--
Jon