On the 0x2EC day of Apache Harmony Alexei Zakharov wrote: > I also think that two months period is well balanced. As well as two > weeks for feature freeze. So I am +1. > > Egor Pasko wrote: > > > 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. > > I agree with Egor. The number of active committers is not so big > currently. So I think it is enough just to establish a good committing > policy and let the committer to decide for himself about each commit. > We may always find the author of bad commit and blame him publicly. > > > 2. why req tags for JIRA? Does this help committers to follow their > > areas of responsibility? > > IMO requirement tags will help to set right priorities to JIRAs. Say > you have a patch that greatly improves stability of some particular > scenario REQ1 but may affect performance of other scenarios in a bad > way. If the list of requirements is defined then you can set the > priority to critical and put [REQ1] into JIRA summary. Without this > tag it is not clear what this issue is critical for.
that makes sense, sounds good, thanks > Alexey Petrenko wrote: > > About M2 marking... Can we create something like "Target milestone" > > field in our JIRA with predefined values? > > Do we have enough power to customize JIRA in this way? > > Regards, > > 05 Jun 2007 09:06:48 +0400, Egor Pasko <[EMAIL PROTECTED]>: > > 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? > > > -- > Alexei Zakharov, > Intel ESSD > -- Egor Pasko
