On 2/1/06, Brett Porter <[EMAIL PROTECTED]> wrote: > jerome lacoste wrote: > > Sorry but it's not marked as such in Jira > > > > http://jira.codehaus.org/browse/MASSEMBLY-19 > > > > Component/s: None > > Affects Version/s: None > > Fix Version/s: None > > > > I know its a pain in the butt, but I will reiterate.
Note I am not trying to be a pain in the butt here. I am just saying that there was something that could have been done better and that I hope won't happen again. So the question is are we sure that this won't happen again? I am not convinced. > We created the JIRA > projects *after* the bugs were resolved. We didn't have enough > information to go back and figure out which belonged to which version. OK > Nothing wrong with the process, the past data was floored. Sorry, but I > can't fix it now. And again, I need to point out the release of your > issue has not been delayed. 2.0.1 wasn't originally planned. Didn't know that. OK. > [snip part based on the assumption we reviewed all 60 assembly issues] Misunderstanding. I didn't assume you reviewed all issues. More on that below. 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. Could there have been more things that made me able to not miss that? I believe so. - 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? - 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. - 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. - "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? - 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? - 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. > > I don't know what else I could do appart from notifying you that it > > wasn't included in the forthcoming release. I missed the vote mail > > (which maybe shouldn't be on the dev list?). > > Right. The proposed solution was already given. > > WRT to backport, I asked in another mail thread to backport it and > > make a 2.0.2. > > I replied here before reading that, sorry. > > > I feelt that the longer you stay with this issue in the > > code, the more you have a chance to break existing user configurations > > who will do the upgrade. > > I think once its released, the time in between is irrelevant as people > don't always upgrade as soon as there is a release. > > Reviewing the issue, I don't get it. I can see how its a breaking > change, but I don't see how anyone would consider the previous behaviour > anything but a bug (its ignoring outputDirectory, right?) I don't see > this as urgent. We do need to prioritise the 2.1 release anyway. 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. 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? * 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...). Jerome --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
