You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafodion.apache.org by Suresh Subbiah <su...@gmail.com> on 2015/07/07 23:45:07 UTC
Project Merge criteria
Hi All,
This message is to revive a thread started by Steve and Alice on project
merge criteria.
Please add your input here, there have been excellent suggestions by
Pierre/others on how JIRA can be used and when in the dev cycle reviews
should be done.
I would personally prefer a model where a committer did not have special
authority on vetoing changes but instead helps choose subject area experts
for review. The opinions of those reviewers are then binding. Once
sufficient information has been collected in an email thread I can collate
it into a proposal we can DISCUSS/VOTE.
Thanks
Suresh
I think the existing tests are sufficient for fixing the current bugs.
My question is what
about new features? The current tests do not cover those.
Personally, I think new tests
(or instructions on how to verify the feature) should accompany new
features even if the new
tests are not fully automated yet. Otherwise how are we supposed to
verify these new features?
Cheers,
Alice
-----Original Message-----
From: Varnau, Steve (Trafodion)
Sent: Thursday, June 18, 2015 1:50 PM
To: dev@trafodion.incubator.apache.org
Subject: Project merge criteria
While we're waiting for the software grant process, perhaps the
committers should discuss
the criteria for accepting and merging in code
changes.https://wiki.trafodion.org/wiki/index.php/Committer_Workflow#Ensure_Criteria_are_Met
I've set up automated testing to run the same test suites as we ran
before for core changes
in the zuul "check". (There is no automated "gate" test.) Assuming
that is the same, then
the other non-test criteria are open for discussion I think.
-Steve
Re: Project Merge criteria
Posted by Selva Govindarajan <se...@esgyn.com>.
To start with, I would think we should enable the capability to do full
test using hub. Currently, only subset of tests are being done as part of
the commit. Depending upon the nature of the commit, I would think the
contributor can choose to run the full test or the reviewer can request the
contributor to run the full test.
Currently, the contributor has the ability to run SQL related tests via
sqlci in his/her work space. We need to document this so that contributor
can run and add new tests if needed.
We should extend this ability to run both ODBC and JDBC tests from the work
space also in near future. These can help the contributor to debug the
issue easier if there are any issues with his/her change.
Selva
On Tue, Jul 7, 2015 at 2:45 PM, Suresh Subbiah <su...@gmail.com>
wrote:
> Hi All,
>
> This message is to revive a thread started by Steve and Alice on project
> merge criteria.
>
> Please add your input here, there have been excellent suggestions by
> Pierre/others on how JIRA can be used and when in the dev cycle reviews
> should be done.
>
> I would personally prefer a model where a committer did not have special
> authority on vetoing changes but instead helps choose subject area experts
> for review. The opinions of those reviewers are then binding. Once
> sufficient information has been collected in an email thread I can collate
> it into a proposal we can DISCUSS/VOTE.
>
> Thanks
> Suresh
>
>
> I think the existing tests are sufficient for fixing the current bugs.
> My question is what
> about new features? The current tests do not cover those.
> Personally, I think new tests
> (or instructions on how to verify the feature) should accompany new
> features even if the new
> tests are not fully automated yet. Otherwise how are we supposed to
> verify these new features?
>
> Cheers,
> Alice
>
>
> -----Original Message-----
> From: Varnau, Steve (Trafodion)
> Sent: Thursday, June 18, 2015 1:50 PM
> To: dev@trafodion.incubator.apache.org
> Subject: Project merge criteria
>
> While we're waiting for the software grant process, perhaps the
> committers should discuss
> the criteria for accepting and merging in code
> changes.
> https://wiki.trafodion.org/wiki/index.php/Committer_Workflow#Ensure_Criteria_are_Met
>
> I've set up automated testing to run the same test suites as we ran
> before for core changes
> in the zuul "check". (There is no automated "gate" test.) Assuming
> that is the same, then
> the other non-test criteria are open for discussion I think.
>
> -Steve
>
Re: Project Merge criteria
Posted by Pierre Smits <pi...@gmail.com>.
My apologies,
That first paragraph, up to the links, was premature and intended in
another message.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Jul 8, 2015 at 2:14 AM, Pierre Smits <pi...@gmail.com> wrote:
> The generic ASF assertion regarding contributions in relation to achieving
> privileges can be summed up to:
>
> 1. All contributions are equal;
> 2. Contributions buys privileges
>
> See slides 27 & 28 of this
> http://www.slideshare.net/gagravarr/the-apache-way-apachecon-2014, or
> here
> http://events.linuxfoundation.org/sites/events/files/slides/TheApacheWay14.pdf
>
> The process regarding improvements and/or new features in relation to JIRA
> can be straight forward:
>
> 1. any contributor wishing to have a improvement or new feature in
> should create a JIRA issue to be the starting point and tracking means and
> supply some context;
> 2. any other interested contributor can, via comments to the issue,
> ask for elaboration on the subject or provide insights
> 3. If the context, risks and dependencies are clear and acceptable a
> patch can be uploaded for review
> 4. If the patch can be reviewed and doesn't trigger any bugs than a
> discusion can be started in the dev mailing list to build consensus whether
> or not to incorporate it in trunk
> 5. if there is consensus regarding incorporation, then any committer
> can commit it to trunk
>
> This is called the Review-Then-Commit process, RTC for short.
>
> Best regards,
>
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Jul 7, 2015 at 11:45 PM, Suresh Subbiah <
> suresh.subbiah60@gmail.com> wrote:
>
>> Hi All,
>>
>> This message is to revive a thread started by Steve and Alice on project
>> merge criteria.
>>
>> Please add your input here, there have been excellent suggestions by
>> Pierre/others on how JIRA can be used and when in the dev cycle reviews
>> should be done.
>>
>> I would personally prefer a model where a committer did not have special
>> authority on vetoing changes but instead helps choose subject area experts
>> for review. The opinions of those reviewers are then binding. Once
>> sufficient information has been collected in an email thread I can collate
>> it into a proposal we can DISCUSS/VOTE.
>>
>> Thanks
>> Suresh
>>
>>
>> I think the existing tests are sufficient for fixing the current bugs.
>> My question is what
>> about new features? The current tests do not cover those.
>> Personally, I think new tests
>> (or instructions on how to verify the feature) should accompany new
>> features even if the new
>> tests are not fully automated yet. Otherwise how are we supposed to
>> verify these new features?
>>
>> Cheers,
>> Alice
>>
>>
>> -----Original Message-----
>> From: Varnau, Steve (Trafodion)
>> Sent: Thursday, June 18, 2015 1:50 PM
>> To: dev@trafodion.incubator.apache.org
>> Subject: Project merge criteria
>>
>> While we're waiting for the software grant process, perhaps the
>> committers should discuss
>> the criteria for accepting and merging in code
>> changes.
>> https://wiki.trafodion.org/wiki/index.php/Committer_Workflow#Ensure_Criteria_are_Met
>>
>> I've set up automated testing to run the same test suites as we ran
>> before for core changes
>> in the zuul "check". (There is no automated "gate" test.) Assuming
>> that is the same, then
>> the other non-test criteria are open for discussion I think.
>>
>> -Steve
>>
>
>
Re: Project Merge criteria
Posted by Pierre Smits <pi...@gmail.com>.
The generic ASF assertion regarding contributions in relation to achieving
privileges can be summed up to:
1. All contributions are equal;
2. Contributions buys privileges
See slides 27 & 28 of this
http://www.slideshare.net/gagravarr/the-apache-way-apachecon-2014, or here
http://events.linuxfoundation.org/sites/events/files/slides/TheApacheWay14.pdf
The process regarding improvements and/or new features in relation to JIRA
can be straight forward:
1. any contributor wishing to have a improvement or new feature in
should create a JIRA issue to be the starting point and tracking means and
supply some context;
2. any other interested contributor can, via comments to the issue, ask
for elaboration on the subject or provide insights
3. If the context, risks and dependencies are clear and acceptable a
patch can be uploaded for review
4. If the patch can be reviewed and doesn't trigger any bugs than a
discusion can be started in the dev mailing list to build consensus whether
or not to incorporate it in trunk
5. if there is consensus regarding incorporation, then any committer can
commit it to trunk
This is called the Review-Then-Commit process, RTC for short.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Jul 7, 2015 at 11:45 PM, Suresh Subbiah <su...@gmail.com>
wrote:
> Hi All,
>
> This message is to revive a thread started by Steve and Alice on project
> merge criteria.
>
> Please add your input here, there have been excellent suggestions by
> Pierre/others on how JIRA can be used and when in the dev cycle reviews
> should be done.
>
> I would personally prefer a model where a committer did not have special
> authority on vetoing changes but instead helps choose subject area experts
> for review. The opinions of those reviewers are then binding. Once
> sufficient information has been collected in an email thread I can collate
> it into a proposal we can DISCUSS/VOTE.
>
> Thanks
> Suresh
>
>
> I think the existing tests are sufficient for fixing the current bugs.
> My question is what
> about new features? The current tests do not cover those.
> Personally, I think new tests
> (or instructions on how to verify the feature) should accompany new
> features even if the new
> tests are not fully automated yet. Otherwise how are we supposed to
> verify these new features?
>
> Cheers,
> Alice
>
>
> -----Original Message-----
> From: Varnau, Steve (Trafodion)
> Sent: Thursday, June 18, 2015 1:50 PM
> To: dev@trafodion.incubator.apache.org
> Subject: Project merge criteria
>
> While we're waiting for the software grant process, perhaps the
> committers should discuss
> the criteria for accepting and merging in code
> changes.
> https://wiki.trafodion.org/wiki/index.php/Committer_Workflow#Ensure_Criteria_are_Met
>
> I've set up automated testing to run the same test suites as we ran
> before for core changes
> in the zuul "check". (There is no automated "gate" test.) Assuming
> that is the same, then
> the other non-test criteria are open for discussion I think.
>
> -Steve
>
Re: Project Merge criteria
Posted by Andrew Purtell <ap...@apache.org>.
> I would personally prefer a model where a committer did not have special
> authority on vetoing changes but instead helps choose subject area experts
> for review.
All committers on an Apache project will have equal* status on the project
as far as voting authority and applying commits to the source code
repository. On complex projects, you will find that committers will
naturally self-specialize. If you do not trust someone to be responsible
enough to do that sufficiently, they probably shouldn't be nominated for
committership.
* - Well... Hadoop has a notion of "branch committers", where they give
commit karma for only specific branches, and those permissions are not the
same as committership on the project. This is something you can ignore at
this stage. Hadoop is a big complex project that evolved into needing that
complication. Should Trafodion graduate from incubation and become super
successful, you might look at Hadoop or other 'prior art' here for managing
that success, at that time.
On Tue, Jul 7, 2015 at 2:45 PM, Suresh Subbiah <su...@gmail.com>
wrote:
> Hi All,
>
> This message is to revive a thread started by Steve and Alice on project
> merge criteria.
>
> Please add your input here, there have been excellent suggestions by
> Pierre/others on how JIRA can be used and when in the dev cycle reviews
> should be done.
>
> I would personally prefer a model where a committer did not have special
> authority on vetoing changes but instead helps choose subject area experts
> for review. The opinions of those reviewers are then binding. Once
> sufficient information has been collected in an email thread I can collate
> it into a proposal we can DISCUSS/VOTE.
>
> Thanks
> Suresh
>
>
> I think the existing tests are sufficient for fixing the current bugs.
> My question is what
> about new features? The current tests do not cover those.
> Personally, I think new tests
> (or instructions on how to verify the feature) should accompany new
> features even if the new
> tests are not fully automated yet. Otherwise how are we supposed to
> verify these new features?
>
> Cheers,
> Alice
>
>
> -----Original Message-----
> From: Varnau, Steve (Trafodion)
> Sent: Thursday, June 18, 2015 1:50 PM
> To: dev@trafodion.incubator.apache.org
> Subject: Project merge criteria
>
> While we're waiting for the software grant process, perhaps the
> committers should discuss
> the criteria for accepting and merging in code
> changes.
> https://wiki.trafodion.org/wiki/index.php/Committer_Workflow#Ensure_Criteria_are_Met
>
> I've set up automated testing to run the same test suites as we ran
> before for core changes
> in the zuul "check". (There is no automated "gate" test.) Assuming
> that is the same, then
> the other non-test criteria are open for discussion I think.
>
> -Steve
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Project Merge criteria
Posted by Hans Zeller <ha...@esgyn.com>.
Hi Suresh,
IMHO we need to add more committers, so that the group of committers has
the needed expertise and we don't overload the existing ones. If someone's
expertise is needed enough times for review, then in a meritocracy that
means that the person should be made a committer. I think it will be good
for Trafodion if people want to be committers and if the community feels
that committers are chosen based on their level of contribution.
Also, there is probably not a good way to get around some special authority
for committers. Even in your proposal, the committers' authority to choose
subject area experts is special. So, I do think that the committers should
have veto authority, within reason, like they do in other Apache projects.
I don't remember any abuses of that power in Trafodion.
My intent is to propose a model that's somewhat similar to what we see in
HBase.
Thanks,
Hans
Hans
On Tue, Jul 7, 2015 at 2:45 PM, Suresh Subbiah <su...@gmail.com>
wrote:
> Hi All,
>
> This message is to revive a thread started by Steve and Alice on project
> merge criteria.
>
> Please add your input here, there have been excellent suggestions by
> Pierre/others on how JIRA can be used and when in the dev cycle reviews
> should be done.
>
> I would personally prefer a model where a committer did not have special
> authority on vetoing changes but instead helps choose subject area experts
> for review. The opinions of those reviewers are then binding. Once
> sufficient information has been collected in an email thread I can collate
> it into a proposal we can DISCUSS/VOTE.
>
> Thanks
> Suresh
>
>
> I think the existing tests are sufficient for fixing the current bugs.
> My question is what
> about new features? The current tests do not cover those.
> Personally, I think new tests
> (or instructions on how to verify the feature) should accompany new
> features even if the new
> tests are not fully automated yet. Otherwise how are we supposed to
> verify these new features?
>
> Cheers,
> Alice
>
>
> -----Original Message-----
> From: Varnau, Steve (Trafodion)
> Sent: Thursday, June 18, 2015 1:50 PM
> To: dev@trafodion.incubator.apache.org
> Subject: Project merge criteria
>
> While we're waiting for the software grant process, perhaps the
> committers should discuss
> the criteria for accepting and merging in code
> changes.
> https://wiki.trafodion.org/wiki/index.php/Committer_Workflow#Ensure_Criteria_are_Met
>
> I've set up automated testing to run the same test suites as we ran
> before for core changes
> in the zuul "check". (There is no automated "gate" test.) Assuming
> that is the same, then
> the other non-test criteria are open for discussion I think.
>
> -Steve
>