jerome lacoste wrote: > Note I am not trying to be a pain in the butt here.
:) I meant I know the fact that the issue could have been moved up to 2.0.1 was the pain, not you. > I am just saying > that there was something that could have been done better and that I > hope won't happen again. I'm aware of that, but I'm trying to remind you to differentiate between "could have been done better" and "being done worse". Yes, the change could have been included, but it not being so didn't delay it's original timeline. > So the question is are we sure that this > won't happen again? I am not convinced. Why? Nothing below in your response indicates it would be a recurring problem. No process is foolproof, mistakes will be made. I can guarantee one will happen again. But I'm pretty sure I've sufficiently explained that our process, now that it's set up, covers this case. > I will try to summarize the problems I see: the only way for me to > know about the fact that my issue wasn't fixed in the forthcoming > release was to read the vote email on the developer list. I missed it. > I also forgot to watch the issue in Jira (why isn't that automatic for > the reporter?) My bad. It is automatic - we didn't change, or look at, the original issue. FWIW, we might well have if JIRA let you edit closed issues. I'll go and look into requesting that on their site. > - why the issue wasn't considered for the branch in the first place? > It was marked as critical in Jira and was a one liner. Is there > something we can do to Jira to mark them better? The problem was it was closed. > - if you cannot review all the issues, make sure we can help. Either > add a message to all issues in Jira "please help us triage these > issues before the forthcoming branch." Jira has a bulk edit mode (I > checked it and it works on the projects I have edit rights), so it > still can be used there. I can't do it though. It doesn't work on closed issues. > - of all the 60 assembly plugin issues, only 18 are marked today with > "no fix version" but "fixed" in Jira. Of all these, only 4 are marked > as critical or above. (funny part, all of these were reported by > me...). All had a patch. The blocker one even had 2 votes (3 if you > include me) and wasn't considered neither. The patch looks complex but > is very very simple if you look at the issue comments. Ok, so we were scared off from something that could have been simple. Lesson learned if we do this on any other plugins (which is unlikely). > - "since we only split out the JIRA projects recently, we didn't know > which were in 2.0 and which were more recent". svn integration in Jira > could have helped with that. Shouldn't this be implemented? It is implemented, but it only matches by keys, not by date. It would still require reopening all the the issues, one by one. > - if you release a branch, make this information more prominent. > Branch don't seem to be that usual in the current plugin release > process. Maybe add the word branch in the vote title, maybe send the > message in another channel (not just the dev list). If the effort is > made to make a branch, backport patches, vote release, why not spend > it to review some issues and make sure the community isn't surprised? I think we already tried to do this, and noted that it needs to be more prominent. Really what should have happened was a mail to the dev list when work started on the branch to say what was happening. That probably would have been noticed. > - each plugin is released with its own version in a very loosed couple > manner. I find it pretty hard to follow what's going on and how it's > going to affect my builds (I've seen wrong dependencies in pom). I > guess the process is going to become better later on, but my > experience with other systems that handle dependencies let me think > that issues in this area won't go away. People make mistakes. This doesn't seem to have any suggestion attached to it :) What was your point? > Assembly plugin within a multi-project doesn't work for me right now. > No more no less. > For me that's a show stopper. And that seems to be a show stopped for > at least 2 other persons. I couldn't grok that anywhere from the description of comments originally. > PS: I could have used a very small part of the time spent writing > these mails to prepare and release 2.0.2. > * I can't. Is there any interest in releasing a 2.0.2? If so how can I help? sure you can! - reopen the issue and attach a patch against the branch. - more patches against 2.1 issues to get that out faster (obviously preferred) > * if I send these mails it's in the hope that things will be better > next time. If you think I am wasting your time, let me know (or ignore > them, but I'd prefer to know...). Calling us on mistakes is good, otherwise it probably would happen again. But some feedback: - you've been pretty verbose. I think a lot of questions were repeated and facts introduced to prove your point, often after your point was proven and accepted. I've judged that on the fact I've repeated the same answers, so that might not necessarily be correct. However, I did think this was pretty much accepted and resolved from the first mail in this thread. - your tone seemed accusatory rather than constructive. We're not out to get you :) I probably didn't help by being excessively short in responses, but that's just how I am. You don't need to respond to these - if you don't agree that's fine, just my 2 cents. Thanks, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
