On the 0x2EC day of Apache Harmony Mikhail Loenko wrote: > Let's have end of month (June, 30?) as a release date. Now we need to > define a date for code freeze (when only critical bugs are fixed) and > define how we will commit between code freeze and release (each commit > approved by one more committer?)
one should be enough. I think, the common process should be well applicable here: we will have comitter responsibility, discussions over dev@, etc. No reason for tight commit process, IMHO. Tightening commit criteria requirements (that you are proposing) is good. > I think the code freeze date should depend on the longest test cycle > we have (I've seen somewhere about 48-hour scenarios?) and be ~2-3 > cycles (1 week?) prior the release. > > We also need a feature freeze date (1-2 weeks prior code freeze?) when > no major changes or redesigns are allowed. reasonable, thanks 2 weeks for feature freeze before M2 should be OK, IMHO > And we need to set up requirements for the release. We already see a > good wish-list here. The only concern I have is that its focus is > almost everything: stability, performance, and completeness. Though I > completely agree with each of these directions, I have a feeling that > having everything in focus means not having a focus. > > So I propose that we go this way: we have directions, we already > discussed them many times. Now let's create requirements based on the > list of directions: *each person who adds something to requirements is > committing to and will be responsible for meeting that requirement* > > The requirements could be to have something specific in stability, > have something specific in performance, completeness, java6, etc > > Once we compose a list, say 1..N of requirements, we create keys or > tags for JIRA, say M2-REQ1, ..., M2-REQN and mark bugs affecting > requirements with these key words. So each person would easily find > bugs affecting requirements he is responsible for. 1. why numbering? let it be descriptive requirement names. Example: M2-req-stable-linux-x86_64-regression-tests 2. why req tags for JIRA? Does this help committers to follow their areas of responsibility? If so, they could, please, please, speak up. I thought, all guys follow their bugs, have reasonable priorities regarding them, etc, etc. I do not mind such a small "commit process enhancement", but there is nothing but an extra burden in it for me) > Comments? Requirement proposals? -- Egor Pasko
