I'm the new maintainer of pykickstart

[Brian C. Lane]

Today we created a new, permanent, location for pykickstart:

https://github.com/pykickstart/pykickstart/

And I've agreed to be the new maintainer. I've been involved with
Anaconda and pykickstart since I joined Red Hat in 2010 so this isn't a
new experience for me :)

My general philosophy for this is going to be "don't break it". I
consider pykickstart to be one of the best examples of how to write a
python library, especially one that has to support so many different
features and versions so I have no plans to make fundamental changes. I
consider it primarily to be in maintenance mode, driven by bugfixing and
requests from Anaconda.

Recently there have been some requests to add features to pyks for the
livecd-creator project that don't have (and never will) support in
Anaconda. I've been trying to come up with a way to make everyone happy
-- and haven't.

At the moment I think the best way to proceed is to require that new
features need to have patches, and be accepted by, Anaconda. Anything
else is just going to lead to a fractured user experience, confusing
documentation, difficult to debug problems, etc. Since Anaconda is the
primary user for pyks it makes practical sense to have the installer
team's input on new features.

I also will *not* be re-reviewing any old closed requests. If the
previous maintainers declined to add something I am not going to re-open
it.

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

[Neal Gompa]

On Thu, Sep 5, 2019 at 7:28 PM Brian C. Lane <bcl(a)redhat.com&gt; wrote:
>  Today we created a new, permanent, location for pykickstart:
>
>  https://github.com/pykickstart/pykickstart/
>
>  And I've agreed to be the new maintainer. I've been involved with
>  Anaconda and pykickstart since I joined Red Hat in 2010 so this isn't a
>  new experience for me :)
>
>  My general philosophy for this is going to be "don't break it". I
>  consider pykickstart to be one of the best examples of how to write a
>  python library, especially one that has to support so many different
>  features and versions so I have no plans to make fundamental changes. I
>  consider it primarily to be in maintenance mode, driven by bugfixing and
>  requests from Anaconda.
>
>  Recently there have been some requests to add features to pyks for the
>  livecd-creator project that don't have (and never will) support in
>  Anaconda. I've been trying to come up with a way to make everyone happy
>  -- and haven't.
>  
As livecd-tools maintainer/developer, I don't particularly want
grammar that doesn't work with Anaconda either. The whole *point* of
livecd-tools is to be able to work off an installation description to
produce media *without* requiring Anaconda. But I personally would not
want to forsake compatibility with Anaconda.

>  At the moment I think the best way to proceed is to require that new
>  features need to have patches, and be accepted by, Anaconda. Anything
>  else is just going to lead to a fractured user experience, confusing
>  documentation, difficult to debug problems, etc. Since Anaconda is the
>  primary user for pyks it makes practical sense to have the installer
>  team's input on new features.
>  
If you only care about Anaconda's requirements, why isn't this just
part of the rhinstaller group like the rest of the Anaconda-only
components?

>  I also will *not* be re-reviewing any old closed requests. If the
>  previous maintainers declined to add something I am not going to re-open
>  it.
>  
This seems a bit harsh. Even if all the other requirements are
satisfied? What about if there was no information about why it was
closed?



-- 
真実はいつも一つ！/ Always, there's only one truth!

Hi Brian,

Thanks for all your work and special thanks for making a stable place
for the pykickstart again.

Congratulations for getting this project under your umbrella. We will
try to help you with PR reviews and other project related stuff ;).
I'm looking forward for our cooperation!

Best Regards,
Jirka

On Thu, 2019-09-05 at 16:28 -0700, Brian C. Lane wrote:
>  Today we created a new, permanent, location for pykickstart:
>  
>  https://github.com/pykickstart/pykickstart/
>  
>  And I've agreed to be the new maintainer. I've been involved with
>  Anaconda and pykickstart since I joined Red Hat in 2010 so this isn't
>  a
>  new experience for me :)
>  
>  My general philosophy for this is going to be "don't break it". I
>  consider pykickstart to be one of the best examples of how to write a
>  python library, especially one that has to support so many different
>  features and versions so I have no plans to make fundamental changes.
>  I
>  consider it primarily to be in maintenance mode, driven by bugfixing
>  and
>  requests from Anaconda.
>  
>  Recently there have been some requests to add features to pyks for
>  the
>  livecd-creator project that don't have (and never will) support in
>  Anaconda. I've been trying to come up with a way to make everyone
>  happy
>  -- and haven't.
>  
>  At the moment I think the best way to proceed is to require that new
>  features need to have patches, and be accepted by, Anaconda. Anything
>  else is just going to lead to a fractured user experience, confusing
>  documentation, difficult to debug problems, etc. Since Anaconda is
>  the
>  primary user for pyks it makes practical sense to have the installer
>  team's input on new features.
>  
>  I also will *not* be re-reviewing any old closed requests. If the
>  previous maintainers declined to add something I am not going to re-
>  open
>  it.
>

[Brian C. Lane]

On Thu, Sep 05, 2019 at 07:42:03PM -0400, Neal Gompa wrote:
>  
>  If you only care about Anaconda's requirements, why isn't this just
>  part of the rhinstaller group like the rest of the Anaconda-only
>  components? 
It's impossible to do both. I *want* to encourage use by other projects,
but at the same time I have to make sure we don't break the anaconda use
case. It is now under its own org because the maintainers are no longer
working directly on the installer, so this seemed like the best
'neutral' place for it.

I *do* promise to try to give due consideration to features/etc. from
non-installer users of pyks, and given time may even work to help with
getting them into anaconda.


>  > I also will *not* be re-reviewing any old closed requests. If
> the
>  > previous maintainers declined to add something I am not going to re-open
>  > it.
>  >
>  
>  This seems a bit harsh. Even if all the other requirements are
>  satisfied? What about if there was no information about why it was
>  closed? 
Good point, if the PR has support in Anaconda then I'll take another
look at it. But closed PRs are closed, I'm not going to re-evaluate them
without a really good reason.

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart