Good idea. I'll add a reminder note about ASF release policy to the website.
You mentioned, 'it would be good to advertise the ability to vote for JIRAs.' Can you share what your thought is for using voting for JIRAs? Would this be used to persuade the release manager to include a fix or to get help from the community to fix something? Will release manager look at the most voted on JIRAs and give them a higher weight? On 8/27/08, ant elder <[EMAIL PROTECTED]> wrote: > > I also share the concerns Luciano mentioned, maybe what we need is just > some more documentation about how ASF releases get done instead of trying to > change the release process, it would be good to advertise the ability to > vote for JIRAs. > > Just to remind what the ASF release policy is: anyone can do a release with > whatever contents they want they only requirement is it gets at least three > PMC +1s and more +1s than -1s, releases can't be vetoed so a -1 does not > block a release. So the way to get something into a release is to do it > yourself or persuade the release manager and developers to get the changes > done. > > ...ant > > On Wed, Aug 27, 2008 at 4:46 AM, haleh mahbod <[EMAIL PROTECTED]> wrote: > >> You have a valid concern. I thought about this potential bottleneck as >> well. The answer to the issue that you raised can be as easy as if someone >> wants a fix in a release, they either watch it get prioritized against other >> things that volunteers work on or they provide a patch to help get the >> content in. >> >> Let me explain what led to the 'how do I get my JIRAs into a release' >> question. As I went through the Tuscany workshop material [1] that you and I >> presented to promote Tuscany and Apache open source, I came across this >> question that was asked by a few. I looked at the website for this >> information and I could not find anything. This made me realize that there >> is nothing about how releases happen and there is no known way for how to >> participate in the discussion and form the content of a release. >> >> As you mentioned, "currently we don't have any formal process to nominate >> features and >> jiras to a given release." In fact, each release has taken a different >> approach. Sometimes it is initiated by an email, sometimes the content is >> put on a wiki, etc. >> >> This lack of information is causing the confusion and question that was >> raised. This is probably not apparent to those who watch and participate in >> the mailing list every day. However, there are users who would like to >> participate in the process and miss these release content gathering windows >> that sometimes do take some time. As we learned from the workshop, there are >> even users who don't know they can participate in these discussions! This >> led me to the question that I asked to see if there can be a published and >> known way for how Tuscany determines the release content and to allow >> users/developers to proactively participate in the discussions. >> >> *The goal is to have clear communication and to allow for maximum >> participation regardless of what approach is taken.* So, with this >> background information, which I should have shared earlier, what do others >> think? >> >> [1]:http://tuscany.apache.org/working-in-open-source.html >> >> Haleh >> >> On 8/26/08, Luciano Resende <[EMAIL PROTECTED]> wrote: >>> >>> Sorry for jumping on the thread when it's already in close mode, but >>> let me express my thoughts on this subject. >>> >>> Currently we don't have any formal process to nominate features and >>> jiras to a given release. Having said that, the whole community can >>> come at any given time and suggest a given feature or jira to be >>> included in a release, or even suggest minor releases for specific >>> issues (as we saw with 1.2.1 and 1.3.1). If we introduce a formal >>> process (e.g "Blocker" and "Critical" jiras must get into the release) >>> I'm worried this would have some undesired side effects, and would >>> force us to stop doing frequent releases, as we will have to wait for >>> all the jiras in these categories to get fixed. Having said that, I >>> believe we haven't missed any important JIRA that contains a patch in >>> our past releases. >>> >>> >>> On Tue, Aug 26, 2008 at 12:29 PM, haleh mahbod <[EMAIL PROTECTED]> >>> wrote: >>> > Any more comments? If not, I document this on the website. >>> > >>> > On 8/22/08, Ramkumar R <[EMAIL PROTECTED]> wrote: >>> >> >>> >> +1 from me. >>> >> >>> >> On Fri, Aug 22, 2008 at 12:08 PM, haleh mahbod <[EMAIL PROTECTED]> >>> wrote: >>> >>> >>> >>> Taking a vote at the beginning of each release cycle can be one way >>> of >>> >>> handling prioritization. >>> >>> >>> >>> It really does not matter if there is a prefect approach for >>> handling >>> >>> this as long as there is an approach that is understood by all. The >>> chosen >>> >>> approach can always be improved if it does not work. >>> >>> >>> >>> So far, one combined approach based on the feedback might be to use >>> JIRA >>> >>> priorities and consider including blocking JIRAs for the next release >>> as >>> >>> well as the most voted Critical, Major and Minor JIRAS. Voting can be >>> >>> done at the end of the release cycle for the start of the next >>> release. I am >>> >>> assuming that JIRAs here mean issues as well as feature requests. >>> >>> >>> >>> Does this seem like a good first try? >>> >>> >>> >>> On 8/21/08, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: >>> >>>> >>> >>>> JIRA itself provides for voting for an issue (look for Voting link >>> under >>> >>>> Operations when viewing a JIRA). Are you suggesting to have a vote >>> after >>> >>>> each release on what are the top features and bugs to be addressed >>> in the >>> >>>> next release? >>> >>>> >>> >>>> ++Vamsi >>> >>>> >>> >>>> On Thu, Aug 21, 2008 at 11:41 PM, Dan Becker < >>> [EMAIL PROTECTED]> >>> >>>> wrote: >>> >>>>> >>> >>>>> Oh, I agree. I like the idea of a vote to help prioritize issues. I >>> >>>>> believe several developer sites have some system like this where >>> each >>> >>>>> developer gets to vote for their top 3 bugs or feature requests. >>> >>>>> >>> >>>>> haleh mahbod wrote: >>> >>>>>> >>> >>>>>> These are good suggestions. However, what if my JIRAs are of the >>> >>>>>> major or >>> >>>>>> minor category. Will I have a chance to provide a weight for the >>> major >>> >>>>>> JIRAs >>> >>>>>> that I would like >>> >>>>>> to have considered. IMO That's where vote can be helpful to decide >>> >>>>>> which of >>> >>>>>> the Major or Minor JIRAs are wanted by many users. This can also >>> be >>> >>>>>> useful >>> >>>>>> for making decisions for critical JIRAs. >>> >>>>>> >>> >>>>>> >>> >>>>>> On 8/21/08, Dan Becker <[EMAIL PROTECTED]> wrote: >>> >>>>>>> >>> >>>>>>> I like the idea of adding some release meta-info to the priority >>> >>>>>>> levels. >>> >>>>>>> However I would slightly clarify your wording on the >>> release info >>> >>>>>>> for the >>> >>>>>>> priority levels: >>> >>>>>>> >>> >>>>>>> *Blocker* - Must have. Release not complete until issue is >>> resolved. >>> >>>>>>> *Critical" - Should have. Release not complete until issue is >>> >>>>>>> resolved or >>> >>>>>>> all parties agree to drop/postpone until next release. >>> >>>>>>> *Major* - Likely have. Release is likely to have issue resolved. >>> >>>>>>> However >>> >>>>>>> due to workload or other major blocking items issue may be >>> postponed. >>> >>>>>>> *Minor* - May have. Issue is low priority for this release and >>> will >>> >>>>>>> be >>> >>>>>>> completed for release time permitting. >>> >>>>>>> *Trivial* - May have. Issue is low priority for this release and >>> may >>> >>>>>>> be >>> >>>>>>> completed for release time permitting. >>> >>>>>>> >>> >>>>>>> It is a similar idea to yours, and I tried to put a >>> release-related >>> >>>>>>> statement next to each level. >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> Ramkumar R wrote: >>> >>>>>>> >>> >>>>>>>> One way, I could think as a solution to this issue is to >>> re-define >>> >>>>>>>> the >>> >>>>>>>> definitions of the existing priority levels in the JIRA system. >>> An >>> >>>>>>>> issue >>> >>>>>>>> has >>> >>>>>>>> a priority level which indicates its importance. >>> >>>>>>>> >>> >>>>>>>> The currently defined priorities are shown below. >>> >>>>>>>> *Blocker* Blocks development and/or testing work, production >>> could >>> >>>>>>>> not >>> >>>>>>>> run >>> >>>>>>>> *Critical* Crashes, loss of data, severe memory leak. *Major* >>> Major >>> >>>>>>>> loss >>> >>>>>>>> of >>> >>>>>>>> function. *Minor* Minor loss of function, or other problem >>> where >>> >>>>>>>> easy >>> >>>>>>>> workaround is present. *Trivial* Cosmetic problem like misspelt >>> >>>>>>>> words or >>> >>>>>>>> misaligned text. >>> >>>>>>>> I believe, re-defining what this priority level means for a >>> release >>> >>>>>>>> as >>> >>>>>>>> shown >>> >>>>>>>> below would help. >>> >>>>>>>> *Blocker* Release will not be completed until issue is >>> resolved. >>> >>>>>>>> *Critical >>> >>>>>>>> * Issue will most likely be resolved for release. *Major* Issue >>> >>>>>>>> should be >>> >>>>>>>> resolved for release. *Minor* Issue may be resolved for >>> release. >>> >>>>>>>> *Trivial* Issues >>> >>>>>>>> that might be resolved before a release. >>> >>>>>>>> >>> >>>>>>>> OR another way to achive the same would be to add additional >>> >>>>>>>> priprity >>> >>>>>>>> levels >>> >>>>>>>> (other the default levels) at the admistration section of the >>> JIRA >>> >>>>>>>> system. >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>> -- >>> >>>>>>> Thanks, Dan Becker >>> >>>>>>> >>> >>>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> -- >>> >>>>> Thanks, Dan Becker >>> >>>> >>> >>> >>> >>> >>> >> >>> >> >>> >> -- >>> >> Thanks & Regards, >>> >> Ramkumar Ramalingam >>> >> >>> > >>> >>> >>> >>> -- >>> Luciano Resende >>> Apache Tuscany Committer >>> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> >>> http://lresende.blogspot.com/ >>> >> >> >> > >
