On Sat, Dec 03, 2011 at 02:24:08PM -0500, Tom Lane wrote:
Toshio Kuratomi <a.badger(a)gmail.com> writes:
Well, unixODBC 2.2.14 isn't going to change anymore, so I don't really
think that end of it would be adding instability. In any case, if we
get to the point of doing a Fedora release before upstream gets their
release sorted, I would also think that we'd not track the upstream
release in released Fedora branches. So AFAICS the only possible extra
churn would be in rawhide. Do you see other reasons why this would be
a bad thing to be shipping in a released version?
<nod> It isn't really about instability, though... it's about
getting
updates that aren't needed. It sounds like the GUI tools in unixODBC-2.2.14
won't be updated, but everytime the library providing tarball is updated (or
new patches are added from the Fedora side), the entire unixODBC package
gets rebuilt and the end user ends up having to update the GUI package.
[snip]
[ goes off and looks at the unixODBC-GUI-Qt sourceforge repository's
commit statistics ] Hmm ... given the speed with which things are
(not) happening upstream, maybe I should reconsider the idea of just
taking an SVN snapshot. What's your opinion of that option?
I think I like this a lot. It sounds like upstream isn't changing the GUI
tools very fast. So even if they reorganize the code and build scripts
significantly before release, we might be perfectly fine continuing to ship
a snapshot in the released Fedoras since the code itelf will have seen few
worthwhile changes.
-Toshio