+1 (binding)
* Built from source
* Started a pseudo-distributed cluster with fairscheduler.
* Ran sample jobs
* Verified WebUI
On Wed, Mar 22, 2017 at 11:56 AM, varunsax...@apache.org <
varun.saxena.apa...@gmail.com> wrote:
> Thanks Junping for creating the release.
>
> +1 (non-binding)
>
> * Ve
[
https://issues.apache.org/jira/browse/MAPREDUCE-6506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-6506.
-
Resolution: Not A Problem
Target Version/s: (was: )
Closing this
t;
> > On Wed, Jan 25, 2017 at 11:14 AM, Karthik Kambatla
> > wrote:
> >
> >> Thanks for driving the alphas, Andrew. I don't see the need to restart
> the
> >> vote and I feel it is okay to fix the minor issues before releasing.
> >>
> >>
Thanks for driving the alphas, Andrew. I don't see the need to restart the
vote and I feel it is okay to fix the minor issues before releasing.
+1 (binding). Downloaded source, stood up a pseudo-distributed cluster with
FairScheduler, ran example jobs, and played around with the UI.
Thanks
Karthi
Given the discussions, I feel we are not ready for VOTE on this yet.
Sangjin, should we go back to the DISCUSS thread?
IMO, these are guidelines and not policies we want to enforce. Maybe, the
text should say something along the lines of: "The Hadoop community is
inclined to". And, maybe, a caveat
+1
I would also like to see some process guidelines. I should have brought
this up on the discussion thread, but I thought of them only now :(
- Is an RM responsible for all maintenance releases against a minor
release, or finding another RM to drive a maintenance release? In the past,
t
it in the discussion thread. Should
> we take it to a vote? Do we need additional discussions?
>
> Regards,
> Sangjin
>
> On Wed, Nov 9, 2016 at 11:11 PM, Karthik Kambatla
> wrote:
>
>> Fair points, Sangjin and Andrew.
>>
>> To get the ball rolling on this, I
gt; > we're at and ship it ASAP.
>> >
>> > Jason
>> > (1) https://issues.apache.org/jira/issues/?jql=project%20in%
>> > 20%28hadoop%2C%20yarn%2C%20mapreduce%2C%20hdfs%29%
>> > 20and%20resolution%20%3D%20Fixed%20and%20fixVersion%20%3D%202.8.0
>&
he latest major line every 6
>>> months,
>>> > and a maintenance release on a minor release (as there may be
>>> concurrently
>>> > maintained minor releases) every 2 months.
>>> >
>>> > A minor release line is EOLed 2 years after it is fir
Is there value in releasing current branch-2.8? Aren't we better off
re-cutting the branch off of branch-2?
On Tue, Oct 25, 2016 at 12:20 AM, Akira Ajisaka
wrote:
> It's almost a year since branch-2.8 has cut.
> I'm thinking we need to release 2.8.0 ASAP.
>
> According to the following list, the
Never included the link :)
https://github.com/gezapeti/jira-comment-collapser
On Mon, Oct 17, 2016 at 6:46 PM, Karthik Kambatla
wrote:
> Hi folks
>
> Sorry for the widespread email, but thought you would find this useful.
>
> My colleague, Peter, had put together this chro
Hi folks
Sorry for the widespread email, but thought you would find this useful.
My colleague, Peter, had put together this chrome extension to collapse
comments from certain users (HadoopQA, Githubbot) that makes tracking
conversations in JIRAs much easier.
Cheers!
Karthik
Thanks for putting the RC together, Sangjin.
+1 (binding)
Built from source, deployed pseudo distributed cluster and ran some example
MR jobs.
On Fri, Oct 7, 2016 at 6:01 PM, Yongjun Zhang wrote:
> Hi Sangjin,
>
> Thanks a lot for your work here.
>
> My +1 (binding).
>
> - Downloaded both bina
>
>
> Here is just an idea to get started. How about "a minor release line is
> EOLed 2 years after it is released or there are 2 newer minor releases,
> whichever is sooner. The community reserves the right to extend or shorten
> the life of a release line if there is a good reason to do so."
>
>
Forking off this discussion from 2.6.5 release thread. Junping and Chris T
have brought up important concerns regarding too many concurrent releases
and the lack of EOL for our releases.
First up, it would be nice to hear from others on our releases having the
notion of EOL and other predictabilit
Since there is sufficient interest in 2.6.5, we should probably do it. All
the reasons Allen outlines make sense.
That said, Junping brings up a very important point that we should think of
for future releases. For a new user or a user that does not directly
contribute to the project, more stable
to alphaX to betaX to GA; this
applies to both the Hadoop-2 model and the 3.0.0-alphaX model.
On Tue, Aug 9, 2016 at 6:02 AM, Karthik Kambatla wrote:
> Most people I talked to found 3.0.0-alpha, 3.1.0-alpha/beta confusing. I
> am not aware of any other software shipped that way. Whi
version to 4.x for landing new incompatible
> changes.
>
> Thanks,
>
> Junping
> ________
> From: Karthik Kambatla
> Sent: Monday, August 08, 2016 6:54 PM
> Cc: common-...@hadoop.apache.org; yarn-...@hadoop.apache.org;
> hdfs-...@hadoop.apach
I like the 3.0.0-alphaX approach primarily for simpler understanding of
compatibility guarantees. Calling 3.0.0 alpha and 3.1.0 beta is confusing
because, it is not immediately clear that 3.0.0 and 3.1.0 could be
incompatible in APIs.
I am open to something like 2.98.x for alphas and 2.99.x for be
Inline.
>
>> BTW, I never see we have a clear definition for alpha release. It is
>> previously used as unstable in API definition (2.1-alpha, 2.2-alpha, etc.)
>> but sometimes means unstable in production quality (2.7.0). I think we
>> should clearly define it with major consensus so user won't
Inline.
> 1) Set the fix version for all a.b.c versions, where c > 0.
> 2) For each major release line, set the lowest a.b.0 version.
>
Sounds reasonable.
>
> The -alphaX versions we're using leading up to 3.0.0 GA can be treated as
> a.b.c versions, with alpha1 being the a.b.0 release.
>
Once
IIRR, the vote is on source artifacts and binaries are for convenience.
If that is right, I am open to either options - do another RC or continue
this vote and fix the binary artifacts.
On Tue, Jul 26, 2016 at 12:11 PM, Vinod Kumar Vavilapalli <
vino...@apache.org> wrote:
> Thanks Daniel and Wei
+1 (binding)
* Downloaded and build from source
* Checked LICENSE and NOTICE
* Pseudo-distributed cluster with FairScheduler
* Ran MR and HDFS tests
* Verified basic UI
On Sun, Jul 24, 2016 at 1:07 PM, larry mccay wrote:
> +1 binding
>
> * downloaded and built from source
> * checked LICENSE an
Thanks for clarifying Andrew. Inline.
On Mon, Jun 13, 2016 at 3:59 PM, Andrew Wang
wrote:
>
> On Fri, Jun 10, 2016 at 9:39 PM, Karthik Kambatla
> wrote:
>
>> I would like to understand the trunk-incompat part of the proposal a
>> little better.
>>
>> Is
significant:
>>> >> > - A lot of commits (incompatible, risky, uncompleted feature, etc.)
>>> have
>>> >> > to wait to commit to trunk or put into a separated branch that could
>>> >> delay
>>> >> > feature development progress as additional vote
oposal forces following these requirements and hence I like it more.
>
> Thanks,
>
> Junping
>
> From: Karthik Kambatla
> Sent: Friday, June 10, 2016 7:49 AM
> To: Andrew Wang
> Cc: common-...@hadoop.apache.org; hdfs-...@hadoop.apache.or
Thanks for restarting this thread Andrew. I really hope we can get this
across to a VOTE so it is clear.
I see a few advantages shipping from trunk:
- The lack of need for one additional backport each time.
- Feature rot in trunk
Instead of creating branch-3, I recommend creating branch-3.
I am with Vinod on avoiding merging mostly_complete_branches to trunk since
we are not shipping any release off it. If 3.x releases going off of trunk
is going to help with this, I am fine with that approach. We should still
make sure to keep trunk-incompat small and not include large features.
On
Karthik Kambatla created MAPREDUCE-6673:
---
Summary: Add a test example job that grows in memory usage over
time
Key: MAPREDUCE-6673
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6673
Karthik Kambatla created MAPREDUCE-6669:
---
Summary: Jobs with encrypted spills don't tolerate AM failures
Key: MAPREDUCE-6669
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6669
Pr
Karthik Kambatla created MAPREDUCE-6638:
---
Summary: Jobs with encrypted spills don't recover if the AM goes
down
Key: MAPREDUCE-6638
URL: https://issues.apache.org/jira/browse/MAPREDUCE
Dustin, one of us could definitely review the patches, but I highly
encourage involving folks in the community (and networking with them) for
non-urgent patches. Tsuyoshi is a cool guy and is generally keen on test
cleanups, as you can see from his chiming in on this JIRA. Want to try
hitting him u
Thanks Vinod. Not labeling 2.8.0 stable sounds perfectly reasonable to me.
Let us not call it alpha or beta though, it is quite confusing. :)
On Wed, Feb 3, 2016 at 8:17 PM, Gangumalla, Uma
wrote:
> Thanks Vinod. +1 for 2.8 release start.
>
> Regards,
> Uma
>
> On 2/3/16, 3:53 PM, "Vinod Kumar V
Filed https://issues.apache.org/jira/browse/INFRA-11136
On Mon, Jan 25, 2016 at 3:41 PM, Vinod Kumar Vavilapalli wrote:
> I believe this is still in place, though I am not sure how we can verify
> this (without doing a force-push of course)
>
> +Vinod
>
> > One thing that wasn't clear from the I
+1 on all counts.
One thing that wasn't clear from the INFRA announcement: are trunk,
branch-* branches protected against force-pushes in the new world? If not,
should we ask them to be locked up?
Thanks
Karthik
On Thu, Jan 14, 2016 at 10:26 PM, Vinod Kumar Vavilapalli <
vino...@apache.org> wrot
Hi folks
In the last few months, we have been shipping multiple releases -
maintenance and minor - elevating the quality and purpose of our releases.
With the increase in releases and related communication, I wonder if we
need to highlight release-related communication in some way. Otherwise, it
Did we consider cutting a branch-3 that borrows relatively compatible
patches from trunk to run the 3.x line? That said, I would like for us to
really tighten our compatibility policies and actually stick to them
starting the next major release.
On Wed, Nov 11, 2015 at 1:11 PM, Vinod Vavilapalli
I am really against the notion of calling x.y.0 releases alpha/beta; it is
very confusing. If we think a release is alpha/beta quality, why not
release it as x.y.0-alpha or x.y.0-beta, and follow it up eventually with
x.y.0 GA.
I am in favor of labeling any of the newer features to be of alpha/bet
[
https://issues.apache.org/jira/browse/MAPREDUCE-6531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-6531.
-
Resolution: Won't Fix
Resolving as "Won't Fix".
> CL
On Wed, Oct 14, 2015 at 4:28 PM, Allen Wittenauer wrote:
>
> If people want, I could setup a cut off of yetus master to run the jenkins
> test-patch. (multiple maven repos, docker support, multijdk support, … )
> Yetus would get some real world testing out of it and hadoop common-dev
> could sto
Karthik Kambatla created MAPREDUCE-6506:
---
Summary: Make the reducer-preemption configs consistent in how
they handle defaults
Key: MAPREDUCE-6506
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6506
Karthik Kambatla created MAPREDUCE-6501:
---
Summary: Improve reducer preemption
Key: MAPREDUCE-6501
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6501
Project: Hadoop Map/Reduce
+1 (binding)
Ran a few MR jobs on a pseudo-distributed cluster on Java 8.
On Tue, Sep 22, 2015 at 8:09 AM, Masatake Iwasaki <
iwasak...@oss.nttdata.co.jp> wrote:
> +1(non-binding)
>
> - verified mds and signature of source and binary tarball
> - built from source tarball with -Pnative on CentOS
[
https://issues.apache.org/jira/browse/MAPREDUCE-6485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-6485.
-
Resolution: Duplicate
I believe this is a duplicate of MAPREDUCE-6302, and an
Hi folks
Just wanted to bring this up and see what people think.
IIUC, JHS memory consumption depends on the number of jobs, tasks per job,
and concurrent accesses. There might be a few orthogonal approaches to
improving its scalability:
- Appears we process jhist files on every access. May b
ill run for the usual 5 days.
>
> Thanks,
> Vinod
>
> PS: It took 2 months instead of the planned [1] 2 weeks in getting this
> release out: post-mortem in a separate thread.
>
> [1]: A 2.7.1 release to follow up 2.7.0
> http://markmail.org/thread/zwzze6cqqgwq4rmw
>
Huge +1
On Thursday, July 2, 2015, Chris Nauroth wrote:
> +1
>
> Thank you to Allen for the script, and thank you to Andrew for
> volunteering to drive the conversion.
>
> --Chris Nauroth
>
>
>
>
> On 7/2/15, 2:01 PM, "Andrew Wang" >
> wrote:
>
> >Hi all,
> >
> >I want to revive the discussion o
Karthik Kambatla created MAPREDUCE-6369:
---
Summary: MR compile shouldn't depend on nodemanager
Key: MAPREDUCE-6369
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6369
Project: Hadoo
[
https://issues.apache.org/jira/browse/MAPREDUCE-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-1439.
-
Resolution: Won't Fix
Given the lack of activity for 5 years and that
1.3 release, especially given that 1.2.1
> was Aug 2013 ….
> >
> > I guess we need a PMC member to declare a vote or whatever….
> >
> >
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
ention of working on the 1.3 release, especially given that 1.2.1
> was Aug 2013 ….
>
> I guess we need a PMC member to declare a vote or whatever….
>
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
[
https://issues.apache.org/jira/browse/MAPREDUCE-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-6343.
-
Resolution: Fixed
Fix Version/s: 3.0.0
Hadoop Flags: Reviewed
> >> I would also like to support Karthik's proposal on the release thread
> > about
> > >> version numbering. 2.7.0 being "alpha" is pretty confusing since all
> of
> > the
> > >> other 2.x releases since GA have been stable. I think users would
> > prefer a
> > >> version like "2.8.0-alpha1" instead, which is very clear and similar
> to
> > >> what we did for 2.0 and 2.1. Then we release 2.8.0 when we're actually
> > >> stable.
> > >>
> > >> I don't know if it's retroactively possible to do this for 2.7.0, but
> > it's
> > >> something to consider for the next 2.7 alpha or beta or whatever.
> > >>
> >
> >
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
e predictable releases instead of holding up releases for ever.
>
> Thoughts?
>
> Thanks
> +Vinod
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
> Please try the release and vote; the vote will run for the usual 5 days.
>
> Thanks,
> Vinod
>
> [1]: A 2.7.1 release to follow up 2.7.0
> http://markmail.org/thread/zwzze6cqqgwq4rmw
>
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
d did a pass. In the unavoidable event
> that we find incompatibilities with 2.7.0, we can fix those in 2.7.1 and
> promote that to be the stable release.
>
Sounds reasonable.
>
> Thoughts?
>
> Thanks,+Vinod
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
deprecated
> at least for one major release before being removed."
>
> http://hadoop.apache.org/docs/r2.6.0/hadoop-project-dist/
> hadoop-common/Compatibility.html#Hadoop_Configuration_Files
>
> Is it applicable for unused properties?
> Can we remove unused properties right
f Jenkins doesn’t setup the
> environment correctly or leaks variables between runs. shellcheck prints
> out so many messages on the current code I’m surprised it doesn’t crash.
>
> On Mar 31, 2015, at 9:21 AM, Karthik Kambatla wrote:
>
> > Hi devs,
> >
> > I am su
N files,
but the test were run against one of the MR modules.
I suspect there is a race condition when there are multiple builds
executing on the same node, or remnants from a previous run are getting
picked up.
Filed HADOOP-11779 for this.
--
Karthik Kambatla
Software Engine
nd API level with the existing java code & JDK7+
> clusters.
>
> A classpath fix that is optional/compatible can then go out on the 2.x
> line, saving the 3.x tag for something that really breaks things, forces
> all downstream apps to set up new hadoop profiles, have separat
For instance, it would be great if we could maintain wire
> > compatibility between 2.x and 3.x, so rolling upgrades work. Keeping
> > branch-2 and branch-3 similar also makes backports easier, since we're
> > likely maintaining 2.x for a while yet.
> >
> > Please let me know any comments / concerns related to the above. If
> people
> > are friendly to the idea, I'd like to cut a branch-3 and start working on
> > the first alpha.
> >
> > Best,
> > Andrew
> >
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
who already has a
> patch sitting there for more than a year before. This may need us to
> collectively agree on some convention - the last comment says that the
> branch patch name should be in some format for this to work.
>
> Thanks
get version. These, while perhaps not revolutionary, are still
> incompatible, and require a major version bump.
>
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
non-committer to review the patch?
> > Creating this thread to discuss these (and other that I sure missed)
> issues
> > and to combine multiple discussions into one.
> >
> > My personal opinion we should just stick to the tradition. Good or bad,
> it
> > worked f
would be great if we could maintain wire
> compatibility between 2.x and 3.x, so rolling upgrades work. Keeping
> branch-2 and branch-3 similar also makes backports easier, since we're
> likely maintaining 2.x for a while yet.
>
> Please let me know any comments / concerns re
>
> Folks,
>
> What is the current status of the 2.7 release? I know initially it started
> out as a "java-7" only release, but looking at the JIRAs that is very much
> not the case.
>
> Do we have a certain timeframe for 2.7 or is it time to discuss it?
&
[
https://issues.apache.org/jira/browse/MAPREDUCE-5842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-5842.
-
Resolution: Duplicate
This appears to be a duplicate of MAPREDUCE-5799
[
https://issues.apache.org/jira/browse/MAPREDUCE-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-4168.
-
Resolution: Not a Problem
It is expected that an appropriate client config is
not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
Folks,
I just renamed (1) the old HowToCommit to HowToCommitWithSvn, and (2) the
new HowToCommitWithGit to HowToCommit.
Thanks
Karthik
--
Karthik Kambatla
Software Engineer, Cloudera Inc.
http://five.sentenc.es
2014, at 11:09 AM, Sangjin Lee wrote:
> >
> > > If 2.7 is being positioned as the JDK7-only release, then it would be
> > good
> > > to know how 2.8 lines up in terms of timing. Our interest is landing
> the
> > > shared cache feature (YARN-1492)... Thanks.
&
Thanks for starting this thread, Arun.
Your proposal seems reasonable to me. I suppose we would like new features
and improvements to go into 2.8 then? If yes, what time frame are we
looking at for 2.8? Looking at YARN, it would be nice to get a release with
shared-cache and a stable version of re
[
https://issues.apache.org/jira/browse/MAPREDUCE-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla reopened MAPREDUCE-5785:
-
> Derive heap size or mapreduce.*.memory.mb automatica
+1 (binding) on the source tarball, would be nice to redo the binary
tarball.
- Stood up a pseudo-dist cluster, and ran some HDFS and MR jobs.
- The binary is about 40 MB larger than the previous release; it appears
the docs are copied over twice - share/doc/hadoop and share/hadoop. The
binary tar
[
https://issues.apache.org/jira/browse/MAPREDUCE-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-5718.
-
Resolution: Won't Fix
Target Version/s: (was: )
With
Looking at the patches, we might be able to get most of YARN-1492 in by the
end of next week. There would be a couple of security items still
remaining, but we can may be call the feature alpha-ready without them.
On Tue, Sep 23, 2014 at 4:25 PM, Chris Trezzo wrote:
> I would like to see the sha
+1
I skimmed over the initial import, but looked at the follow-up patches more
closely. There is very little change to the existing code, most (all?) of
which is already committed to trunk. Ran wordcount with the default
collector and the native collector on a single node setup - the latter
takes
rce tarball
> + successfully run apache-rat:check
> + checked CHANGES, LICENSE, README, NOTICE files.
> + built from source tarball
> + started pseudo cluster
> + run a couple of MR example jobs
> + basic test on HttpFS
>
> On Wed, Sep 10, 2014 at 10:10 AM, Karthik Kambatla
nt release. Filed HADOOP-11078 to track this.
>
> Regards,
> Akira
>
>
> (2014/09/09 0:51), Karthik Kambatla wrote:
>
>> +1 (non-binding)
>>
>> Built the source tarball, brought up a pseudo-distributed cluster and ran
>> a
>> few MR jobs. Verifie
+1 (non-binding)
Built the source tarball, brought up a pseudo-distributed cluster and ran a
few MR jobs. Verified documentation and size of the binary tarball.
On Fri, Sep 5, 2014 at 5:18 PM, Karthik Kambatla wrote:
> Hi folks,
>
> I have put together a release candidate (RC0) f
Hi folks,
I have put together a release candidate (RC0) for Hadoop 2.5.1.
The RC is available at: http://people.apache.org/~kasha/hadoop-2.5.1-RC0/
The RC git tag is release-2.5.1-RC0
The maven artifacts are staged at:
https://repository.apache.org/content/repositories/orgapachehadoop-1010/
You
Hi folks
Now that all issues with target 2.5.1 are committed, I am planning to cut
an RC for 2.5.1 this Friday. The fixes going into 2.5.1 are -
http://s.apache.org/2Mz
Are there any other "Blocker" issues that we would like to get into 2.5.1?
If there are any, please mark them as "Blocker" and t
[
https://issues.apache.org/jira/browse/MAPREDUCE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla resolved MAPREDUCE-5956.
-
Resolution: Fixed
Target Version/s: 2.6.0 (was: 2.5.1)
Spoke to
sf?p=cloudstack.git;h=7260e8d
This is more concise and easier to look at than the Hudson list.
On Wed, Aug 27, 2014 at 10:48 AM, Karthik Kambatla
wrote:
> It appears the comments from Hudson on our JIRAs (post commits) are not
> setup by the INFRA team. Do we use any other scripts for this?
It appears the comments from Hudson on our JIRAs (post commits) are not
setup by the INFRA team. Do we use any other scripts for this? If yes, do
we want to fix those scripts or use svngit2jira?
On Wed, Aug 27, 2014 at 10:18 AM, Karthik Kambatla
wrote:
> The emails for commits apparently
at 1:40 AM, Karthik Kambatla
wrote:
> Oh.. a couple more things.
>
> The git commit hashes have changed and are different from what we had on
> our github. This might interfere with any build automations that folks
> have.
>
> Another follow-up item: email and JIRA integration
Oh.. a couple more things.
The git commit hashes have changed and are different from what we had on
our github. This might interfere with any build automations that folks
have.
Another follow-up item: email and JIRA integration
On Wed, Aug 27, 2014 at 1:33 AM, Karthik Kambatla
wrote:
>
Hi folks,
I am very excited to let you know that the git repo is now writable. I
committed a few changes (CHANGES.txt fixes and branching for 2.5.1) and
everything looks good.
Current status:
1. All branches have the same names, including trunk.
2. Force push is disabled on trunk, branch-2
gt; In my experience, especially when a project has committers new to git,
> force-push support causes more trouble than it's worth.
>
> -Todd
>
>
> On Tue, Aug 26, 2014 at 4:39 PM, Karthik Kambatla
> wrote:
>
> > Looks like our git repo is good to go.
> >
>
the branches
> are present. Also checked a few branches and the recent commit history
> matches our existing repo. Everything looks good so far.
>
>
> On Tue, Aug 26, 2014 at 1:19 PM, Karthik Kambatla
> wrote:
>
> > The git repository is now ready for inspection. I ll t
g.
Are we comfortable with making the git repo writable under these
conditions? I ll let other people poke around and report.
Thanks for your cooperation,
Karthik
On Tue, Aug 26, 2014 at 1:19 PM, Karthik Kambatla
wrote:
> The git repository is now ready for inspection. I ll take a look shortly,
&
The git repository is now ready for inspection. I ll take a look shortly,
but it would be great if a few others could too.
Once we are okay with it, we can ask it to be writable.
On Tuesday, August 26, 2014, Karthik Kambatla wrote:
> Hi Suresh
>
> There was one vote thread on w
ad-hoc basis. Was there any voting on this in PMC and should
> we have a vote to ensure everyone is one the same page on doing this and
> how to go about it?
>
> Regards,
> Suresh
>
>
> On Tue, Aug 26, 2014 at 9:17 AM, Karthik Kambatla
> wrote:
>
> > Last I heard,
Last I heard, the import is still going on and appears closer to getting
done. Thanks for your patience with the migration.
I ll update you as and when there is something. Eventually, the git repo
should be at the location in the wiki.
On Mon, Aug 25, 2014 at 3:45 PM, Karthik Kambatla
wrote
se
configs?
>
> Moreover, do we want to use "--author="Author Name "
> when committing on behalf of a particular contributor?
>
Fetching the email-address is complicated here. Should we use the
contributor's email from JIRA? What if that is not their @apache
uot;master" may be viewed as the official git way, but it doesn't have to be.
> For git-flow workflows (which we use in slider) master/ is for releases,
> develop/ for dev.
>
>
>
>
> On 24 August 2014 02:31, Karthik Kambatla wrote:
>
> > Couple of things:
Thanks Giri.
By the way, writes to svn are now disabled.
On Saturday, August 23, 2014, Giridharan Kesavan
wrote:
> I can take a look at this on Monday.
>
> -giri
>
>
> On Sat, Aug 23, 2014 at 6:31 PM, Karthik Kambatla >
> wrote:
>
> > Couple of things:
>
understand Giri maintains those builds, do we have anyone
else who has access in case Giri is not reachable? Giri - please shout out
if you can help us with this either on Sunday or Monday.
Thanks
Karthik
On Fri, Aug 22, 2014 at 3:50 PM, Karthik Kambatla
wrote:
> Also, does anyone know what
Also, does anyone know what we use for integration between JIRA and svn? I
am assuming svn2jira.
On Fri, Aug 22, 2014 at 3:48 PM, Karthik Kambatla
wrote:
> Hi folks,
>
> For the SCM migration, feel free to follow
> https://issues.apache.org/jira/browse/INFRA-8195
>
> Most of
Hi folks,
For the SCM migration, feel free to follow
https://issues.apache.org/jira/browse/INFRA-8195
Most of this is planned to be handled this Sunday. As a result, the
subversion repository would be read-only. If this is a major issue for you,
please shout out.
Daniel Gruno, the one helping us
1 - 100 of 255 matches
Mail list logo
