Hi, > >> An alternative is that after a couple of months proving on rawhide, the > >> rawhide version is pushed to core. > > > > I admit I much prefer the latter method, it keeps the stack roughly the same > > accross releases which means our users have access to the latest bug fixes > > and a version that is supported by upstream. It also keeps the amount of > > code actively supported as low as possible. Aggressively pushing vetted > > versions of the Mono stack seems like the wisest plan to me. As a bonus, we > > also gain the ability to push the latest and thus often the only supported > > version of Mono using apps in our stable repos, something our users expect - > > just watch the Banshee mailing list, not only do our users expect the latest > > to be available but upstreams first reply to potential problems is nearly > > always to install the latest supported version. Sounds fair enough. I have no problems in doing the push... > I concur; the Mono stack seems to be monotonically (pun alert!) > increasing in usability, that the benefits of maintaining a single > Mono major version across our supported releases outweigh the > stability concerns. No. Stability is a major issue. Remember what rawhide is there for; it's the testing ground. I have no problems doing the mono packaging, wait a few months and then bounce it down to stable, but never at the cost of stability. Release versions need to be treated with cotton gloves as not everyone is as brave as us nutjobs! > Would we have time to get 2.0 into F-9, and rebuild the Mono stack > there, or do we need an interim release of currently-FTBFS Mono > packages? (thinking of Monodevelop here. Wouldn't want it blacklisted) Should have... TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
