As mentioned on HADOOP-12111, there is now an incubator-style proposal:
http://wiki.apache.org/incubator/YetusProposal
On Wed, Jun 24, 2015 at 9:41 AM, Sean Busbey bus...@cloudera.com wrote:
Hi Folks!
Work in a feature branch is now being tracked by HADOOP-12111.
On Thu, Jun 18, 2015 at
+1 for a separate project and going directly to TLP if possible (as Hadoop
itself did when split out of Nutch)
+1 for having language discussions once it's a TLP :-)
Cheers,
Nigel
On Jun 22, 2015, at 1:55 PM, Andrew Purtell apurt...@apache.org wrote:
On Mon, Jun 22, 2015 at 1:03 PM, Nick
Hi Folks!
Work in a feature branch is now being tracked by HADOOP-12111.
On Thu, Jun 18, 2015 at 10:07 PM, Sean Busbey bus...@cloudera.com wrote:
It looks like we have consensus.
I'll start drafting up a proposal for the next board meeting (July 15th).
Once we work out the name I'll submit
On Mon, Jun 22, 2015 at 1:03 PM, Nick Dimiduk ndimi...@gmail.com wrote:
On Mon, Jun 22, 2015 at 12:43 PM, Colin P. McCabe cmcc...@apache.org
wrote:
You mentioned that most of our project will be focused on shell
scripts I guess based on the existing test-patch code. Allen did a
lot of
+1 for making this a separate project. We've always struggled with a
lot of forks of the test-patch code and perhaps this project can help
create something that works well for multiple projects.
Bypassing the incubator seems kind of weird (I didn't know that was an
option) but I will let other
On Mon, Jun 22, 2015 at 12:43 PM, Colin P. McCabe cmcc...@apache.org
wrote:
You mentioned that most of our project will be focused on shell
scripts I guess based on the existing test-patch code. Allen did a
lot of good work in this area recently. I am curious if you evaluated
languages such
It looks like we have consensus.
I'll start drafting up a proposal for the next board meeting (July 15th).
Once we work out the name I'll submit a PODLINGNAMESEARCH jira to track
that we did due diligence on whatever we pick.
In the mean time, Hadoop PMC would y'all be willing to host us in a
+1. From its user's viewpoint, recent improvements on test-patch made my
work really efficient.
For example, quick feedback due to avoiding unnecessary tests, automated
build environment setup due to Docker support, automated patch download
from JIRA, automated shellcheck and whitespace checker,
I think this is a great idea! Having just gone through the process of
getting Phoenix up to speed with precommits, it would be really nice to
have a place to go other than fork/hack someone else's work. For the same
project, I recently integrated its first daemon service. This meant adding
a bunch
+1 on the idea.
It would be great if tests about dependency management. multiple
branches, and distributed environment can be done in the project. One
discussion point is how Hadoop depends on Yetus, including the
development cycles. It's a good time to rethink what's can be done for
making
Since a couple of people have brought it up:
I think the release question is probably one of the big question marks.
Other than tar balls, how does something like this actually get used
downstream?
For test-patch, in particular, I have a few thoughts on this:
Short term:
I'm going to try responding to several things at once here, so apologies if
I miss anyone and sorry for the long email. :)
On Tue, Jun 16, 2015 at 3:44 PM, Steve Loughran ste...@hortonworks.com
wrote:
I think it's good to have a general build/test process projects can share,
so +1 to pulling
+1 A separate project sounds great. It'd be great to have more
standard tooling across the ecosystem.
As a practical matter, how should projects consume releases? -C
On Mon, Jun 15, 2015 at 4:47 PM, Sean Busbey bus...@cloudera.com wrote:
Oof. I had meant to push on this again but life got in
How about harbinger for a name :)
On Sunday, June 7, 2015, Sean Busbey bus...@cloudera.com wrote:
Sorry for the resend. I figured this deserves a [DISCUSS] flag.
On Sat, Jun 6, 2015 at 10:39 PM, Sean Busbey bus...@cloudera.com
javascript:; wrote:
Hi Folks!
After working on
Also +1 for the idea in general. Sound like a lot of projects could
benefit.
How would we have to add testing to our pre commit testing?
Each project has likely customized their own core commit scripts (multiple
Jvms versions, checkstyle, javadoc exceptions etc.). We should probably
soliciit
+1
(Have been talking to Sean in private on the subject -- seems
appropriate to voice some public support)
I'd be interested in this for Accumulo and Slider. For Accumulo, we've
come a far way without a pre-commit build, primarily due to a CTR
process. We have seen the repeated questions of
thank you for making a more digestible version Allen. :)
If you're interested in soliciting feedback from other projects, I created
ASF short links to this thread in common-dev and hbase:
* http://s.apache.org/yetus-discuss-hadoop
* http://s.apache.org/yetus-discuss-hbase
While I agree that
I'm clearly +1 on this idea. As part of the rewrite in Hadoop of
test-patch, it was amazing to see how far and wide this bit of code as spread.
So I see consolidating everyone's efforts as a huge win for a large number of
projects. (esp considering how many I saw suffering from a
+1
ZooKeeper is another project that has expressed interest in improving its
pre-commit process lately. I understand Allen has had some success
applying this to the ZooKeeper build too, with some small caveats around
quirks in the build.xml that I think we can resolve.
I'm interested in
Oof. I had meant to push on this again but life got in the way and now the
June board meeting is upon us. Sorry everyone. In the event that this ends
up contentious, hopefully one of the copied communities can give us a
branch to work in.
I know everyone is busy, so here's the short version of
Sorry for the resend. I figured this deserves a [DISCUSS] flag.
On Sat, Jun 6, 2015 at 10:39 PM, Sean Busbey bus...@cloudera.com wrote:
Hi Folks!
After working on test-patch with other folks for the last few months, I
think we've reached the point where we can make the fastest progress
21 matches
Mail list logo
