Packaging not the latest release

[Miro Hrončok]

Hi,

I'm trying to package httpretty [0] for Python 2 and 3. However, the 
latest upstream release 0.7.0 seems to not work with Python 3 (at least 
the tests are failing). Version 0.6.5 however works fine (or at least 
way better) with Python 3.

What should I do now?

1) Create separate packages python-httpretty (0.7.0) and 
python3-httpretty (0.6.5)
2) Create one package with both (0.6.5)
3) Do not package httpretty for Python 3 at all

I need this package working with Python 3 and I only package Python 2 
version as well because it's appropriate :) So 3) is not really good for 
me and if I choose 1) I might not package Python 2 version at all.

What does guidelines say about packaging latest upstream release? I 
somehow remeber that being checked in the review, but I cannot find it 
in the guidelines.

Is it OK to package older release when the new one is broken? Do I need 
FPC approval/exception for that?

Thanks.

[0] https://github.com/gabrielfalcao/HTTPretty
-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Dominik 'Rathann' Mierzejewski]

Hi Miro,

On Monday, 02 December 2013 at 08:37, Miro Hrončok wrote:
>  Hi,
>  
>  I'm trying to package httpretty [0] for Python 2 and 3. However, the
>  latest upstream release 0.7.0 seems to not work with Python 3 (at
>  least the tests are failing). Version 0.6.5 however works fine (or
>  at least way better) with Python 3.
>  
>  What should I do now?
>  
>  1) Create separate packages python-httpretty (0.7.0) and
>  python3-httpretty (0.6.5)
>  2) Create one package with both (0.6.5)
>  3) Do not package httpretty for Python 3 at all
>  
>  I need this package working with Python 3 and I only package Python
>  2 version as well because it's appropriate :) So 3) is not really
>  good for me and if I choose 1) I might not package Python 2 version
>  at all.
>  
>  What does guidelines say about packaging latest upstream release? I
>  somehow remeber that being checked in the review, but I cannot find
>  it in the guidelines.
>  
>  Is it OK to package older release when the new one is broken? Do I
>  need FPC approval/exception for that? 
I'd say it's common sense not to package the latest version if it's
broken, so I'd go for option 2 in your case and updated to the latest
when it's fixed.

Is there an upstream bug open for the failing tests?

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

[Christopher Meng]

1. What kind of bug?(I guess is the functional)

2. We should not try to pollute SCM repo without ant special reason.

[Miro Hrončok]

>  Is there an upstream bug open for the failing tests? 
Well,
officaily I'm not sure if this is supposed to run on Python 3, but 
I'll try to solve this upstream.

However the tests are passing in their CI, so I might hit a wall here. 
Will see.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Miro Hrončok]

>  2. We should not try to pollute SCM repo without ant special reason.
I'm sorry but I don't underestant your point. What do you mena by 
polluting SCM repo?


Thanks for clarification,
-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Christopher Meng]

Ah...I mean that when we can use one slot python-xxx for both
python-xxx and python3-xxx, don't use 2 separate slot python-xxx.git
and python3-xxx.git.