Excerpts from Travis Mcpeak's message of 2016-09-21 16:23:55 +0000: > Ouch. I'd be among the first to admit I don't keep up with dev ML > as I should. Missing the PTL elections is certainly embarrassing > for us and it shouldn't be the community's job to baby-sit us and > make sure we're meeting our OpenStack deadlines. > > That being said, relegating us to a working group seems like a > knee-jerk and drastic consequence to levy against a project as > vibrant as ours.
Why is being a working group seen as less desirable? In what way do you consider working groups "less"? > > In a previous response Rob has highlighted many of our recent > accomplishments, so I won't revisit that here. > > What I do want to mention is the work Rob himself has done to > coordinate and secure funding for our fifth consecutive mid-cycle > (and each prior to that). He has worked consistently to build support > for our initiatives, both within and outside of OpenStack. > > Since assuming the PTL role none of our active members have been > inclined to run against him. > > So yes, he's dropped the ball on reading the ML (I have too). If > allowed to keep our project status we'll ensure that these mistakes > don't happen in the future. > > Taking away our project status because "we act like a working group" > is an unfair categorization and, in my opinion, a severe reaction to a > relatively minor infraction. > > -Travis McPeak > > > > From: openstack-dev-requ...@lists.openstack.org > To: openstack-dev@lists.openstack.org > Date: 09/21/2016 05:04 AM > Subject: OpenStack-dev Digest, Vol 53, Issue 51 > > > > Send OpenStack-dev mailing list submissions to > openstack-dev@lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > or, via email, send a message with subject or body 'help' to > openstack-dev-requ...@lists.openstack.org > > You can reach the person managing the list at > openstack-dev-ow...@lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenStack-dev digest..." > > > Today's Topics: > > 1. Re: [cinder][sahara] LVM vs BDD drivers performance tests > results (Micha? Dulko) > 2. [manila] Enable IPv6 in Manila Ocata (jun zhong) > 3. [vitrage] Barcelona design sessions (Afek, Ifat (Nokia - IL)) > 4. [Kuryr] Kuryr IPVlan Code PoC (Daly, Louise M) > 5. Re: [Neutron] Adding ihrachys to the neutron-drivers team > (Rossella Sblendido) > 6. Re: [tripleo] Setting kernel args to overcloud nodes > (Saravanan KR) > 7. Re: [tripleo] [puppet] Preparing TripleO agenda for Barcelona > - action needed (Giulio Fidente) > 8. [security] [salt] Removal of Security and OpenStackSalt > project teams from the Big Tent (Thierry Carrez) > 9. Re: [tc]a chance to meet all TCs for Tricircle big-tent > application in Barcelona summit? (Mike Perez) > 10. Re: [stackalytics] [deb] [packaging] OpenStack contribution > stats skewed by deb-* projects (Thierry Carrez) > 11. [ptl] code churn and questionable changes (Amrith Kumar) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Sep 2016 09:57:43 +0200 > From: Micha? Dulko <michal.du...@intel.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers > performance tests results > Message-ID: <ca9f10ad-51e4-274c-95bd-247719c89...@intel.com> > Content-Type: text/plain; charset=UTF-8 > > On 09/20/2016 05:48 PM, John Griffith wrote: > > On Tue, Sep 20, 2016 at 9:06 AM, Duncan Thomas > > <duncan.tho...@gmail.com <mailto:duncan.tho...@gmail.com>> wrote: > > > > On 20 September 2016 at 16:24, Nikita Konovalov > > <nkonova...@mirantis.com <mailto:nkonova...@mirantis.com>> wrote: > > > > Hi, > > > > From Sahara (and Hadoop workload in general) use-case the > > reason we used BDD was a complete absence of any overhead on > > compute resources utilization. > > > > The results show that the LVM+Local target perform pretty > > close to BDD in synthetic tests. It's a good sign for LVM. It > > actually shows that most of the storage virtualization > > overhead is not caused by LVM partitions and drivers > > themselves but rather by the iSCSI daemons. > > > > So I would still like to have the ability to attach partitions > > locally bypassing the iSCSI to guarantee 2 things: > > * Make sure that lio processes do not compete for CPU and RAM > > with VMs running on the same host. > > * Make sure that CPU intensive VMs (or whatever else is > > running nearby) are not blocking the storage. > > > > > > So these are, unless we see the effects via benchmarks, completely > > meaningless requirements. Ivan's initial benchmarks suggest > > that LVM+LIO is pretty much close enough to BDD even with iSCSI > > involved. If you're aware of a case where it isn't, the first > > thing to do is to provide proof via a reproducible benchmark. > > Otherwise we are likely to proceed, as John suggests, with the > > assumption that local target does not provide much benefit. > > > > I've a few benchmarks myself that I suspect will find areas where > > getting rid of iSCSI is benefit, however if you have any then you > > really need to step up and provide the evidence. Relying on vague > > claims of overhead is now proven to not be a good idea. > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > ?Honestly we can have both, I'll work up a bp to resurrect the idea of > > a "smart" scheduling feature that lets you request the volume be on > > the same node as the compute node and use it directly, and then if > > it's NOT it will attach a target and use it that way (in other words > > you run a stripped down c-vol service on each compute node). > > Don't we have at least scheduling problem solved [1] already? > > [1] > https://github.com/openstack/cinder/blob/master/cinder/scheduler/filters/instance_locality_filter.py > > > > > Sahara keeps insisting on being a snow-flake with Cinder volumes and > > the block driver, it's really not necessary. I think we can > > compromise just a little both ways, give you standard Cinder semantics > > for volumes, but allow you direct acccess to them if/when requested, > > but have those be flexible enough that targets *can* be attached so > > they meet all of the required functionality and API implementations. > > This also means that we don't have to continue having a *special* > > driver in Cinder that frankly only works for one specific use case and > > deployment. > > > > I've pointed to this a number of times but it never seems to > > resonate... but I never learn so I'll try it once again [1]. Note > > that was before the name "brick" was hijacked and now means something > > completely different. > > > > [1]: https://wiki.openstack.org/wiki/CinderBrick > > > > Thanks, > > John? > > > > > ------------------------------ > > Message: 2 > Date: Wed, 21 Sep 2016 16:05:08 +0800 > From: jun zhong <jun.zhongj...@gmail.com> > To: openstack-dev <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [manila] Enable IPv6 in Manila Ocata > Message-ID: > <caaz2tn-hrs_3d0hvavvvu2ephs4cch1pko88fx1egguh8h9...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > As agreed by the manila community in IRC meeting, > we try to enable IPv6 in Ocata. Please check the brief spec[1] and > code[2]). > > The areas affected most are API (access rules) and in the drivers (access > rules > & export locations). This change intends to add the IPv6 format validation > for > ip access rule type in allow_access API, allowing manila to support IPv6 > ACL. > > Hi all of the driver maintainers, could you test the IPv6 feature code[2] > to make sure whether your driver can completely support IPv6. > If there still have something else might not be IPv6-ready, please let me > known. Thanks > [1] https://review.openstack.org/#/c/362786/ > [2] https://review.openstack.org/#/c/312321/ > > > Thanks, > Jun > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/880e28e8/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 21 Sep 2016 08:38:53 +0000 > From: "Afek, Ifat (Nokia - IL)" <ifat.a...@nokia.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [vitrage] Barcelona design sessions > Message-ID: <cad9e9dc-e55d-4bcc-bc8e-1cacdffa7...@alcatel-lucent.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > As discussed in our IRC meeting today, you are welcome to suggest topics > for vitrage design sessions in Barcelona: > https://etherpad.openstack.org/p/vitrage-barcelona-design-sessions > > Thanks, > Ifat. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/3b999def/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Wed, 21 Sep 2016 09:53:06 +0000 > From: "Daly, Louise M" <louise.m.d...@intel.com> > To: "openstack-dev@lists.openstack.org" > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [Kuryr] Kuryr IPVlan Code PoC > Message-ID: > <d2c06722ff4fe54c88729fc07a5dcd91b43...@irsmsx101.ger.corp.intel.com> > Content-Type: text/plain; charset="us-ascii" > > Hi everyone, > > As promised here is a link to the code PoC for the Kuryr-IPVlan proposal. > https://github.com/lmdaly/kuryr-libnetwork > > Link to specific commit > https://github.com/lmdaly/kuryr-libnetwork/commit/1dc895a6d8bfaa03c0dd5cfb2d3e23e2e948a67c > > >From here you can clone the repo and install Kuryr as you normally would > with a few additional steps: > > 1. The IPVlan driver must be installed on the VM/Machine that the PoC will > be run on. Fedora-Server(not the cloud image) includes the driver by > default but the likes of the cloud image must be modified to include the > driver. > 2. You must install Docker experimental. > 3. You must use the Kuryr IPAM driver for address management. > 4. In order to enable the IPVlan mode you must change the ipvlan option in > the kuryr.conf file from false to true. > 5. You must also change the ifname option to match the interface of the > private network you wish to run the containers on. (Default is ens3) > 6. As listed in the limitations on the README.rst on kuryr "To create > Docker networks with subnets having same/overlapping cidr, it is expected > to pass unique pool name for each such network creation Docker command." > You will need to do this if you are creating a docker network with the > same private network on another VM. > > The IPVlan proposal was sent out to the mailing list - link for those who > missed it. > http://osdir.com/ml/openstack-dev/2016-09/msg00816.html > > Please send any feedback, issues, comments, bugs. > > Thanks, > Louise > > > -------------------------------------------------------------- > Intel Research and Development Ireland Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > > > This e-mail and any attachments may contain confidential material for the > sole > use of the intended recipient(s). Any review or distribution by others is > strictly prohibited. If you are not the intended recipient, please contact > the > sender and delete all copies. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/e8c695c3/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Wed, 21 Sep 2016 12:00:38 +0200 > From: Rossella Sblendido <rsblend...@suse.com> > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to the > neutron-drivers team > Message-ID: <0ffde713-a31d-9362-9b0d-9d88e7852...@suse.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Congratulations Ihar! You really deserved this, I am sure you'll do great. > > Rossella > > On 09/20/2016 10:57 AM, Miguel Angel Ajo Pelayo wrote: > > Congratulations Ihar!, well deserved through hard work! :) > > > > On Mon, Sep 19, 2016 at 8:03 PM, Brian Haley <brian.ha...@hpe.com> > wrote: > >> Congrats Ihar! > >> > >> -Brian > >> > >> > >> On 09/17/2016 12:40 PM, Armando M. wrote: > >>> > >>> Hi folks, > >>> > >>> I would like to propose Ihar to become a member of the Neutron drivers > >>> team [1]. > >>> > >>> Ihar wide knowledge of the Neutron codebase, and his longstanding > duties > >>> as > >>> stable core, downstream package whisperer, release and oslo liaison (I > am > >>> sure I > >>> am forgetting some other capacity he is in) is going to put him at > great > >>> comfort > >>> in the newly appointed role, and help him grow and become wise even > >>> further. > >>> > >>> Even though we have not been meeting regularly lately we will resume > our > >>> Thursday meetings soon [2], and having Ihar onboard by then will be > highly > >>> beneficial. > >>> > >>> Please, join me in welcome Ihar to the team. > >>> > >>> Cheers, > >>> Armando > >>> > >>> [1] > >>> > http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team > > >>> > >>> < > http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team > > > >>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers > >>> <https://wiki.openstack.org/wiki/Meetings/NeutronDrivers> > >>> > >>> > >>> > __________________________________________________________________________ > >>> 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 > > > > > > > > ------------------------------ > > Message: 6 > Date: Wed, 21 Sep 2016 15:43:24 +0530 > From: Saravanan KR <skram...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [tripleo] Setting kernel args to > overcloud nodes > Message-ID: > <captmiaekd0ybgkafs5oayzp0kqd+o0x1hwef-suczfsum0_...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I have been working on the user-data scripts (first-boot) for updating > the kernel args on the overcloud node [1]. The pre-condition is that > the kernel args has to be applied and node has to be restarted before > os-net-config runs. > > I got in to problem of provisioning network not getting ip after the > reboot in the user-data script. While investigating, figured out that > network.service starts the nodes on the alpha-numeric order, on which > the first nic is not the one used for provisioning. network.service > initiates a DHCP DISCOVER on it, when it times out, network.service > goes to failed state and all other interfaces are DOWN state. If i > manually bring the interface up (via ipmi console), then all proceeds > fine without any issue. > > To overcome this issue, I have written a small script to find out the > provisioning network via metadata (metadata has the mac address of the > provisioning network) and make BOOTPROTO=none on all other interface's > ifcfg files except the provisioning network. There still an issue of > IP not ready at the time of querying metadata, temporarily added a > sleep which solves it. The user-data script [1] has all these fixes > and tested on an baremetal overcloud node. > > If anyone has a better way of doing it, you are more than welcome to > suggest. > > Regards, > Saravanan KR > > [1] https://gist.github.com/krsacme/1234bf024ac917c74913827298840c1c > > On Wed, Jul 27, 2016 at 6:52 PM, Saravanan KR <skram...@redhat.com> wrote: > > Hello, > > > > We are working on SR-IOV & DPDK tripleo integration. In which, setting > > the kernel args for huge pages, iommu and cpu isolation is required. > > Earlier we were working on setting of kernel args via IPA [1], reasons > > being: > > 1. IPA is installing the boot loader on the overcloud node > > 2. Ironic knows the hardware spec, using which, we can target specific > > args to nodes via introspection rules > > > > As the proposal is to change the image owned file '/etc/default/grub', > > it has been suggested by ironic team to use the instance user data to > > set the kernel args [2][3], instead of IPA. In the suggested approach, > > we are planning to update the file /etc/default/grub, update > > /etc/grub2.cfg and then issue a reboot. Reboot is mandatory because, > > os-net-config will configure the DPDK bridges and ports by binding the > > DPDK driver, which requires kernel args should be set for iommu and > > huge pages. > > > > As discussed on the IRC tripleo meeting, we need to ensure that the > > user data with update of kernel args, does not overlap with any other > > puppet configurations. Please let us know if you have any comments on > > this approach. > > > > Regards, > > Saravanan KR > > > > [1] https://review.openstack.org/#/c/331564/ > > [2] > http://docs.openstack.org/developer/ironic/deploy/install-guide.html#appending-kernel-parameters-to-boot-instances > > > [3] > http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/extra_config.html#firstboot-extra-configuration > > > > > ------------------------------ > > Message: 7 > Date: Wed, 21 Sep 2016 12:49:58 +0200 > From: Giulio Fidente <gfide...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org>, Emilien Macchi > <emac...@redhat.com> > Subject: Re: [openstack-dev] [tripleo] [puppet] Preparing TripleO > agenda for Barcelona - action needed > Message-ID: <ea008395-f1d1-47ca-f7d5-321fa9f7d...@redhat.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 09/19/2016 10:49 PM, Emilien Macchi wrote: > > (adding puppet tag for cross project session). > > > > Let's continue to prepare TripleO sessions. > > > > https://etherpad.openstack.org/p/ocata-tripleo > > > > For reminder, we have 2 fishbowls and 4 working rooms. > > I looked at the topic proposals and I started to organize some sessions. > > > > Some actions from you are required: > > - review the session proposal > > - if you want to drive a session, please put your name in "Chair". > > - for each session we need to choose if we want it to be a work room > > or a fishbowl session. > > - 4 topics are still there, please propose a session (concatenate them > > if possible) > > - if you missed this etherpad until now, feel free to propose a > > session with your topic (ex: TripleO UI - roadmap, etc). > > > > At least but not least, I would propose a cross project session with > > Puppet OpenStack group (using a slot from their schedule) so we might > > have a 7th session. > > the cross project session with the puppet group is a nice idea indeed, > thanks Emilien > > in that context it would be nice to gather some ideas/feedback on the > status of openstack integration scenarios vs tripleo scenarios and see > if we can optimize resources and/or coverage > -- > Giulio Fidente > GPG KEY: 08D733BA | IRC: gfidente > > > > ------------------------------ > > Message: 8 > Date: Wed, 21 Sep 2016 13:23:32 +0200 > From: Thierry Carrez <thie...@openstack.org> > To: OpenStack Development Mailing List > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [security] [salt] Removal of Security and > OpenStackSalt project teams from the Big Tent > Message-ID: <c7e735c1-bfbf-cfca-c972-b2e019840...@openstack.org> > Content-Type: text/plain; charset=utf-8 > > Hi everyone, > > As announced previously[1][2], there were no PTL candidates within the > election deadline for a number of official OpenStack project teams: > Astara, UX, OpenStackSalt and Security. > > In the Astara case, the current team working on it would like to abandon > the project (and let it be available for any new team who wishes to take > it away). A change should be proposed really soon now to go in that > direction. > > In the UX case, the current PTL (Piet Kruithof) very quickly reacted, > explained his error and asked to be considered for the position for > Ocata. The TC will officialize his nomination at the next meeting, > together with the newly elected PTLs. > > That leaves us with OpenStackSalt and Security, where nobody reacted to > the announcement that we are missing PTL candidates. That points to a > real disconnect between those teams and the rest of the community. Even > if you didn't have the election schedule in mind, it was pretty hard to > miss all the PTL nominations in the email last week. > > The majority of TC members present at the meeting yesterday suggested > that those project teams should be removed from the Big Tent, with their > design summit space allocation slightly reduced to match that (and make > room for other not-yet-official teams). > > In the case of OpenStackSalt, it's a relatively new addition, and if > they get their act together they could probably be re-proposed in the > future. In the case of Security, it points to a more significant > disconnect (since it's not the first time the PTL misses the nomination > call). We definitely still need to care about Security (and we also need > a home for the Vulnerability Management team), but I think the "Security > team" acts more like a workgroup than as an official project team, as > evidenced by the fact that nobody in that team reacted to the lack of > PTL nomination, or the announcement that the team missed the bus. > > The suggested way forward there would be to remove the "Security project > team", have the Vulnerability Management Team file to be its own > official project team (in the same vein as the stable maintenance team), > and have Security be just a workgroup rather than a project team. > > Thoughts, comments ? > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2016-September/103904.html > > [2] > http://lists.openstack.org/pipermail/openstack-dev/2016-September/103939.html > > > -- > Thierry Carrez (ttx) > > > > ------------------------------ > > Message: 9 > Date: Wed, 21 Sep 2016 04:32:57 -0700 > From: Mike Perez <thin...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [tc]a chance to meet all TCs for > Tricircle big-tent application in Barcelona summit? > Message-ID: <20160921113257.gj31...@gmail.com> > Content-Type: text/plain; charset=us-ascii > > On 00:48 Sep 21, joehuang wrote: > > Thank you for the message. Will the weekly IRC meeting in that week also > be cancelled during > > the summit period according to your experience? > > Likely yes. > > -- > Mike Perez > > > > ------------------------------ > > Message: 10 > Date: Wed, 21 Sep 2016 13:37:18 +0200 > From: Thierry Carrez <thie...@openstack.org> > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [stackalytics] [deb] [packaging] > OpenStack contribution stats skewed by deb-* projects > Message-ID: <4d62157c-fb5f-5395-3515-e7e564ff6...@openstack.org> > Content-Type: text/plain; charset=windows-1252 > > Ilya Shakhat wrote: > > Hi, > > > > tldr; Commits stats are significantly skewed by deb-* projects > > (http://stackalytics.com/?metric=commits&module=packaging-deb-group) > > > > By default Stackalytics processes commits from project's master branch. > > For some "old core" projects there is configuration to process stable > > branches as well. If some commit is cherry-picked from master to stable > > it is counted twice in both branches / releases. The configuration for > > stable branch is simple - branch starting with branching point (e.g. > > stable/newton that starts with rc1) > > > > In deb-* projects master branch corresponds to upstream Debian > > community. All OpenStack-related contribution goes into debian/<release> > > branch. But unlike in the rest of OpenStack, git workflow differs and > > the branch contains merge commits from master. This makes filtering > > "pure" branch commits from those that came from master quite tricky (not > > possible to specify the branch-point). And support of this will require > > changes in Stackalytics code. > > > > Since currently we are at the time when people may get nervous about > > numbers, I'd suggest to temporary hide all commits from deb-* projects > > and revise stats processing in a month. > > Sounds good. Are you working on it ? > > > -- > Thierry Carrez (ttx) > > > > ------------------------------ > > Message: 11 > Date: Wed, 21 Sep 2016 11:56:06 +0000 > From: Amrith Kumar <amr...@tesora.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [ptl] code churn and questionable changes > Message-ID: > > <co2pr17mb0011672ebe3dd1b02aff35eca0...@co2pr17mb0011.namprd17.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > Of late I've been seeing a lot of rather questionable changes that appear > to be getting blasted out across multiple projects; changes that cause > considerable code churn, and don't (IMHO) materially improve the quality > of OpenStack. > > I'd love to provide a list of the changes that triggered this email but I > know that this will result in a rat hole where we end up discussing the > merits of the individual items on the list and lose sight of the bigger > picture. That won't help address the question I have below in any way, so > I'm at a disadvantage of having to describe my issue in abstract terms. > > > > Here's how I characterize these changes (changes that meet one or more of > these criteria): > > > > - Contains little of no information in the commit message (often just a > single line) > > - Makes some generic statement like "Do X not Y", "Don't use Z", "Make > ABC better" with no further supporting information > > - Fail (literally) every single CI job, clearly never tested by the > developer > > - Gets blasted across many projects, literally tens with often the same > kind of questionable (often wrong) change > > - Makes a stylistic python improvement that is not enforced by any > check (causes a cottage industry of changes making the same correction > every couple of months) > > - Reverses some previous python stylistic improvement with no clear > reason (another cottage industry) > > > > I've tried to explain it to myself as enthusiasm, and a desire to > contribute aggressively; I've lapsed into cynicism at times and tried to > explain it as gaming the numbers system, but all that is merely > rationalization and doesn't help. > > > > Over time, the result generally is that these developers' changes get > ignored. And that's not a good thing for the community as a whole. We want > to be a welcoming community and one which values all contributions so I'm > looking for some suggestions and guidance on how one can work with > contributors to try and improve the quality of these changes, and help the > contributor feel that their changes are valued by the project? Other more > experienced PTL's, ex-PTL's, long time open-source-community folks, I'm > seriously looking for suggestions and ideas. > > > > Any and all input is welcome, do other projects see this, how do you > handle it, is this normal, ... > > > > Thanks! > > > > -amrith > > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.openstack.org/pipermail/openstack-dev/attachments/20160921/c3bc37fe/attachment-0001.html > > > __________________________________________________________________________ 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
