Den 9. sep. 2008 00.05 skrev Paul <paul@xxxxxxxxxxxxxxxxxxxxxx>:
You should also not forget about updates-testing as a source of testing. Once we have a 2.0 release or any release deemed stable by upstream which has survived a build in Rawhide we can do a push for the Mono stack to updates-testing. One reason this is a good idea is that we can gain more testers, not everyone is willing to try out rawhide so we can only count on rawhide to remove the rough of edges - getting people to enable the updates-testing repo everytime a leaf application puts out an update though is easy. I'll use Banshee as the example as they have the most elegant way to address this. Each release note comes with instructions on how to install the new goodies on various distros, for Fedora we merely then trick users into doing yum --enablerepo=updates-testing install banshee. Then they automatically agree to become our guinea pigs for the Mono stack and most related items when available, if nothing is being tested at that moment they just get their fix of new shiny mediaplayer software. Slightly evil but users generally seem to desire the new shiny apps and thus are willing to do testing. Tricking them into providing feedback is a bit harder, bodhi is not very easily discoverable - search it for the correct rpm entries is a disaster, which likely means our metric has to be te lack of fall out measured on bugzilla and in the upstream mailing lists. Not all together the best approach but testing feedback is a problem for all of Fedora not just the Mono stack so we are no worse off than any other piece of software in Fedora.
- David
Hi,
Sounds fair enough. I have no problems in doing the push...
> >> 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.
No. Stability is a major issue. Remember what rawhide is there for; it's
> 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.
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!
You should also not forget about updates-testing as a source of testing. Once we have a 2.0 release or any release deemed stable by upstream which has survived a build in Rawhide we can do a push for the Mono stack to updates-testing. One reason this is a good idea is that we can gain more testers, not everyone is willing to try out rawhide so we can only count on rawhide to remove the rough of edges - getting people to enable the updates-testing repo everytime a leaf application puts out an update though is easy. I'll use Banshee as the example as they have the most elegant way to address this. Each release note comes with instructions on how to install the new goodies on various distros, for Fedora we merely then trick users into doing yum --enablerepo=updates-testing install banshee. Then they automatically agree to become our guinea pigs for the Mono stack and most related items when available, if nothing is being tested at that moment they just get their fix of new shiny mediaplayer software. Slightly evil but users generally seem to desire the new shiny apps and thus are willing to do testing. Tricking them into providing feedback is a bit harder, bodhi is not very easily discoverable - search it for the correct rpm entries is a disaster, which likely means our metric has to be te lack of fall out measured on bugzilla and in the upstream mailing lists. Not all together the best approach but testing feedback is a problem for all of Fedora not just the Mono stack so we are no worse off than any other piece of software in Fedora.
- David
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
