On Sat, Dec 03, 2011 at 02:24:08PM -0500, Tom Lane wrote: > Toshio Kuratomi <a.badger@xxxxxxxxx> 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
Attachment:
pgpp6mtLSAtUd.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
