On Tue, Feb 7, 2017 at 7:34 AM, Andrea Frittoli <andrea.fritt...@gmail.com> wrote:
> > On Tue, Feb 7, 2017 at 1:55 AM Ghanshyam Mann <ghanshyamm...@gmail.com> > wrote: > >> Hi Jordan, >> >> Thanks for bring it up. I know we had both side of argument on those >> changes. >> >> IMO in general, its all QA team responsibility to verify the requirement >> very strictly and make sure no changes break existing released version and >> so users. Many times QA team does not agree to development team :). >> >> But as we are working as community and one of our key goal is to smooth >> development also. But as of now, strong rejection or formal approval from >> QA team is something missing in formal guidelines or formal written. >> >> We have api-wg and its guidelines which are a great things in OpenStack >> and helped a lot to improve the APIs. But those are just guidelines and no >> hard restriction. >> >> Many of us can say if we are changing the APIs in backward incompatible >> way, then api-wg and QA agreements are great to consider and then only >> proceed but many of us can say if project team want then even disagreement >> from QA or api-wg does not matter much. >> >> As we do not have any official statement anywhere about mandatory >> agreement of QA team, i do not think we can stop any projects for such >> changes but we can always put our strong opinion and try to make project >> team understand that how harmful that changes can be. >> >> To make it in more smooth way in future, there is proposal in TC for new >> tag "supports-api-compatibility" [1] (thanks matt for that) and cdent is >> refactoring the api-wg guidelines accordingly [2]. >> >> This is really nice direction and if any projects adopt to have that new >> tag, then they have to honor the API compatibility and honor the api-wg, QA >> and TC decision. >> > > +1. > I think the discussion around the referenced API changes has been quite > positive, it has lead to a review of api-wg guidelines as well as the > proposal for a new tag. > As a QA team we have the responsibility - at least for the projects whose > tests are hosted in Tempest - to identity changes that may break API > compatibility and trigger such discussions in the community and help > building consensus. Ideally in future the process will be much smoother as > we keep improving guidelines and processes around API stability. > Changes that break APIs stability are not uncommon, in keystone, for example, we already had to deal with some of them. Hopefully, we are creating a culture where tempest-like tests are being more present and with this, we can quickly spot such kind of changes. > > >> >> My opinion on that to have a clear responsibility of QA, api-wg to make >> projects considering new tag strictly honor the compatibility guidelines. >> So that we as QA team have formal rights to stop any incompatible changes. >> >> > >> I personally feel we have to have a very clear responsibility of QA team >> over API incompatible changes which will be helped by TC and all of us to >> have consensus on that and keep/make OpenStack APIs as one of the best APIs >> for users. >> >> ..1 https://review.openstack.org/#/c/418010/3 >> ..2 https://review.openstack.org/#/c/421846/ >> >> >> -gmann >> >> On Mon, Feb 6, 2017 at 8:14 PM, Jordan Pittier < >> jordan.pitt...@scality.com> wrote: >> >> Hi gmann, >> Thanks for your candidacy. Let me ask one question if it's not too >> late. What's the role of the QA team when it comes to API change ? I >> have in mind the recent Glance change related to private vs shared >> image status. >> >> Someone in our community asked : >> * "I need to get an official decision from the QA team on whether >> [such a] patch is acceptable or not" >> * "what's needed is an "official" response from the QA team concerning >> the acceptability of the patch" >> >> But we didn't provide such an answer. There could be a feeling that >> the QA team is acting as a self-appointed activist judiciary. >> >> Now we have another occurrence of a disagreement between the QA team >> and a project team: https://bugs.launchpad.net/glance/+bug/1656183, >> https://review.openstack.org/#/c/420038/, >> https://review.openstack.org/#/c/425487/ >> >> I have myself no strong opinion on the matter, that why I need a leader >> here :) >> >> Note, there *is* a question in this email :D >> >> Jordan >> >> On Thu, Jan 19, 2017 at 12:05 PM, Ghanshyam Mann >> <ghanshyam.m...@nectechnologies.in> wrote: >> > Hi All, >> > >> > >> > >> > First and foremost would like to wish you all a successful 2017 ahead >> and >> > with this I'm announcing my PTL candidacy of the Quality Assurance team >> for >> > the Pike release cycle. >> > >> > >> > >> > I am glad to work in OpenStack community and would like to thank all the >> > contributors who supported me to explore new things which brings out my >> best >> > for the community. >> > >> > >> > >> > Let me introduce myself, briefly. I have joined the OpenStack community >> > development in 2014 during mid of Ice-House release. Currently, I'm >> > contributing in QA projects and Nova as well as a core member in >> Tempest. >> > Since Barcelona Summit, I volunteered as mentor in the upstream >> training. >> > It‘s always a great experience to introduce OpenStack upstream workflow >> to >> > new contributors and encourage them. >> > >> > >> > >> > Following are my contribution activities: >> > >> > * Review: >> > http://stackalytics.com/?release=all&metric=marks&user_id=ghanshyammann >> > >> > * Commit: >> > http://stackalytics.com/?release=all&metric=commits& >> user_id=ghanshyammann >> > >> > >> > >> > I have worked on some key areas on QA like Interfaces migration to lib, >> JSON >> > schema response validation(for compute), API Microversion testing >> framework >> > in Tempest, Improve test coverage and Bug Triage etc. >> > >> > >> > >> > QA program has been immensely improved since it was introduced which >> > increased upstream development quality as well as helping production >> Cloud >> > for their testing and stability. We have a lot of ideas from many >> different >> > contributors to keep improving the QA which is phenomenal and I truly >> > appreciate. >> > >> > >> > >> > Moving forwards, following are my focus areas for Pike Cycle: >> > >> > >> > >> > * Help the other Projects' developments and Plugin Improvement: >> > >> > OpenStack projects consider the quality is important and QA team needs >> to >> > provide useful testing framework for them. Projects who all needs to >> > implement their tempest tests in plugin, focus will be to help plugin >> tests >> > improvement and so projects quality. Lot of Tempest interfaces are >> moving >> > towards stable interfaces, existing plugin tests needs to be fixed >> multiple >> > times. We are taking care of those and helping them to migrate >> smoothly. But >> > there are still many interfaces going to migrate to lib and further to >> be >> > adopted on plugin side. I’d like to have some mechanism/automation to >> > trigger plugins to know about change interfaces before it breaks them. >> Also >> > help them to use the framework correctly. This helps the other non-core >> > projects’ tests. >> > >> > >> > >> > * Improve QA projects for Production Cloud: >> > >> > This will be the main focus area. Having QA projects more useful for >> > Production Cloud testing is/will be great achievement for QA team. This >> area >> > has been improved a lot since last couple of cycles and still a lot to >> do. >> > We have to improve Production scenario testing coverage and make all QA >> > projects easy to configure and use. During Barcelona summit, 2 new >> projects >> > are initiated which will definitely help to achieve this goal. >> > >> > * RBAC Policy - https://github.com/openstack/patrole >> > >> > * HA testing - https://review.openstack.org/#/c/374667/ >> > >> > https://review.openstack.org/#/c/399618/ >> > >> > * Hoping for more in future >> > >> > There will be more focus on those projects and new ideas which will help >> > production Cloud testing in more powerful way. >> > >> > >> > >> > * JSON Schema *response* validation for projects: >> > >> > JSON schema response validation for compute APIs has been very helpful >> to >> > keep the APIs quality and compatibility. Currently many projects support >> > microversion which provides a way to introduce the APIs changes in >> Backward >> > compatible way. I'd like to concentrate on response schema validation >> for >> > those projects also. This helps the OpenStack interoperability and the >> APIs >> > compatibility. >> > >> > >> > >> > * Improve Documentation and UX: >> > >> > Documentation and UX are the key part for any software. There have been >> huge >> > improvement in UX , documentation side and new Tempest workflow is >> > available. Still configuration and usage is the pain point for Users. >> > During summit/ptg or other platforms I’d like us to have more feedbacks >> from >> > users and improve accordingly. Making configuration easy for people is >> one >> > of the area we will be focusing on. >> > >> > >> > >> > * Bring on more contributor and core reviewers: >> > >> > QA projects have been one of the active projects during last couple of >> years >> > and I'd like the team to mentor new contributors to help QA projects in >> > planned goal and get them to a place where they will be ready for core >> > reviewers. >> > >> > >> > >> > * Migrate required Tempest Interfaces as stable to lib: >> > >> > We together have done great job in this area which helped plugin tests. >> In >> > Service clients migration, Object Storage service client are left and >> all >> > others have been moved as stable interfaces. Lot of others >> > framework/interface also available in lib. But still lot of unstable >> > interfaces are being used in Plugins which should be migrated to lib >> soon. >> > In Pike cycle, we will wind up all remaining service client migration >> and >> > other required interfaces. >> > >> > >> > >> > * Last but not the least, Openness is great power of Open Source and so >> does >> > OpenStack. All new ideas from anyone will be most welcome. >> > >> > >> > >> > Thanks to previous QA PTL, Sean, Matthew, Kenichi who have shown great >> > leadership quality and taken QA projects to a new height. I have learnt >> a >> > lot from them which motivates me. >> > >> > >> > >> > I look forward to contributing to all of these areas and more during the >> > Pike cycle. >> > >> > >> > >> > -gmann >> > >> > >> > >> > >> > ____________________________________________________________ >> ______________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> -- >> >> <http://go.scality.com/acton/media/18585/gartner-magic- >> quadrant-object-storage?utm_campaign=MQ&utm_medium=Email& >> utm_source=signatures> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Rodrigo Duarte Sousa Senior Quality Engineer @ Red Hat MSc in Computer Science http://rodrigods.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev