Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
>>
>> You should take a look at this old deferred PEP:
>> https://www.python.org/dev/peps/pep-0407/
>
> I don't understand the reasoning behind that PEP. With the proposed
> timing, those "LTS" releases would be no different than what we have
> today
On 1/25/2017 7:30 AM, Antoine Pitrou wrote:
We'd just say:
this is our new LTS release (e.g. Python 3.7) and then move on
until we're confident again that the feature set has stabilized
enough to create a new LTS release.
In practice you wouldn't just "move on" but have to maintain that LTS
rel
On 25 January 2017 at 12:45, Eric V. Smith wrote:
> Channeling Nick, I'd say that LTS support should come from commercial third
> parties, such as OS vendors. I agree with Antoine: it's not something we
> want to impose on the core devs. How much fun is 2.7 maintenance?
Agreed. When lack of revie
On Wed, Jan 25, 2017 at 07:45:05AM -0500, Eric V. Smith wrote:
> Channeling Nick, I'd say that LTS support should come from commercial third
> parties, such as OS vendors. I agree with Antoine: it's not something we
> want to impose on the core devs. How much fun is 2.7 maintenance?
Are there any
On 25.01.2017 13:30, Antoine Pitrou wrote:
>
> Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
>> All that said, I believe a having a Python 2.7 style long
>> support version for Python 3 would be nice and have a stabilizing
>> effect which our user base would appreciate.
>
> Trying to enforce suc
On Jan 25, 2017, at 07:45 AM, Eric V. Smith wrote:
>Channeling Nick, I'd say that LTS support should come from commercial third
>parties, such as OS vendors. I agree with Antoine: it's not something we want
>to impose on the core devs. How much fun is 2.7 maintenance?
Which effectively happens an
On Wed, 25 Jan 2017 at 06:11 A.M. Kuchling wrote:
> On Wed, Jan 25, 2017 at 07:45:05AM -0500, Eric V. Smith wrote:
> > Channeling Nick, I'd say that LTS support should come from commercial
> third
> > parties, such as OS vendors. I agree with Antoine: it's not something we
> > want to impose on t
On 2017-01-25, A.M. Kuchling wrote:
> I think this is the next frontier for Python maintenance; we need
> full-time core maintainers, no third parties are funding any such
> developers, and the PSF doesn't seem interested in pursuing that.
IMHO, the PSF should be doing it. I don't know exactly ho
On Wed, 25 Jan 2017 at 06:29 M.-A. Lemburg wrote:
> On 25.01.2017 13:30, Antoine Pitrou wrote:
> >
> > Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
> >> All that said, I believe a having a Python 2.7 style long
> >> support version for Python 3 would be nice and have a stabilizing
> >> effect w
On 25 January 2017 at 15:29, M.-A. Lemburg wrote:
> I also believe that the PSF should start stepping up and
> invest some money into helping with Python support. A lot
> of money is being spent on community work, but hardly any
> on development work at the moment.
Software maintenance is a comme
On 25 January 2017 at 19:28, Neil Schemenauer wrote:
> On 2017-01-25, A.M. Kuchling wrote:
>> I think this is the next frontier for Python maintenance; we need
>> full-time core maintainers, no third parties are funding any such
>> developers, and the PSF doesn't seem interested in pursuing that.
On Thu, Jan 26, 2017 at 01:58:42PM +0100, Nick Coghlan wrote:
> Software maintenance is a commercial support activity that is normally
> done for profit, so the PSF needs to be careful in how it approaches
> it to avoid getting in trouble with the IRS (public interest charities
> like the PSF opera
On 26.01.2017 17:34, A.M. Kuchling wrote:
> On Thu, Jan 26, 2017 at 01:58:42PM +0100, Nick Coghlan wrote:
>> Software maintenance is a commercial support activity that is normally
>> done for profit, so the PSF needs to be careful in how it approaches
>> it to avoid getting in trouble with the IRS
On 26 January 2017 at 17:34, A.M. Kuchling wrote:
> I mean, if funding software maintenance is illegal for a 501c3, then
> the FSF, Software Conservancy, Software in the Public Interest, Django
> Foundation, NumFOCUS, etc. are probably all illegal.
Note that I said the PSF needs to be careful in
2017-01-24 21:46 GMT+01:00 Neil Schemenauer :
> Maybe we could emulate the Linux kernel releases. I.e. have
> relatively fast moving development but also choose releases to give
> long maintenance cycles. Ideally the long term releases would be
> synchronized with OS distribitions (e.g. Red Hat,
On 2017-01-24, Victor Stinner wrote:
> You should take a look at this old deferred PEP:
> https://www.python.org/dev/peps/pep-0407/
Thanks, that's very close to what I was thinking. I would still add
that we should be extra careful about incompatible language features
until 2.7.x usage has mostly
On Tue, Jan 24, 2017 at 1:26 PM, Neil Schemenauer
wrote:
> On 2017-01-24, Victor Stinner wrote:
> > You should take a look at this old deferred PEP:
> > https://www.python.org/dev/peps/pep-0407/
>
> Thanks, that's very close to what I was thinking. I would still add
> that we should be extra car
On Tue, 24 Jan 2017 at 13:26 Neil Schemenauer
wrote:
> On 2017-01-24, Victor Stinner wrote:
> > You should take a look at this old deferred PEP:
> > https://www.python.org/dev/peps/pep-0407/
>
> Thanks, that's very close to what I was thinking. I would still add
> that we should be extra careful
On 24.01.2017 22:08, Victor Stinner wrote:
> 2017-01-24 21:46 GMT+01:00 Neil Schemenauer :
>> Maybe we could emulate the Linux kernel releases. I.e. have
>> relatively fast moving development but also choose releases to give
>> long maintenance cycles. Ideally the long term releases would be
>> s
On 25 January 2017 at 10:19, M.-A. Lemburg wrote:
> Perhaps making the last minor version to a major release version
> as we did with 2.7 is a good approach, i.e. we'd switch the
> major number when cutting an LTS release and follow similar
> guidelines as we have for 2.7 for this 3.x LTS release.
20 matches
Mail list logo
