Thorsten, ping 

Any thoughts on the matter, as a pure leaf package this appears to have almost no detrimental user facing changes.  So updating in EPEL seems reasonable.

Note 2.67 is now available

I will apply for comaintainership of this.

Actually, looks like there already is a comaintainer.

pertusus, do you have time to bounce the rss2email version?

Note that if you want to follow upstream's preferences, it may be useful to upgrade python-html2text, too. Currently in EPEL 5:

  python-html2text-2.26-2.el5.src.rpm
  python-feedparser-4.1-10.el5.src.rpm

rss2email includes copies of those two modules, but with higher versions because old ones in various dists are the cause of rss2email bug reports - I've been told today. rss2email's html2text is 2.37, feedparser is 4.2-pre (a development snapshot). Fedora 14's feedparser is also just 4.1, latest release from Apr 2007.

Readin the Changelog, in 2.66 there were change in defaults, and then there are Compatibility changes in 2.67. Maybe rebasing to 2.65 would be safer?

My thoughts are that this is more of a user space app and doesn't really have an ABI that other programs are likely to rely on.

As such, I think it's not a big concern about some of the items you mentioned changing as long as there's an upgrade path...

(At least this is kind of how I've thought of the apps EPEL provides -- more conservative with anything providing an ABI to other programs).

Looks like 2.70 is already out (and I did like the OPML import/export feature in 2.68).  I'd be happy with any upgrade bump of course, even to 2.65. :)

(In reply to comment #6)
> My thoughts are that this is more of a user space app and doesn't really have
> an ABI that other programs are likely to rely on.

Other programs, sure, but users? EPEL should follow the path of least surprise for users.

> (At least this is kind of how I've thought of the apps EPEL provides -- more
> conservative with anything providing an ABI to other programs).

Not only the ABI. It involves stability in general, like not changing the behaviour of the program, not needing to change the configuration and so on and so forth. If you can argue that the Changelog is misleading and that the upgrade won't require the user to change their configuration, I could consider bumping to more recent version, but in the mean time I prefer to stich to 2.65.

> Looks like 2.70 is already out (and I did like the OPML import/export feature
> in 2.68).  I'd be happy with any upgrade bump of course, even to 2.65. :)

You can apply to comaintainership and do the bump to 2.65. I cannot really tell when I'll have time myself.

(In reply to comment #7)
> Not only the ABI. It involves stability in general, like not changing the
> behaviour of the program, not needing to change the configuration and so on
> and so forth. If you can argue that the Changelog is misleading and that the
> upgrade won't require the user to change their configuration, I could consider
> bumping to more recent version, but in the mean time I prefer to stich to 2.65.

Changelog mentions only these two changes which could affect users:

    * Deprecated QP_REQUIRED option as this is more than likely no longer
      needed and part of what triggered Python warnings
    * Default to HTML mail and CSS results 

Patrice, did I miss anything? If not, then I don't the former is a problem (it shouldn't be removed yet, just depreceated, right?). The latter could be, and we may have to comment it out.

On the plus side, it is not like there are no bugs in EPEL-5 version of rss2email (e.g., I have just filed bug 677095), so either we should rebase or backport the fixes from the later versions of rss2email.

(In reply to comment #8)

>     * Default to HTML mail and CSS results 
> 
> Patrice, did I miss anything? If not, then I don't the former is a problem (it
> shouldn't be removed yet, just depreceated, right?). The latter could be, and
> we may have to comment it out.

I agree on that, and it is the entry that made me think that an upgrade may break user expectations.

I have also seen (v2.67)

* Compatibility changes to support most recent development versions of feedparser
* Compatibility changes to support Google Reader feeds

> On the plus side, it is not like there are no bugs in EPEL-5 version of
> rss2email (e.g., I have just filed bug 677095), so either we should rebase or
> backport the fixes from the later versions of rss2email.

I am not sure that this particular bug is in rss2email, it could also be in html2text. I don't see it in the fixed things list in the CHANGELOG, although there is something similar in the v2.67 entry:
* Fixed From headers with HTML entities encoded twice



As a side note, it seems that the package is orphaned, so anybody could step and be the maintainer and do a choice on bumping the version that may not be aconservative as I think it should be.

(In reply to comment #9)
> I am not sure that this particular bug is in rss2email, it could also be in
> html2text.

Just on this particular note ... see bug 677095 comment 2

*** Bug 704907 has been marked as a duplicate of this bug. ***

OK, would anybody mind here rebase in EPEL-5 to the latest version in EPEL-6 or just closing this bug as WONTFIX? There is probably not a third option.

Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5
is no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
or Fedora EPEL, please feel free to reopen this bug against that version. If
you are unable to reopen this bug, please file a new report against the current
release. If you experience problems, please add a comment to this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.