Everyone,

First of all thank you for all signing up to help making Mono and Mono using applications a much more enjoyable experience for Fedora users. This effort has been long underway, and I personally have very little experience with this kind of organizing.

The first thing I would like to stress is that the SIG is open to everyone, regardless of skill and available time. Even if you are a user you can be a valuable asset for improving the application stack. Primarily I am thinking about sending out testing requests when major work is being done and put into the updates-testing repos, instructions will always follow. All that is required for this type of work is membership on the mailing list as well as a bugzilla account. There is on the wiki page for the SIG a sub section for "Faithful testers" I would suggest that you add your name there so that everyone might get to know each other and the maintainers might know what kind of level of testing we might expect to attain.

Should you wish to get more engaged, there will always be new packages to review and other work. Learning the required skills is something we can help with if needed, there are no dumb questions, every interested person we can get is valuable and lessens the maintainship burden on everyone. Aside packaging work we will make sure that all members have access to a list of open bugs against all packages maintained by SIG members, one valuable thing would be for members to confirm bugs and using bug templates (more on this later) to get bugs in as good a shape as possible. The aim will always be to push real bugs upstream to be the least amount of work and the highest level of benefit for everyone.

Now to the action points.

1) High on my list of things to do is to review and rewrite the packaging guidelines. The current ones do not encompass neither recommendations from upstream or other major distros. There isn't any information on how to obtain the information required for reviews or packaging for new packagers to learn from. I would suggest basing these new guidelines on the work Debian already has done. This does involve moving 100% managed code packages to be noarch which is a major change and will require a lot of concerted effort to announce and push correctly. Till such guidelines are in place and agreed upon, we will use the existing ones. Once such guidelines are in place I would suggest putting aside the required time to convert everything for a one time push to rawhide after which this will be our new packaging base and the old guidelines are obsoleted entirely.

2) Assessing the situation with regards to debug symbol packages, currently they are in the main package but there is a patch to let us use the same script as other packages to handle these separately. We should review this work, it will make packages smaller and bring us more in line with the rest of Fedora.

3) Reviewing Debian and Ubuntus work to obsolete Mono 1.0 for smaller packages and improved performance.

4) We need a script to monitor upstream versions and compare them to our available versions. Optimally this would file a bug against the relevant package when we are behind upstream. Typically only the most recent versions are supported so it is important that they are present on all the platforms we have supported in Fedora.

5) Improve the process for pushing the entire stack to existing stable platforms. Currently this isn't very organized and doesn't involve a recompile for all packages, it's pushed in bits instead of all at once. We need to research how to do this properly and make sure we stick to those guidelines, also we need to make this as scriptable as possible.

6) New packaging. Every new package to be brought in to the repos needs to start with an intent to package mail to the list to make sure no work is duplicated. When a bug has been filed for review this is made as a reply to that thread. Everyone capable and with time available is requested to help out with reviewing this. Both for purposes of ensuring a quality product but also so that new packagers might learn their way around the review process. If there are questions during the packaging process please feel free to contact the mailing list, we are here to help.

7) Love weeks. I would like to see us set aside every week as dedicated to loving one special application. This would involve reviewing all open bugs, making sure the version we have is up to date and that upstream requested patches have been applied. That bugs have been been pushed upstream where proper and so on. Finally this would also entail making sure that we have packages for all the plugins that program has available. I suggest the first target for a week of love would be Monodevelop.

Additionally links for most of this can be found here:
http://davidnielsen.wordpress.com/2009/03/05/mono-sig-full-stream-ahead/

Kind regards,
David Nielsen