[
https://issues.apache.org/jira/browse/APEXMALHAR-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shubham pathak resolved APEXMALHAR-2479.
Resolution: Fixed
Fix Version/s: 3.8.0
> Create example for RegexParser
[
https://issues.apache.org/jira/browse/APEXMALHAR-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988268#comment-15988268
]
ASF GitHub Bot commented on APEXMALHAR-2479:
Github user asfgit closed th
Github user asfgit closed the pull request at:
https://github.com/apache/apex-malhar/pull/607
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
In this case please propose how to deal with PR merge policy violations
in the future. I will -1 proposal to commit an improvement on top of a
commit.
Thank you,
Vlad
On 4/27/17 21:48, Pramod Immaneni wrote:
I am sorry but I am -1 on the force push in this case.
On Apr 27, 2017, at 9:27 PM
GitHub user vrozov opened a pull request:
https://github.com/apache/apex-core/pull/521
APEXCORE-715 Remove unnecessary @Evolving annotation in engine
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vrozov/apex-core APEXCORE-715
[
https://issues.apache.org/jira/browse/APEXCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988250#comment-15988250
]
ASF GitHub Bot commented on APEXCORE-715:
-
GitHub user vrozov opened a pull requ
Vlad Rozov created APEXCORE-715:
---
Summary: Remove unnecessary @Evolving annotation in engine
Key: APEXCORE-715
URL: https://issues.apache.org/jira/browse/APEXCORE-715
Project: Apache Apex Core
I am sorry but I am -1 on the force push in this case.
> On Apr 27, 2017, at 9:27 PM, Thomas Weise wrote:
>
> +1 as measure of last resort.
>
>> On Thu, Apr 27, 2017 at 9:25 PM, Vlad Rozov wrote:
>>
>> IMO, force push will bring enough consequent embarrassment to avoid such
>> behavior in the fu
Let's move forward and discuss ideas that will help decrease the
occurrence of this or prevent it and not do the force commit which is
disruptive and in my opinion not needed for this situation.
Thomas whatever your opinion of the review, it was not the cause of
this. Second, like I mentioned earl
There is one more important difference not mentioned:
Join Impl 1 doesn't work and Join Impl 2 does :)
Can you clarify why a (working) Join Impl 1 would perform better? And if it
is the case, how the amount of work fixing 1 would stack up against
improving 2?
Join Impl 2 has greater flexibility
+1 as measure of last resort.
On Thu, Apr 27, 2017 at 9:25 PM, Vlad Rozov wrote:
> IMO, force push will bring enough consequent embarrassment to avoid such
> behavior in the future.
>
> Thank you,
>
> Vlad
>
> On 4/27/17 21:16, Munagala Ramanath wrote:
>
>> My thought was that leaving the bad co
That's an interesting thought also. Here is one more: Committer on the
project should require demonstrated responsible behavior in this area.
Proven ability to collaborate and doing the right things will be a criteria
for such nominations on my list.
On Thu, Apr 27, 2017 at 9:16 PM, Munagala Rama
IMO, force push will bring enough consequent embarrassment to avoid such
behavior in the future.
Thank you,
Vlad
On 4/27/17 21:16, Munagala Ramanath wrote:
My thought was that leaving the bad commit would be a permanent reminder to
the committer
(and others) that a policy violation occurred an
My thought was that leaving the bad commit would be a permanent reminder to
the committer
(and others) that a policy violation occurred and the consequent
embarrassment would be an
adequate deterrent.
Ram
On Thu, Apr 27, 2017 at 9:12 PM, Vlad Rozov wrote:
> I also was under impression that ever
Haha. Community won't grow without idealism.
On Thu, Apr 27, 2017 at 9:03 PM, Munagala Ramanath
wrote:
> Idealism is a wonderful thing but reality sometimes intrudes.
>
> Ram
>
> On Thu, Apr 27, 2017 at 8:54 PM, Thomas Weise wrote:
>
> > I also thought that everybody was in agreement about tha
I also was under impression that everyone agreed to the policy that
gives everyone in the community a chance to raise a concern or to
propose an improvement to a PR. Unfortunately, it is not the case, and
we need to discuss it again. I hope that this discussion will lead to no
future violations
Idealism is a wonderful thing but reality sometimes intrudes.
Ram
On Thu, Apr 27, 2017 at 8:54 PM, Thomas Weise wrote:
> I also thought that everybody was in agreement about that after the first
> round of discussion and as you say it would be hard to argue against it.
> And I think we should n
I also thought that everybody was in agreement about that after the first
round of discussion and as you say it would be hard to argue against it.
And I think we should not have to be back to the same topic a few days
later.
While you seem to be focussed on the disagreement on policy violation, I'
Everybody seems agreed on what the committers should do -- that waiting a
day or two for
others to have a chance to comment seems like an entirely reasonable thing.
The disagreement is about what to do when that policy is violated.
Ram
On Thu, Apr 27, 2017 at 8:37 PM, Thomas Weise wrote:
> For
Forced push should not be necessary if committers follow the development
process.
So why not focus on what the committer should do? Development process and
guidelines are there for a reason, and the issue was raised before.
In this specific case, there is a string of commits related to the plugin
I agree with Pramod that force pushing should be a rare event done only
when there is an immediate
need to undo something serious. Doing it just for a policy violation should
itself be codified in our
policies as a policy violation.
Why not just commit an improvement on top ?
Ram
On Thu, Apr 27,
Violation of the PR merge policy is a sufficient reason to forcibly undo
the commit and such violations affect everyone in the community.
Thank you,
Vlad
On 4/27/17 19:36, Pramod Immaneni wrote:
I agree that PRs should not be merged without a chance for others to
review. I don't agree to forc
I agree that PRs should not be merged without a chance for others to
review. I don't agree to force push and altering the commit tree unless it
is absolutely needed, as it affects everyone. This case doesn't warrant
this step, one scenario where a force push might be needed is if somebody
pushed so
I am open to both approaches - two commits or a join commit. Both have
pros and cons that we may discuss. What I am strongly against are PRs
that are merged without a chance for other contributors/committers to
review. There should be a way to forcibly undo such commits.
Thank you,
Vlad
On 4
GitHub user sanjaypujare opened a pull request:
https://github.com/apache/apex-core/pull/520
APEXCORE-711 create a new attribute CUSTOM_SSL_SERVER_CONFIG and use its
value to set custom ssl server config
@PramodSSImmaneni pls review and merge as appropriate
You can merge this pull
[
https://issues.apache.org/jira/browse/APEXCORE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987779#comment-15987779
]
ASF GitHub Bot commented on APEXCORE-711:
-
GitHub user sanjaypujare opened a pul
My comments inline..
On Thu, Apr 27, 2017 at 12:01 PM, Thomas Weise wrote:
> I'm -1 on using the author field like this in Apex for the reason stated
> (it is also odd to see something like this showing up without prior
> discussion).
>
>
I am not set on this for future commits but would like to
I'm -1 on using the author field like this in Apex for the reason stated
(it is also odd to see something like this showing up without prior
discussion).
Consider adding the additional author information to the commit message.
Thomas
On Thu, Apr 27, 2017 at 11:55 AM, Pramod Immaneni
wrote:
> A
Agreed it is not regular and should only be used in special circumstances.
One example of this is pair programming. It has been done before in other
projects and searching on google or stackoverflow you can see how other
people have tried to handle it
https://bugs.eclipse.org/bugs/show_bug.cgi?id=
commit 9856080ede62a4529d730bcb6724c757f5010990
Author: Pramod Immaneni & Vlad Rozov
Date: Tue Apr 18 09:37:22 2017 -0700
Please don't use the author field in such a way, it leads to incorrect
tracking of contributions.
Either have separate commits or have one author.
Thanks
On Thu, Apr 27
The issue was two different plugin models were developed, one for
pre-launch and other for post-launch. I felt that the one built latter was
better and it would be better to have a uniform interface for the users and
hence asked for the changes.
On Thu, Apr 27, 2017 at 9:05 AM, Thomas Weise wrote
I think the plugins feature could have benefited from better original
review, which would have eliminated much of the back and forth after the
fact.
On Thu, Apr 27, 2017 at 8:20 AM, Vlad Rozov wrote:
> Pramod,
>
> No, it is not a request to update the apex.apache.org (to do that we need
> to fi
Pramod,
No, it is not a request to update the apex.apache.org (to do that we
need to file JIRA). It is a reminder that it is against Apex policy to
merge PR without giving enough time for others to review it (few hours
after PR was open).
Thank you,
Vlad
On 4/27/17 08:05, Pramod Immaneni wr
Vlad, are you asking for a consensus on the policy to make it official
(publish on website etc). I believe we have one. However, I did not see
much difference between what you said on Mar 26th to what I proposed on Mar
24th. Is the main difference any committer can merge (not just the main
reviewer
This is a friendly reminder regarding PR merge policy.
Thank you,
Vlad
On 3/23/17 12:58, Vlad Rozov wrote:
Lately there were few instances where PR open against apex-core and
apex-malhar were merged just few hours after it being open and JIRA
being raised without giving chance for other contr
[
https://issues.apache.org/jira/browse/APEXMALHAR-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986303#comment-15986303
]
ASF GitHub Bot commented on APEXMALHAR-2484:
Github user chaithu14 closed
[
https://issues.apache.org/jira/browse/APEXMALHAR-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986306#comment-15986306
]
ASF GitHub Bot commented on APEXMALHAR-2484:
GitHub user chaithu14 opened
GitHub user chaithu14 opened a pull request:
https://github.com/apache/apex-malhar/pull/614
APEXMALHAR-2484 Support of PartFileWriter for writing the part files
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/chaithu14/incubator-
Github user chaithu14 closed the pull request at:
https://github.com/apache/apex-malhar/pull/611
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
All the issues marked as 3.6 have been resolved. I will go ahead and
prepare RC1 candidate.
Thanks,
- Tushar.
On Wed, Apr 26, 2017 at 2:30 PM, Tushar Gosavi
wrote:
> These errors went away after switching to 1.7 version of java for build.
>
> Thanks,
> -Tushar.
>
>
> On Wed, Apr 26, 2017 at 12:
[
https://issues.apache.org/jira/browse/APEXCORE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986185#comment-15986185
]
ASF GitHub Bot commented on APEXCORE-700:
-
Github user asfgit closed the pull re
Github user asfgit closed the pull request at:
https://github.com/apache/apex-core/pull/519
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is e
GitHub user tushargosavi opened a pull request:
https://github.com/apache/apex-core/pull/519
APEXCORE-700 Add Evolving annotations for classes changed through 985â¦
â¦6080ed
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tushar
[
https://issues.apache.org/jira/browse/APEXCORE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986146#comment-15986146
]
ASF GitHub Bot commented on APEXCORE-700:
-
GitHub user tushargosavi opened a pul
[
https://issues.apache.org/jira/browse/APEXCORE-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tushar Gosavi resolved APEXCORE-594.
Resolution: Fixed
Fix Version/s: 3.6.0
> Plugin support in Apex
> -
[
https://issues.apache.org/jira/browse/APEXCORE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tushar Gosavi resolved APEXCORE-700.
Resolution: Fixed
> Make the plugin registration interface uniform
> -
Github user asfgit closed the pull request at:
https://github.com/apache/apex-core/pull/518
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is e
[
https://issues.apache.org/jira/browse/APEXCORE-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986133#comment-15986133
]
ASF GitHub Bot commented on APEXCORE-700:
-
Github user asfgit closed the pull re
48 matches
Mail list logo
