On 2017-09-29 17:31:10 +0200 (+0200), Thierry Carrez wrote:
> OK, I got individual PTL confirmation that it was OK to remove all of
> those from PyPI:
>
> mistral-extra 2015.1.0
> mistral-dashboard 2015.1.*
>
> networking-odl, 2015.1.1 2015.1.dev986
>
> networking-midonet, 2014.2.2 and various
OK, I got individual PTL confirmation that it was OK to remove all of
those from PyPI:
mistral-extra 2015.1.0
mistral-dashboard 2015.1.*
networking-odl, 2015.1.1 2015.1.dev986
networking-midonet, 2014.2.2 and various 2015.1.* versions
(might have been removed by networking-midonet folks by now)
I confirm that you can delete mistral versions with “2015”.
Thanks
Renat Akhmerov
@Nokia
On 15 Sep 2017, 23:58 +0700, Rong Zhu , wrote:
> +1 for murano-dashboard and murano-agent
>
> On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez wrote:
> > Claudiu Belu wrote:
> > > So, I believe the general co
+1 for murano-dashboard and murano-agent
On Fri, Sep 1, 2017 at 1:51 AM, Thierry Carrez wrote:
> Claudiu Belu wrote:
>> So, I believe the general consensus is that the easiest thing to do is to
>> unpublish the 2015.1.0 version from pypi, with which I also agree.
>> [...]
>
> Yes, for a first ba
On 2017-09-07 08:59:15 +0200 (+0200), Thierry Carrez wrote:
> Jeremy Stanley wrote:
> > On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote:
> > [...]
> >> Yes, for a first batch I propose we clean up the following:
> >>
> >> python-congressclient 2015.1.0
> >> python-congressclient 2015.1.0
Jeremy Stanley wrote:
> On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote:
> [...]
>> Yes, for a first batch I propose we clean up the following:
>>
>> python-congressclient 2015.1.0
>> python-congressclient 2015.1.0rc1
>> python-designateclient 2013.1.a8.g3a2a320
>> networking-hyperv 2015
On 2017-09-01 09:51:36 +0200 (+0200), Thierry Carrez wrote:
[...]
> Yes, for a first batch I propose we clean up the following:
>
> python-congressclient 2015.1.0
> python-congressclient 2015.1.0rc1
> python-designateclient 2013.1.a8.g3a2a320
> networking-hyperv 2015.1.0
[...]
Are we waiting for
: Friday, September 01, 2017 10:51 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [relmgt] Libraries published to pypi with .X.Z
versions
Claudiu Belu wrote:
> So, I believe the general consensus is that the easiest thing to do is to
> unpublish the 2015.1.0 version fro
Claudiu Belu wrote:
> So, I believe the general consensus is that the easiest thing to do is to
> unpublish the 2015.1.0 version from pypi, with which I also agree.
> [...]
Yes, for a first batch I propose we clean up the following:
python-congressclient 2015.1.0
python-congressclient 2015.1.0rc
is used.
Thanks @all for your opinions!
Best regards,
Claudiu Belu
From: Jeremy Stanley [fu...@yuggoth.org]
Sent: Thursday, August 31, 2017 3:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [relmgt] L
On 2017-08-31 15:21:19 +1000 (+1000), Tony Breeds wrote:
[...]
> I assume it's infra that needs to do the actual unpublish?
We're the ones with the most consistent access to all of them,
though in a majority of cases there's at least one other account
with sufficient access to do the same (it just
On Wed, Aug 30, 2017 at 05:04:58PM +0200, Thierry Carrez wrote:
> Tony Breeds wrote:
> > An extension to this would be to check for other items in the same boat.
> > I wrote [1] to find anything in the openstack namespace that isn't a
> > service and has something that looks like a date based relea
Tony Breeds wrote:
> An extension to this would be to check for other items in the same boat.
> I wrote [1] to find anything in the openstack namespace that isn't a
> service and has something that looks like a date based release on pypi.
> [...]
Thanks for computing the list. Unpublishing is a bi
On 17-08-29 15:58:55, Jeremy Stanley wrote:
> On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote:
> [...]
> > 3. reversion. Start new versions at 3000 or something, kinda
> > dirty imo.
>
> And sort of a 3.1 option is to prepend a PEP 440 version epoch:
>
> https://www.python.org/dev/p
On Tue, Aug 29, 2017 at 02:09:32PM +, Claudiu Belu wrote:
> (test) ubuntu@ubuntu:~$ pip freeze | grep networking-hyperv
>
> (test) ubuntu@ubuntu:~$ pip install networking-hyperv
I know this isn't a solution but I'd be remiss if I didn't point it out:
uc_url=https://git.openstack.org/cgit/op
On 2017-08-29 18:26:49 +0200 (+0200), Thierry Carrez wrote:
[...]
> Yeah, in that specific case I think that's the simplest route. It's not
> really destroying it, it just prevents PyPI from erroneously
> distributing it, without having to add a PEP440-Epoch to an OpenStack
> deliverable and discov
Doug Hellmann wrote:
> If that 2015 version is no longer maintained, then deleting it from
> PyPI may be the most effective way to avoid this particular support
> issue, even though that is normally not something we recommend.
Yeah, in that specific case I think that's the simplest route. It's not
On 2017-08-29 10:30:42 -0500 (-0500), Matthew Thode wrote:
[...]
> 3. reversion. Start new versions at 3000 or something, kinda
> dirty imo.
And sort of a 3.1 option is to prepend a PEP 440 version epoch:
https://www.python.org/dev/peps/pep-0440/#version-epochs
Challenge there is that, while
Excerpts from Claudiu Belu's message of 2017-08-29 14:09:32 +:
> Hello,
>
> As many of you know, during Kilo, the neutron vendor decomposition happened,
> which lead to the birth of many networking-* libraries, including
> networking-hyperv. When it was time for us to make a release for that
On 17-08-29 14:09:32, Claudiu Belu wrote:
> Hello,
>
> As many of you know, during Kilo, the neutron vendor decomposition happened,
> which lead to the birth of many networking-* libraries, including
> networking-hyperv. When it was time for us to make a release for that cycle,
> pretty much ev
20 matches
Mail list logo
