On Thu, Sep 5, 2019 at 7:28 PM Brian C. Lane <bcl(a)redhat.com> wrote:
Today we created a new, permanent, location for 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
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
This seems a bit harsh. Even if all the other requirements are
satisfied? What about if there was no information about why it was
真実はいつも一つ！/ Always, there's only one truth!