Mono - rfc for future developments

[David Nielsen]

Den 9. sep. 2008 00.05 skrev Paul <paul at all-the-johnsons.co.uk>:

> 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!


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080909/20a4ce60/attachment.htm>