You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Joshua McKenzie <jm...@apache.org> on 2020/03/28 14:14:40 UTC
Idea: Marking required scope for 4.0 GA vs. optional
As we're under a feature freeze but not code freeze, there are quite
reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look like
nice to haves for the release but wouldn't necessarily block cutting GA. I
think there would be value in us flagging tickets that are required for 4.0
to get out the door as blockers - it looks like we don't have the Priority
entry anymore (a good thing imo) but we could use the label field to
indicate which tickets are blockers and filter our JIRA board and weekly
reporting on that. That would also help contributors know where to focus
their efforts to help get 4.0 out the door while not stifling people
scratching their own itch on things leading up to the release.
What do the rest of you on the project think?
~Josh
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Stefan Miklosovic <st...@instaclustr.com>.
Yeah, the statement "we want to release ASAP" was quite scary to read. Did
I miss something? When do we cut GA? ASAP is like next week? What is going
on? Help! :D
On Sat, 28 Mar 2020 at 22:00, Joshua McKenzie <jm...@apache.org> wrote:
> >
> > since we want to release ASAP
> >
> Help me understand how to reconcile this statement with the fact that
> improvements and other nice-to-have optional tickets are being created and
> worked on in even 4.0-alpha as recently as this past week. While *you* and
> many others may want to release ASAP (including myself fwiw), this is a
> large project with a large number of participants and I think it inaccurate
> to speak for everyone.
>
> Do we gain much by introducing yet another view on Jira that nobody will
> > properly maintain?
> >
> I don't share your belief that this will not be maintained, as I will be
> one of three people keeping an eye on maintaining a view like this for the
> hopefully small number of months leading up to 4.0 GA. It seems we
> currently have a state that is not being demarcated - what is MVP for scope
> on release vs. what is optional but targeting it. Rather than forcing
> peoples' tickets out of the release even if they still have every intent to
> get them in, I would prefer we have additional metadata and allow signaling
> of "targeting release" vs. "required for release".
>
> Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> indicate something is targeting a release vs. blocking on inclusion for it.
> That seems to be a more "project JIRA hackish idiom", and one that's
> historically been confusing for people. At least with a label it would be
> clear with a name like "4.0-blocker", and we could then easily filter the
> JIRA board on it.
>
>
> On Sat, Mar 28, 2020 at 2:52 PM Benedict Elliott Smith <
> benedict@apache.org>
> wrote:
>
> > I would personally prefer we simply bump tickets from the milestone
> > periodically. The point of a milestone is to collect tickets we expect
> to
> > land there, and since we want to release ASAP we should have at most a
> > handful of optional items there sponsored by some community members, so
> the
> > burden should be low.
> >
> > Do we gain much by introducing yet another view on Jira that nobody will
> > properly maintain? It sounds like a classic situation of having one
> > problem, and simply ending up with two problems.
> >
> >
> > On 28/03/2020, 18:44, "Scott Andreas" <sc...@paradoxica.net> wrote:
> >
> > Yep that makes sense to me.
> >
> > There's still much work to be done to exercise 4.0 builds to identify
> > unknown issues that haven't yet been filed – but those items can be
> tagged
> > as release blockers as they're identified. 👍
> >
> > ________________________________________
> > From: Joshua McKenzie <jm...@apache.org>
> > Sent: Saturday, March 28, 2020 7:14 AM
> > To: dev@cassandra.apache.org
> > Subject: Idea: Marking required scope for 4.0 GA vs. optional
> >
> > As we're under a feature freeze but not code freeze, there are quite
> > reasonably tickets being opened for 4.0 (alpha, beta, or rc) that
> look
> > like
> > nice to haves for the release but wouldn't necessarily block cutting
> > GA. I
> > think there would be value in us flagging tickets that are required
> > for 4.0
> > to get out the door as blockers - it looks like we don't have the
> > Priority
> > entry anymore (a good thing imo) but we could use the label field to
> > indicate which tickets are blockers and filter our JIRA board and
> > weekly
> > reporting on that. That would also help contributors know where to
> > focus
> > their efforts to help get 4.0 out the door while not stifling people
> > scratching their own itch on things leading up to the release.
> >
> > What do the rest of you on the project think?
> >
> > ~Josh
> >
> >
> B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�
> > � [��X��ܚX�K K[XZ[
> > � ]�][��X��ܚX�P �\��[� �K�\ X� K�ܙ�B��܈ Y ] [ۘ[ ��[X[� � K[XZ[
> > � ]�Z [ �\��[� �K�\ X� K�ܙ�B�B
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Joshua McKenzie <jm...@apache.org>.
An initial rough attempt to get together a queried view of outstanding
scope for "4.0 GA blockers" is here on this quick filter:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA&quickFilter=1719
JQL for a very similar query (pulls in about 10 more: catches sub-tasks for
things that are improvements I think?):
https://issues.apache.org/jira/issues/?filter=12348578
So that should at least help unblock anybody that's looking for "what's a
more refined subset of things that are GA blockers for 4.0". Hopefully
that's helpful.
Be aware - that query does a dumb pull in of things that haven't updated in
two weeks. That might be too aggressive, might be just fine, but be aware
that there's tickets people are probably deeply into that don't need
external prodding captured in that list along with just trivially stuck
things that fell off radars.
~Josh
On Tue, Mar 31, 2020 at 4:27 PM Jake Luciani <ja...@gmail.com> wrote:
> I've been starting to look at the work left for 4.0 and was surprised to
> see almost 1/2 the open tickets are Improvements.
> Shouldn't the only criteria for 4.0 at this point should be bugs.
>
> Can we agree to move the improvements out to 4.0.x?
>
> -Jake
>
> On Tue, Mar 31, 2020 at 4:02 PM Ekaterina Dimitrova <
> ekaterina.dimitrova@datastax.com> wrote:
>
> > Hello everyone,
> > I think the project might benefit of one "filter applied" now on the
> > current scope of JIRA tickets.
> > And then, regular triage so focus is not lost.
> >
> > Up to now, I always try to look at the Release Lifecycle [1] criteria
> when
> > I open a new ticket in order to mark what is the target version of the
> > patch. Also, I look from the perspective of the general code freeze.
> > Hope I am doing it right. If those are strictly marked, do we need
> > additional label for blocking tickets? Or we want to differentiate
> between
> > strong blockers and such patches which would be good if they land at a
> > specific release but not mandatory?
> >
> > Why I am in for initial filter now? As I found many tickets opened in
> > 2016...17...etc Things have changed a lot since then and there can be
> > easily different PoV nowadays.
> >
> > I would be more than happy to help in any of these activities, too.
> >
> > Ekaterina
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> >
> >
> > > Begin forwarded message:
> > >
> > > *From:* David Capwell <dc...@gmail.com>
> > > *Date:* 31 March 2020, 15:15:11 GMT-4
> > > *To:* dev@cassandra.apache.org
> > > *Subject:* *Re: Idea: Marking required scope for 4.0 GA vs. optional*
> > > *Reply-To:* dev@cassandra.apache.org
> > >
> > > What I'm used to is having two buckets for a release: tickets in the
> > > release (if not complete they are blockers), and triage. How this is
> done
> > > isn't important but I do feel it's important to have both.
> > >
> > > Right now I don't see a active triage, but to Josh's point we would
> need
> > to
> > > know who should first. Without answering, let me ask a question;
> should I
> > > (non committer) be adding blockers? If I add a blocker who should
> verify
> > it
> > > should block? What if project members elect non-commiters to do this?
> > >
> > >
> > >
> > > On Mon, Mar 30, 2020, 8:45 AM Joshua McKenzie <jm...@apache.org>
> > > wrote:
> > >
> > > Regardless of how we indicate optional vs. required for rel, are there
> > >
> > > strong opinions on who should set that metadata on tickets? Reporter?
> > >
> > > Assignee? One person? A group of people?
> > >
> > >
> > >
> > > On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie <jmckenzie@apache.org
> >
> > >
> > > wrote:
> > >
> > >
> > > FWIW, I don't care what we go with as long as we can differentiate
> > >
> > > tickets
> > >
> > > that are optional for the rel vs. tickets that are blockers and filter
> > >
> > > the
> > >
> > > JIRA board on them so people know where they should focus their effort.
> > >
> > >
> > > The rest of it's just paint colors to me.
> > >
> > >
> > > On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever <mc...@apache.org>
> wrote:
> > >
> > >
> > >
> > > Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> > >
> > > indicate something is targeting a release vs. blocking on inclusion
> > >
> > > for
> > >
> > > it.
> > >
> > > That seems to be a more "project JIRA hackish idiom", and one that's
> > >
> > > historically been confusing for people. At least with a label it would
> > >
> > > be
> > >
> > > clear with a name like "4.0-blocker", and we could then easily filter
> > >
> > > the
> > >
> > > JIRA board on it.
> > >
> > >
> > >
> > >
> > > Now that I better understand Benedict's previous response (see the
> > >
> > > 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view
> > >
> > > for
> > >
> > > now.
> > >
> > >
> > > I certainly missed the difference on how tickets ended up resolved as
> > >
> > > `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
> > >
> > > still go into `4.0-alpha` if they satisfied the feature freeze and met
> > >
> > > someone's itch, while the unresolved `4.0-alpha` tickets were those the
> > >
> > > community declared as blockers.
> > >
> > >
> > > Putting aside the discussion on what is a blocker, when it is
> discovered
> > >
> > > to
> > >
> > > be a blocker (and vice versa). My confusion stemmed from the fact there
> > >
> > > was
> > >
> > > no specific alpha|beta versions for tickets to get resolved into, eg
> > >
> > > 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x`
> > >
> > > nomenclature got changed, but having accurate fix versions was also
> > >
> > > removed. If we added the specific alpha|beta versions then I wouldn't
> > >
> > > consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
> > >
> > > 4.0-beta and 4.0, versions become purely target versions like the `.x`,
> > >
> > > and
> > >
> > > no resolved ticket is ever assigned them.
> > >
> > >
> > > The simpler we can make and document this the better. please.
> > >
> > >
> > > regards,
> > >
> > > Mick
> > >
> > >
> > > ¹)
> > >
> > >
> > >
> > >
> > >
> >
> https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
> > >
> > >
> > >
> > >
> > >
> >
>
>
> --
> http://twitter.com/tjake
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Dinesh Joshi <dj...@icloud.com.INVALID>.
On CASSANDRA-15379, I think we would’ve discovered this issue during 4.0 testing and would have needed this bug fix anyway. We just caught it early because you went ahead and tested the feature ;)
Dinesh
> On Mar 31, 2020, at 3:27 PM, Joseph Lynch <jo...@gmail.com> wrote:
>
> On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani <ja...@gmail.com> wrote:
>>
>> Can we agree to move the improvements out to 4.0.x?
>
> Generally I've been asked to put performance issues as improvements,
> e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
> on real clusters without that patch, and therefore I wouldn't feel
> great releasing ZstdCompressor in 4.0 without that patch.
>
> I'm fine to start calling all performance issues "bugs" since at least
> in our deployments and I think in many others performance regressions
> are P0 bugs that cost a lot of $$, or we can just keep calling them
> improvements and just tag them with the ~right target fix version.
> Namely 4.0-alpha if the change impacts any public interface in a non
> backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
> or later if it does not require changes to public interfaces.
>
> -Joey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Joshua McKenzie <jm...@apache.org>.
My PoV re: perf: if it's a regression or something that makes a new
feature just Not Work, mark it as bug.
All else mark improvement and can go in in patch rel.
On Tue, Mar 31, 2020 at 9:17 PM Jake Luciani <ja...@gmail.com> wrote:
>
> I see what you mean, I guess my personal line is: does this work worse than
> the previous released version?
> Seems like that's a yes in this case :)
>
> On Tue, Mar 31, 2020 at 7:35 PM David Capwell <dc...@gmail.com> wrote:
>
> > One ticket I wanted to bring up is CASSANDRA-15566, this ticket is not a
> > regression but it is a critical bug. Personally I feel that only
> > regression should go into a freeze so I have a hard time justifying that
> > ticket right now (all known failure modes have been failing since at least
> > 2.1). I guess the thing that is hard is where do we draw the line? One
> > person's bug is another person's improvement, so it's easy for different
> > perspectives to clash on this.
> >
> >
> > On Tue, Mar 31, 2020, 3:27 PM Joseph Lynch <jo...@gmail.com> wrote:
> >
> > > On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani <ja...@gmail.com> wrote:
> > > >
> > > > Can we agree to move the improvements out to 4.0.x?
> > >
> > > Generally I've been asked to put performance issues as improvements,
> > > e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
> > > on real clusters without that patch, and therefore I wouldn't feel
> > > great releasing ZstdCompressor in 4.0 without that patch.
> > >
> > > I'm fine to start calling all performance issues "bugs" since at least
> > > in our deployments and I think in many others performance regressions
> > > are P0 bugs that cost a lot of $$, or we can just keep calling them
> > > improvements and just tag them with the ~right target fix version.
> > > Namely 4.0-alpha if the change impacts any public interface in a non
> > > backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
> > > or later if it does not require changes to public interfaces.
> > >
> > > -Joey
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > > For additional commands, e-mail: dev-help@cassandra.apache.org
> > >
> > >
> >
>
>
> --
> http://twitter.com/tjake
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Jake Luciani <ja...@gmail.com>.
I see what you mean, I guess my personal line is: does this work worse than
the previous released version?
Seems like that's a yes in this case :)
On Tue, Mar 31, 2020 at 7:35 PM David Capwell <dc...@gmail.com> wrote:
> One ticket I wanted to bring up is CASSANDRA-15566, this ticket is not a
> regression but it is a critical bug. Personally I feel that only
> regression should go into a freeze so I have a hard time justifying that
> ticket right now (all known failure modes have been failing since at least
> 2.1). I guess the thing that is hard is where do we draw the line? One
> person's bug is another person's improvement, so it's easy for different
> perspectives to clash on this.
>
>
> On Tue, Mar 31, 2020, 3:27 PM Joseph Lynch <jo...@gmail.com> wrote:
>
> > On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani <ja...@gmail.com> wrote:
> > >
> > > Can we agree to move the improvements out to 4.0.x?
> >
> > Generally I've been asked to put performance issues as improvements,
> > e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
> > on real clusters without that patch, and therefore I wouldn't feel
> > great releasing ZstdCompressor in 4.0 without that patch.
> >
> > I'm fine to start calling all performance issues "bugs" since at least
> > in our deployments and I think in many others performance regressions
> > are P0 bugs that cost a lot of $$, or we can just keep calling them
> > improvements and just tag them with the ~right target fix version.
> > Namely 4.0-alpha if the change impacts any public interface in a non
> > backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
> > or later if it does not require changes to public interfaces.
> >
> > -Joey
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
--
http://twitter.com/tjake
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by David Capwell <dc...@gmail.com>.
One ticket I wanted to bring up is CASSANDRA-15566, this ticket is not a
regression but it is a critical bug. Personally I feel that only
regression should go into a freeze so I have a hard time justifying that
ticket right now (all known failure modes have been failing since at least
2.1). I guess the thing that is hard is where do we draw the line? One
person's bug is another person's improvement, so it's easy for different
perspectives to clash on this.
On Tue, Mar 31, 2020, 3:27 PM Joseph Lynch <jo...@gmail.com> wrote:
> On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani <ja...@gmail.com> wrote:
> >
> > Can we agree to move the improvements out to 4.0.x?
>
> Generally I've been asked to put performance issues as improvements,
> e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
> on real clusters without that patch, and therefore I wouldn't feel
> great releasing ZstdCompressor in 4.0 without that patch.
>
> I'm fine to start calling all performance issues "bugs" since at least
> in our deployments and I think in many others performance regressions
> are P0 bugs that cost a lot of $$, or we can just keep calling them
> improvements and just tag them with the ~right target fix version.
> Namely 4.0-alpha if the change impacts any public interface in a non
> backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
> or later if it does not require changes to public interfaces.
>
> -Joey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Jake Luciani <ja...@gmail.com>.
If the performance issue is a regression compared to 3.11 that makes total
sense.
And in the case of ZStd since that's new if its unusable without the
"improvement" then it also makes sense.
I think in both cases though it makes sense to classify these as
performance regression bugs.
I'll take a deeper look at the Improvement tickets, perhaps they all fall
into this category.
Jake
On Tue, Mar 31, 2020 at 6:27 PM Joseph Lynch <jo...@gmail.com> wrote:
> On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani <ja...@gmail.com> wrote:
> >
> > Can we agree to move the improvements out to 4.0.x?
>
> Generally I've been asked to put performance issues as improvements,
> e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
> on real clusters without that patch, and therefore I wouldn't feel
> great releasing ZstdCompressor in 4.0 without that patch.
>
> I'm fine to start calling all performance issues "bugs" since at least
> in our deployments and I think in many others performance regressions
> are P0 bugs that cost a lot of $$, or we can just keep calling them
> improvements and just tag them with the ~right target fix version.
> Namely 4.0-alpha if the change impacts any public interface in a non
> backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
> or later if it does not require changes to public interfaces.
>
> -Joey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
--
http://twitter.com/tjake
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Joseph Lynch <jo...@gmail.com>.
On Tue, Mar 31, 2020 at 1:27 PM Jake Luciani <ja...@gmail.com> wrote:
>
> Can we agree to move the improvements out to 4.0.x?
Generally I've been asked to put performance issues as improvements,
e.g. CASSANDRA-15379. To be frank though we can't run ZstdCompressor
on real clusters without that patch, and therefore I wouldn't feel
great releasing ZstdCompressor in 4.0 without that patch.
I'm fine to start calling all performance issues "bugs" since at least
in our deployments and I think in many others performance regressions
are P0 bugs that cost a lot of $$, or we can just keep calling them
improvements and just tag them with the ~right target fix version.
Namely 4.0-alpha if the change impacts any public interface in a non
backwards compatible way (yaml, properties, cql, jmx etc...), 4.0-beta
or later if it does not require changes to public interfaces.
-Joey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Jake Luciani <ja...@gmail.com>.
I've been starting to look at the work left for 4.0 and was surprised to
see almost 1/2 the open tickets are Improvements.
Shouldn't the only criteria for 4.0 at this point should be bugs.
Can we agree to move the improvements out to 4.0.x?
-Jake
On Tue, Mar 31, 2020 at 4:02 PM Ekaterina Dimitrova <
ekaterina.dimitrova@datastax.com> wrote:
> Hello everyone,
> I think the project might benefit of one "filter applied" now on the
> current scope of JIRA tickets.
> And then, regular triage so focus is not lost.
>
> Up to now, I always try to look at the Release Lifecycle [1] criteria when
> I open a new ticket in order to mark what is the target version of the
> patch. Also, I look from the perspective of the general code freeze.
> Hope I am doing it right. If those are strictly marked, do we need
> additional label for blocking tickets? Or we want to differentiate between
> strong blockers and such patches which would be good if they land at a
> specific release but not mandatory?
>
> Why I am in for initial filter now? As I found many tickets opened in
> 2016...17...etc Things have changed a lot since then and there can be
> easily different PoV nowadays.
>
> I would be more than happy to help in any of these activities, too.
>
> Ekaterina
>
> [1]
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
>
> > Begin forwarded message:
> >
> > *From:* David Capwell <dc...@gmail.com>
> > *Date:* 31 March 2020, 15:15:11 GMT-4
> > *To:* dev@cassandra.apache.org
> > *Subject:* *Re: Idea: Marking required scope for 4.0 GA vs. optional*
> > *Reply-To:* dev@cassandra.apache.org
> >
> > What I'm used to is having two buckets for a release: tickets in the
> > release (if not complete they are blockers), and triage. How this is done
> > isn't important but I do feel it's important to have both.
> >
> > Right now I don't see a active triage, but to Josh's point we would need
> to
> > know who should first. Without answering, let me ask a question; should I
> > (non committer) be adding blockers? If I add a blocker who should verify
> it
> > should block? What if project members elect non-commiters to do this?
> >
> >
> >
> > On Mon, Mar 30, 2020, 8:45 AM Joshua McKenzie <jm...@apache.org>
> > wrote:
> >
> > Regardless of how we indicate optional vs. required for rel, are there
> >
> > strong opinions on who should set that metadata on tickets? Reporter?
> >
> > Assignee? One person? A group of people?
> >
> >
> >
> > On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie <jm...@apache.org>
> >
> > wrote:
> >
> >
> > FWIW, I don't care what we go with as long as we can differentiate
> >
> > tickets
> >
> > that are optional for the rel vs. tickets that are blockers and filter
> >
> > the
> >
> > JIRA board on them so people know where they should focus their effort.
> >
> >
> > The rest of it's just paint colors to me.
> >
> >
> > On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever <mc...@apache.org> wrote:
> >
> >
> >
> > Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> >
> > indicate something is targeting a release vs. blocking on inclusion
> >
> > for
> >
> > it.
> >
> > That seems to be a more "project JIRA hackish idiom", and one that's
> >
> > historically been confusing for people. At least with a label it would
> >
> > be
> >
> > clear with a name like "4.0-blocker", and we could then easily filter
> >
> > the
> >
> > JIRA board on it.
> >
> >
> >
> >
> > Now that I better understand Benedict's previous response (see the
> >
> > 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view
> >
> > for
> >
> > now.
> >
> >
> > I certainly missed the difference on how tickets ended up resolved as
> >
> > `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
> >
> > still go into `4.0-alpha` if they satisfied the feature freeze and met
> >
> > someone's itch, while the unresolved `4.0-alpha` tickets were those the
> >
> > community declared as blockers.
> >
> >
> > Putting aside the discussion on what is a blocker, when it is discovered
> >
> > to
> >
> > be a blocker (and vice versa). My confusion stemmed from the fact there
> >
> > was
> >
> > no specific alpha|beta versions for tickets to get resolved into, eg
> >
> > 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x`
> >
> > nomenclature got changed, but having accurate fix versions was also
> >
> > removed. If we added the specific alpha|beta versions then I wouldn't
> >
> > consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
> >
> > 4.0-beta and 4.0, versions become purely target versions like the `.x`,
> >
> > and
> >
> > no resolved ticket is ever assigned them.
> >
> >
> > The simpler we can make and document this the better. please.
> >
> >
> > regards,
> >
> > Mick
> >
> >
> > ¹)
> >
> >
> >
> >
> >
> https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
> >
> >
> >
> >
> >
>
--
http://twitter.com/tjake
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Ekaterina Dimitrova <ek...@datastax.com>.
Hello everyone,
I think the project might benefit of one "filter applied" now on the
current scope of JIRA tickets.
And then, regular triage so focus is not lost.
Up to now, I always try to look at the Release Lifecycle [1] criteria when
I open a new ticket in order to mark what is the target version of the
patch. Also, I look from the perspective of the general code freeze.
Hope I am doing it right. If those are strictly marked, do we need
additional label for blocking tickets? Or we want to differentiate between
strong blockers and such patches which would be good if they land at a
specific release but not mandatory?
Why I am in for initial filter now? As I found many tickets opened in
2016...17...etc Things have changed a lot since then and there can be
easily different PoV nowadays.
I would be more than happy to help in any of these activities, too.
Ekaterina
[1] https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> Begin forwarded message:
>
> *From:* David Capwell <dc...@gmail.com>
> *Date:* 31 March 2020, 15:15:11 GMT-4
> *To:* dev@cassandra.apache.org
> *Subject:* *Re: Idea: Marking required scope for 4.0 GA vs. optional*
> *Reply-To:* dev@cassandra.apache.org
>
> What I'm used to is having two buckets for a release: tickets in the
> release (if not complete they are blockers), and triage. How this is done
> isn't important but I do feel it's important to have both.
>
> Right now I don't see a active triage, but to Josh's point we would need to
> know who should first. Without answering, let me ask a question; should I
> (non committer) be adding blockers? If I add a blocker who should verify it
> should block? What if project members elect non-commiters to do this?
>
>
>
> On Mon, Mar 30, 2020, 8:45 AM Joshua McKenzie <jm...@apache.org>
> wrote:
>
> Regardless of how we indicate optional vs. required for rel, are there
>
> strong opinions on who should set that metadata on tickets? Reporter?
>
> Assignee? One person? A group of people?
>
>
>
> On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie <jm...@apache.org>
>
> wrote:
>
>
> FWIW, I don't care what we go with as long as we can differentiate
>
> tickets
>
> that are optional for the rel vs. tickets that are blockers and filter
>
> the
>
> JIRA board on them so people know where they should focus their effort.
>
>
> The rest of it's just paint colors to me.
>
>
> On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever <mc...@apache.org> wrote:
>
>
>
> Alternatively, we could revert to using 4.0.X or 4.X as we once did to
>
> indicate something is targeting a release vs. blocking on inclusion
>
> for
>
> it.
>
> That seems to be a more "project JIRA hackish idiom", and one that's
>
> historically been confusing for people. At least with a label it would
>
> be
>
> clear with a name like "4.0-blocker", and we could then easily filter
>
> the
>
> JIRA board on it.
>
>
>
>
> Now that I better understand Benedict's previous response (see the
>
> 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view
>
> for
>
> now.
>
>
> I certainly missed the difference on how tickets ended up resolved as
>
> `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
>
> still go into `4.0-alpha` if they satisfied the feature freeze and met
>
> someone's itch, while the unresolved `4.0-alpha` tickets were those the
>
> community declared as blockers.
>
>
> Putting aside the discussion on what is a blocker, when it is discovered
>
> to
>
> be a blocker (and vice versa). My confusion stemmed from the fact there
>
> was
>
> no specific alpha|beta versions for tickets to get resolved into, eg
>
> 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x`
>
> nomenclature got changed, but having accurate fix versions was also
>
> removed. If we added the specific alpha|beta versions then I wouldn't
>
> consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
>
> 4.0-beta and 4.0, versions become purely target versions like the `.x`,
>
> and
>
> no resolved ticket is ever assigned them.
>
>
> The simpler we can make and document this the better. please.
>
>
> regards,
>
> Mick
>
>
> ¹)
>
>
>
>
> https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
>
>
>
>
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Brandon Williams <dr...@gmail.com>.
On Tue, Mar 31, 2020 at 2:15 PM David Capwell <dc...@gmail.com> wrote:
> Right now I don't see a active triage, but to Josh's point we would need to
> know who should first. Without answering, let me ask a question; should I
> (non committer) be adding blockers?
If you like, yes. I don't think anyone, committer or otherwise,
should limit themselves in any fashion, ticket-wise. That said, I
think committers should also feel free to change those statuses, and
generally that should not be fought with action, but only with
commentary. I think those who tussle with ticket action make up only
a small percentage of the community, however.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by David Capwell <dc...@gmail.com>.
What I'm used to is having two buckets for a release: tickets in the
release (if not complete they are blockers), and triage. How this is done
isn't important but I do feel it's important to have both.
Right now I don't see a active triage, but to Josh's point we would need to
know who should first. Without answering, let me ask a question; should I
(non committer) be adding blockers? If I add a blocker who should verify it
should block? What if project members elect non-commiters to do this?
On Mon, Mar 30, 2020, 8:45 AM Joshua McKenzie <jm...@apache.org> wrote:
> Regardless of how we indicate optional vs. required for rel, are there
> strong opinions on who should set that metadata on tickets? Reporter?
> Assignee? One person? A group of people?
>
>
> On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie <jm...@apache.org>
> wrote:
>
> > FWIW, I don't care what we go with as long as we can differentiate
> tickets
> > that are optional for the rel vs. tickets that are blockers and filter
> the
> > JIRA board on them so people know where they should focus their effort.
> >
> > The rest of it's just paint colors to me.
> >
> > On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever <mc...@apache.org> wrote:
> >
> >> >
> >> > Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> >> > indicate something is targeting a release vs. blocking on inclusion
> for
> >> it.
> >> > That seems to be a more "project JIRA hackish idiom", and one that's
> >> > historically been confusing for people. At least with a label it would
> >> be
> >> > clear with a name like "4.0-blocker", and we could then easily filter
> >> the
> >> > JIRA board on it.
> >> >
> >>
> >>
> >> Now that I better understand Benedict's previous response (see the
> >> 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view
> >> for
> >> now.
> >>
> >> I certainly missed the difference on how tickets ended up resolved as
> >> `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
> >> still go into `4.0-alpha` if they satisfied the feature freeze and met
> >> someone's itch, while the unresolved `4.0-alpha` tickets were those the
> >> community declared as blockers.
> >>
> >> Putting aside the discussion on what is a blocker, when it is discovered
> >> to
> >> be a blocker (and vice versa). My confusion stemmed from the fact there
> >> was
> >> no specific alpha|beta versions for tickets to get resolved into, eg
> >> 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x`
> >> nomenclature got changed, but having accurate fix versions was also
> >> removed. If we added the specific alpha|beta versions then I wouldn't
> >> consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
> >> 4.0-beta and 4.0, versions become purely target versions like the `.x`,
> >> and
> >> no resolved ticket is ever assigned them.
> >>
> >> The simpler we can make and document this the better. please.
> >>
> >> regards,
> >> Mick
> >>
> >> ¹)
> >>
> >>
> https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
> >>
> >
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Joshua McKenzie <jm...@apache.org>.
Regardless of how we indicate optional vs. required for rel, are there
strong opinions on who should set that metadata on tickets? Reporter?
Assignee? One person? A group of people?
On Sun, Mar 29, 2020 at 10:04 AM Joshua McKenzie <jm...@apache.org>
wrote:
> FWIW, I don't care what we go with as long as we can differentiate tickets
> that are optional for the rel vs. tickets that are blockers and filter the
> JIRA board on them so people know where they should focus their effort.
>
> The rest of it's just paint colors to me.
>
> On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever <mc...@apache.org> wrote:
>
>> >
>> > Alternatively, we could revert to using 4.0.X or 4.X as we once did to
>> > indicate something is targeting a release vs. blocking on inclusion for
>> it.
>> > That seems to be a more "project JIRA hackish idiom", and one that's
>> > historically been confusing for people. At least with a label it would
>> be
>> > clear with a name like "4.0-blocker", and we could then easily filter
>> the
>> > JIRA board on it.
>> >
>>
>>
>> Now that I better understand Benedict's previous response (see the
>> 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view
>> for
>> now.
>>
>> I certainly missed the difference on how tickets ended up resolved as
>> `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
>> still go into `4.0-alpha` if they satisfied the feature freeze and met
>> someone's itch, while the unresolved `4.0-alpha` tickets were those the
>> community declared as blockers.
>>
>> Putting aside the discussion on what is a blocker, when it is discovered
>> to
>> be a blocker (and vice versa). My confusion stemmed from the fact there
>> was
>> no specific alpha|beta versions for tickets to get resolved into, eg
>> 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x`
>> nomenclature got changed, but having accurate fix versions was also
>> removed. If we added the specific alpha|beta versions then I wouldn't
>> consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
>> 4.0-beta and 4.0, versions become purely target versions like the `.x`,
>> and
>> no resolved ticket is ever assigned them.
>>
>> The simpler we can make and document this the better. please.
>>
>> regards,
>> Mick
>>
>> ¹)
>>
>> https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
>>
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Joshua McKenzie <jm...@apache.org>.
FWIW, I don't care what we go with as long as we can differentiate tickets
that are optional for the rel vs. tickets that are blockers and filter the
JIRA board on them so people know where they should focus their effort.
The rest of it's just paint colors to me.
On Sun, Mar 29, 2020 at 9:24 AM Mick Semb Wever <mc...@apache.org> wrote:
> >
> > Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> > indicate something is targeting a release vs. blocking on inclusion for
> it.
> > That seems to be a more "project JIRA hackish idiom", and one that's
> > historically been confusing for people. At least with a label it would be
> > clear with a name like "4.0-blocker", and we could then easily filter the
> > JIRA board on it.
> >
>
>
> Now that I better understand Benedict's previous response (see the
> 'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view for
> now.
>
> I certainly missed the difference on how tickets ended up resolved as
> `4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
> still go into `4.0-alpha` if they satisfied the feature freeze and met
> someone's itch, while the unresolved `4.0-alpha` tickets were those the
> community declared as blockers.
>
> Putting aside the discussion on what is a blocker, when it is discovered to
> be a blocker (and vice versa). My confusion stemmed from the fact there was
> no specific alpha|beta versions for tickets to get resolved into, eg
> 4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x`
> nomenclature got changed, but having accurate fix versions was also
> removed. If we added the specific alpha|beta versions then I wouldn't
> consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
> 4.0-beta and 4.0, versions become purely target versions like the `.x`, and
> no resolved ticket is ever assigned them.
>
> The simpler we can make and document this the better. please.
>
> regards,
> Mick
>
> ¹)
>
> https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Mick Semb Wever <mc...@apache.org>.
>
> Alternatively, we could revert to using 4.0.X or 4.X as we once did to
> indicate something is targeting a release vs. blocking on inclusion for it.
> That seems to be a more "project JIRA hackish idiom", and one that's
> historically been confusing for people. At least with a label it would be
> clear with a name like "4.0-blocker", and we could then easily filter the
> JIRA board on it.
>
Now that I better understand Benedict's previous response (see the
'Dev Cassandra 4.0 Dev Work Status' thread¹), I'm leaning with his view for
now.
I certainly missed the difference on how tickets ended up resolved as
`4.0-alpha`. That unresolved `4.x` tickets were non-blockers that could
still go into `4.0-alpha` if they satisfied the feature freeze and met
someone's itch, while the unresolved `4.0-alpha` tickets were those the
community declared as blockers.
Putting aside the discussion on what is a blocker, when it is discovered to
be a blocker (and vice versa). My confusion stemmed from the fact there was
no specific alpha|beta versions for tickets to get resolved into, eg
4.0-alpha1, 4.0-alpha2, etc. So it wasn't just that the normal `.x`
nomenclature got changed, but having accurate fix versions was also
removed. If we added the specific alpha|beta versions then I wouldn't
consider the approach to be a "hackish idiom" anymore. The 4.0-alpha,
4.0-beta and 4.0, versions become purely target versions like the `.x`, and
no resolved ticket is ever assigned them.
The simpler we can make and document this the better. please.
regards,
Mick
¹)
https://lists.apache.org/thread.html/rd06dabeaa10849795d15ee77c1a8c400b034dce005ac2d0b9366567a%40%3Cdev.cassandra.apache.org%3E
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Joshua McKenzie <jm...@apache.org>.
>
> since we want to release ASAP
>
Help me understand how to reconcile this statement with the fact that
improvements and other nice-to-have optional tickets are being created and
worked on in even 4.0-alpha as recently as this past week. While *you* and
many others may want to release ASAP (including myself fwiw), this is a
large project with a large number of participants and I think it inaccurate
to speak for everyone.
Do we gain much by introducing yet another view on Jira that nobody will
> properly maintain?
>
I don't share your belief that this will not be maintained, as I will be
one of three people keeping an eye on maintaining a view like this for the
hopefully small number of months leading up to 4.0 GA. It seems we
currently have a state that is not being demarcated - what is MVP for scope
on release vs. what is optional but targeting it. Rather than forcing
peoples' tickets out of the release even if they still have every intent to
get them in, I would prefer we have additional metadata and allow signaling
of "targeting release" vs. "required for release".
Alternatively, we could revert to using 4.0.X or 4.X as we once did to
indicate something is targeting a release vs. blocking on inclusion for it.
That seems to be a more "project JIRA hackish idiom", and one that's
historically been confusing for people. At least with a label it would be
clear with a name like "4.0-blocker", and we could then easily filter the
JIRA board on it.
On Sat, Mar 28, 2020 at 2:52 PM Benedict Elliott Smith <be...@apache.org>
wrote:
> I would personally prefer we simply bump tickets from the milestone
> periodically. The point of a milestone is to collect tickets we expect to
> land there, and since we want to release ASAP we should have at most a
> handful of optional items there sponsored by some community members, so the
> burden should be low.
>
> Do we gain much by introducing yet another view on Jira that nobody will
> properly maintain? It sounds like a classic situation of having one
> problem, and simply ending up with two problems.
>
>
> On 28/03/2020, 18:44, "Scott Andreas" <sc...@paradoxica.net> wrote:
>
> Yep that makes sense to me.
>
> There's still much work to be done to exercise 4.0 builds to identify
> unknown issues that haven't yet been filed – but those items can be tagged
> as release blockers as they're identified. 👍
>
> ________________________________________
> From: Joshua McKenzie <jm...@apache.org>
> Sent: Saturday, March 28, 2020 7:14 AM
> To: dev@cassandra.apache.org
> Subject: Idea: Marking required scope for 4.0 GA vs. optional
>
> As we're under a feature freeze but not code freeze, there are quite
> reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look
> like
> nice to haves for the release but wouldn't necessarily block cutting
> GA. I
> think there would be value in us flagging tickets that are required
> for 4.0
> to get out the door as blockers - it looks like we don't have the
> Priority
> entry anymore (a good thing imo) but we could use the label field to
> indicate which tickets are blockers and filter our JIRA board and
> weekly
> reporting on that. That would also help contributors know where to
> focus
> their efforts to help get 4.0 out the door while not stifling people
> scratching their own itch on things leading up to the release.
>
> What do the rest of you on the project think?
>
> ~Josh
>
> B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�
> � [��X��ܚX�K K[XZ[
> � ]�][��X��ܚX�P �\��[� �K�\ X� K�ܙ�B��܈ Y ] [ۘ[ ��[X[� � K[XZ[
> � ]�Z [ �\��[� �K�\ X� K�ܙ�B�B
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Benedict Elliott Smith <be...@apache.org>.
I would personally prefer we simply bump tickets from the milestone periodically. The point of a milestone is to collect tickets we expect to land there, and since we want to release ASAP we should have at most a handful of optional items there sponsored by some community members, so the burden should be low.
Do we gain much by introducing yet another view on Jira that nobody will properly maintain? It sounds like a classic situation of having one problem, and simply ending up with two problems.
On 28/03/2020, 18:44, "Scott Andreas" <sc...@paradoxica.net> wrote:
Yep that makes sense to me.
There's still much work to be done to exercise 4.0 builds to identify unknown issues that haven't yet been filed – but those items can be tagged as release blockers as they're identified. 👍
________________________________________
From: Joshua McKenzie <jm...@apache.org>
Sent: Saturday, March 28, 2020 7:14 AM
To: dev@cassandra.apache.org
Subject: Idea: Marking required scope for 4.0 GA vs. optional
As we're under a feature freeze but not code freeze, there are quite
reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look like
nice to haves for the release but wouldn't necessarily block cutting GA. I
think there would be value in us flagging tickets that are required for 4.0
to get out the door as blockers - it looks like we don't have the Priority
entry anymore (a good thing imo) but we could use the label field to
indicate which tickets are blockers and filter our JIRA board and weekly
reporting on that. That would also help contributors know where to focus
their efforts to help get 4.0 out the door while not stifling people
scratching their own itch on things leading up to the release.
What do the rest of you on the project think?
~Josh
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�� [��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�\��[� �K�\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[
�]�Z[ �\��[� �K�\X�K�ܙ�B�B
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: Idea: Marking required scope for 4.0 GA vs. optional
Posted by Scott Andreas <sc...@paradoxica.net>.
Yep that makes sense to me.
There's still much work to be done to exercise 4.0 builds to identify unknown issues that haven't yet been filed – but those items can be tagged as release blockers as they're identified. 👍
________________________________________
From: Joshua McKenzie <jm...@apache.org>
Sent: Saturday, March 28, 2020 7:14 AM
To: dev@cassandra.apache.org
Subject: Idea: Marking required scope for 4.0 GA vs. optional
As we're under a feature freeze but not code freeze, there are quite
reasonably tickets being opened for 4.0 (alpha, beta, or rc) that look like
nice to haves for the release but wouldn't necessarily block cutting GA. I
think there would be value in us flagging tickets that are required for 4.0
to get out the door as blockers - it looks like we don't have the Priority
entry anymore (a good thing imo) but we could use the label field to
indicate which tickets are blockers and filter our JIRA board and weekly
reporting on that. That would also help contributors know where to focus
their efforts to help get 4.0 out the door while not stifling people
scratching their own itch on things leading up to the release.
What do the rest of you on the project think?
~Josh