Mono - rfc for future developments

[Paul F. Johnson]

Hi,

I've just been notified that RC1 of Mono is due to be tagged today at
some point with RC2 (final) on the 10th. Given the date difference of
only 2 days, I'll be packaging Mono 2.0 for rawhide.

Future plans.

Currently the mono stack for Fedora is a bit of a mess over the three
versions available. What I'm proposing for future mono/libgdiplus
releases is this.

Mono 2.0 is released on the 10th and packaged for rawhide
Mono 1.9.1 is then released on F9

The stack is then rebuilt to cover gtk-sharp2 et al so that by the end
of the process rawhide is one version ahead of core.

When Mono 2 becomes 2.9, version 2 is released onto core and so on.
This, in theory, should kill the problems experienced with the likes of
monodevelop in core. It also means that core is operating on the stable
release.

An alternative is that after a couple of months proving on rawhide, the
rawhide version is pushed to core.

Comments on this are welcome either on or off list.

TTFN

Paul
(looking for work so has a bit of time to spare to such activities)
-- 
Sie können mich aufreizen und wirklich heiß machen!

[David Nielsen]

Den 8. sep. 2008 19.48 skrev Paul <paul(a)all-the-johnsons.co.uk&gt;:

>  Hi,
>
>  I've just been notified that RC1 of Mono is due to be tagged today at
>  some point with RC2 (final) on the 10th. Given the date difference of
>  only 2 days, I'll be packaging Mono 2.0 for rawhide.
>
>  Future plans.
>
>  Currently the mono stack for Fedora is a bit of a mess over the three
>  versions available. What I'm proposing for future mono/libgdiplus
>  releases is this.
>
>  Mono 2.0 is released on the 10th and packaged for rawhide
>  Mono 1.9.1 is then released on F9
>
>  The stack is then rebuilt to cover gtk-sharp2 et al so that by the end
>  of the process rawhide is one version ahead of core.
>
>  When Mono 2 becomes 2.9, version 2 is released onto core and so on.
>  This, in theory, should kill the problems experienced with the likes of
>  monodevelop in core. It also means that core is operating on the stable
>  release.
>
>  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.

Let make use for Rawhide and updates-testing to vet the Mono stack, bodhi
can be used as a metric for when to push updates to stable.

- David

[Michel Salim]

2008/9/8 David Nielsen <gnomeuser(a)gmail.com&gt;:
>  Den 8. sep. 2008 19.48 skrev Paul <paul(a)all-the-johnsons.co.uk&gt;:
> >
> > Hi,
> >
> > I've just been notified that RC1 of Mono is due to be tagged today at
> > some point with RC2 (final) on the 10th. Given the date difference of
> > only 2 days, I'll be packaging Mono 2.0 for rawhide.
> >
> > Future plans.
> >
> > Currently the mono stack for Fedora is a bit of a mess over the three
> > versions available. What I'm proposing for future mono/libgdiplus
> > releases is this.
> >
> > Mono 2.0 is released on the 10th and packaged for rawhide
> > Mono 1.9.1 is then released on F9
> >
> > The stack is then rebuilt to cover gtk-sharp2 et al so that by the end
> > of the process rawhide is one version ahead of core.
> >
> > When Mono 2 becomes 2.9, version 2 is released onto core and so on.
> > This, in theory, should kill the problems experienced with the likes of
> > monodevelop in core. It also means that core is operating on the stable
> > release.
> >
> > 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.
>  
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.

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)


-- 
Michel Salim
http://hircus.jaiku.com/

[Paul F. Johnson]

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!

[Michel Salim]

2008/9/8 Paul <paul(a)all-the-johnsons.co.uk&gt;:
>  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!
>  
Um, that was bad phrasing on my part. What I intended to say is that
new Mono releases tend to be good enough, that stabilizing any new
release in Rawhide for a few months would be good enough, and we don't
need to duplicate our testing efforts by packaging another different
version for F9.

Regards,

-- 
Michel Salim
http://hircus.jaiku.com/

[David Nielsen]

Den 9. sep. 2008 00.05 skrev Paul <paul(a)all-the-johnsons.co.uk&gt;:

>  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