process of releasing plugins & bug reports

[jerome lacoste <je...@gmail.com>]

Hi,

I've had a little issue with regard to the latest release of maven
assembly plugin. Mostly because some issues I had reported and fixed
almost 3 months ago didn't make it into the release.

So I am being told that 1- there was a description of the issues to be
fixed, and 2- there was a 72h vote. I don't deny that, but this is not
enough for me.

First even though I've spent some time using maven or writing a couple
of plugins, I don't feel that I should intervene much on the dev list.
So I don't read it everyday.

Second, maven introduced a new concept here: its plugins are released
on a case by case basis. This makes it very powerful, but makes us
having to be careful all the time. With all the other open source
programs I follow up, there's a traditional beta or rc release that I
can test and notify the developers when they missed one issue I cared
for (in particular if I've provided a patch). That doesn't work here.
And no, I can't read every single message on every single developer
list of all the projects I am using to be sure that my fixes make it
into the programs I use.

When a milestone is about to be released, there should probably be a
way for us bug reporters to know. That's why I proposed to use Jira:
targeting an issue to a future release will notify me and I can react.

So maybe you have a better solution, but clearly there needs to be
something to accommodate the life for those like me who cannot spend
their time going through 1000s of emails on 10s of mailing lists.

Thanks for your understanding,

Jerome, just trying to improve the process

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: process of releasing plugins & bug reports

[Brett Porter <br...@apache.org>]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: process of releasing plugins & bug reports

[jerome lacoste <je...@gmail.com>]

On 2/1/06, Brett Porter <br...@apache.org> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: process of releasing plugins & bug reports

[Brett Porter <br...@apache.org>]

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. 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.

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.

[snip part based on the assumption we reviewed all 60 assembly issues]

> 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.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: process of releasing plugins & bug reports

[jerome lacoste <je...@gmail.com>]

On 1/30/06, Brett Porter <br...@apache.org> wrote:
> As I explained in response to your previous message, we already do that.
> You fixes were scheduled for, and always have been scheduled for 2.1.

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

Same for

http://jira.codehaus.org/browse/MASSEMBLY-35

> 2.1 has not been delayed in any way. 2.0.1 was pushed up with some bug
> fixes that were represented as more critical.
>
> As soon as the outstanding 2.1 bugs/features are completed, it will be
> released. If you now feel your bugfix is very critical, then it can be
> considered for backporting to the 2.0.x branch and a 2.0.2 release can
> be made. The lack of versions in JIRA back to 3 months ago limited our
> ability to do that.

To me it's critical. I initially reported it as Critical in Jira. Next
time should I make it a blocker?

I added this in the first lines of the issue description.

"[I hope this can be looked into before official 2.0 otherwise that
could create issues with regard to breaking existing code. Making
critical for this reason]"

On IRC, when I saw that it missed 2.0 I am pretty certain someone told
me that 2.0.1 would be out soon (to me implying that it would be in).

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?).

WRT to backport, I asked in another mail thread to backport it and
make a 2.0.2. 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.

> As for betas of plugins - that's definitely something we'd like to do
> but we don't have the repository separation setup right now. What we ask
> people to do is test snapshots instead. Perhaps a better idea is to push
> that to the users@ list for greater notice. When we have the announce@
> list that will be different.

OK. That sounds good.

Jerome

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: process of releasing plugins & bug reports

[Brett Porter <br...@apache.org>]

As I explained in response to your previous message, we already do that.
You fixes were scheduled for, and always have been scheduled for 2.1.

2.1 has not been delayed in any way. 2.0.1 was pushed up with some bug
fixes that were represented as more critical.

As soon as the outstanding 2.1 bugs/features are completed, it will be
released. If you now feel your bugfix is very critical, then it can be
considered for backporting to the 2.0.x branch and a 2.0.2 release can
be made. The lack of versions in JIRA back to 3 months ago limited our
ability to do that.

As for betas of plugins - that's definitely something we'd like to do
but we don't have the repository separation setup right now. What we ask
people to do is test snapshots instead. Perhaps a better idea is to push
that to the users@ list for greater notice. When we have the announce@
list that will be different.

- Brett

jerome lacoste wrote:
> Hi,
> 
> I've had a little issue with regard to the latest release of maven
> assembly plugin. Mostly because some issues I had reported and fixed
> almost 3 months ago didn't make it into the release.
> 
> So I am being told that 1- there was a description of the issues to be
> fixed, and 2- there was a 72h vote. I don't deny that, but this is not
> enough for me.
> 
> First even though I've spent some time using maven or writing a couple
> of plugins, I don't feel that I should intervene much on the dev list.
> So I don't read it everyday.
> 
> Second, maven introduced a new concept here: its plugins are released
> on a case by case basis. This makes it very powerful, but makes us
> having to be careful all the time. With all the other open source
> programs I follow up, there's a traditional beta or rc release that I
> can test and notify the developers when they missed one issue I cared
> for (in particular if I've provided a patch). That doesn't work here.
> And no, I can't read every single message on every single developer
> list of all the projects I am using to be sure that my fixes make it
> into the programs I use.
> 
> When a milestone is about to be released, there should probably be a
> way for us bug reporters to know. That's why I proposed to use Jira:
> targeting an issue to a future release will notify me and I can react.
> 
> So maybe you have a better solution, but clearly there needs to be
> something to accommodate the life for those like me who cannot spend
> their time going through 1000s of emails on 10s of mailing lists.
> 
> Thanks for your understanding,
> 
> Jerome, just trying to improve the process
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org