Details

    • Task
    • Status: Closed
    • Major
    • Resolution: Fixed
    • queryserver-6.0.0
    • queryserver-6.0.0
    • python, queryserver
    • None

    Description

      The original PhoenixDB driver was published to PyPI.

      The improved version in phoenix-queryserver is only available from there.

      We should start publishing the driver again.

      Some questions to answer:

      • Can we take over the old PyPI project ?
      • Do we want to ?
      • What should be the project/artifact name (if not the old one)
      • Version numbering ?
      • Do we want to publish development versions ?
      • What is the process / who should do the publishing ?
      • Any blockers before we start publishing ?

      Attachments

        Issue Links

          Activity

            stoty Istvan Toth added a comment -

            My opinion on some of the questions:

            • I think that we should try to take over the old project for minimum disruption for users
            • Sync releases to the queryserver versioning, and publish 1.0.0.devX versions for worthwhile changes. After 1.0.0 we can probably use a forth digit for intermediate releases, i.e 1.0.0.X
            • Blocker: We should get the the licensing stuff sorted at least for the python code 
            • Publishing should be done by whoever drives the python stuff (me for the time being)

            elserj ankit (and of course others) Do you have any insights ?

             

            stoty Istvan Toth added a comment - My opinion on some of the questions: I think that we should try to take over the old project for minimum disruption for users Sync releases to the queryserver versioning, and publish 1.0.0.devX versions for worthwhile changes. After 1.0.0 we can probably use a forth digit for intermediate releases, i.e 1.0.0.X Blocker: We should get the the licensing stuff sorted at least for the python code  Publishing should be done by whoever drives the python stuff (me for the time being) elserj ankit  (and of course others) Do you have any insights ?  
            elserj Josh Elser added a comment -

            I think that we should try to take over the old project for minimum disruption for users

            We can ask Lukas if he would be OK with us doing this. I would assume he would be supportive (as he's been supportive for everything else so far). If not, we'd need to make sure we point people to something we do control as a PMC.

            Do we want to [take over PyPi account]?

            We definitely need to have something here. I actually don't know what kind of infrastructure/automation we have at the ASF. I've asked around to see if I know anyone who knows more, but I'll also start digging through ASF docs. Hopefully we can find someone to give us Java-wizards some Python direction

            Sync releases to the queryserver versioning, and publish 1.0.0.devX versions for worthwhile changes. After 1.0.0 we can probably use a forth digit for intermediate releases, i.e 1.0.0.X

            I think we can use any versioning that we want. Since queryserver and client are decoupled in terms of builds, and Avatica tries to make strong backwards compatibility guarantees, we can generally tell folks to use the latest of each (avoiding the "are these two versions compatible")

            Blocker: We should get the the licensing stuff sorted at least for the python code 

            I should be able to help here.

            Publishing should be done by whoever drives the python stuff (me for the time being)

            Thanks for volunteering!

            elserj Josh Elser added a comment - I think that we should try to take over the old project for minimum disruption for users We can ask Lukas if he would be OK with us doing this. I would assume he would be supportive (as he's been supportive for everything else so far). If not, we'd need to make sure we point people to something we do control as a PMC. Do we want to [take over PyPi account] ? We definitely need to have something here. I actually don't know what kind of infrastructure/automation we have at the ASF. I've asked around to see if I know anyone who knows more, but I'll also start digging through ASF docs. Hopefully we can find someone to give us Java-wizards some Python direction Sync releases to the queryserver versioning, and publish  1.0.0.devX  versions for worthwhile changes. After  1.0.0  we can probably use a forth digit for intermediate releases, i.e  1.0.0.X I think we can use any versioning that we want. Since queryserver and client are decoupled in terms of builds, and Avatica tries to make strong backwards compatibility guarantees, we can generally tell folks to use the latest of each (avoiding the "are these two versions compatible") Blocker: We should get the the licensing stuff sorted at least for the python code  I should be able to help here. Publishing should be done by whoever drives the python stuff (me for the time being) Thanks for volunteering!
            ankit@apache.org Ankit Singhal added a comment -

            I think that we should try to take over the old project for minimum disruption for users

            Do we want to [take over PyPi account]?

            Yeah agreed with Josh, if an account in PyPi is the convenient way of distributing an Apache Phoenix python driver then Phoenix PMC should be able to control and manage it.

            It will be great if Lucas could give up his account( wouldn't be a problem considering how gracious he originally was with code donation) and let Phoenix PMC  manage it so that once PMC voted and release the artifacts, we can also share it through PyPi or stage dev builds.  But in case if we come to a point that we are not able to reach him, then how about going with the new account ApachePhoenixDB and update our documentation accordingly?

            Sync releases to the queryserver versioning, and publish 1.0.0.devX versions for worthwhile changes. After 1.0.0 we can probably use a forth digit for intermediate releases, i.e 1.0.0.X

            If we are thinking of one release per repository then I think we need to sync with the query server versions anyway, right?  And also how about following only semantic versioning(MAJOR.MINOR.PATCH) and using SNAPSHOT for staged version as we follow for other Phoenix releases to avoid confusion in understandability?

            Blocker: We should get the the licensing stuff sorted at least for the python code 

            Josh has already volunteered and he is the best with an Apache attorney role.

            Publishing should be done by whoever drives the python stuff (me for the time being)

            Thanks stoty for volunteering, though can we have group managing the PyPi account instead of a single user so that we can have Phoenix dev added as the need arises?

            ankit@apache.org Ankit Singhal added a comment - I think that we should try to take over the old project for minimum disruption for users Do we want to  [take over PyPi account] ? Yeah agreed with Josh, if an account in PyPi is the convenient way of distributing an Apache Phoenix python driver then Phoenix PMC should be able to control and manage it. It will be great if Lucas could give up his account( wouldn't be a problem considering how gracious he originally was with code donation) and let Phoenix PMC  manage it so that once PMC voted and release the artifacts, we can also share it through PyPi or stage dev builds.  But in case if we come to a point that we are not able to reach him, then how about going with the new account ApachePhoenixDB and update our documentation accordingly? Sync releases to the queryserver versioning, and publish  1.0.0.devX  versions for worthwhile changes. After  1.0.0  we can probably use a forth digit for intermediate releases, i.e  1.0.0.X If we are thinking of one release per repository then I think we need to sync with the query server versions anyway, right?  And also how about following only semantic versioning(MAJOR.MINOR.PATCH) and using SNAPSHOT for staged version as we follow for other Phoenix releases to avoid confusion in understandability? Blocker: We should get the the licensing stuff sorted at least for the python code  Josh has already volunteered and he is the best with an Apache attorney role. Publishing should be done by whoever drives the python stuff (me for the time being) Thanks stoty  for volunteering, though can we have group managing the PyPi account instead of a single user so that we can have Phoenix dev added as the need arises?
            stoty Istvan Toth added a comment -

            Admin/Owner stuff:

            I've skimmed the docs. There are two roles in PyPI, maintainer and ownerhttps://pypi.org/help/#collaborator-roles

            It seems to me that both need to be actual persons, and not groups, but there may be multiple owners and maintainers.

            Releasing packages requires only the lesser maintainer role.

            Versioning:

            As elserj pointed out, the phoenix client versioning could be in theory be detached from the queryserver versioning.

            Example: After queryserver 1.0.0 is released, someone steps up to actually implement SQLAlchemy ORM, or finds a python security issue. Neither if these warrant a new (Java) PQS release, but they do warrant a new PhoenixDB release. Assume that we have already released PhoenixDB 1.0.0

            We can release the new version as

            A) 1.1.0dev0

            B) 1.0.0.1

            C) 1.1 or 1.0.1

            **A) is not optimal, since we'd ask users to switch from a stable version to a dev version to get the features/fixes.

            B) is an imperfect compromise, as it provides neither information about the level of changes in a new release, nor does it keep the versions completely in sync.

            C) is optimal from a PhoenixDB end user POV, but since it shares a repo with PQS, it causes confusion in source versioning. We could maybe tag python releases with a separate python release git tag ?

            **The cleanest solution would be splitting PhonenixDB into its own repo, but it'd cause repo creep, would be quite a lot of work, and make testing somewhat more complex.

            Anyway, deciding on this can wait until after PQS 1.0.0 is released.

            Phoenix/PyPI doesn't have the concept of -SNAPSHOT, the corresponding concept seems to be dev releases. These can be distributed from PyPI, and they must be numbered.  So we could release 1.0.0dev0, and if additional fixes show up before 1.0.0, release 1.0.0dev1 dev2, etc.

            To support the Hue work, and other users (as well as get some experience with the releasing process), I think that we should release some dev versions before the final 1.0.0 

            Licensing

            **elserj has already provided the necessary information for this, I just couldn't find the time (or the will) do it yet.

            Next steps

            1. We need to figure out who should be the PyPI project owner. ankit@apache.org as PMCC is an obvious choice, with maybe a backup person for when he's not available.
            2. Once that's done, we should contact Lukas and ask him to transfer ownership to the new owner, who can add the other owners and maintainers.
            stoty Istvan Toth added a comment - Admin/Owner stuff: I've skimmed the docs. There are two roles in PyPI, maintainer and owner .  https://pypi.org/help/#collaborator-roles It seems to me that both need to be actual persons, and not groups, but there may be multiple owners and maintainers . Releasing packages requires only the lesser  maintainer role. Versioning: As elserj pointed out, the phoenix client versioning could be in theory be detached from the queryserver versioning. Example: After queryserver 1.0.0 is released, someone steps up to actually implement SQLAlchemy ORM, or finds a python security issue. Neither if these warrant a new (Java) PQS release, but they do warrant a new PhoenixDB release. Assume that we have already released PhoenixDB 1.0.0 We can release the new version as A)  1.1.0dev0 B) 1.0.0.1 C) 1.1 or 1.0.1 **A) is not optimal, since we'd ask users to switch from a stable version to a dev version to get the features/fixes. B) is an imperfect compromise, as it provides neither information about the level of changes in a new release, nor does it keep the versions completely in sync. C) is optimal from a PhoenixDB end user POV, but since it shares a repo with PQS, it causes confusion in source versioning. We could maybe tag python releases with a separate python release git tag ? **The cleanest solution would be splitting PhonenixDB into its own repo, but it'd cause repo creep, would be quite a lot of work, and make testing somewhat more complex. Anyway, deciding on this can wait until after PQS 1.0.0 is released. Phoenix/PyPI doesn't have the concept of -SNAPSHOT, the corresponding concept seems to be dev releases. These can be distributed from PyPI, and they must be numbered.  So we could release 1.0.0dev0 , and if additional fixes show up before 1.0.0, release 1.0.0dev1   dev2 , etc. To support the Hue work, and other users (as well as get some experience with the releasing process), I think that we should release some dev versions before the final 1.0.0  Licensing ** elserj has already provided the necessary information for this, I just couldn't find the time (or the will) do it yet. Next steps We need to figure out who should be the PyPI project owner. ankit@apache.org  as PMCC is an obvious choice, with maybe a backup person for when he's not available. Once that's done, we should contact Lukas and ask him to transfer ownership to the new owner, who can add the other owners and maintainers.
            elserj Josh Elser added a comment -

            I think A is ok. We don't have to make a downstream ready first release. I would pick C were it me. We can have multiple tags.

            I think it's ok to sign up as yourself. We have private space on svn we can use. We can later figure out long term plans.

            Let me know when you think we're ready – I can email Lukas if you want.

            elserj Josh Elser added a comment - I think A is ok. We don't have to make a downstream ready first release. I would pick C were it me. We can have multiple tags. I think it's ok to sign up as yourself. We have private space on svn we can use. We can later figure out long term plans. Let me know when you think we're ready – I can email Lukas if you want.
            stoty Istvan Toth added a comment -

            elserj Yes, please contact Lukas for the ownership transfer. 

            I have created a PyPI account, it's stoty .

            stoty Istvan Toth added a comment - elserj  Yes, please contact Lukas for the ownership transfer.  I have created a PyPI account, it's stoty .
            stoty Istvan Toth added a comment -

            It seems that I have already added the required entries to the NOTICE file, so the licensing for PhoenixDB seems to be taken care of.

            Still, I wouldn't mind if you took a look at it as well, elserj

            stoty Istvan Toth added a comment - It seems that I have already added the required entries to the NOTICE file, so the licensing for PhoenixDB seems to be taken care of. Still, I wouldn't mind if you took a look at it as well, elserj
            elserj Josh Elser added a comment -

            Yes, please contact Lukas for the ownership transfer. 

            Done! private@phoenix is cc'ed, just in case there are sensitive details required to transfer ownership/add maintainers.

            Still, I wouldn't mind if you took a look at it as well

            You bet.

            elserj Josh Elser added a comment - Yes, please contact Lukas for the ownership transfer.  Done! private@phoenix is cc'ed, just in case there are sensitive details required to transfer ownership/add maintainers. Still, I wouldn't mind if you took a look at it as well You bet.
            stoty Istvan Toth added a comment -

            For the record, lukaslalinsky has added me and elserj as owners to the PyPI project.

            Thank you lukaslalinsky !

            I plan to wait a few days so that romainr can test the just committed impersonation changes, and if nothing major shows up, I'll start the release process for 1.0.0.dev0 

            Do we need to follow any formal process (like a vote) for a dev release ? 

             

            stoty Istvan Toth added a comment - For the record, lukaslalinsky  has added me and elserj  as owners to the PyPI project. Thank you lukaslalinsky  ! I plan to wait a few days so that romainr  can test the just committed impersonation changes, and if nothing major shows up, I'll start the release process for 1.0.0.dev0  Do we need to follow any formal process (like a vote) for a dev release ?   
            ankit@apache.org Ankit Singhal added a comment - - edited

             Do we need to follow any formal process (like a vote) for a dev release ? 

            For dev artifacts, I don't think so, I have seen projects posting their SNAPSHOT versions on maven on every build and for staging before the release

            But asking PMC once on the dev list would be a good idea.

            ankit@apache.org Ankit Singhal added a comment - - edited  Do we need to follow any formal process (like a vote) for a dev release ?  For dev artifacts, I don't think so, I have seen projects posting their SNAPSHOT versions on maven on every build and for staging before the release But asking PMC once on the dev list would be a good idea.
            stoty Istvan Toth added a comment -

            I've uploaded the Python Phoenix driver to the test PyPI server. 
            The command to install is:
            {{}}

            pip3 install requests-gssapi

            {{}} (this module is not available on the test server)
            {{}}

            pip3 install -i https://test.pypi.org/simple/ phoenixdb==1.0.0.dev0

            {{}}
            For python 2.7:
            {{}}

            pip2 install 'gssapi<1.6.0' 

            {{}}(this module is not available on the test server)
            {{}}

            pip2 install -i https://test.pypi.org/simple/ phoenixdb==1.0.0.dev0 
            stoty Istvan Toth added a comment - I've uploaded the Python Phoenix driver to the  test  PyPI server.  The command to install is: {{}} pip3 install requests-gssapi {{}} (this module is not available on the test server) {{}} pip3 install -i https: //test.pypi.org/simple/ phoenixdb==1.0.0.dev0 {{}} For python 2.7: {{}} pip2 install 'gssapi<1.6.0' {{}}(this module is not available on the test server) {{}} pip2 install -i https: //test.pypi.org/simple/ phoenixdb==1.0.0.dev0 
            stoty Istvan Toth added a comment -

            I've published 1.0.0 on PyPI.

            stoty Istvan Toth added a comment - I've published 1.0.0 on PyPI.
            stoty Istvan Toth added a comment -

            Bulk Closing JIRAs after PQS 6.0.0 release

            stoty Istvan Toth added a comment - Bulk Closing JIRAs after PQS 6.0.0 release

            People

              stoty Istvan Toth
              stoty Istvan Toth
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: