Chris,
with 2.0.5-alpha (rc1) out, would you please take a look at the release bits?
I assume the four-digit numbering scheme issue has been resolved now.
Regards,
Cos
On Thu, May 30, 2013 at 06:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik wrote:
> > I have
Thanks for the headstart Arun!
I will be sending a separate email to the *-dev@ lists outlining the plan and
the schedule of the changes, so we won't step on each other feet, like Vinod
expressed earlier.
Cos
On Fri, May 31, 2013 at 11:20AM, Arun C Murthy wrote:
>
> On May 30, 2013, at 8:41 PM,
On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
>
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
>
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 a
This started out as something and ended up as something else altogether.
In any case, I think you should give a fresh heads up outside this thread.
There are a bunch of commits and merges happening into branch-2 and thus 2.0.5,
so it'll be safe to have an explicit hold-off/all-clear signaling.
Thanks Alejandro,
that's what my plan for the morning. Thanks for putting together the
check-list - would be easier for me not to miss anything. I am aiming to have
the bits out by noon or so. Appreciate the help!
Cos
On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
Sounds like a plan.
Thanks,
--Konst
On Thu, May 30, 2013 at 8:41 PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
>
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
>
> * rename the svn branch
> * update the versions in the POMs
> * upd
Konstantin, Cos,
As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
housekeeping as you work the new RC.
* rename the svn branch
* update the versions in the POMs
* update the CHANGES.txt in trunk, branch-2 and the release branch
* change the current 2.0.5 version in JIRA to 2.1.0
On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik wrote:
> I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> of the number change?
+1 Sounds great.
> Does the result of bylaw vote nu
On Thu, May 30, 2013 at 05:30PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik wrote:
> > There's no plans to release anything else at this point - this is a bug-fix
> > release, as I pointed out on a numerous occasions. There's no new features -
> > just 2 fixes.
>
>
On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik wrote:
> There's no plans to release anything else at this point - this is a bug-fix
> release, as I pointed out on a numerous occasions. There's no new features -
> just 2 fixes.
If you're worried about extending the voting by a week, I don't t
On Thu, May 30, 2013 at 04:08PM, Jean-Daniel Cryans wrote:
> FWIW, not that I have a dog in this fight, but the only release with a
> 4th number (not including .0 like the 0.20.20x releases did) we had
> was:
>
> http://hadoop.6.n7.nabble.com/VOTE-Release-0-17-2-1-rc-0-td13398.html
>
> 0.17.2 was
FWIW, not that I have a dog in this fight, but the only release with a
4th number (not including .0 like the 0.20.20x releases did) we had
was:
http://hadoop.6.n7.nabble.com/VOTE-Release-0-17-2-1-rc-0-td13398.html
0.17.2 was missing some native libs so 0.17.2.1 was released to fix
that critical i
On Thu, May 30, 2013 at 03:11PM, Matt Foley wrote:
> Hi Cos,
> I would also request that you renumber the release candidate to just
> three-numbers, hence "2.0.5-alpha".
>
> Arun, are you willing to start the 2.1.x name-space for your next release,
> so that 2.0.x-alpha can become an intermediate
On Thu, May 30, 2013 at 03:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik wrote:
> > There's no misunderstanding Chris - this release is to unblock downstream.
> >
> > As for your question: I don't have a crystal ball; I wish though. I think
> > the
> > answer de
On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik wrote:
> There's no misunderstanding Chris - this release is to unblock downstream.
>
> As for your question: I don't have a crystal ball; I wish though. I think the
> answer depends on will be there more blocking bugs found in the later releases
Hi Cos,
I would also request that you renumber the release candidate to just
three-numbers, hence "2.0.5-alpha".
Arun, are you willing to start the 2.1.x name-space for your next release,
so that 2.0.x-alpha can become an intermediate stabilization branch as Cos
and Konst want?
I just think that
There's no misunderstanding Chris - this release is to unblock downstream.
As for your question: I don't have a crystal ball; I wish though. I think the
answer depends on will be there more blocking bugs found in the later releases
of Bigtop or other downstream components.
This is bugfix release a
On the version number we use, if it is greater than 2.0.4, I really don't
care. Though I think Konstantin argument that branch-2 is publishing as
2.0.5-SNAPSHOT has some ground (still, it could be argued that they are DEV
JARs so they can be in flux).
On the changes that went into this RC, they a
On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy wrote:
> Why not include MAPREDUCE-4211 as well rather than create one release per
> patch?
>From Cos's description, it sounded like these were backports of fixes
to help Sqoop2 and fix some build issues. If it's not just to fixup
leftover bugs in
> Why not call this 2.0.5-alpha?
Technically, current branch-2 uses 2.0.5-SNAPSHOT and produces maven
artifacts with that version.
So having another version with the same numbers will be confusing.
Therefore 4-level numbers.
I thought I mentioned it to you before.
Thanks,
--Konst
On Thu, May 30
+1
I verified checksums, the signature, built sources on CentOS, ran tests and
a few hadoop commands.
Thanks,
--Konst
On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik wrote:
> All,
>
> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I
> would
> like to release.
>
> Th
On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:
> I see you just re-opened MAPREUDCE-5211.
>
> Why not include MAPREDUCE-5211 as well rather than create one release per
> patch?
Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per
https://issues.apache.org/jira/browse/MA
Sorry, it should be MAPREDUCE-5211 (not MAPREDUCE-4211).
thanks,
Arun
On May 30, 2013, at 10:57 AM, Arun C Murthy wrote:
> I see you just re-opened MAPREUDCE-4211.
>
> Why not include MAPREDUCE-4211 as well rather than create one release per
> patch?
>
> Also, this is the first time we are se
I see you just re-opened MAPREUDCE-4211.
Why not include MAPREDUCE-4211 as well rather than create one release per patch?
Also, this is the first time we are seeing a four-numbered scheme in Hadoop.
Why not call this 2.0.5-alpha?
Arun
On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:
> A
+1
Checksum and signature match, ran some unit tests, verified w/ a diff
of release-2.0.4-alpha that the release contains MAPREDUCE-5240 and
HADOOP-9407, plus some fixups to the release notes. -C
On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik wrote:
> All,
>
> I have created a release candi
+1, verified MD5 and signature. Did a full build, started pseudo cluster,
run a few MR jobs, verified httpfs works.
Thanks.
On Sat, May 25, 2013 at 10:01 AM, Sangjin Lee wrote:
> +1 (non-binding)
>
> Thanks,
> Sangjin
>
>
> On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik
> wrote:
>
> > Al
All,
I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would
like to release.
This is a stabilization release that includes fixed for a couple a of issues
discovered in the testing with BigTop 0.6.0 release candidate.
The RC is available at: http://people.apache.org/~cos/h
27 matches
Mail list logo
