[openstack-dev] [security] [salt] Removal of Security and OpenStackSalt project teams from the Big Tent

Doug Hellmann doug at doughellmann.com
Wed Sep 21 17:26:15 UTC 2016


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-request at lists.openstack.org
> To:     openstack-dev at 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 at 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-request at lists.openstack.org
> 
> You can reach the person managing the list at
>                  openstack-dev-owner at 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.dulko at intel.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>                  <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [cinder][sahara] LVM vs BDD drivers
>                  performance tests results
> Message-ID: <ca9f10ad-51e4-274c-95bd-247719c89b48 at 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.thomas at gmail.com <mailto:duncan.thomas at gmail.com>> wrote:
> >
> >     On 20 September 2016 at 16:24, Nikita Konovalov
> >     <nkonovalov at mirantis.com <mailto:nkonovalov at 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-request at lists.openstack.org?subject:unsubscribe
> >     <
> http://OpenStack-dev-request@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.zhongjun2 at gmail.com>
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev]  [manila] Enable IPv6 in Manila Ocata
> Message-ID:
>  <CAAz2tN-hrs_3d0HvavVvU2epHS4CCH1pko88FX1EGgUh8H9DfQ at 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.afek at nokia.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>                  <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [vitrage] Barcelona design sessions
> Message-ID: <CAD9E9DC-E55D-4BCC-BC8E-1CACDFFA7E09 at 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.daly at intel.com>
> To: "openstack-dev at lists.openstack.org"
>                  <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev]  [Kuryr] Kuryr IPVlan Code PoC
> Message-ID:
>  <D2C06722FF4FE54C88729FC07A5DCD91B43469 at 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 <rsblendido at suse.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron] Adding ihrachys to the
>                  neutron-drivers team
> Message-ID: <0ffde713-a31d-9362-9b0d-9d88e78528fc at 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.haley at 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-request at 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-request at 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-request at 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 <skramaja at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>                  <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tripleo] Setting kernel args to
>                  overcloud nodes
> Message-ID:
>  <CAPtmiAeKd0yBgkaFS5oAyzp0KqD+O0x1HweF-SucZFSUm0_NSg at 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 <skramaja at 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 <gfidente at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>                  <openstack-dev at lists.openstack.org>, Emilien Macchi
>                  <emacchi at redhat.com>
> Subject: Re: [openstack-dev] [tripleo] [puppet] Preparing TripleO
>                  agenda for Barcelona - action needed
> Message-ID: <ea008395-f1d1-47ca-f7d5-321fa9f7d9f9 at 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 <thierry at openstack.org>
> To: OpenStack Development Mailing List
>                  <openstack-dev at 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-b2e019840579 at 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 <thingee at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>                  <openstack-dev at 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.GJ31426 at 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 <thierry at openstack.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [stackalytics] [deb] [packaging]
>                  OpenStack contribution stats skewed by deb-* projects
> Message-ID: <4d62157c-fb5f-5395-3515-e7e564ff66d2 at 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 <amrith at tesora.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
>                  <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [ptl] code churn and questionable changes
> Message-ID:
>  
> <CO2PR17MB0011672EBE3DD1B02AFF35ECA0F60 at 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
> >
> 



More information about the OpenStack-dev mailing list