[openstack-dev] [packaging-rpm] PTL candidacy

[Javier Pena]

Hello fellow packagers!

I would like to announce my candidacy to be the PTL for the Packaging Rpm
project during the Rocky development cycle.

During the last cycles, the project has become a great collaboration space for
people working on RPM packages for OpenStack products. We have a number of
great tools that help us in different areas, even beyond the boundaries of
RPM-based distributions [1], and a wide, up-to-date package set.

For the Rocky cycle, my focus would be on:

* Fixing 3rd party CI annoyances: we are often getting hit by known issues in
  the 3rd party CI systems. Let's try to work on those known issues and reduce
  their occurrence to a minimum, so we can spend more time on reviews and less
  time troubleshooting our CI.

* Work on getting the packages created by the project tested by some installer
  project. This would greatly help us in improving quality on those small
  details that only get caught during real life tests.

* Expanding OpenStack distribution usage of the artifacts generated by the
  Packaging Rpm project.

That, of course, would be in addition to our common goals: expanding our
contributor base, improving collaboration between RPM distributions, and
keeping a high quality set of packages.

Thanks for reading,
Javier

[1] - 
https://github.com/openstack/pymod2pkg/blob/master/pymod2pkg/__init__.py#L294-L316

__
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-dev] [Packaging Rpm] PTL candidacy

[Haïkel]

Fellow RPM packagers,

I announce my candidacy for PTL of the Packaging Rpm project.
During the Newton cycle, we reached the point where we provide enough
artefacts to build OpenStack clients usable on all supported platforms.

As a PTL, my primary focus would be on:
* 3rd party CI: increase coverage and stability so that we can promote
  existing CI to voting gates.  Next step would be allowing other
  projects to consume our packaging for their own CI (mostly installer
  ones)
* better tooling to generate more native packages, and reduce
  churn. Also adding python3 support.
* allowing people to deploy a minimal OpenStack from our
  packages. Rather than focusing on shoving as much services as
  possible, I'd like us to focus on curating a minimal but high
  quality set of packages to build upon it. After such milestone,
  adding more services will be much easier later.

Why? The goal is to produce a production-ready and curated set of
OpenStack packages for all supported RPM-based platforms (SUSE, RHEL,
etc.). Such deliverables could be used to seed downstream
distributions and encourage collaboration between them around
packaging. It would also help OpenStack installers CI to test against
fresh OpenStack packages.


Off course, I plan to continue supporting these ongoing efforts:
* extending our packages set
* extending our contributors pool (including core)
* last but not least, foster collaboration between downstream vendors.

Best regards,
H.

__
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-dev] [packaging-rpm] PTL candidacy for the Newton Cycle

[Dirk Müller]

Hi everyone,

I'd like to announce my candidacy for the RPM Packaging for OpenStack PTL. I
am putting up the candidacy because I would feel honored to continue doing the
PTL role, but I'm also fine with passing on the torch. At the end of the
day what matters is that the project becomes successful and relevant and
I'm happy to contribute my share to that.

During the Mitaka cycle I've been working closely with our small but motivated
contributor group to reach a critical mass of package spec files to self-sustain
the project. While we haven't reached the full goal the trend is up[1]
and I still
very much care about the idea and implementation. We're at least in a
state where the spec file templates are already in actual production use
by one of the vendors (SUSE), and both Red Hat and Mirantis are considering it.

We've reached a lot by diligently working through the various RPM packaging
vendors packaging requirements and abstracting them in a way that allows
them to feel "native" to the platform while still sharing the bulk of the
work on packaging openstack and I'd be happy to work on that further with
the help from the other contributors.

Obviously all that I did so far I would like to continue and make sure that
we build something that everyone can embrace.

For Newton I would like to focus on:

* Extend package spec template set to cover the bulk of packages that define
 an OpenStack distribution and are maintained in the OpenStack git/gerrit

* Foster collaboration with downstream packaging vendors (Mirantis/RDO/SUSE) to
 switch to the common packaging by working through barriers that prevent
 adoption and contributions.

* Work with downstream packaging vendors to contribute extra CI for
their platform,
 as currently only SUSE invested the effort in adding a check CI step.


Thanks,
Dirk

[1] = http://stackalytics.com/?module=rpm-packaging

__
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-dev] [Packaging-Rpm] PTL Candidacy

[Igor Yozhikov]

I would like to announce my candidacy for PTL in Packaging-Rpm

I’m working on creating, building, polishing and maintaining Linux packages
for OpenStack projects with  various dependencies for few years since
IceHouse launch. It allowed me to accumulate deep knowledge base about core
OpenStack functionality. My first project was Murano in the very early
state of development even before incubation. I successfully started to
maintain Murano project packages specifications for those period of time.


The main goal for the Packaging-Rpm project, as I see it, is to unify and
simplify approaches Linux package maintainers use in their work day by day.
It is very important that availability of publicly published and suitable
for different flavors of rpm based Linux distros package specifications
makes package building process untied with mainstream vendors.

I wish my experience as package maintainer could help developers all over
the world to make their work easier and more transparent with efficiency
pushed to higher level.

I’m very eager to make it happen and I’m going to dedicate a lot of my time
and efforts as Packaging-RPM’s PTL.


There are a few topics to concentrate on during Newton cycle for the
upstream rpm-packaging:

   1.

   Move forward to finish with already started initiative for initial
   filling of projects’ templates for a common OpenStack dependencies like
   oslo, python clients. This should create basis for further work and should
   unlock development of package specification templates for core OpenStack
   projects.
   2.

   Continue with development of automation tooling for packaging. Creation
   and publishing package specifications for renderspec, pymod2pkg and
   openstack-macros will makes maintenance easier for all who require to build
   and use these tools from packages.
   3. CI checks. At the present moment only SUSE was added it to the
   project. This is not enough because it covers cases only for one vendor.
   Adding more 3rd party CIs (Eg: Mirantis or Fedora/RDO) will improve tests
   and use-cases coverage.


Thanks,
Igor Yozhikov
Senior Deployment Engineer
at Mirantis 
skype: igor.yozhikov
cellular: +7 901 5331200
slack: iyozhikov
__
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