[
https://issues.apache.org/jira/browse/APEXCORE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15990108#comment-15990108
]
Sanjay M Pujare commented on APEXCORE-711:
--
[~vrozov] I tested it with my own h
On 4/29/17 15:51, Justin Mclean wrote:
HI,
Does anybody know if:
1. Any other Apache project has a similar forced-revert policy; and
None that I’m aware of. But if a committer checks in some code the breaks
something and someone vetoes it, it is expected that they revert the checkin
and fix
public static class Pojo implements Tuple
{
@Override
public Object getValue()
{
return this;
}
}
@Override
public void populateDAG(DAG dag, Configuration conf)
{
CsvParser csvParser = dag.addOperator("csvParser", CsvParser.class);
WindowedOperatorImpl windowedOperator =
dag.addO
HI,
> Does anybody know if:
> 1. Any other Apache project has a similar forced-revert policy; and
None that I’m aware of. But if a committer checks in some code the breaks
something and someone vetoes it, it is expected that they revert the checkin
and fix it. I’ve seen this happen a few times,
I will add one more question:
How many contributors/committers can tell how many force pushes were
done to apex repositories since graduation without looking into
commits@apex.
Thank you,
Vlad
On 4/29/17 11:48, Munagala Ramanath wrote:
Looks like we have clarity now that we are at an impas
I agree that there is no silver bullet here. My view on the force push
is that it is not so disruptive to the community as it looks to be. It
is very easy to reset master to apache/github remote master and rebase
branches if necessary assuming that it is not done frequently. I view
multiple com
Even this will not work because the output port of CsvParser is of type
Object. Even though Customer extends Tuple, it will still fail to
work since Tuple gets output as Object.
*DefaultOutputPort output = new DefaultOutputPort();*
The input port type at windowed operator with InputT = Object :
*
Use Object in place of InputT in the WindowedOperatorImpl. Cast Object to the
actual type of InputT at runtime. Introducing an operator just to do a cast is
not a good design decision, IMO.
Thank you,
Vlad
Отправлено с iPhone
> On Apr 29, 2017, at 02:50, AJAY GUPTA wrote:
>
> I am using Wind
Looks like we have clarity now that we are at an impasse: -1 on forced
revert and -1 on the
only other alternative with is additional commits. We need a continuing
resolution
(
https://federalnewsradio.com/federal-headlines/2017/04/short-term-spending-measure-introduced-to-keep-government-open/
)
t
[
https://issues.apache.org/jira/browse/APEXCORE-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pramod Immaneni resolved APEXCORE-715.
--
Resolution: Fixed
> Remove unnecessary @Evolving annotation in engine
> --
That is not the main point I was making. I think your main concern is that
when a commit gets added like this, the principle of putting community
first is being violated. That is well taken but what I am trying to say is
that your remedy is going the same route because you are focusing only on a
sp
Github user asfgit closed the pull request at:
https://github.com/apache/apex-core/pull/521
---
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-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989966#comment-15989966
]
ASF GitHub Bot commented on APEXCORE-715:
-
Github user asfgit closed the pull re
Pramod Immaneni created APEXCORE-716:
Summary: Add a package level javadoc for engine api about it's
intended use
Key: APEXCORE-716
URL: https://issues.apache.org/jira/browse/APEXCORE-716
Project:
[
https://issues.apache.org/jira/browse/APEXCORE-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15989953#comment-15989953
]
Vlad Rozov commented on APEXCORE-711:
-
[~sanjaypujare] While fix does not introduce
I am -1 on the proposal to submit new PR. If commit was done
prematurely, it needs to be undone as quickly as it was done.
Thank you,
Vlad
On 4/29/17 09:34, Munagala Ramanath wrote:
Given the divergence of views on this topic, I think we need to clarify
what "last resort"
means; to me it means
I don't think that anyone proposed shaming of individuals who violated
the policy especially in a public e-mail. Understanding of inconvenience
caused to the community is sufficient to avoid policy violations.
I would propose using PR to communicate to a committer and a contributor
request to
Given the divergence of views on this topic, I think we need to clarify
what "last resort"
means; to me it means:
In most cases when PRs are prematurely merged, the preferred
mechanism to address it will be to open a new PR with corrections resulting
in a new
commit on top. A forced reversion of t
Yes, the rollback is the last resort as Thomas mentioned. I hope that we
will not need it.
Possibly I misjudge, but I don't see forced push as an extremely
disturbing event for the community especially if it is done quickly.
Thank you,
Vlad
On 4/28/17 23:33, Bhupesh Chawda wrote:
Vlad,
I assume we are still referring to force push and removing the commit from
the upstream git commit tree as rollback and not to applying a new commit
that reverts the changes. When a violation happens, why should everyone
(who synced with the repo) suffer the inconvenience of their local git
repo/br
I am using WindowedOperatorImpl and it is declared as follows.
WindowedOperatorImpl windowedOperator
= new WindowedOperatorImpl<>();
In my application scenario, the InputT is Customer POJO which is getting
output as an Object by CsvParser.
Ajay
On Fri, Apr 28, 2017 at 11:53 PM, Vlad Rozov
wro
21 matches
Mail list logo
