ok for me. > So, in detail:
> Every three months (fixed date) we copy the current `unstable' into > `frozen'. At this point `stable', `frozen' and `unstable' should all > stay interoperable both in source and binary form. alternative : seperate place for new uploads and unstable, but well known packages. package developers do uploads. they always go to the place for new packages. "quality keepers" can promote a package from "the new place" to "unstable". a sample guideline could be : this package has been in use for 10 days, and nobody complained about it, and there was no new upload of the package. this "unstable" will be frozen every 3 months. also an old version shouldn't be thrown away automaticaly. the additional step might save us some problems with "new xx is in, but new libxx isn't", or "people found out that it's broken, but there was no new upload since that". the current testing scheme is : a) one developer (or two or three) test a package b) then all 300 developers test the package, because it's in unstable. it would realy realy nice to have some group in the middle with ca. 30 people or so. too much time is spend by debian developers, because they need to be relative up to date, but they get some broken packages and fail because of that. > Bugfixes must be applied to frozen, and important ones to stable too. > After one or two months of beta frozen should be stable enough to > release. not directly to stable. IMO the hamm/ archive and the cdroms should never be changed after release. instead we should have an errate directory, with a detailed explenation for every updated package (available as text and html, so sgml could be used). > We also need to make automatic building a real possibility. till end of juli i'm busy but then i can work on this. maybe earlier, but don't count on that. andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
