[I planed to send this over one week ago, but many things got in my way, sorry]
I think we should make a 0.4.0 distro release pretty soon. To prevent problems like last time, I'd like to have the release process formalized more than it is (which is not at all). I believe this will benefit us all. I plan to add a section to the documenation/policy on this eventually. Following some thoughts of mine, not yet complete. I) Distro Release Frequency =========================== Full distro releases should occur roughly every 2 months. This ensures the binary distro doesn't lag behind to much (see point III). II) Time table for distro release ================================= After each release, we'll publish the date of the estimated time for the next release. Ideally we'd even give estimates for the next couple of dates. These dates will not be guranteed to be met, but we'll try our best to keep close to the scheduled date for the next release. I propose our next release be on Saturday, 13th April. (This gives us enough time to follow the procedure outlined below; also it means that in case of screw up, I have the sunday to fix up; feel free to suggest other dates, but make sure to include proper reasons as to why you think that date is better suited). Before each release, we'll undergo the following phases [to be refined]: 1) Stable-Move-Phase We try to get as many package to stable. This way we can ensure a big binary distro, plus stable users have more current stuff. Of course, we still must be careful doing so, it's no use to have packages in stable that don't work properly. So don't rush! 2) Freeze Roughly one week before the scheduled release date, we make freeze stable. This means no changes may be made to stable in this time, except to fix bugs. In this time, I (and ideally others developers, too) will switch to a clean stable-only system to verify stable works as promised, and do test all packages (to this end we could need a scripted batch test system). Any problem encountered will be reported and have to be fixed ASAP. Packages not fixed by the end of this phase will be temporarily removed from stable. Also during this period, I will compile a list of packages that do not conform the license policy and will make that list public, to give maintainers a last chance to get their package compliant. Only packages that comply to the license policy can get into the bin dist. If required, this phase can be prolonged, if sever problem occur which have to be resolved first. The decision to do so will be made by the core developers, via discussion & consent on fink-devel. 3) Deep freeze Two days before the scheduled release date, we go into deep freeze mode. No change may be made to CVS in this time, except to fix mission critical bugs. That includes unstable. CVS will be tagged with a special tag at the beginning of this period. Ideally, a prerelease distro will be made available, too, but I am not sure how and whether at all this will work out (gotta think about it). I'll upload the bin dist in this time, and prepare everything else for the actual release. In the case of severe problems during this phase, we'll go back to phase 2 until the problems are resolved, at which point phase three 3 anew (with a new CVS tag). 4) Release If all worked out in the steps above, CVS will be tagged for the release version, and the binary installer/source distro will be released on SourceForge, the bin dist will be enabled for public use (ideally this means change of a single file) III) Binary Distro ================== For now, the binary distro will continue to be only updated on each full distro release. In the future, we may try to come up with a system that allows for greater update frequency. Some parameters: 1) The build enviroment will be fixed (i.e. I'll mark the exact machine/OS revision/compiler version). We will note these and other parameter so that we can reproduce the build setting later on if required. 2) For now, packages will probably still be built only by me. In the future, we'll want to extend this to a couple of other people. However, it's mandatory that these be team members, available, and guranteed to be trusted. We can't just take binaries from everybody, for security reaons. Identify of people submitting packages will have to be verified before their binaries can be put into the bindist. I'd like to encourage others to do likewise. BTW; you don't need a full clean system for this; you can also rename your /sw dir for the testing period, and bootstrap a new one (you can restore you real sw dir back later on this way). The idea of this phase is to catch any stable-only problems (like dependencies that can only be fullfiled in unstable, etc., happens easily). UPDATE: Finally, thanks to recent events, I am now always testing a stable system on an external Dual-800 G4. More on this in another mail soon. Cheers, Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
