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!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Den 8. sep. 2008 19.48 skrev Paul <paul@all-the-johnsons.co.uk>:

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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/9/8 David Nielsen <gnomeuser@gmail.com>:
>
>
> Den 8. sep. 2008 19.48 skrev Paul <paul@all-the-johnsons.co.uk>:
>>
>> 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/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

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!
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

2008/9/8 Paul <paul@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!
>
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/

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Den 9. sep. 2008 00.05 skrev Paul <paul@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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list