You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apex.apache.org by Pramod Immaneni <pr...@datatorrent.com> on 2016/07/05 18:23:56 UTC
Re: Malhar contribution guidelines
I received some feedback. Any other comments before adding these guidelines
to the project.
Thanks
On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:
> Hi everyone,
>
> I wanted to create a set of guidelines that would help folks that want to
> contribute to Malhar. The goal is that by following these guidelines the
> contributions will be assured a certain level of quality as the different
> aspects to consider, common missteps and mistakes will be taken care of
> which in turn would also make the review process smoother by reducing the
> number of review iterations before the contribution gets merged. I tried to
> capture as much information as I thought would help developers towards this
> goal based on past experience and exposure, in a document.
>
> Please go through it and provide your feedback, it will be greatly
> appreciated. I will go through your comments and incorporate any necessary
> changes. After that I hope this document will become a living document as
> part of the contribution guidelines and evolve with the times.
>
>
> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
>
> Thanks
>
Re: Malhar contribution guidelines
Posted by Pramod Immaneni <pr...@datatorrent.com>.
Hi Sanjay,
Thanks for the feedback. My comments inline.
On Tue, Jul 5, 2016 at 2:37 PM, Sanjay Pujare <sa...@datatorrent.com>
wrote:
> Hi Pramod
>
> Very useful document. Some questions/comments from me (sorry for any newbie
> comments):
>
> - for the "Update an Existing Operator" section, are there any backward
> compatibility constraints one should be aware of?
>
Yes the public and protected methods need to be preserved if they are not
evolving operators. There is a semantic versioning check that happens
during the build process, which ensures that these constraints are not
violated. I will add these to the guidelines.
> - it will be very useful to have each guideline illustrated by an actual
> example (e.g. an example of combining 2 or more operators in a module,
> initialization and teardown cases in
> constructor/setup/beginWindow/endWindow/deactivate/teardown etc)
>
I think those would be best suited for the operator developer guide. The
guidelines are meant to be used as a primer.
> - should the guidelines say something about unit tests and how unit tests
> should typically be written for operators (also include other kinds of
> automated tests in-case "unit" testing is difficult)
>
Good point, will add a section on that.
> - didn't find any references to WindowedOperator anywhere (but did find
> WindowedStream). Will be good to have hyperlinks for all references
>
David would probably work on that as he is working on the implementation.
The comment was forward looking.
> - java 1.8/1.7 compatibility requirement?
>
1.7 is a general requirement we have for the platform and should be
mentioned elsewhere in the docs. Not sure if we need to mention it
specifically in this document.
> - with respect to "...only the data for the first input port..." , how is
> "first" input port determined?
>
The first declared port, changed to mention that specifically.
>
>
>
>
> On Tue, Jul 5, 2016 at 11:23 AM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> > I received some feedback. Any other comments before adding these
> guidelines
> > to the project.
> >
> > Thanks
> >
> > On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <pramod@datatorrent.com
> >
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I wanted to create a set of guidelines that would help folks that want
> to
> > > contribute to Malhar. The goal is that by following these guidelines
> the
> > > contributions will be assured a certain level of quality as the
> different
> > > aspects to consider, common missteps and mistakes will be taken care of
> > > which in turn would also make the review process smoother by reducing
> the
> > > number of review iterations before the contribution gets merged. I
> tried
> > to
> > > capture as much information as I thought would help developers towards
> > this
> > > goal based on past experience and exposure, in a document.
> > >
> > > Please go through it and provide your feedback, it will be greatly
> > > appreciated. I will go through your comments and incorporate any
> > necessary
> > > changes. After that I hope this document will become a living document
> as
> > > part of the contribution guidelines and evolve with the times.
> > >
> > >
> > >
> >
> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
> > >
> > > Thanks
> > >
> >
>
Re: Malhar contribution guidelines
Posted by Sanjay Pujare <sa...@datatorrent.com>.
Hi Pramod
Very useful document. Some questions/comments from me (sorry for any newbie
comments):
- for the "Update an Existing Operator" section, are there any backward
compatibility constraints one should be aware of?
- it will be very useful to have each guideline illustrated by an actual
example (e.g. an example of combining 2 or more operators in a module,
initialization and teardown cases in
constructor/setup/beginWindow/endWindow/deactivate/teardown etc)
- should the guidelines say something about unit tests and how unit tests
should typically be written for operators (also include other kinds of
automated tests in-case "unit" testing is difficult)
- didn't find any references to WindowedOperator anywhere (but did find
WindowedStream). Will be good to have hyperlinks for all references
- java 1.8/1.7 compatibility requirement?
- with respect to "...only the data for the first input port..." , how is
"first" input port determined?
On Tue, Jul 5, 2016 at 11:23 AM, Pramod Immaneni <pr...@datatorrent.com>
wrote:
> I received some feedback. Any other comments before adding these guidelines
> to the project.
>
> Thanks
>
> On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> > Hi everyone,
> >
> > I wanted to create a set of guidelines that would help folks that want to
> > contribute to Malhar. The goal is that by following these guidelines the
> > contributions will be assured a certain level of quality as the different
> > aspects to consider, common missteps and mistakes will be taken care of
> > which in turn would also make the review process smoother by reducing the
> > number of review iterations before the contribution gets merged. I tried
> to
> > capture as much information as I thought would help developers towards
> this
> > goal based on past experience and exposure, in a document.
> >
> > Please go through it and provide your feedback, it will be greatly
> > appreciated. I will go through your comments and incorporate any
> necessary
> > changes. After that I hope this document will become a living document as
> > part of the contribution guidelines and evolve with the times.
> >
> >
> >
> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
> >
> > Thanks
> >
>
Re: Malhar contribution guidelines
Posted by Pramod Immaneni <pr...@datatorrent.com>.
The document has been split into two, one for contribution guidelines to
malhar on Apex site (discussed in an earlier email) and one for operator
development best practices and submitted as pull requests
https://github.com/apache/apex-malhar/pull/350
https://github.com/apache/apex-site/pull/44
Thanks
On Tue, Jul 5, 2016 at 4:43 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:
> Thanks for the feedback. I think details should be in the operator
> developer guide. The guidelines document is a condensed document, that
> tells someone what they need to be aware of, in a few sentences for each
> topic. Once they read something in this document and they want more detail
> they should go to the operator developer guide. I can explain that in the
> beginning of the document.
>
> On Tue, Jul 5, 2016 at 3:49 PM, Ashwin Chandra Putta <
> ashwinchandrap@gmail.com> wrote:
>
>> Added a few comments Pramod, otherwise looks good. Dividing the guidelines
>> would probably make sense. Contribution process related guidelines can go
>> into contribution guidelines and technical implementation related
>> guidelines can go into implementation guidelines. Another thing that might
>> be helpful is a section describing a simple process for new contributors
>> to
>> get started without much complexity.
>>
>> Regards,
>> Ashwin.
>>
>> On Tue, Jul 5, 2016 at 2:06 PM, Pramod Immaneni <pr...@datatorrent.com>
>> wrote:
>>
>> > I can wait. I can also try to break it up into an abridged set of
>> > guidelines and add the details into the operator developer guide if
>> > they are missing.
>> >
>> > > On Jul 5, 2016, at 1:38 PM, Thomas Weise <th...@datatorrent.com>
>> wrote:
>> > >
>> > > I will also have a look at it.
>> > >
>> > > Wondering though if it shouldn't replace the existing operator
>> developer
>> > > guide?
>> > >
>> > > http://apex.apache.org/docs/apex/operator_development/
>> > >
>> > > For the contributing guidelines on the web site, maybe it is better to
>> > have
>> > > a shorter checklist that gives folks the necessary pointers w/o too
>> much
>> > > detail?
>> > >
>> > > http://apex.apache.org/contributing.html
>> > >
>> > > Thomas
>> > >
>> > >
>> > >
>> > > On Tue, Jul 5, 2016 at 1:07 PM, Munagala Ramanath <
>> ram@datatorrent.com>
>> > > wrote:
>> > >
>> > >> Pramod, I'll take a look this evening if you can wait that long.
>> > >> Ram
>> > >>> On Jul 5, 2016 11:24 AM, "Pramod Immaneni" <pr...@datatorrent.com>
>> > wrote:
>> > >>>
>> > >>> I received some feedback. Any other comments before adding these
>> > >> guidelines
>> > >>> to the project.
>> > >>>
>> > >>> Thanks
>> > >>>
>> > >>> On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <
>> > pramod@datatorrent.com
>> > >>>
>> > >>> wrote:
>> > >>>
>> > >>>> Hi everyone,
>> > >>>>
>> > >>>> I wanted to create a set of guidelines that would help folks that
>> want
>> > >> to
>> > >>>> contribute to Malhar. The goal is that by following these
>> guidelines
>> > >> the
>> > >>>> contributions will be assured a certain level of quality as the
>> > >> different
>> > >>>> aspects to consider, common missteps and mistakes will be taken
>> care
>> > of
>> > >>>> which in turn would also make the review process smoother by
>> reducing
>> > >> the
>> > >>>> number of review iterations before the contribution gets merged. I
>> > >> tried
>> > >>> to
>> > >>>> capture as much information as I thought would help developers
>> towards
>> > >>> this
>> > >>>> goal based on past experience and exposure, in a document.
>> > >>>>
>> > >>>> Please go through it and provide your feedback, it will be greatly
>> > >>>> appreciated. I will go through your comments and incorporate any
>> > >>> necessary
>> > >>>> changes. After that I hope this document will become a living
>> document
>> > >> as
>> > >>>> part of the contribution guidelines and evolve with the times.
>> > >>
>> >
>> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
>> > >>>>
>> > >>>> Thanks
>> > >>
>> >
>>
>>
>>
>> --
>>
>> Regards,
>> Ashwin.
>>
>
>
Re: Malhar contribution guidelines
Posted by Pramod Immaneni <pr...@datatorrent.com>.
Thanks for the feedback. I think details should be in the operator
developer guide. The guidelines document is a condensed document, that
tells someone what they need to be aware of, in a few sentences for each
topic. Once they read something in this document and they want more detail
they should go to the operator developer guide. I can explain that in the
beginning of the document.
On Tue, Jul 5, 2016 at 3:49 PM, Ashwin Chandra Putta <
ashwinchandrap@gmail.com> wrote:
> Added a few comments Pramod, otherwise looks good. Dividing the guidelines
> would probably make sense. Contribution process related guidelines can go
> into contribution guidelines and technical implementation related
> guidelines can go into implementation guidelines. Another thing that might
> be helpful is a section describing a simple process for new contributors to
> get started without much complexity.
>
> Regards,
> Ashwin.
>
> On Tue, Jul 5, 2016 at 2:06 PM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> > I can wait. I can also try to break it up into an abridged set of
> > guidelines and add the details into the operator developer guide if
> > they are missing.
> >
> > > On Jul 5, 2016, at 1:38 PM, Thomas Weise <th...@datatorrent.com>
> wrote:
> > >
> > > I will also have a look at it.
> > >
> > > Wondering though if it shouldn't replace the existing operator
> developer
> > > guide?
> > >
> > > http://apex.apache.org/docs/apex/operator_development/
> > >
> > > For the contributing guidelines on the web site, maybe it is better to
> > have
> > > a shorter checklist that gives folks the necessary pointers w/o too
> much
> > > detail?
> > >
> > > http://apex.apache.org/contributing.html
> > >
> > > Thomas
> > >
> > >
> > >
> > > On Tue, Jul 5, 2016 at 1:07 PM, Munagala Ramanath <ram@datatorrent.com
> >
> > > wrote:
> > >
> > >> Pramod, I'll take a look this evening if you can wait that long.
> > >> Ram
> > >>> On Jul 5, 2016 11:24 AM, "Pramod Immaneni" <pr...@datatorrent.com>
> > wrote:
> > >>>
> > >>> I received some feedback. Any other comments before adding these
> > >> guidelines
> > >>> to the project.
> > >>>
> > >>> Thanks
> > >>>
> > >>> On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <
> > pramod@datatorrent.com
> > >>>
> > >>> wrote:
> > >>>
> > >>>> Hi everyone,
> > >>>>
> > >>>> I wanted to create a set of guidelines that would help folks that
> want
> > >> to
> > >>>> contribute to Malhar. The goal is that by following these guidelines
> > >> the
> > >>>> contributions will be assured a certain level of quality as the
> > >> different
> > >>>> aspects to consider, common missteps and mistakes will be taken care
> > of
> > >>>> which in turn would also make the review process smoother by
> reducing
> > >> the
> > >>>> number of review iterations before the contribution gets merged. I
> > >> tried
> > >>> to
> > >>>> capture as much information as I thought would help developers
> towards
> > >>> this
> > >>>> goal based on past experience and exposure, in a document.
> > >>>>
> > >>>> Please go through it and provide your feedback, it will be greatly
> > >>>> appreciated. I will go through your comments and incorporate any
> > >>> necessary
> > >>>> changes. After that I hope this document will become a living
> document
> > >> as
> > >>>> part of the contribution guidelines and evolve with the times.
> > >>
> >
> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
> > >>>>
> > >>>> Thanks
> > >>
> >
>
>
>
> --
>
> Regards,
> Ashwin.
>
Re: Malhar contribution guidelines
Posted by Ashwin Chandra Putta <as...@gmail.com>.
Added a few comments Pramod, otherwise looks good. Dividing the guidelines
would probably make sense. Contribution process related guidelines can go
into contribution guidelines and technical implementation related
guidelines can go into implementation guidelines. Another thing that might
be helpful is a section describing a simple process for new contributors to
get started without much complexity.
Regards,
Ashwin.
On Tue, Jul 5, 2016 at 2:06 PM, Pramod Immaneni <pr...@datatorrent.com>
wrote:
> I can wait. I can also try to break it up into an abridged set of
> guidelines and add the details into the operator developer guide if
> they are missing.
>
> > On Jul 5, 2016, at 1:38 PM, Thomas Weise <th...@datatorrent.com> wrote:
> >
> > I will also have a look at it.
> >
> > Wondering though if it shouldn't replace the existing operator developer
> > guide?
> >
> > http://apex.apache.org/docs/apex/operator_development/
> >
> > For the contributing guidelines on the web site, maybe it is better to
> have
> > a shorter checklist that gives folks the necessary pointers w/o too much
> > detail?
> >
> > http://apex.apache.org/contributing.html
> >
> > Thomas
> >
> >
> >
> > On Tue, Jul 5, 2016 at 1:07 PM, Munagala Ramanath <ra...@datatorrent.com>
> > wrote:
> >
> >> Pramod, I'll take a look this evening if you can wait that long.
> >> Ram
> >>> On Jul 5, 2016 11:24 AM, "Pramod Immaneni" <pr...@datatorrent.com>
> wrote:
> >>>
> >>> I received some feedback. Any other comments before adding these
> >> guidelines
> >>> to the project.
> >>>
> >>> Thanks
> >>>
> >>> On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <
> pramod@datatorrent.com
> >>>
> >>> wrote:
> >>>
> >>>> Hi everyone,
> >>>>
> >>>> I wanted to create a set of guidelines that would help folks that want
> >> to
> >>>> contribute to Malhar. The goal is that by following these guidelines
> >> the
> >>>> contributions will be assured a certain level of quality as the
> >> different
> >>>> aspects to consider, common missteps and mistakes will be taken care
> of
> >>>> which in turn would also make the review process smoother by reducing
> >> the
> >>>> number of review iterations before the contribution gets merged. I
> >> tried
> >>> to
> >>>> capture as much information as I thought would help developers towards
> >>> this
> >>>> goal based on past experience and exposure, in a document.
> >>>>
> >>>> Please go through it and provide your feedback, it will be greatly
> >>>> appreciated. I will go through your comments and incorporate any
> >>> necessary
> >>>> changes. After that I hope this document will become a living document
> >> as
> >>>> part of the contribution guidelines and evolve with the times.
> >>
> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
> >>>>
> >>>> Thanks
> >>
>
--
Regards,
Ashwin.
Re: Malhar contribution guidelines
Posted by Pramod Immaneni <pr...@datatorrent.com>.
I can wait. I can also try to break it up into an abridged set of
guidelines and add the details into the operator developer guide if
they are missing.
> On Jul 5, 2016, at 1:38 PM, Thomas Weise <th...@datatorrent.com> wrote:
>
> I will also have a look at it.
>
> Wondering though if it shouldn't replace the existing operator developer
> guide?
>
> http://apex.apache.org/docs/apex/operator_development/
>
> For the contributing guidelines on the web site, maybe it is better to have
> a shorter checklist that gives folks the necessary pointers w/o too much
> detail?
>
> http://apex.apache.org/contributing.html
>
> Thomas
>
>
>
> On Tue, Jul 5, 2016 at 1:07 PM, Munagala Ramanath <ra...@datatorrent.com>
> wrote:
>
>> Pramod, I'll take a look this evening if you can wait that long.
>> Ram
>>> On Jul 5, 2016 11:24 AM, "Pramod Immaneni" <pr...@datatorrent.com> wrote:
>>>
>>> I received some feedback. Any other comments before adding these
>> guidelines
>>> to the project.
>>>
>>> Thanks
>>>
>>> On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <pramod@datatorrent.com
>>>
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I wanted to create a set of guidelines that would help folks that want
>> to
>>>> contribute to Malhar. The goal is that by following these guidelines
>> the
>>>> contributions will be assured a certain level of quality as the
>> different
>>>> aspects to consider, common missteps and mistakes will be taken care of
>>>> which in turn would also make the review process smoother by reducing
>> the
>>>> number of review iterations before the contribution gets merged. I
>> tried
>>> to
>>>> capture as much information as I thought would help developers towards
>>> this
>>>> goal based on past experience and exposure, in a document.
>>>>
>>>> Please go through it and provide your feedback, it will be greatly
>>>> appreciated. I will go through your comments and incorporate any
>>> necessary
>>>> changes. After that I hope this document will become a living document
>> as
>>>> part of the contribution guidelines and evolve with the times.
>> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
>>>>
>>>> Thanks
>>
Re: Malhar contribution guidelines
Posted by Thomas Weise <th...@datatorrent.com>.
I will also have a look at it.
Wondering though if it shouldn't replace the existing operator developer
guide?
http://apex.apache.org/docs/apex/operator_development/
For the contributing guidelines on the web site, maybe it is better to have
a shorter checklist that gives folks the necessary pointers w/o too much
detail?
http://apex.apache.org/contributing.html
Thomas
On Tue, Jul 5, 2016 at 1:07 PM, Munagala Ramanath <ra...@datatorrent.com>
wrote:
> Pramod, I'll take a look this evening if you can wait that long.
> Ram
> On Jul 5, 2016 11:24 AM, "Pramod Immaneni" <pr...@datatorrent.com> wrote:
>
> > I received some feedback. Any other comments before adding these
> guidelines
> > to the project.
> >
> > Thanks
> >
> > On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <pramod@datatorrent.com
> >
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I wanted to create a set of guidelines that would help folks that want
> to
> > > contribute to Malhar. The goal is that by following these guidelines
> the
> > > contributions will be assured a certain level of quality as the
> different
> > > aspects to consider, common missteps and mistakes will be taken care of
> > > which in turn would also make the review process smoother by reducing
> the
> > > number of review iterations before the contribution gets merged. I
> tried
> > to
> > > capture as much information as I thought would help developers towards
> > this
> > > goal based on past experience and exposure, in a document.
> > >
> > > Please go through it and provide your feedback, it will be greatly
> > > appreciated. I will go through your comments and incorporate any
> > necessary
> > > changes. After that I hope this document will become a living document
> as
> > > part of the contribution guidelines and evolve with the times.
> > >
> > >
> > >
> >
> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
> > >
> > > Thanks
> > >
> >
>
Re: Malhar contribution guidelines
Posted by Munagala Ramanath <ra...@datatorrent.com>.
Pramod, I'll take a look this evening if you can wait that long.
Ram
On Jul 5, 2016 11:24 AM, "Pramod Immaneni" <pr...@datatorrent.com> wrote:
> I received some feedback. Any other comments before adding these guidelines
> to the project.
>
> Thanks
>
> On Fri, Jun 17, 2016 at 3:12 PM, Pramod Immaneni <pr...@datatorrent.com>
> wrote:
>
> > Hi everyone,
> >
> > I wanted to create a set of guidelines that would help folks that want to
> > contribute to Malhar. The goal is that by following these guidelines the
> > contributions will be assured a certain level of quality as the different
> > aspects to consider, common missteps and mistakes will be taken care of
> > which in turn would also make the review process smoother by reducing the
> > number of review iterations before the contribution gets merged. I tried
> to
> > capture as much information as I thought would help developers towards
> this
> > goal based on past experience and exposure, in a document.
> >
> > Please go through it and provide your feedback, it will be greatly
> > appreciated. I will go through your comments and incorporate any
> necessary
> > changes. After that I hope this document will become a living document as
> > part of the contribution guidelines and evolve with the times.
> >
> >
> >
> https://drive.google.com/open?id=1WjbaIogVtMDQwbvxTlQxrFqUbK9D75bk98asW9e5OxA
> >
> > Thanks
> >
>