Packaging Guidelines generally go to the Fedora Packaging Committee for discussion, review, and approval. Then they go to FESCo to make sure the FPC isn't slipping in anything that packagers won't be able to live with.

FESCo and rjones, are there any reasons these should be reviewed by FESCo first or can FPC start discussing them? (If portions of this are for FESCo to look at FPC can look at them in parallel if we know what FESCo wants to have jurisdiction over.)

OK, maybe I've got my committees mixed up then. If FESCO doesn't need to discuss this on Wednesday then close this bug and I'll ask FPC to take a look.

No need to close this ticket - FESCo will have to review anyway. I have no problem with this going through the normal FPC process first (and think that it should).

Has FESCo discussed the MinGW feature, and how it will be handled in Fedora? The Board asked FESCo to look into this a month or so ago.

http://fedoraproject.org/wiki/Board/Meetings/2008-07-15

Since I still haven't seen that MinGW has found an appropriate home and build mechanism, I've been holding on reviewing the guidelines, as to not put the cart before the horse.

Has FESCo discussed the MinGW feature, and how it will be handled in >Fedora? The Board asked FESCo to look into this a month or so ago.

Yes, it was discussed at not the last FESCo meeting, but the one before.
No final conclusion was reached however.

Personally, I think this should be no different from any other group of packages, as long as they can get guidelines passed by Packaging, they should be allowed to follow the normal process to review, import, build and update their packages.

From the Board minutes link it seems the Board wants to "Leave technical details and implementation to FESCo" but require that "it is self contained and separated from the main package respository". So, I guess based on that it has to be in a seperate repository. I don't see any advantage in that at this time, just more work and infrastructure.

I expect this will be on the docket for the next FESCo meeting.

I will inevitably end up sounding like a broken record here, but it's worth setting things straight again:

No one from the MinGW SIG was asked to come to the Board meeting, nor were we told it was happening, nor were we told it had happened until I accidentally found out about it several days afterwards.

There is no log of who said what at the meeting, all we have is the final decision in the minutes.

Therefore no one knows what Jef Spaleta said to the Board which caused them to make what we (the SIG) believe was a mistaken decision. But based on what he's said elsewhere it may have been along the lines of MinGW intending to recompile everything in Fedora at huge cost.

No such thing is true. Only 1 in 5 Fedora packages are libraries. You have to port each library -- it is time-consuming, and sometimes impossible. It is not just recompiling, and this is nothing like a secondary arch. It has taken us many man-weeks of effort just to do this small selection of libraries.

The actual requirements for our repository so far are just over 200 MB (built for x86-64, but most packages are noarch). You can see the list of files here: http://www.annexia.org/tmp/mingw/00-files.txt and download them from http://www.annexia.org/tmp/mingw/

Add to add further to this, Richard has made it clear (at least to me) that the MinGW SIG has no intention of actually packaging Windows executables in Fedora - we all agree that they have no place in the main repo. What we're talking about is a small selection of libraries for Windows applications to build against.

It would probably be best if packaging guidelines were to state that, too - in order to avoid future confusion.

Replying to [comment:6 rjones]:

No one from the MinGW SIG was asked to come to the Board meeting, nor were we told it was happening, nor were we told it had happened until I accidentally found out about it several days afterwards.

There is no log of who said what at the meeting, all we have is the final decision in the minutes.

I have to admit I'm more than a little troubled by the Board's lack of transparency on this, and it's apparent desire to also to decide the implementation details (which I thought was under FESCo's domain).

Replying to [comment:8 bpepple]:

I have to admit I'm more than a little troubled by the Board's lack of transparency on this, and it's apparent desire to also to decide the implementation details (which I thought was under FESCo's domain).

To be fair, the Board decided to let FESCo decide the implementation details. We suggested that perhaps a separate repository for these packages would make sense, but didn't mandate it.

Replying to [comment:9 spot]:

To be fair, the Board decided to let FESCo decide the implementation details. We suggested that perhaps a separate repository for these packages would make sense, but didn't mandate it.

Ah, sorry then. Based on some of the other comments I saw I looked like the Board made that a requirement.

The issue main issue that FESCo needs to discuss is the 'packaged natively for Fedora' part. The separate repo is mostly a wash either way. The packaging guidelines, as it has already been pointed out, are something that the FPC needs to look at.

I will, however, point out that general FESCo discussion of cross compiling should probably also be done. It's a new and interesting problem space for Fedora and some careful consideration of the impacts should be looked at. I personally thing the MinGW packaging guidelines are pretty generic and are a wonderful start.

/me dons infrastructure hat:
[comment:6 rjones]

The actual requirements for our repository so far are just over 200 MB (built for x86-64, but
most packages are noarch).

Informational:
This repo looks like a mixed SRPM and x86_64 repo. Making a wildly inaccurate estimate that the size is half SRPMs and half binary, the size of a release tree would be ~500MB. We'd need to know how frequently the packages update to know if we'd also fill the updates and updates-testing repo with the same amount of data. We also won't know about rate of growth until this is out there for others to use and enhance to meet their needs.

/me dons FPC hat

Replying to [comment:7 jstanley]:

Add to add further to this, Richard has made it clear (at least to me) that the MinGW SIG has no intention of actually packaging Windows executables in Fedora - we all agree that they have no place in the main repo. What we're talking about is a small selection of libraries for Windows applications to build against.

It would probably be best if packaging guidelines were to state that, too - in order to avoid future confusion.

FPC could pass a Guideline that bans executables but I personally would rather that be added to the draft by Richard/the MingW SIG. I don't want us (the FPC) to write guidelines that ban all executables and inadvertantly prevent something like a Linux program to create Windows installers that need executables to run their equivalent of %post scriptlets.

Also, I don't foresee FPC passing Guidelines that limit what libraries are appropriate for cross compiling and which are not so I hope that "small selection of libraries" is descriptive of what you think people will choose to package for it rather than an expectation that FPC will pass Guidelines meant to restrict the selection of libraries :-)

We have packaged some Windows executables (eg. certtool.exe & virsh.exe), on the basis that someone who wants to supply Windows binaries of their applications to end users would likely want to supply these for support or debugging. eg. It's a lot easier to debug a problem in GnuTLS-dependent code if you've can run "certtool -i ..." to diagnose & debug your certificates.

What we '''don't''' want to see is end-user applications being packaged by Fedora. The classic example being "firefox.exe" -- it has no place in Fedora and no purpose for developers by being in Fedora.

It's worth referring to the MinGW SIG's mission:

The Fedora MinGW project's mission is to ''provide an excellent development environment for Fedora users'' who wish to cross-compile their programs to run on Windows, minimizing the need to use Windows at all. In the past developers have had to port and compile all of the libraries and tools they have needed, and this huge effort has happened independently many times over. We aim to ''eliminate duplication of work for application developers'' by providing a range of libraries and development tools which have already been ported to the cross-compiler environment. This means that ''developers will not need to recompile the application stack themselves'', but can concentrate just on the changes needed to their own application.

(My emphasis added). If an application developer needs to recompile RPMs because some useful tool in a base library was left out, then we feel that we're not providing an excellent development environment nor avoiding the need to duplicate work.

I hope that's clearer, although regretfully it isn't well expressed in the draft guidelines yet, but it should be.

Replying to [comment:12 toshio]:

Informational:
This repo looks like a mixed SRPM and x86_64 repo. Making a wildly inaccurate estimate that the size is half SRPMs and half binary, the size of a release tree would be ~500MB. We'd need to know how frequently the packages update to know if we'd also fill the updates and updates-testing repo with the same amount of data. We also won't know about rate of growth until this is out there for others to use and enhance to meet their needs.

Anything is going to be a guess, but Dan Berrange has developed a Python tool[*] for comparing RPMs. Our aim (expressed in the guidelines) is to follow Fedora native releases. So if GnuTLS native has a bump, we would bump mingw-gnutls too. I hope that's helpful in estimating these things.

[*] In http://hg.et.redhat.com/misc/fedora-mingw--devel/ in the compare/ directory. Basically it compares the two RPMs and checks that version numbers, base URIs, patch sets, build options, etc are the same.

Oof. The fact that you require to run a script to check that you're in sync for all your packages sounds like failure. Of course, requiring other maintainers who don't care about such things to maintain those bits in the main specs themselves is also failure, albeit a different sort.

The only way we'd avoid this is to have each cross-compiled arch as a sub-RPM in the native specfile. It would be hard to get buy-in from native developers for this approach because it would be pushing maintainence burden for fixing all archs onto them whenever they made a change. It also wouldn't scale up too nicely if we got a situation where there was more than just a couple of cross-archs.

That said we did prototype such an approach, but in the end, having separate spec files resulted in something which was much clearer to understand, and doesn't burden primary arch maintainers. The 'rpm spec diff' is intended to lower the burden of these parallel spec files to an acceptable level. It will also help other Fedora derived distros track changes they might be making to Fedora distros, or alternate branched Fedora spins like OLPC tracks changes.

MinGW Packaging guidelines have been approved by FPC & FESCo. Closing ticket.