subject:"Cleanup"



slachiewicz commented on pull request #4:
URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636504356


   I use the plexus version that was imported by the Maven 3.1 dependencies 
(3.1.1 already has a different version). It seems to me that if we use a newer 
version of Plexus and someone uses the classes/methods that were available 
before then this plugin may not work properly. I think Maven 3.1 will use 
artifacts that are provided by Core 
(https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml)



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-shared-jar] elharo commented on pull request #4: [MSHARED-887] set Maven 3.1.0 as minimum and cleanup dependencies



elharo commented on pull request #4:
URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636486988


   @slachiewicz After looking at that commit, the difference seems to be that 
this PR imports plexus-containers-default and that one imports 
org.eclipse.sisu.plexus. 
   
   I'm not sure why one should be chosen over the other or why two different 
artifacts provide the same classes. 
   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-shared-jar] elharo commented on pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies



elharo commented on pull request #4:
URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636474949


   That code doesn't seem to be in HEAD? 



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-shared-jar] slachiewicz commented on pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies



slachiewicz commented on pull request #4:
URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636472449


   
https://github.com/apache/maven-shared-jar/commit/580f53c1b63a7630cb3a70822035f4531bfadf2b



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-shared-jar] slachiewicz edited a comment on pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies



slachiewicz edited a comment on pull request #4:
URL: https://github.com/apache/maven-shared-jar/pull/4#issuecomment-636472449


   See other jira and commit 
https://github.com/apache/maven-shared-jar/commit/580f53c1b63a7630cb3a70822035f4531bfadf2b



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-shared-jar] elharo opened a new pull request #4: [MSHARED-905] set Maven 3.1.0 as minimum and cleanup dependencies



elharo opened a new pull request #4:
URL: https://github.com/apache/maven-shared-jar/pull/4


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-site-plugin] elharo commented on pull request #27: [MSITE-757] More cleanup after upgrade to Maven 3.0.5



elharo commented on pull request #27:
URL: https://github.com/apache/maven-site-plugin/pull/27#issuecomment-634132747


   seems to have broken Jenkins: 
https://builds.apache.org/job/maven-box/job/maven-site-plugin/job/master/99/



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-site-plugin] slachiewicz opened a new pull request #27: [MSITE-757] More cleanup after upgrade to Maven 3.0.5



slachiewicz opened a new pull request #27:
URL: https://github.com/apache/maven-site-plugin/pull/27


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-site-plugin] slachiewicz commented on pull request #27: [MSITE-757] More cleanup after upgrade to Maven 3.0.5



slachiewicz commented on pull request #27:
URL: https://github.com/apache/maven-site-plugin/pull/27#issuecomment-633969397







This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

[GitHub] [maven-site-plugin] slachiewicz closed pull request #27: [MSITE-757] More cleanup after upgrade to Maven 3.0.5



slachiewicz closed pull request #27:
URL: https://github.com/apache/maven-site-plugin/pull/27


   



This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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

Re: Yearly JIRA cleanup

2019-12-23 Thread Elliotte Rusty Harold

This morning I finished reviewing the last of these issues. Only four
remain untouched, all of which were previously autoclosed and
reopened, so we shouldn't autoclose them again.

I didn't keep track of exact numbers of how many I closed,
reprioritized, duped, marked abandoned etc. There were a number of
issues that had long comment threads related to proposed fixes and
changes, indicating that a lot of work and thought had gone into them
but ultimately didn't lead anywhere. In these cases, I tried to make
my best judgement based on the thread as to whether the issue deserved
to stay open or not. Since everything in the list was already
scheduled for closure, I was more aggressive than usual about "Won't
Fixing" and closing issues. If any seem to you to be closed in error,
you're probably right. Please reopen them.

There were a lot of new feature requests that were incomplete and hard
to follow. There were also many patches submitted by non-committers
that had never been reviewed. We might want to rethink how we accept
new feature and model change requests. Filing such a request in Jira
seems likely to lead to a frustrating experience for contributors and
reviewers alike. Perhaps we can ask for more formal design proposals
in a doc outside of Jira that is discussed on the dev mailing list
first before it gets added to the Jira and reserve Jira only for new
features we actively want to do. I'm not sure. But I would prefer not
to be back in this place five years from now.

On Fri, Dec 20, 2019 at 7:14 AM Tibor Digana  wrote:
>
> sorry for typo, in the backlog they should not be closed because they are
> serious bugs and need to be fixed.
>
> On Fri, Dec 20, 2019 at 1:11 PM Tibor Digana  wrote:
>
> > I want to review the closed issues as well i would like to come up with
> > those which should be reopened to a certain release version.
> > I guess the release version should be set in such case.
> > We have also backlog version and that's the place where the issues should
> > be closed be the version has not been proposed yet.
> >
> > On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold 
> > wrote:
> >
> >> One thing we should try going forward is be more ready to won't fix
> >> and close bugs and RFEs we disagree with. I've seen several examples
> >> where the comments indicate the maintainers did not agree with the
> >> issue, but it still wasn't closed. E.g.
> >>
> >> https://issues.apache.org/jira/browse/SUREFIRE-1227
> >>
> >> Closing an issue is not irrevocable. Issues can always be reopened, if
> >> the reporter or anyone else disagrees. Indeed it is more respectful to
> >> reporters to be politely honest with them about our true objections,
> >> rather than simply ignoring the issue and not responding.
> >>
> >> On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
> >>  wrote:
> >> >
> >> > While working through the bugs I found this interesting bit of history:
> >> >
> >> >
> >> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
> >> >
> >> > It seems like we've been here before. Some of the bugs that were
> >> > autoclosed then were reopened and are now scheduled for autoclose
> >> > again. Any thoughts about how we might update our processes to avoid
> >> > getting into this situation again?
> >> >
> >> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov 
> >> wrote:
> >> > >
> >> > > Hi folks,
> >> > >
> >> > > after at least one year of silence, I'd like to perform another JIRA
> >> > > issue cleanup for issues which have been not touched for more than
> >> three
> >> > > years.
> >> > >
> >> > > Query:
> >> > >
> >> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >> > >
> >> > > Stats:
> >> > >
> >> > > 567 issues not touched for more than three years
> >> > > of which
> >> > > * 68 have fix version set
> >> > > * 36 were already reopened, should they be excluded?
> >> > > * 1 in progress by Karl
> >> > >
> >> > > Type breakdown:
> >> > > * 200 bugs
> >> > > * 164 improvements
> >> > > * 72 new features
> >> > > * 6 subtasks
> >> > > * 13 tasks
> >> > > * 12 wishes
>

Re: Yearly JIRA cleanup

2019-12-20 Thread Tibor Digana

sorry for typo, in the backlog they should not be closed because they are
serious bugs and need to be fixed.

On Fri, Dec 20, 2019 at 1:11 PM Tibor Digana  wrote:

> I want to review the closed issues as well i would like to come up with
> those which should be reopened to a certain release version.
> I guess the release version should be set in such case.
> We have also backlog version and that's the place where the issues should
> be closed be the version has not been proposed yet.
>
> On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold 
> wrote:
>
>> One thing we should try going forward is be more ready to won't fix
>> and close bugs and RFEs we disagree with. I've seen several examples
>> where the comments indicate the maintainers did not agree with the
>> issue, but it still wasn't closed. E.g.
>>
>> https://issues.apache.org/jira/browse/SUREFIRE-1227
>>
>> Closing an issue is not irrevocable. Issues can always be reopened, if
>> the reporter or anyone else disagrees. Indeed it is more respectful to
>> reporters to be politely honest with them about our true objections,
>> rather than simply ignoring the issue and not responding.
>>
>> On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
>>  wrote:
>> >
>> > While working through the bugs I found this interesting bit of history:
>> >
>> >
>> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
>> >
>> > It seems like we've been here before. Some of the bugs that were
>> > autoclosed then were reopened and are now scheduled for autoclose
>> > again. Any thoughts about how we might update our processes to avoid
>> > getting into this situation again?
>> >
>> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov 
>> wrote:
>> > >
>> > > Hi folks,
>> > >
>> > > after at least one year of silence, I'd like to perform another JIRA
>> > > issue cleanup for issues which have been not touched for more than
>> three
>> > > years.
>> > >
>> > > Query:
>> > >
>> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
>> > >
>> > > Stats:
>> > >
>> > > 567 issues not touched for more than three years
>> > > of which
>> > > * 68 have fix version set
>> > > * 36 were already reopened, should they be excluded?
>> > > * 1 in progress by Karl
>> > >
>> > > Type breakdown:
>> > > * 200 bugs
>> > > * 164 improvements
>> > > * 72 new features
>> > > * 6 subtasks
>> > > * 13 tasks
>> > > * 12 wishes
>> > >
>> > > If there are issues still valid for you please leave a comment on the
>> > > issue and they will not appear in the query anymore.
>> > > Please also raise your voice if you have anything to discuss.
>> > >
>> > > If the issue is not modified or no objection has been raised, I will
>> > > autoclose those issues with a comment by 2019-12-30.
>> > >
>> > > Michael
>> > >
>> > > -
>> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> > > For additional commands, e-mail: dev-h...@maven.apache.org
>> > >
>> >
>> >
>> > --
>> > Elliotte Rusty Harold
>> > elh...@ibiblio.org
>>
>>
>>
>> --
>> Elliotte Rusty Harold
>> elh...@ibiblio.org
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: Yearly JIRA cleanup

2019-12-20 Thread Tibor Digana

I want to review the closed issues as well i would like to come up with
those which should be reopened to a certain release version.
I guess the release version should be set in such case.
We have also backlog version and that's the place where the issues should
be closed be the version has not been proposed yet.

On Fri, Dec 20, 2019 at 12:49 PM Elliotte Rusty Harold 
wrote:

> One thing we should try going forward is be more ready to won't fix
> and close bugs and RFEs we disagree with. I've seen several examples
> where the comments indicate the maintainers did not agree with the
> issue, but it still wasn't closed. E.g.
>
> https://issues.apache.org/jira/browse/SUREFIRE-1227
>
> Closing an issue is not irrevocable. Issues can always be reopened, if
> the reporter or anyone else disagrees. Indeed it is more respectful to
> reporters to be politely honest with them about our true objections,
> rather than simply ignoring the issue and not responding.
>
> On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
>  wrote:
> >
> > While working through the bugs I found this interesting bit of history:
> >
> >
> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
> >
> > It seems like we've been here before. Some of the bugs that were
> > autoclosed then were reopened and are now scheduled for autoclose
> > again. Any thoughts about how we might update our processes to avoid
> > getting into this situation again?
> >
> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov 
> wrote:
> > >
> > > Hi folks,
> > >
> > > after at least one year of silence, I'd like to perform another JIRA
> > > issue cleanup for issues which have been not touched for more than
> three
> > > years.
> > >
> > > Query:
> > >
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> > >
> > > Stats:
> > >
> > > 567 issues not touched for more than three years
> > > of which
> > > * 68 have fix version set
> > > * 36 were already reopened, should they be excluded?
> > > * 1 in progress by Karl
> > >
> > > Type breakdown:
> > > * 200 bugs
> > > * 164 improvements
> > > * 72 new features
> > > * 6 subtasks
> > > * 13 tasks
> > > * 12 wishes
> > >
> > > If there are issues still valid for you please leave a comment on the
> > > issue and they will not appear in the query anymore.
> > > Please also raise your voice if you have anything to discuss.
> > >
> > > If the issue is not modified or no objection has been raised, I will
> > > autoclose those issues with a comment by 2019-12-30.
> > >
> > > Michael
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Yearly JIRA cleanup

2019-12-20 Thread Elliotte Rusty Harold

Please share the new query for this. It would give me fewer issues to look at.

By the way, I've chopped the original list from over four hundred to
just over two hundred, learned a lot about Maven in the process, found
one or two gems that have serious impact at my day job, and identified
one truly scary security issue someone badly needs to look at.

On Fri, Dec 20, 2019 at 6:42 AM Michael Osipov  wrote:
>
> I will exlude those. It does not makes sense to close/reopen again.
>
> Am 2019-12-20 um 12:29 schrieb Elliotte Rusty Harold:
> > While working through the bugs I found this interesting bit of history:
> >
> > https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
> >
> > It seems like we've been here before. Some of the bugs that were
> > autoclosed then were reopened and are now scheduled for autoclose
> > again. Any thoughts about how we might update our processes to avoid
> > getting into this situation again?
> >
> > On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
> >>
> >> Hi folks,
> >>
> >> after at least one year of silence, I'd like to perform another JIRA
> >> issue cleanup for issues which have been not touched for more than three
> >> years.
> >>
> >> Query:
> >> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >>
> >> Stats:
> >>
> >> 567 issues not touched for more than three years
> >> of which
> >> * 68 have fix version set
> >> * 36 were already reopened, should they be excluded?
> >> * 1 in progress by Karl
> >>
> >> Type breakdown:
> >> * 200 bugs
> >> * 164 improvements
> >> * 72 new features
> >> * 6 subtasks
> >> * 13 tasks
> >> * 12 wishes
> >>
> >> If there are issues still valid for you please leave a comment on the
> >> issue and they will not appear in the query anymore.
> >> Please also raise your voice if you have anything to discuss.
> >>
> >> If the issue is not modified or no objection has been raised, I will
> >> autoclose those issues with a comment by 2019-12-30.
> >>
> >> Michael
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> >
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-20 Thread Elliotte Rusty Harold

One thing we should try going forward is be more ready to won't fix
and close bugs and RFEs we disagree with. I've seen several examples
where the comments indicate the maintainers did not agree with the
issue, but it still wasn't closed. E.g.

https://issues.apache.org/jira/browse/SUREFIRE-1227

Closing an issue is not irrevocable. Issues can always be reopened, if
the reporter or anyone else disagrees. Indeed it is more respectful to
reporters to be politely honest with them about our true objections,
rather than simply ignoring the issue and not responding.

On Fri, Dec 20, 2019 at 6:29 AM Elliotte Rusty Harold
 wrote:
>
> While working through the bugs I found this interesting bit of history:
>
> https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
>
> It seems like we've been here before. Some of the bugs that were
> autoclosed then were reopened and are now scheduled for autoclose
> again. Any thoughts about how we might update our processes to avoid
> getting into this situation again?
>
> On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
> >
> > Hi folks,
> >
> > after at least one year of silence, I'd like to perform another JIRA
> > issue cleanup for issues which have been not touched for more than three
> > years.
> >
> > Query:
> > https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >
> > Stats:
> >
> > 567 issues not touched for more than three years
> > of which
> > * 68 have fix version set
> > * 36 were already reopened, should they be excluded?
> > * 1 in progress by Karl
> >
> > Type breakdown:
> > * 200 bugs
> > * 164 improvements
> > * 72 new features
> > * 6 subtasks
> > * 13 tasks
> > * 12 wishes
> >
> > If there are issues still valid for you please leave a comment on the
> > issue and they will not appear in the query anymore.
> > Please also raise your voice if you have anything to discuss.
> >
> > If the issue is not modified or no objection has been raised, I will
> > autoclose those issues with a comment by 2019-12-30.
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-20 Thread Michael Osipov


I will exlude those. It does not makes sense to close/reopen again.

Am 2019-12-20 um 12:29 schrieb Elliotte Rusty Harold:

While working through the bugs I found this interesting bit of history:

https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014

It seems like we've been here before. Some of the bugs that were
autoclosed then were reopened and are now scheduled for autoclose
again. Any thoughts about how we might update our processes to avoid
getting into this situation again?

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA
issue cleanup for issues which have been not touched for more than three
years.

Query:
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC

Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the
issue and they will not appear in the query anymore.
Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will
autoclose those issues with a comment by 2019-12-30.

Michael

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







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

Re: Yearly JIRA cleanup

2019-12-20 Thread Elliotte Rusty Harold

While working through the bugs I found this interesting bit of history:

https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014

It seems like we've been here before. Some of the bugs that were
autoclosed then were reopened and are now scheduled for autoclose
again. Any thoughts about how we might update our processes to avoid
getting into this situation again?

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
>
> Hi folks,
>
> after at least one year of silence, I'd like to perform another JIRA
> issue cleanup for issues which have been not touched for more than three
> years.
>
> Query:
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
>
> Stats:
>
> 567 issues not touched for more than three years
> of which
> * 68 have fix version set
> * 36 were already reopened, should they be excluded?
> * 1 in progress by Karl
>
> Type breakdown:
> * 200 bugs
> * 164 improvements
> * 72 new features
> * 6 subtasks
> * 13 tasks
> * 12 wishes
>
> If there are issues still valid for you please leave a comment on the
> issue and they will not appear in the query anymore.
> Please also raise your voice if you have anything to discuss.
>
> If the issue is not modified or no objection has been raised, I will
> autoclose those issues with a comment by 2019-12-30.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-14 Thread Michael Osipov


Am 2019-12-13 um 16:08 schrieb Elliotte Rusty Harold:

NVM, I seem to have access now. I think I just needed to logout with
my old credentials and back in with the new ones.


Elliotte,

please go through the list and update those tickets you seen to be 
addressible within a decent timeframe.


Michael

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

Re: Yearly JIRA cleanup

2019-12-13 Thread Elliotte Rusty Harold

NVM, I seem to have access now. I think I just needed to logout with
my old credentials and back in with the new ones.

On Fri, Dec 13, 2019 at 9:56 AM Elliotte Rusty Harold
 wrote:
>
> On Thu, Dec 12, 2019 at 6:56 PM Stephen Connolly
>  wrote:
> > I think we have some crazy permissions that Brian manages. Ldap just fixes
> > the account name to match across systems AIUI
> >
>
> That's probably true. As of an hour ago, I did not seem able to close issues.
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org



-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-13 Thread Elliotte Rusty Harold

On Thu, Dec 12, 2019 at 6:56 PM Stephen Connolly
 wrote:
> I think we have some crazy permissions that Brian manages. Ldap just fixes
> the account name to match across systems AIUI
>

That's probably true. As of an hour ago, I did not seem able to close issues.


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-12 Thread Stephen Connolly

On Thu 12 Dec 2019 at 17:31, Robert Scholte  wrote:

> IIUC since Jira uses the ASF LDAP, there's no extra need for Brian to do
> this anymore. All should be in place by now.
>

I think we have some crazy permissions that Brian manages. Ldap just fixes
the account name to match across systems AIUI

>
> thanks,
> Robert
> On 12-12-2019 15:20:24, Stephen Connolly 
> wrote:
> On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold
> wrote:
>
> > On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov wrote:
> > >
> > > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > > Please don't. There are certainly some real and important issues in
> > > > there. More importantly, users spent a great deal of effort and time
> > > > to file those. Bulk closing them tells those users we don't value
> > > > their feedback or effort. It is useful to triage these issues and
> > > > consider them individually. Doubtless many of these issues are
> already
> > > > fixed, moot, or things we expressly chose not to do. However this
> > > > should be decided case by case. We can't simply close our eyes and
> > > > pretend they're all irrelevant.
> > >
> > > Hi Elliotte,
> >
> > > We have almost 2000 open issues. How would you reasonably sieve between
> > > them? even if you allocate 10 min per ticket, you would need two months
> > > of work to triage them.
> > >
> >
> > Use the time we have to fix as much as we can. Leave the rest open.
> > Some will never be touched but some will be when someone encounters
> > the same problem and finds the bug again. It's better to leave it open
> > and unaddressed than to close it without giving it a fair look.
> >
> > As to time spent triaging, it's worth considering whether permissions
> > could be opened up further. Right now, almost anyone can file a bug
> > but few people can resolve and close them. I can't, for example, even
> > when I see one that's clearly no longer relevant. :-(
>
>
> As soon as Brian fixes your JIRA permissions you’ll be able too... your
> committer status is only freshly minted! (welcome/congrats)
>
> Another issue is the lack of a clearly defined process for triage. We
> should document what we mean by triage and what outcomes we expect. That
> could even include closing stale issues after a check for active reporters
>
> >
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone
>
-- 
Sent from my phone

Re: Yearly JIRA cleanup

2019-12-12 Thread Robert Scholte

IIUC since Jira uses the ASF LDAP, there's no extra need for Brian to do this 
anymore. All should be in place by now.

thanks,
Robert
On 12-12-2019 15:20:24, Stephen Connolly  
wrote:
On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold
wrote:

> On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov wrote:
> >
> > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > Please don't. There are certainly some real and important issues in
> > > there. More importantly, users spent a great deal of effort and time
> > > to file those. Bulk closing them tells those users we don't value
> > > their feedback or effort. It is useful to triage these issues and
> > > consider them individually. Doubtless many of these issues are already
> > > fixed, moot, or things we expressly chose not to do. However this
> > > should be decided case by case. We can't simply close our eyes and
> > > pretend they're all irrelevant.
> >
> > Hi Elliotte,
>
> > We have almost 2000 open issues. How would you reasonably sieve between
> > them? even if you allocate 10 min per ticket, you would need two months
> > of work to triage them.
> >
>
> Use the time we have to fix as much as we can. Leave the rest open.
> Some will never be touched but some will be when someone encounters
> the same problem and finds the bug again. It's better to leave it open
> and unaddressed than to close it without giving it a fair look.
>
> As to time spent triaging, it's worth considering whether permissions
> could be opened up further. Right now, almost anyone can file a bug
> but few people can resolve and close them. I can't, for example, even
> when I see one that's clearly no longer relevant. :-(


As soon as Brian fixes your JIRA permissions you’ll be able too... your
committer status is only freshly minted! (welcome/congrats)

Another issue is the lack of a clearly defined process for triage. We
should document what we mean by triage and what outcomes we expect. That
could even include closing stale issues after a check for active reporters

>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Yearly JIRA cleanup

2019-12-12 Thread Stephen Connolly

On Mon 9 Dec 2019 at 20:53, Elliotte Rusty Harold 
wrote:

> On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov  wrote:
> >
> > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > > Please don't. There are certainly some real and important issues in
> > > there. More importantly, users spent a great deal of effort and time
> > > to file those. Bulk closing them tells those users we don't value
> > > their feedback or effort. It is useful to triage these issues and
> > > consider them individually. Doubtless many of these issues are already
> > > fixed, moot, or things we expressly chose not to do. However this
> > > should be decided case by case. We can't simply close our eyes and
> > > pretend they're all irrelevant.
> >
> > Hi Elliotte,
>
> > We have almost 2000 open issues. How would you reasonably sieve between
> > them? even if you allocate 10 min per ticket, you would need two months
> > of work to triage them.
> >
>
> Use the time we have to fix as much as we can. Leave the rest open.
> Some will never be touched but some will be when someone encounters
> the same problem and finds the bug again. It's better to leave it open
> and unaddressed than to close it without giving it a fair look.
>
> As to time spent triaging, it's worth considering whether permissions
> could be opened up further. Right now, almost anyone can file a bug
> but few people can resolve and close them. I can't, for example, even
> when I see one that's clearly no longer relevant. :-(


As soon as Brian fixes your JIRA permissions you’ll be able too... your
committer status is only freshly minted! (welcome/congrats)

Another issue is the lack of a clearly defined process for triage. We
should document what we mean by triage and what outcomes we expect. That
could even include closing stale issues after a check for active reporters

>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Yearly JIRA cleanup

2019-12-09 Thread Elliotte Rusty Harold

On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov  wrote:
>
> Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:
> > Please don't. There are certainly some real and important issues in
> > there. More importantly, users spent a great deal of effort and time
> > to file those. Bulk closing them tells those users we don't value
> > their feedback or effort. It is useful to triage these issues and
> > consider them individually. Doubtless many of these issues are already
> > fixed, moot, or things we expressly chose not to do. However this
> > should be decided case by case. We can't simply close our eyes and
> > pretend they're all irrelevant.
>
> Hi Elliotte,

> We have almost 2000 open issues. How would you reasonably sieve between
> them? even if you allocate 10 min per ticket, you would need two months
> of work to triage them.
>

Use the time we have to fix as much as we can. Leave the rest open.
Some will never be touched but some will be when someone encounters
the same problem and finds the bug again. It's better to leave it open
and unaddressed than to close it without giving it a fair look.

As to time spent triaging, it's worth considering whether permissions
could be opened up further. Right now, almost anyone can file a bug
but few people can resolve and close them. I can't, for example, even
when I see one that's clearly no longer relevant. :-(

-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-09 Thread Michael Osipov

Take your time, you have at least three weeks.

Am 2019-12-08 um 18:23 schrieb Tibor Digana:

Hi Michael,

What's up :-)
Thx for making the list of issues.
Pls give me one day to see it completely. I will get back to you tomorrow.

Cheers
Tibor17

On Sun, Dec 8, 2019 at 6:08 PM Elliotte Rusty Harold
wrote:

Please don't. There are certainly some real and important issues in
there. More importantly, users spent a great deal of effort and time
to file those. Bulk closing them tells those users we don't value
their feedback or effort. It is useful to triage these issues and
consider them individually. Doubtless many of these issues are already
fixed, moot, or things we expressly chose not to do. However this
should be decided case by case. We can't simply close our eyes and
pretend they're all irrelevant.

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote:

Hi folks,

after at least one year of silence, I'd like to perform another JIRA
issue cleanup for issues which have been not touched for more than three
years.

Query:

https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC

Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the
issue and they will not appear in the query anymore.
Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will
autoclose those issues with a comment by 2019-12-30.

Michael

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

--
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-09 Thread Michael Osipov

Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold:

Hi Elliotte,

I share your concerns. I do traverse through tickets once in a while and
check for samples projects. Please also feel free to go through the list
and update them.
At the end we need to be honest. I.e., if we weren't to triage them
within three years, we likely never won't. We honestly tell that we
acknowledge the issue, but are simply unable to do anything fruitful.

We have almost 2000 open issues. How would you reasonably sieve between
them? even if you allocate 10 min per ticket, you would need two months
of work to triage them.

Regards,

Michael

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote:

Hi folks,

after at least one year of silence, I'd like to perform another JIRA
issue cleanup for issues which have been not touched for more than three
years.

Query:
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC

Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the
issue and they will not appear in the query anymore.
Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will
autoclose those issues with a comment by 2019-12-30.

Michael

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

Re: Yearly JIRA cleanup

2019-12-08 Thread Tibor Digana

Hi Michael,

What's up :-)
Thx for making the list of issues.
Pls give me one day to see it completely. I will get back to you tomorrow.

Cheers
Tibor17

On Sun, Dec 8, 2019 at 6:08 PM Elliotte Rusty Harold 
wrote:

> Please don't. There are certainly some real and important issues in
> there. More importantly, users spent a great deal of effort and time
> to file those. Bulk closing them tells those users we don't value
> their feedback or effort. It is useful to triage these issues and
> consider them individually. Doubtless many of these issues are already
> fixed, moot, or things we expressly chose not to do. However this
> should be decided case by case. We can't simply close our eyes and
> pretend they're all irrelevant.
>
> On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
> >
> > Hi folks,
> >
> > after at least one year of silence, I'd like to perform another JIRA
> > issue cleanup for issues which have been not touched for more than three
> > years.
> >
> > Query:
> >
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
> >
> > Stats:
> >
> > 567 issues not touched for more than three years
> > of which
> > * 68 have fix version set
> > * 36 were already reopened, should they be excluded?
> > * 1 in progress by Karl
> >
> > Type breakdown:
> > * 200 bugs
> > * 164 improvements
> > * 72 new features
> > * 6 subtasks
> > * 13 tasks
> > * 12 wishes
> >
> > If there are issues still valid for you please leave a comment on the
> > issue and they will not appear in the query anymore.
> > Please also raise your voice if you have anything to discuss.
> >
> > If the issue is not modified or no objection has been raised, I will
> > autoclose those issues with a comment by 2019-12-30.
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Yearly JIRA cleanup

2019-12-08 Thread Elliotte Rusty Harold

Please don't. There are certainly some real and important issues in
there. More importantly, users spent a great deal of effort and time
to file those. Bulk closing them tells those users we don't value
their feedback or effort. It is useful to triage these issues and
consider them individually. Doubtless many of these issues are already
fixed, moot, or things we expressly chose not to do. However this
should be decided case by case. We can't simply close our eyes and
pretend they're all irrelevant.

On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov  wrote:
>
> Hi folks,
>
> after at least one year of silence, I'd like to perform another JIRA
> issue cleanup for issues which have been not touched for more than three
> years.
>
> Query:
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC
>
> Stats:
>
> 567 issues not touched for more than three years
> of which
> * 68 have fix version set
> * 36 were already reopened, should they be excluded?
> * 1 in progress by Karl
>
> Type breakdown:
> * 200 bugs
> * 164 improvements
> * 72 new features
> * 6 subtasks
> * 13 tasks
> * 12 wishes
>
> If there are issues still valid for you please leave a comment on the
> issue and they will not appear in the query anymore.
> Please also raise your voice if you have anything to discuss.
>
> If the issue is not modified or no objection has been raised, I will
> autoclose those issues with a comment by 2019-12-30.
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: Yearly JIRA cleanup

2019-12-08 Thread Michael Osipov


Am 2019-12-08 um 13:55 schrieb Maarten Mulders:

Hi Michael,

Great initiative. After logging in to JIRA, accessing your link shows 
"The requested filter doesn't exist or is private."
This means I'm not able to verify whether there are issues in that list 
that are valid for me.

Is there another way to find those issues?


Apologies, here is the proper filter: 
https://issues.apache.org/jira/issues/?jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC


I forgot to remove the filter id for my custom saved search.

Michael


On December 8, 2019 at 13:50, Michael Osipov wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA 
issue cleanup for issues which have been not touched for more than 
three years.


Query: 
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC 



Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the 
issue and they will not appear in the query anymore.

Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will 
autoclose those issues with a comment by 2019-12-30.


Michael

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


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





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

Re: Yearly JIRA cleanup

2019-12-08 Thread Maarten Mulders


Hi Michael,

Great initiative. After logging in to JIRA, accessing your link shows 
"The requested filter doesn't exist or is private."
This means I'm not able to verify whether there are issues in that list 
that are valid for me.

Is there another way to find those issues?

Cheers,

Maarten

On December 8, 2019 at 13:50, Michael Osipov wrote:


Hi folks,

after at least one year of silence, I'd like to perform another JIRA 
issue cleanup for issues which have been not touched for more than 
three years.


Query: 
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC


Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the 
issue and they will not appear in the query anymore.

Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will 
autoclose those issues with a comment by 2019-12-30.


Michael

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


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

Yearly JIRA cleanup

2019-12-08 Thread Michael Osipov


Hi folks,

after at least one year of silence, I'd like to perform another JIRA 
issue cleanup for issues which have been not touched for more than three 
years.


Query: 
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC


Stats:

567 issues not touched for more than three years
of which
* 68 have fix version set
* 36 were already reopened, should they be excluded?
* 1 in progress by Karl

Type breakdown:
* 200 bugs
* 164 improvements
* 72 new features
* 6 subtasks
* 13 tasks
* 12 wishes

If there are issues still valid for you please leave a comment on the 
issue and they will not appear in the query anymore.

Please also raise your voice if you have anything to discuss.

If the issue is not modified or no objection has been raised, I will 
autoclose those issues with a comment by 2019-12-30.


Michael

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

Re: Cleanup Jenkins Jobs - Part II

2018-08-18 Thread Karl Heinz Marbaise


Hi,

I have removed all the jobs in that view including the view itself...

Kind regards
Karl Heinz Marbaise
On 07/08/18 21:31, Karl Heinz Marbaise wrote:

Hi,

we have a number of Maven Jobs:

https://builds.apache.org/view/M-R/view/Maven%20Core%20ITs/

which are superflous in the meantime cause they are handled by the 
pipelines.


I would go to delete them on 17.08.2018 except somebody will object?


Kind regards
Karl Heinz Marbaise

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



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

Cleanup Jenkins Jobs - Part II

2018-08-07 Thread Karl Heinz Marbaise


Hi,

we have a number of Maven Jobs:

https://builds.apache.org/view/M-R/view/Maven%20Core%20ITs/

which are superflous in the meantime cause they are handled by the 
pipelines.


I would go to delete them on 17.08.2018 except somebody will object?


Kind regards
Karl Heinz Marbaise

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

Re: Spring cleanup JIRA

2018-03-08 Thread Michael Osipov


Am 2018-03-07 um 23:31 schrieb Michael Osipov:

Folks,

I did yet another analysis on open issues. We have currently more than 
400 open issues which haven't been touched for more than three (3) years.


The last two times I autoclosed them with a message. People could 
request a reopen, very little did.


Should we do this again? The list won't get shorter and a lot of them do 
not even contain a sample project.


JIRA query: 
https://issues.apache.org/jira/issues/?jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC 



Please comment!


Note: if you see an issue which worth keeping, just add a comment to the 
issue: "still valid"


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

Re: Spring cleanup JIRA

2018-03-08 Thread Robert Scholte

100 for the whole Maven project? Luckily we have ~85 projects, so the  
damage looks manageable.
However, with a total of 2000+ open issues and with the current active  
resources it is impossible to fix them all.
So yes, close them as Auto-Close with a clear message. I sometimes look at  
auto-closed issues, sometimes  they are indeed interesting to add even  
though the reporter didn't ask to reopen such issue.

thanks,
Robert

[1]  
https://cwiki.apache.org/confluence/display/MAVEN/Maven+JIRA+issues+overview

On Thu, 08 Mar 2018 11:16:57 +0100, Martijn Verburg  
 wrote:

Non binding but agreed - once an issue list gets beyond 50 it's hard to  
see

the forest, once it's beyond 100 you can pretty much guarantee that
everyone is lost.

Cheers,
Martijn

On 8 March 2018 at 07:45, Anders Hammar  wrote:

+1 for the same process as last time.

/Anders

On Wed, Mar 7, 2018 at 11:31 PM, Michael Osipov 
wrote:

> Folks,
>
> I did yet another analysis on open issues. We have currently more than
400
> open issues which haven't been touched for more than three (3) years.
>
> The last two times I autoclosed them with a message. People could  
request

> a reopen, very little did.
>
> Should we do this again? The list won't get shorter and a lot of them  
do

> not even contain a sample project.
>
> JIRA query: https://issues.apache.org/jira/issues/?jql=category%20%3D%
> 20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%
> 20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
>
> Please comment!
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

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

Re: Spring cleanup JIRA

2018-03-08 Thread Martijn Verburg

Non binding but agreed - once an issue list gets beyond 50 it's hard to see
the forest, once it's beyond 100 you can pretty much guarantee that
everyone is lost.

Cheers,
Martijn

On 8 March 2018 at 07:45, Anders Hammar  wrote:

> +1 for the same process as last time.
>
> /Anders
>
> On Wed, Mar 7, 2018 at 11:31 PM, Michael Osipov 
> wrote:
>
> > Folks,
> >
> > I did yet another analysis on open issues. We have currently more than
> 400
> > open issues which haven't been touched for more than three (3) years.
> >
> > The last two times I autoclosed them with a message. People could request
> > a reopen, very little did.
> >
> > Should we do this again? The list won't get shorter and a lot of them do
> > not even contain a sample project.
> >
> > JIRA query: https://issues.apache.org/jira/issues/?jql=category%20%3D%
> > 20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%
> > 20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
> >
> > Please comment!
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: Spring cleanup JIRA

2018-03-07 Thread Anders Hammar

+1 for the same process as last time.

/Anders

On Wed, Mar 7, 2018 at 11:31 PM, Michael Osipov  wrote:

> Folks,
>
> I did yet another analysis on open issues. We have currently more than 400
> open issues which haven't been touched for more than three (3) years.
>
> The last two times I autoclosed them with a message. People could request
> a reopen, very little did.
>
> Should we do this again? The list won't get shorter and a lot of them do
> not even contain a sample project.
>
> JIRA query: https://issues.apache.org/jira/issues/?jql=category%20%3D%
> 20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%
> 20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
>
> Please comment!
>
> Michael
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Spring cleanup JIRA

2018-03-07 Thread Michael Osipov


Folks,

I did yet another analysis on open issues. We have currently more than 
400 open issues which haven't been touched for more than three (3) years.


The last two times I autoclosed them with a message. People could 
request a reopen, very little did.


Should we do this again? The list won't get shorter and a lot of them do 
not even contain a sample project.


JIRA query: 
https://issues.apache.org/jira/issues/?jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-156w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC


Please comment!

Michael

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

[GitHub] maven-indexer issue #23: Full codebase reformat, minor cleanup, no code/logi...

2017-11-25 Thread hboutemy

Github user hboutemy commented on the issue:

https://github.com/apache/maven-indexer/pull/23
  
sorry, I did not notice you were working on it, I did some checkstyle fixes 
that messed your work :(


---

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

[GitHub] maven-indexer issue #23: Full codebase reformat, minor cleanup, no code/logi...

2017-11-25 Thread cstamas

Github user cstamas commented on the issue:

https://github.com/apache/maven-indexer/pull/23
  
Not merged, gave up.


---

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

[GitHub] maven-indexer pull request #23: Full codebase reformat, minor cleanup, no co...

2017-11-25 Thread cstamas

Github user cstamas closed the pull request at:

https://github.com/apache/maven-indexer/pull/23


---

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

[GitHub] maven-indexer pull request #23: Full codebase reformat, minor cleanup, no co...

2017-11-24 Thread cstamas

GitHub user cstamas opened a pull request:

https://github.com/apache/maven-indexer/pull/23

Full codebase reformat, minor cleanup, no code/logic change

Reformatted full codebase, as there was mixed formatting, and
checkstyle did report a huge amount of errors. Now, mostly the
javadoc ones :) remain, and few minor issues. As part of cleanup,
applied some changes proposed by checkstyle, like removing public
modifiers from inner enums etc.

No code/logic change happened.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cstamas/maven-indexer reformat

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-indexer/pull/23.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #23


commit d01a354aeb53126968e8020ec423b17326f35c14
Author: Tamas Cservenak <ta...@cservenak.net>
Date:   2017-11-24T14:42:56Z

Full codebase reformat, minor cleanup, no code/logic change

Reformatted full codebase, as there was mixed formatting. Also,
checkstyle did report a huge amount of errors. Now, mostly the
javadoc ones :) remain, and few minor issues. As part of cleanup,
applied some changes proposed by checkstyle, like removing public
modifiers from inner enums etc.

No code/logic change happened.




---

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

[GitHub] maven pull request #111: [MNG-6203] Minor cleanup in MavenCli.java

2017-04-05 Thread stefaneicher

Github user stefaneicher closed the pull request at:

https://github.com/apache/maven/pull/111


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven issue #111: [MNG-6203] Minor cleanup in MavenCli.java

2017-04-05 Thread khmarbaise

Github user khmarbaise commented on the issue:

https://github.com/apache/maven/pull/111
  
This pull request has been integrated into maven core. Thanks for your 
support. Please close this pull request.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven issue #111: [MNG-6203] Minor cleanup in MavenCli.java

2017-04-05 Thread khmarbaise

Github user khmarbaise commented on the issue:

https://github.com/apache/maven/pull/111
  
If you add the JIRA ticket this PR is automatically added to the JIRA 
ticket...Thanks for this..


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven pull request #111: [MNG-6203] Minor cleanup in MavenCli.java

2017-04-05 Thread stefaneicher

GitHub user stefaneicher opened a pull request:

https://github.com/apache/maven/pull/111

[MNG-6203] Minor cleanup in MavenCli.java

There is some unnecessary code in the MavenCli.java from line #1465 to 
#1474.
The functionality has been moved to line #1215.

Signed-off-by: Stefan Eicher <stefan.eic...@gmail.com>

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stefaneicher/maven MNG-6203

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven/pull/111.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #111


commit d73d36fc82babd52800ab25e537a9b973ee51c68
Author: Stefan Eicher <stefan.eic...@gmail.com>
Date:   2017-04-05T18:52:01Z

[MNG-6203] Minor cleanup in MavenCli.java

There is some unnecessary code in the MavenCli.java from line #1465 to 
#1474.
The functionality has been moved to line #1215.

Signed-off-by: Stefan Eicher <stefan.eic...@gmail.com>




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: Another yearly issue cleanup in JIRA

2016-01-01 Thread Michael Osipov

Just wanted you to remember that no issue has been updated since my last 
mail. You still have a couple of days to take a look. Monday is deadline.


Am 2015-12-25 um 19:00 schrieb Michael Osipov:

Hi folks,

the previous had a bad wording, so I decided to rerun that.

I'd like to do another issue cleanup in JIRA like a did last year.
We currently have 127 unresolved issues which haven't been updated for
more than three years.

They drill down as follows:
Wish: 3
Task: 4
New Feature: 14
Improvement: 34
Bug: 72

Here is the query for: category = Maven AND updated <= -156w AND
resolution = Unresolved ORDER BY updated DESC

I hardly believe that they will be updated or resolved ever. Maybe they
have been resolved with new versions automatically.
Please have a look whether you see some of yours which are still valid
or anything else. Is an issue worth kept alive, add a validity note to
it. If you don't object, I will go ahead and close them
as won't fix. Let me know by 2 January 2016.

@Hervé Is that an acceptable approach for you?

Michael


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






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

Re: Another yearly issue cleanup in JIRA

2016-01-01 Thread Michael Osipov


Am 2016-01-01 um 23:13 schrieb Ron Wheeler:

You might want to delay your deadline for a few days to allow people who
have been on holidays to get back to work.


Good point, let's push for another week until 2016-01-10.

Michael


On 01/01/2016 3:25 PM, Michael Osipov wrote:

Just wanted you to remember that no issue has been updated since my
last mail. You still have a couple of days to take a look. Monday is
deadline.

Am 2015-12-25 um 19:00 schrieb Michael Osipov:

Hi folks,

the previous had a bad wording, so I decided to rerun that.

I'd like to do another issue cleanup in JIRA like a did last year.
We currently have 127 unresolved issues which haven't been updated for
more than three years.

They drill down as follows:
Wish: 3
Task: 4
New Feature: 14
Improvement: 34
Bug: 72

Here is the query for: category = Maven AND updated <= -156w AND
resolution = Unresolved ORDER BY updated DESC

I hardly believe that they will be updated or resolved ever. Maybe they
have been resolved with new versions automatically.
Please have a look whether you see some of yours which are still valid
or anything else. Is an issue worth kept alive, add a validity note to
it. If you don't object, I will go ahead and close them
as won't fix. Let me know by 2 January 2016.

@Hervé Is that an acceptable approach for you?

Michael


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






-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org









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

Re: Another yearly issue cleanup in JIRA

2015-12-28 Thread Michael Osipov


Am 2015-12-25 um 19:00 schrieb Michael Osipov:

Hi folks,

the previous had a bad wording, so I decided to rerun that.

I'd like to do another issue cleanup in JIRA like a did last year.
We currently have 127 unresolved issues which haven't been updated for
more than three years.

They drill down as follows:
Wish: 3
Task: 4
New Feature: 14
Improvement: 34
Bug: 72

Here is the query for: category = Maven AND updated <= -156w AND
resolution = Unresolved ORDER BY updated DESC


Hervé, did you have a change to take a look at yours/valid ones?

Michael



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

Another yearly issue cleanup in JIRA

2015-12-25 Thread Michael Osipov


Hi folks,

the previous had a bad wording, so I decided to rerun that.

I'd like to do another issue cleanup in JIRA like a did last year.
We currently have 127 unresolved issues which haven't been updated for
more than three years.

They drill down as follows:
Wish: 3
Task: 4
New Feature: 14
Improvement: 34
Bug: 72

Here is the query for: category = Maven AND updated <= -156w AND 
resolution = Unresolved ORDER BY updated DESC


I hardly believe that they will be updated or resolved ever. Maybe they 
have been resolved with new versions automatically.

Please have a look whether you see some of yours which are still valid
or anything else. Is an issue worth kept alive, add a validity note to 
it. If you don't object, I will go ahead and close them

as won't fix. Let me know by 2 January 2016.

@Hervé Is that an acceptable approach for you?

Michael


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

Maven Core Branch Cleanup

2015-10-12 Thread Karl Heinz Marbaise


Hi,

i have taken a look onto the list of branches on maven core which is a 
list of 17 beanches but where many of them haven't been touched for 
years (yes i'm using plural)...


MNG-3004 Updated 6 years ago by Daniel Fabulich
MNG-4388 Updated 6 years ago by bentmann
MNG-1803 Updated 5 years ago by bentmann
guice-support Updated 5 years ago by olamy
mirror-group-routing Updated 4 years ago by John Dennis Casey
feature/colorized-console/log4j2 Updated 3 years ago by aheritier
dynamic-logging-impl Updated 3 years ago by olamy
MNG-5406 Updated 3 years ago by hboutemy
logging/slf4j-logback Updated 3 years ago by jvanzyl
logging/slf4j-log4j Updated 3 years ago by stephenc
logging/slf4j-jul Updated 3 years ago by stephenc
logging/slf4j-log4j2 Updated 3 years ago by olamy
eclipse-aether Updated 3 years ago by jvanzyl
slf4j-logback Updated 3 years ago by jvanzyl
pom500 Updated 2 years ago by rfscholte
aether-M3 Updated 2 years ago by jvanzyl
guice-from-google Updated 2 years ago by olamy

The following i would not delete them:

1) maven-3.0.x Updated 2 years ago by hboutemy
2) maven-2.2.x Updated 2 years ago by hboutemy
3) maven-3.1.x Updated 2 years ago by michael-o

And the last one
4) configurator Updated 10 months ago by jvanzyl


Any objects against removing the above list list with branches (except 
1..4)..?


Kind regards
Karl Heinz Marbaise

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

Re: Maven Core Branch Cleanup

2015-10-12 Thread Karl Heinz Marbaise


Hi,

cleaning up done...

heads
23 hours agomaster   shortlog | log | tree
8 days ago  slf4j-log4j2.4   shortlog | log | tree
6 weeks ago MNG-5878 shortlog | log | tree
9 months agoconfigurator shortlog | log | tree
19 months ago   maven-3.1.x  shortlog | log | tree
2 years ago maven-2.2.x  shortlog | log | tree
2 years ago maven-3.0.x  shortlog | log | tree


Kind regards
Karl Heinz Marbaise

On 10/12/15 8:56 PM, Kristian Rosenvold wrote:

Anyone wishing to retain these branches can just go ahead and fork the
girhub repo, they'

2015-10-12 20:20 GMT+02:00 Jason van Zyl :

You can nuke all my branches. They are either integrated, irrelevant, or easy 
to recreate.


On Oct 12, 2015, at 2:11 PM, Karl Heinz Marbaise  wrote:

Hi,

i have taken a look onto the list of branches on maven core which is a list of 
17 beanches but where many of them haven't been touched for years (yes i'm 
using plural)...

MNG-3004 Updated 6 years ago by Daniel Fabulich
MNG-4388 Updated 6 years ago by bentmann
MNG-1803 Updated 5 years ago by bentmann
guice-support Updated 5 years ago by olamy
mirror-group-routing Updated 4 years ago by John Dennis Casey
feature/colorized-console/log4j2 Updated 3 years ago by aheritier
dynamic-logging-impl Updated 3 years ago by olamy
MNG-5406 Updated 3 years ago by hboutemy
logging/slf4j-logback Updated 3 years ago by jvanzyl
logging/slf4j-log4j Updated 3 years ago by stephenc
logging/slf4j-jul Updated 3 years ago by stephenc
logging/slf4j-log4j2 Updated 3 years ago by olamy
eclipse-aether Updated 3 years ago by jvanzyl
slf4j-logback Updated 3 years ago by jvanzyl
pom500 Updated 2 years ago by rfscholte
aether-M3 Updated 2 years ago by jvanzyl
guice-from-google Updated 2 years ago by olamy

The following i would not delete them:

1) maven-3.0.x Updated 2 years ago by hboutemy
2) maven-2.2.x Updated 2 years ago by hboutemy
3) maven-3.1.x Updated 2 years ago by michael-o

And the last one
4) configurator Updated 10 months ago by jvanzyl


Any objects against removing the above list list with branches (except 1..4)..?



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

Re: Maven Core Branch Cleanup

2015-10-12 Thread Jason van Zyl

You can nuke all my branches. They are either integrated, irrelevant, or easy 
to recreate.

> On Oct 12, 2015, at 2:11 PM, Karl Heinz Marbaise  wrote:
> 
> Hi,
> 
> i have taken a look onto the list of branches on maven core which is a list 
> of 17 beanches but where many of them haven't been touched for years (yes i'm 
> using plural)...
> 
> MNG-3004 Updated 6 years ago by Daniel Fabulich
> MNG-4388 Updated 6 years ago by bentmann
> MNG-1803 Updated 5 years ago by bentmann
> guice-support Updated 5 years ago by olamy
> mirror-group-routing Updated 4 years ago by John Dennis Casey
> feature/colorized-console/log4j2 Updated 3 years ago by aheritier
> dynamic-logging-impl Updated 3 years ago by olamy
> MNG-5406 Updated 3 years ago by hboutemy
> logging/slf4j-logback Updated 3 years ago by jvanzyl
> logging/slf4j-log4j Updated 3 years ago by stephenc
> logging/slf4j-jul Updated 3 years ago by stephenc
> logging/slf4j-log4j2 Updated 3 years ago by olamy
> eclipse-aether Updated 3 years ago by jvanzyl
> slf4j-logback Updated 3 years ago by jvanzyl
> pom500 Updated 2 years ago by rfscholte
> aether-M3 Updated 2 years ago by jvanzyl
> guice-from-google Updated 2 years ago by olamy
> 
> The following i would not delete them:
> 
> 1) maven-3.0.x Updated 2 years ago by hboutemy
> 2) maven-2.2.x Updated 2 years ago by hboutemy
> 3) maven-3.1.x Updated 2 years ago by michael-o
> 
> And the last one
> 4) configurator Updated 10 months ago by jvanzyl
> 
> 
> Any objects against removing the above list list with branches (except 
> 1..4)..?
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.

  -- Jacques Ellul, The Technological Society













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

Re: Maven Core Branch Cleanup

2015-10-12 Thread Kristian Rosenvold

Anyone wishing to retain these branches can just go ahead and fork the
girhub repo, they'

2015-10-12 20:20 GMT+02:00 Jason van Zyl :
> You can nuke all my branches. They are either integrated, irrelevant, or easy 
> to recreate.
>
>> On Oct 12, 2015, at 2:11 PM, Karl Heinz Marbaise  wrote:
>>
>> Hi,
>>
>> i have taken a look onto the list of branches on maven core which is a list 
>> of 17 beanches but where many of them haven't been touched for years (yes 
>> i'm using plural)...
>>
>> MNG-3004 Updated 6 years ago by Daniel Fabulich
>> MNG-4388 Updated 6 years ago by bentmann
>> MNG-1803 Updated 5 years ago by bentmann
>> guice-support Updated 5 years ago by olamy
>> mirror-group-routing Updated 4 years ago by John Dennis Casey
>> feature/colorized-console/log4j2 Updated 3 years ago by aheritier
>> dynamic-logging-impl Updated 3 years ago by olamy
>> MNG-5406 Updated 3 years ago by hboutemy
>> logging/slf4j-logback Updated 3 years ago by jvanzyl
>> logging/slf4j-log4j Updated 3 years ago by stephenc
>> logging/slf4j-jul Updated 3 years ago by stephenc
>> logging/slf4j-log4j2 Updated 3 years ago by olamy
>> eclipse-aether Updated 3 years ago by jvanzyl
>> slf4j-logback Updated 3 years ago by jvanzyl
>> pom500 Updated 2 years ago by rfscholte
>> aether-M3 Updated 2 years ago by jvanzyl
>> guice-from-google Updated 2 years ago by olamy
>>
>> The following i would not delete them:
>>
>> 1) maven-3.0.x Updated 2 years ago by hboutemy
>> 2) maven-2.2.x Updated 2 years ago by hboutemy
>> 3) maven-3.1.x Updated 2 years ago by michael-o
>>
>> And the last one
>> 4) configurator Updated 10 months ago by jvanzyl
>>
>>
>> Any objects against removing the above list list with branches (except 
>> 1..4)..?
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> In short, man creates for himself a new religion of a rational
> and technical order to justify his work and to be justified in it.
>
>   -- Jacques Ellul, The Technological Society
>
>
>
>
>
>
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: Another JIRA cleanup

2015-09-16 Thread Michael Osipov


Am 2015-09-07 um 10:40 schrieb Michael Osipov:

Am 2015-08-30 um 21:31 schrieb Michael Osipov:

Hi folks,

some of you might remember that I have closed a bunch of issues some
time ago. I'd like to reperform that task because we have more than 3100
open issues at the moment [1].

Many issues (thousands) haven't been touched for years. I hardly believe
that someone will pick them up after two or three years.

To get us focused on new issues and ongoing improvements, I'd like to
perform another cleanup in JIRA.

Currectly we have:

* 729 issues older than three (3) years [2]
* 1496 issues older than two (2) years [3]

(Numbers accumulate)

I'd like to set the three-year-old issues to ASF JIRA "Auto Closed" with
the following text:

"This issue has been closed because it has been inactive for a long
period of time. If you think this issues still applies, retest your
problem with the most recent version of Maven and the affected
component, reopen and post your results."

If you guys happen to find any of your tickets (reporter/assignee) which
are still valid, ping them.

If I don't get any objections by 2015-09-06, I will perform the close.

A couple of months later, I'd like to squash those two-year-olds too.

Michael

[1]
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC


[2] category = Maven AND updated <= -156w AND resolution = Unresolved
ORDER BY created DESC
[3] category = Maven AND updated <= -104w AND resolution = Unresolved
ORDER BY created DESC


I have concluded the cleanup yesterday and closed around 600 issues.
I'll repost in a week now many of them have been reopened.


Some time has passed and approx. 15 issues have been reopened, the rest 
did not even receive a feedback from the reporters.


Michael


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

Re: Another JIRA cleanup

2015-09-07 Thread Michael Osipov


Am 2015-08-30 um 21:31 schrieb Michael Osipov:

Hi folks,

some of you might remember that I have closed a bunch of issues some
time ago. I'd like to reperform that task because we have more than 3100
open issues at the moment [1].

Many issues (thousands) haven't been touched for years. I hardly believe
that someone will pick them up after two or three years.

To get us focused on new issues and ongoing improvements, I'd like to
perform another cleanup in JIRA.

Currectly we have:

* 729 issues older than three (3) years [2]
* 1496 issues older than two (2) years [3]

(Numbers accumulate)

I'd like to set the three-year-old issues to ASF JIRA "Auto Closed" with
the following text:

"This issue has been closed because it has been inactive for a long
period of time. If you think this issues still applies, retest your
problem with the most recent version of Maven and the affected
component, reopen and post your results."

If you guys happen to find any of your tickets (reporter/assignee) which
are still valid, ping them.

If I don't get any objections by 2015-09-06, I will perform the close.

A couple of months later, I'd like to squash those two-year-olds too.

Michael

[1]
https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC

[2] category = Maven AND updated <= -156w AND resolution = Unresolved
ORDER BY created DESC
[3] category = Maven AND updated <= -104w AND resolution = Unresolved
ORDER BY created DESC


I have concluded the cleanup yesterday and closed around 600 issues. 
I'll repost in a week now many of them have been reopened.


Moreover, as promised, I will perform another cleanup by christmas for 
the two years old issues.


Michael


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

Re: Another JIRA cleanup

2015-09-02 Thread Tibor Digana

The link is not reachable. Can you fix it?
The requested filter doesn't exist or is private.

On Sun, Aug 30, 2015 at 9:31 PM, Michael Osipov <micha...@apache.org> wrote:

> Hi folks,
>
> some of you might remember that I have closed a bunch of issues some time
> ago. I'd like to reperform that task because we have more than 3100 open
> issues at the moment [1].
>
> Many issues (thousands) haven't been touched for years. I hardly believe
> that someone will pick them up after two or three years.
>
> To get us focused on new issues and ongoing improvements, I'd like to
> perform another cleanup in JIRA.
>
> Currectly we have:
>
> * 729 issues older than three (3) years [2]
> * 1496 issues older than two (2) years [3]
>
> (Numbers accumulate)
>
> I'd like to set the three-year-old issues to ASF JIRA "Auto Closed" with
> the following text:
>
> "This issue has been closed because it has been inactive for a long period
> of time. If you think this issues still applies, retest your problem with
> the most recent version of Maven and the affected component, reopen and
> post your results."
>
> If you guys happen to find any of your tickets (reporter/assignee) which
> are still valid, ping them.
>
> If I don't get any objections by 2015-09-06, I will perform the close.
>
> A couple of months later, I'd like to squash those two-year-olds too.
>
> Michael
>
> [1]
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
> [2] category = Maven AND updated <= -156w AND resolution = Unresolved
> ORDER BY created DESC
> [3] category = Maven AND updated <= -104w AND resolution = Unresolved
> ORDER BY created DESC
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers
Tibor

Re: Re: Another JIRA cleanup

2015-09-02 Thread Michael Osipov



> Gesendet: Mittwoch, 02. September 2015 um 10:31 Uhr
> Von: "Tibor Digana" <tibor.dig...@googlemail.com>
> An: "Maven Developers List" <dev@maven.apache.org>
> Betreff: Re: Another JIRA cleanup
>
> The link is not reachable. Can you fix it?
> The requested filter doesn't exist or is private.


Please try this filter: category = Maven AND resolution = Unresolved ORDER BY 
created DESC
 
> On Sun, Aug 30, 2015 at 9:31 PM, Michael Osipov <micha...@apache.org> wrote:
> 
> > Hi folks,
> >
> > some of you might remember that I have closed a bunch of issues some time
> > ago. I'd like to reperform that task because we have more than 3100 open
> > issues at the moment [1].
> >
> > Many issues (thousands) haven't been touched for years. I hardly believe
> > that someone will pick them up after two or three years.
> >
> > To get us focused on new issues and ongoing improvements, I'd like to
> > perform another cleanup in JIRA.
> >
> > Currectly we have:
> >
> > * 729 issues older than three (3) years [2]
> > * 1496 issues older than two (2) years [3]
> >
> > (Numbers accumulate)
> >
> > I'd like to set the three-year-old issues to ASF JIRA "Auto Closed" with
> > the following text:
> >
> > "This issue has been closed because it has been inactive for a long period
> > of time. If you think this issues still applies, retest your problem with
> > the most recent version of Maven and the affected component, reopen and
> > post your results."
> >
> > If you guys happen to find any of your tickets (reporter/assignee) which
> > are still valid, ping them.
> >
> > If I don't get any objections by 2015-09-06, I will perform the close.
> >
> > A couple of months later, I'd like to squash those two-year-olds too.
> >
> > Michael
> >
> > [1]
> > https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
> > [2] category = Maven AND updated <= -156w AND resolution = Unresolved
> > ORDER BY created DESC
> > [3] category = Maven AND updated <= -104w AND resolution = Unresolved
> > ORDER BY created DESC
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> 
> 
> -- 
> Cheers
> Tibor
> 

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

Re: Another JIRA cleanup

2015-09-02 Thread Hervé BOUTEMY

just remove the filter param and it will work

https://issues.apache.org/jira/issues/?jql=category%20%3D%20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC

Regards,

Hervé

Le mercredi 2 septembre 2015 10:31:43 Tibor Digana a écrit :
> The link is not reachable. Can you fix it?
> The requested filter doesn't exist or is private.
> 
> On Sun, Aug 30, 2015 at 9:31 PM, Michael Osipov <micha...@apache.org> wrote:
> > Hi folks,
> > 
> > some of you might remember that I have closed a bunch of issues some time
> > ago. I'd like to reperform that task because we have more than 3100 open
> > issues at the moment [1].
> > 
> > Many issues (thousands) haven't been touched for years. I hardly believe
> > that someone will pick them up after two or three years.
> > 
> > To get us focused on new issues and ongoing improvements, I'd like to
> > perform another cleanup in JIRA.
> > 
> > Currectly we have:
> > 
> > * 729 issues older than three (3) years [2]
> > * 1496 issues older than two (2) years [3]
> > 
> > (Numbers accumulate)
> > 
> > I'd like to set the three-year-old issues to ASF JIRA "Auto Closed" with
> > the following text:
> > 
> > "This issue has been closed because it has been inactive for a long period
> > of time. If you think this issues still applies, retest your problem with
> > the most recent version of Maven and the affected component, reopen and
> > post your results."
> > 
> > If you guys happen to find any of your tickets (reporter/assignee) which
> > are still valid, ping them.
> > 
> > If I don't get any objections by 2015-09-06, I will perform the close.
> > 
> > A couple of months later, I'd like to squash those two-year-olds too.
> > 
> > Michael
> > 
> > [1]
> > https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%
> > 20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DES
> > C [2] category = Maven AND updated <= -156w AND resolution = Unresolved
> > ORDER BY created DESC
> > [3] category = Maven AND updated <= -104w AND resolution = Unresolved
> > ORDER BY created DESC
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org


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

Re: Another JIRA cleanup

2015-09-01 Thread Hervé BOUTEMY

ok for me: I didn't like it the first time, but with experience, this cause 
less trouble than manual dust cleaning in Jira issues

Regards,

Hervé

Le dimanche 30 août 2015 21:31:43 Michael Osipov a écrit :
> Hi folks,
> 
> some of you might remember that I have closed a bunch of issues some
> time ago. I'd like to reperform that task because we have more than 3100
> open issues at the moment [1].
> 
> Many issues (thousands) haven't been touched for years. I hardly believe
> that someone will pick them up after two or three years.
> 
> To get us focused on new issues and ongoing improvements, I'd like to
> perform another cleanup in JIRA.
> 
> Currectly we have:
> 
> * 729 issues older than three (3) years [2]
> * 1496 issues older than two (2) years [3]
> 
> (Numbers accumulate)
> 
> I'd like to set the three-year-old issues to ASF JIRA "Auto Closed" with
> the following text:
> 
> "This issue has been closed because it has been inactive for a long
> period of time. If you think this issues still applies, retest your
> problem with the most recent version of Maven and the affected
> component, reopen and post your results."
> 
> If you guys happen to find any of your tickets (reporter/assignee) which
> are still valid, ping them.
> 
> If I don't get any objections by 2015-09-06, I will perform the close.
> 
> A couple of months later, I'd like to squash those two-year-olds too.
> 
> Michael
> 
> [1]
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20
> Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
> [2] category = Maven AND updated <= -156w AND resolution = Unresolved ORDER
> BY created DESC
> [3] category = Maven AND updated <= -104w AND resolution = Unresolved
> ORDER BY created DESC
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


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

Re: Another JIRA cleanup

2015-08-31 Thread Jason van Zyl

+1

I think the constant looking at ways to cleanup the issues is necessary. So I 
appreciate going through and culling the issues that have not been looked at in 
quite a while.

> On Aug 30, 2015, at 3:31 PM, Michael Osipov <micha...@apache.org> wrote:
> 
> Hi folks,
> 
> some of you might remember that I have closed a bunch of issues some time 
> ago. I'd like to reperform that task because we have more than 3100 open 
> issues at the moment [1].
> 
> Many issues (thousands) haven't been touched for years. I hardly believe that 
> someone will pick them up after two or three years.
> 
> To get us focused on new issues and ongoing improvements, I'd like to perform 
> another cleanup in JIRA.
> 
> Currectly we have:
> 
> * 729 issues older than three (3) years [2]
> * 1496 issues older than two (2) years [3]
> 
> (Numbers accumulate)
> 
> I'd like to set the three-year-old issues to ASF JIRA "Auto Closed" with the 
> following text:
> 
> "This issue has been closed because it has been inactive for a long period of 
> time. If you think this issues still applies, retest your problem with the 
> most recent version of Maven and the affected component, reopen and post your 
> results."
> 
> If you guys happen to find any of your tickets (reporter/assignee) which are 
> still valid, ping them.
> 
> If I don't get any objections by 2015-09-06, I will perform the close.
> 
> A couple of months later, I'd like to squash those two-year-olds too.
> 
> Michael
> 
> [1] 
> https://issues.apache.org/jira/issues/?filter=12333204=category%20%3D%20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
> [2] category = Maven AND updated <= -156w AND resolution = Unresolved ORDER 
> BY created DESC
> [3] category = Maven AND updated <= -104w AND resolution = Unresolved ORDER 
> BY created DESC
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

The most dangerous risk: spending your life not doing what you want on the bet 
you can buy yourself freedom to do it later.

 -- Randy Komisar












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

Another JIRA cleanup

2015-08-30 Thread Michael Osipov


Hi folks,

some of you might remember that I have closed a bunch of issues some 
time ago. I'd like to reperform that task because we have more than 3100 
open issues at the moment [1].


Many issues (thousands) haven't been touched for years. I hardly believe 
that someone will pick them up after two or three years.


To get us focused on new issues and ongoing improvements, I'd like to 
perform another cleanup in JIRA.


Currectly we have:

* 729 issues older than three (3) years [2]
* 1496 issues older than two (2) years [3]

(Numbers accumulate)

I'd like to set the three-year-old issues to ASF JIRA Auto Closed with 
the following text:


This issue has been closed because it has been inactive for a long 
period of time. If you think this issues still applies, retest your 
problem with the most recent version of Maven and the affected 
component, reopen and post your results.


If you guys happen to find any of your tickets (reporter/assignee) which 
are still valid, ping them.


If I don't get any objections by 2015-09-06, I will perform the close.

A couple of months later, I'd like to squash those two-year-olds too.

Michael

[1] 
https://issues.apache.org/jira/issues/?filter=12333204jql=category%20%3D%20Maven%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20created%20DESC
[2] category = Maven AND updated = -156w AND resolution = Unresolved 
ORDER BY created DESC
[3] category = Maven AND updated = -104w AND resolution = Unresolved 
ORDER BY created DESC


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

Re: Maven site cleanup

2015-07-01 Thread Robert Scholte

Op Wed, 01 Jul 2015 07:18:14 +0200 schreef Hervé BOUTEMY  
herve.bout...@free.fr:



Hi,

I like the new http://maven.apache.org/repository-management.html


I like this page as well. Maybe we should explicitly say that the order  
repository managers is alphabetic and doesn't say anything about a  
preferred solution.


Other question:
How do you get to this page nowadays? IIRC it used to be by the panel on  
the right hand side, but now that it is gone...


Robert



This proves that when you completely rewrite some pages, the result is  
far

better than the previous approach

then +1 for ideas expressed in MNGSITE-245

Don't hesitate to ask if you need help to review: notice that IRC is  
open for

immediate feedback about such things

Regards,

Hervé

Le lundi 29 juin 2015 22:26:49 Manfred Moser a écrit :

Hi all,


I have not heard any feedback and had positive feedback from Jason when  
we

talked about this in the past.

At this stage I will move forward with this suspecting that your  
silence is

a sign of agreement.

manfred

Manfred Moser wrote on 2015-06-25 13:07:
 Hi!

 I would like to do some cleanup of download page and related things.  
It is
 the most used page on the site and I think we could have some  
signficant

 improvements around the downloa and installation experience.

 Please check out details at
 https://issues.apache.org/jira/browse/MNGSITE-245


 and comment here or in the issue. I only want to go ahead with this  
larger

 change if I get some confirmation.

 Manfred

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



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


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

Re: Maven site cleanup

2015-06-30 Thread Karl Heinz Marbaise


Hi Manfred,


please do so

whatever you do will better than the current state ...

Thanks for working on that...

Kind regards
Karl Heinz Marbaise
On 6/29/15 10:26 PM, Manfred Moser wrote:

Hi all,


I have not heard any feedback and had positive feedback from Jason when we 
talked about this in the past.

At this stage I will move forward with this suspecting that your silence is a 
sign of agreement.

manfred


Manfred Moser wrote on 2015-06-25 13:07:


Hi!

I would like to do some cleanup of download page and related things. It is
the most used page on the site and I think we could have some signficant
improvements around the downloa and installation experience.

Please check out details at
https://issues.apache.org/jira/browse/MNGSITE-245


and comment here or in the issue. I only want to go ahead with this larger
change if I get some confirmation.

Manfred




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

Re: Maven site cleanup

2015-06-30 Thread Arnaud Héritier

+1000
All docs improvements are good to take...

On Mon, Jun 29, 2015 at 10:26 PM, Manfred Moser manf...@simpligility.com
wrote:

 Hi all,


 I have not heard any feedback and had positive feedback from Jason when we
 talked about this in the past.

 At this stage I will move forward with this suspecting that your silence
 is a sign of agreement.

 manfred


 Manfred Moser wrote on 2015-06-25 13:07:
 
  Hi!
 
  I would like to do some cleanup of download page and related things. It
 is
  the most used page on the site and I think we could have some signficant
  improvements around the downloa and installation experience.
 
  Please check out details at
  https://issues.apache.org/jira/browse/MNGSITE-245
 
 
  and comment here or in the issue. I only want to go ahead with this
 larger
  change if I get some confirmation.
 
  Manfred
 
 


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




-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: Maven site cleanup

2015-06-30 Thread Hervé BOUTEMY

Hi,

I like the new http://maven.apache.org/repository-management.html

This proves that when you completely rewrite some pages, the result is far 
better than the previous approach

then +1 for ideas expressed in MNGSITE-245

Don't hesitate to ask if you need help to review: notice that IRC is open for 
immediate feedback about such things

Regards,

Hervé

Le lundi 29 juin 2015 22:26:49 Manfred Moser a écrit :
 Hi all,
 
 
 I have not heard any feedback and had positive feedback from Jason when we
 talked about this in the past.
 
 At this stage I will move forward with this suspecting that your silence is
 a sign of agreement.
 
 manfred
 
 Manfred Moser wrote on 2015-06-25 13:07:
  Hi!
  
  I would like to do some cleanup of download page and related things. It is
  the most used page on the site and I think we could have some signficant
  improvements around the downloa and installation experience.
  
  Please check out details at
  https://issues.apache.org/jira/browse/MNGSITE-245
  
  
  and comment here or in the issue. I only want to go ahead with this larger
  change if I get some confirmation.
  
  Manfred
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


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

Re: Maven site cleanup

2015-06-29 Thread Manfred Moser

Hi all,


I have not heard any feedback and had positive feedback from Jason when we 
talked about this in the past. 

At this stage I will move forward with this suspecting that your silence is a 
sign of agreement.

manfred


Manfred Moser wrote on 2015-06-25 13:07:
 
 Hi!
 
 I would like to do some cleanup of download page and related things. It is
 the most used page on the site and I think we could have some signficant
 improvements around the downloa and installation experience.
 
 Please check out details at
 https://issues.apache.org/jira/browse/MNGSITE-245

 
 and comment here or in the issue. I only want to go ahead with this larger
 change if I get some confirmation.
 
 Manfred
 



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

Re: Maven site cleanup

2015-06-29 Thread Jason van Zyl

http://s1.postimg.org/7ge8xeulr/flamethrower.jpg

 On Jun 29, 2015, at 4:26 PM, Manfred Moser manf...@simpligility.com wrote:
 
 Hi all,
 
 
 I have not heard any feedback and had positive feedback from Jason when we 
 talked about this in the past. 
 
 At this stage I will move forward with this suspecting that your silence is a 
 sign of agreement.
 
 manfred
 
 
 Manfred Moser wrote on 2015-06-25 13:07:
 
 Hi!
 
 I would like to do some cleanup of download page and related things. It is
 the most used page on the site and I think we could have some signficant
 improvements around the downloa and installation experience.
 
 Please check out details at
 https://issues.apache.org/jira/browse/MNGSITE-245
 
 
 and comment here or in the issue. I only want to go ahead with this larger
 change if I get some confirmation.
 
 Manfred
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Lastly, Impossible. The lamest of the lame excuses! Difficult maybe, or 
impractical, or too expensive, but rarely is anything impossible.

  -- Yvon Chouinard, Let my People Go Surfing













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

Re: Two cleanup patches for maven-eclipse-plugin (MECLIPSE-697, MECLIPSE-758)

2015-04-09 Thread Andreas Gudian

Great, Thanks!

I'll do the 2.10 release in a not too distant future.


Am Donnerstag, 9. April 2015 schrieb Joseph Walton :

 I've taken a look at two cleanup tasks for maven-eclipse-plugin.

 One is a clearout of long-deprecated classes:

 https://issues.apache.org/jira/browse/MECLIPSE-697

 and the other is updating the mojos to use annotations:

 https://issues.apache.org/jira/browse/MECLIPSE-758

 Both have patches attached which apply cleanly and leave the integration
 tests passing. The one for MECLIPSE-758 applies cleanly on top of
 MECLIPSE-697.

 Would someone with commit privileges be able to take a look and apply them,
 or give me some feedback? I understand that releasing 2.10 isn't a priority
 right now, but it'd be nice to get those in place to simplify things for
 when that happens.

 Thanks.

Two cleanup patches for maven-eclipse-plugin (MECLIPSE-697, MECLIPSE-758)

2015-04-09 Thread Joseph Walton

I've taken a look at two cleanup tasks for maven-eclipse-plugin.

One is a clearout of long-deprecated classes:

https://issues.apache.org/jira/browse/MECLIPSE-697

and the other is updating the mojos to use annotations:

https://issues.apache.org/jira/browse/MECLIPSE-758

Both have patches attached which apply cleanly and leave the integration
tests passing. The one for MECLIPSE-758 applies cleanly on top of
MECLIPSE-697.

Would someone with commit privileges be able to take a look and apply them,
or give me some feedback? I understand that releasing 2.10 isn't a priority
right now, but it'd be nice to get those in place to simplify things for
when that happens.

Thanks.

Maven 1.x cleanup

2014-07-28 Thread Brett Porter

Hi,

About a year ago, the EOL banner was added for Maven 1.x. Today I saw there was 
a still a maven-1.x link in the navigation from the parent POM, which I 
removed, and added a single section to the bottom of the front page for 
archived documentation.

Looking at http://maven.apache.org/maven-1.x-eol.html, it says that the docs 
will move to archives, but that hadn't happened yet - so I did that also and 
put in a redirect. Let me know if you spot any issues.

The doc also says that the SVN tree will move to the retired section - does 
anyone still want to pursue that for maven-1 and maven-2? The main downside is 
that it breaks old tag locations.

- Brett

Re: Maven 1.x cleanup

2014-07-28 Thread Fred Cooke

Leave SVN alone, it's only a matter of time before it's permanently retired
in it's entirety, right?


On Tue, Jul 29, 2014 at 12:58 PM, Brett Porter br...@apache.org wrote:

 Hi,

 About a year ago, the EOL banner was added for Maven 1.x. Today I saw
 there was a still a maven-1.x link in the navigation from the parent POM,
 which I removed, and added a single section to the bottom of the front page
 for archived documentation.

 Looking at http://maven.apache.org/maven-1.x-eol.html, it says that the
 docs will move to archives, but that hadn't happened yet - so I did that
 also and put in a redirect. Let me know if you spot any issues.

 The doc also says that the SVN tree will move to the retired section -
 does anyone still want to pursue that for maven-1 and maven-2? The main
 downside is that it breaks old tag locations.

 - Brett

Further cleanup of Builders (extension of MNG-5575)

2014-02-06 Thread Jason van Zyl

Hi,

I made a first pass at coalescing the logic for a specific way to build (single 
threaded, multi threaded, weave) into its own implementation but there is still 
much cleanup to be done. This was pure refactoring and there isn't much 
functional change aside from adding a command line parameter to specify the id 
of a specific builder if you have your own implementation. I'm using this 
capability for an aggressive mode of parallelization and while that works the 
core is still a bit of a mess, and the signature for a Builder still isn't very 
nice. It should ultimately become:

builder.build( session );

or if we ultimately make the session immutable (which would be nice because in 
any parallel mode it has to be cloned for safety which is expensive)

build.build( session, mutableDataThatCanPotentiallyBeSharedBetweenProjects )

Right now the weave mode code has been conflated into much of the other code 
and it should be contained to its implementation. Ideally a builder gets the 
projects to build and the task segments to execute (clean install) and the rest 
is up to the implementation. All scheduling information, specific metrics, 
particulars about the order of execution should all be local to the 
implementation. Now that there is a clean spot at the end of the build that you 
can attach to the ordering of execution that occurs in a Builder won't affect 
code that takes advantage of this. Though code using the if last 
reactorProject type logic need to be change as that breaks badly in parallel 
mode. The projects to built are already stored in the session, we can probably 
store the task segments there as well to try and reduce the signature of a 
Builder.

I would like to start the next phase by removing the weave mode code. I don't 
think it's really a viable model for execution, and even if it was a cleaner 
implementation can be made but I don't think anyone is really using it to be 
honest. If your projects are modularized properly you will be rewarded in any 
parallel mode. I think the weave mode would just encourage poor structuring and 
ultimately not much gain because even if you can move a little bit ahead in the 
build and do a few segments in a few more projects you're still going to get 
blocked by the critical path and if you don't clean that up you're screwed 
anyway. The second you clean that up any parallelized mode you will be rewarded 
and the complexity of the weave mode for possibly a slight gain is not worth 
it. 

At any rate there is a lot more cleanup to do but I would like to start by 
removing the weave mode. Really this is up to Kristian, but it will help me 
greatly clean up the rest of the code.

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

Re: Further cleanup of Builders (extension of MNG-5575)

2014-02-06 Thread Kristian Rosenvold

I can fremover weave mode entirely this weekend. It wasnt worth it.

K
6. feb. 2014 16:06 skrev Jason van Zyl ja...@takari.io følgende:

 Hi,

 I made a first pass at coalescing the logic for a specific way to build
 (single threaded, multi threaded, weave) into its own implementation but
 there is still much cleanup to be done. This was pure refactoring and there
 isn't much functional change aside from adding a command line parameter to
 specify the id of a specific builder if you have your own implementation.
 I'm using this capability for an aggressive mode of parallelization and
 while that works the core is still a bit of a mess, and the signature for a
 Builder still isn't very nice. It should ultimately become:

 builder.build( session );

 or if we ultimately make the session immutable (which would be nice
 because in any parallel mode it has to be cloned for safety which is
 expensive)

 build.build( session, mutableDataThatCanPotentiallyBeSharedBetweenProjects
 )

 Right now the weave mode code has been conflated into much of the other
 code and it should be contained to its implementation. Ideally a builder
 gets the projects to build and the task segments to execute (clean install)
 and the rest is up to the implementation. All scheduling information,
 specific metrics, particulars about the order of execution should all be
 local to the implementation. Now that there is a clean spot at the end of
 the build that you can attach to the ordering of execution that occurs in a
 Builder won't affect code that takes advantage of this. Though code using
 the if last reactorProject type logic need to be change as that breaks
 badly in parallel mode. The projects to built are already stored in the
 session, we can probably store the task segments there as well to try and
 reduce the signature of a Builder.

 I would like to start the next phase by removing the weave mode code. I
 don't think it's really a viable model for execution, and even if it was a
 cleaner implementation can be made but I don't think anyone is really using
 it to be honest. If your projects are modularized properly you will be
 rewarded in any parallel mode. I think the weave mode would just encourage
 poor structuring and ultimately not much gain because even if you can move
 a little bit ahead in the build and do a few segments in a few more
 projects you're still going to get blocked by the critical path and if you
 don't clean that up you're screwed anyway. The second you clean that up any
 parallelized mode you will be rewarded and the complexity of the weave mode
 for possibly a slight gain is not worth it.

 At any rate there is a lot more cleanup to do but I would like to start by
 removing the weave mode. Really this is up to Kristian, but it will help me
 greatly clean up the rest of the code.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -

 First, the taking in of scattered particulars under one Idea,
 so that everyone understands what is being talked about ... Second,
 the separation of the Idea into parts, by dividing it at the joints,
 as nature directs, not breaking any limb in half as a bad carver might.

   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

Re: Further cleanup of Builders (extension of MNG-5575)

2014-02-06 Thread Tamás Cservenák

Jason,

a bit off topic, but you mention that  if last reactorProject type logic
breaks badly in parallel mode.

Any pointers how to fix/replace it?


Thanks,
~t~


On Thu, Feb 6, 2014 at 4:05 PM, Jason van Zyl ja...@takari.io wrote:

 Hi,

 I made a first pass at coalescing the logic for a specific way to build
 (single threaded, multi threaded, weave) into its own implementation but
 there is still much cleanup to be done. This was pure refactoring and there
 isn't much functional change aside from adding a command line parameter to
 specify the id of a specific builder if you have your own implementation.
 I'm using this capability for an aggressive mode of parallelization and
 while that works the core is still a bit of a mess, and the signature for a
 Builder still isn't very nice. It should ultimately become:

 builder.build( session );

 or if we ultimately make the session immutable (which would be nice
 because in any parallel mode it has to be cloned for safety which is
 expensive)

 build.build( session, mutableDataThatCanPotentiallyBeSharedBetweenProjects
 )

 Right now the weave mode code has been conflated into much of the other
 code and it should be contained to its implementation. Ideally a builder
 gets the projects to build and the task segments to execute (clean install)
 and the rest is up to the implementation. All scheduling information,
 specific metrics, particulars about the order of execution should all be
 local to the implementation. Now that there is a clean spot at the end of
 the build that you can attach to the ordering of execution that occurs in a
 Builder won't affect code that takes advantage of this. Though code using
 the if last reactorProject type logic need to be change as that breaks
 badly in parallel mode. The projects to built are already stored in the
 session, we can probably store the task segments there as well to try and
 reduce the signature of a Builder.

 I would like to start the next phase by removing the weave mode code. I
 don't think it's really a viable model for execution, and even if it was a
 cleaner implementation can be made but I don't think anyone is really using
 it to be honest. If your projects are modularized properly you will be
 rewarded in any parallel mode. I think the weave mode would just encourage
 poor structuring and ultimately not much gain because even if you can move
 a little bit ahead in the build and do a few segments in a few more
 projects you're still going to get blocked by the critical path and if you
 don't clean that up you're screwed anyway. The second you clean that up any
 parallelized mode you will be rewarded and the complexity of the weave mode
 for possibly a slight gain is not worth it.

 At any rate there is a lot more cleanup to do but I would like to start by
 removing the weave mode. Really this is up to Kristian, but it will help me
 greatly clean up the rest of the code.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -

 First, the taking in of scattered particulars under one Idea,
 so that everyone understands what is being talked about ... Second,
 the separation of the Idea into parts, by dividing it at the joints,
 as nature directs, not breaking any limb in half as a bad carver might.

   -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

Re: Further cleanup of Builders (extension of MNG-5575)

2014-02-06 Thread Jason van Zyl

If you're not running in parallel mode you will be fine. If you are then right
now you can use the new method introduced in the
AbstractMavenLifecycleParticipant:

https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/AbstractMavenLifecycleParticipant.java#L68

This is what I'm using right now for my deploy-at-end logic, but collectively
we need to refine Maven's overall lifecycle as having normal plugins being
capable of executing before/after the actual build would be useful. Right now
you have to create an AbstractMavenLifecycleParticipant and use the
before/after methods there. I don't think this is ideal but it's in the public
API now so it will stay there for a long time if you need something now.

On Feb 6, 2014, at 3:37 PM, Tamás Cservenák ta...@cservenak.net wrote:

Jason,

a bit off topic, but you mention that if last reactorProject type logic
breaks badly in parallel mode.

Any pointers how to fix/replace it?

Thanks,
~t~

On Thu, Feb 6, 2014 at 4:05 PM, Jason van Zyl ja...@takari.io wrote:

Hi,

I made a first pass at coalescing the logic for a specific way to build
(single threaded, multi threaded, weave) into its own implementation but
there is still much cleanup to be done. This was pure refactoring and there
isn't much functional change aside from adding a command line parameter to
specify the id of a specific builder if you have your own implementation.
I'm using this capability for an aggressive mode of parallelization and
while that works the core is still a bit of a mess, and the signature for a
Builder still isn't very nice. It should ultimately become:

builder.build( session );

or if we ultimately make the session immutable (which would be nice
because in any parallel mode it has to be cloned for safety which is
expensive)

build.build( session, mutableDataThatCanPotentiallyBeSharedBetweenProjects
)

Right now the weave mode code has been conflated into much of the other
code and it should be contained to its implementation. Ideally a builder
gets the projects to build and the task segments to execute (clean install)
and the rest is up to the implementation. All scheduling information,
specific metrics, particulars about the order of execution should all be
local to the implementation. Now that there is a clean spot at the end of
the build that you can attach to the ordering of execution that occurs in a
Builder won't affect code that takes advantage of this. Though code using
the if last reactorProject type logic need to be change as that breaks
badly in parallel mode. The projects to built are already stored in the
session, we can probably store the task segments there as well to try and
reduce the signature of a Builder.

I would like to start the next phase by removing the weave mode code. I
don't think it's really a viable model for execution, and even if it was a
cleaner implementation can be made but I don't think anyone is really using
it to be honest. If your projects are modularized properly you will be
rewarded in any parallel mode. I think the weave mode would just encourage
poor structuring and ultimately not much gain because even if you can move
a little bit ahead in the build and do a few segments in a few more
projects you're still going to get blocked by the critical path and if you
don't clean that up you're screwed anyway. The second you clean that up any
parallelized mode you will be rewarded and the complexity of the weave mode
for possibly a slight gain is not worth it.

At any rate there is a lot more cleanup to do but I would like to start by
removing the weave mode. Really this is up to Kristian, but it will help me
greatly clean up the rest of the code.

Thanks,

Jason

--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)

Thanks,

Jason

--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau

Re: Further cleanup of Builders (extension of MNG-5575)

2014-02-06 Thread Jason van Zyl

I can remove the implementation as it's all fairly self-contained, but you 
probably know best which classes like Schedule, Scheduling, ProjectIndex, 
PhaseRecorder and possibly other classes that were weave specific that we can 
remove from the lifecycle executor code. If that's done it will help a lot and 
then I want to try and whittle the Builder interface down to

builder.build( session )

On Feb 6, 2014, at 11:16 AM, Kristian Rosenvold kristian.rosenv...@gmail.com 
wrote:

 I can fremover weave mode entirely this weekend. It wasnt worth it.
 
 K
 6. feb. 2014 16:06 skrev Jason van Zyl ja...@takari.io følgende:
 
 Hi,
 
 I made a first pass at coalescing the logic for a specific way to build
 (single threaded, multi threaded, weave) into its own implementation but
 there is still much cleanup to be done. This was pure refactoring and there
 isn't much functional change aside from adding a command line parameter to
 specify the id of a specific builder if you have your own implementation.
 I'm using this capability for an aggressive mode of parallelization and
 while that works the core is still a bit of a mess, and the signature for a
 Builder still isn't very nice. It should ultimately become:
 
 builder.build( session );
 
 or if we ultimately make the session immutable (which would be nice
 because in any parallel mode it has to be cloned for safety which is
 expensive)
 
 build.build( session, mutableDataThatCanPotentiallyBeSharedBetweenProjects
 )
 
 Right now the weave mode code has been conflated into much of the other
 code and it should be contained to its implementation. Ideally a builder
 gets the projects to build and the task segments to execute (clean install)
 and the rest is up to the implementation. All scheduling information,
 specific metrics, particulars about the order of execution should all be
 local to the implementation. Now that there is a clean spot at the end of
 the build that you can attach to the ordering of execution that occurs in a
 Builder won't affect code that takes advantage of this. Though code using
 the if last reactorProject type logic need to be change as that breaks
 badly in parallel mode. The projects to built are already stored in the
 session, we can probably store the task segments there as well to try and
 reduce the signature of a Builder.
 
 I would like to start the next phase by removing the weave mode code. I
 don't think it's really a viable model for execution, and even if it was a
 cleaner implementation can be made but I don't think anyone is really using
 it to be honest. If your projects are modularized properly you will be
 rewarded in any parallel mode. I think the weave mode would just encourage
 poor structuring and ultimately not much gain because even if you can move
 a little bit ahead in the build and do a few segments in a few more
 projects you're still going to get blocked by the critical path and if you
 don't clean that up you're screwed anyway. The second you clean that up any
 parallelized mode you will be rewarded and the complexity of the weave mode
 for possibly a slight gain is not worth it.
 
 At any rate there is a lot more cleanup to do but I would like to start by
 removing the weave mode. Really this is up to Kristian, but it will help me
 greatly clean up the rest of the code.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 http://twitter.com/takari_io
 -
 
 First, the taking in of scattered particulars under one Idea,
 so that everyone understands what is being talked about ... Second,
 the separation of the Idea into parts, by dividing it at the joints,
 as nature directs, not breaking any limb in half as a bad carver might.
 
  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
 
 
 
 
 
 
 
 
 
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

We know what we are, but know not what we may be.

  -- Shakespeare

RE: JIRA Cleanup

2014-01-24 Thread Sievers, Jan

just a thought about going forward (maybe you do that already but thought I'd 
mention it):

when you create an issue on 
https://jira.codehaus.org/browse/MNG

there are 2 JIRA fields Testcase included and Patch Submitted.

a) this should help with filtering for quality bug reports in JIRA and
b) would be good to mention it on [1] or similar that bugs with these 2 
attributes will get priority

Regards,
Jan

[1] http://maven.apache.org/issue-tracking.html 




-Original Message-
From: Jason van Zyl [mailto:ja...@takari.io] 
Sent: Donnerstag, 23. Januar 2014 03:33
To: Maven Developers List
Subject: Re: JIRA Cleanup

I changed the strategy slightly as I thought it might be crappy if the issue 
was created 5 years ago, but the person updated it 2 months ago. So I took all 
the issues that have not been updated in the last year and unassigned and 
closed those out. Got to about the same number and thought this more fair.

I referred anyone looking at the comment to 
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014

I'll start sifting through what remains tomorrow.

On Jan 22, 2014, at 1:02 PM, Jason van Zyl ja...@takari.io wrote:

 Yup, it's very straight forward to add a comment to each of the issues that 
 will be closed. When I publish the accompanying documentation I can point the 
 comment at the documentation. Good call.
 
 On Jan 22, 2014, at 12:16 PM, Jason van Zyl ja...@takari.io wrote:
 
 Sure, good idea. I assume there's a relatively straight forward way to do 
 that with a bulk operation.
 
 On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org wrote:
 
 I advise that we add a comment in each closing issue explaining that it was
 closed specifically because it's more than 2 years old and to re-open it
 only if it is still valid. Otherwise, it will look very rude to close a
 ticket without an explanation.
 
 BTW, what I just recommended was done by JBoss Hibernate and Spring
 Framework when they cleared out their old tickets. It was great to know
 their reasoning.
 
 
 On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'm going to pull the ripcord tonight (8 hours from now).
 
 On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote:
 
 So after looking at the issues more closely even at the 5 year-old mark
 there are still too many. At the 2 year-old mark it's a bit more
 reasonable. If I close all issues older than 2 years-old which are not
 assigned thats 415 so we would be left with 220 open issues which after a
 week or two I can probably get through, faster with some help. But that's
 probably reasonable as more recent issues are pertinent to 3.x as I myself
 am probably not going to dig back into 2.x issues and fix them.
 
 So I propose sending a note to the dev and user list stating that we're
 trying to get the JIRA issue under control. We're closing all unassigned
 issues older than 2 years but people are free to reopen issues for bugs if
 they follow a process of providing a working stand-alone example of the
 problem.
 
 This will at least start the cleanup process.
 
 How's that sound?
 
 On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'll write something up and send it to the user and dev list.
 
 On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com
 wrote:
 
 +1 here.
 
 On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net
 wrote:
 +1 on clean up if we communicate this (and explain why).
 0 on move
 
 /Anders
 
 
 On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch
 wrote:
 
 +1 cleanup is a really good idea!
 
 On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com
 wrote:
 
 +1 with a jira cleanup (but documented and announced to users to
 let them
 understand what we do and why)
 +1 to move to ASF
 
 
 
 
 On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io
 wrote:
 
 Works for me to just start over on the ASF JIRA. There are a couple
 issues
 I'd move but we can migrate a issues easily. What can't continue
 is the
 complete, incomprehensible mess that is there now.
 
 On Jan 20, 2014, at 12:32 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
 
 If we are going wholesale dumping issues (and I am not against
 that), I
 have a more radical suggestion... let's just move core to the ASF
 JIRA...
 with next to no issues needing migration it would be easy ;-)
 
 
 On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote:
 
 Really, it's more about dropping a nuclear bomb on JIRA. While
 trying
 to
 sift through it this weekend it's clear to me it's less than
 ideal in
 there.
 
 There are issues that are 12 years old and while there might be
 some
 useful information in there that we hand select, I think
 anything that
 is
 older than 5 years we should just close as incomplete because
 with the
 great deal of change that's happened with 3.x most of it isn't
 relevant
 and
 if it is, and someone

Re: JIRA Cleanup

2014-01-24 Thread Jason van Zyl

Thanks, I think it's the only sane way to try and help people.

On Jan 23, 2014, at 5:43 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote:

 Jason,
 
 the wiki page is a really good writeup and I like the strategy to force
 reporters to create a simple project which will reproduce their issue.
 
 Regards
 Mirko
 -- 
 Sent from my mobile
 On Jan 23, 2014 3:33 AM, Jason van Zyl ja...@takari.io wrote:
 
 I changed the strategy slightly as I thought it might be crappy if the
 issue was created 5 years ago, but the person updated it 2 months ago. So I
 took all the issues that have not been updated in the last year and
 unassigned and closed those out. Got to about the same number and thought
 this more fair.
 
 I referred anyone looking at the comment to
 https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
 
 I'll start sifting through what remains tomorrow.
 
 On Jan 22, 2014, at 1:02 PM, Jason van Zyl ja...@takari.io wrote:
 
 Yup, it's very straight forward to add a comment to each of the issues
 that will be closed. When I publish the accompanying documentation I can
 point the comment at the documentation. Good call.
 
 On Jan 22, 2014, at 12:16 PM, Jason van Zyl ja...@takari.io wrote:
 
 Sure, good idea. I assume there's a relatively straight forward way to
 do that with a bulk operation.
 
 On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org
 wrote:
 
 I advise that we add a comment in each closing issue explaining that
 it was
 closed specifically because it's more than 2 years old and to re-open
 it
 only if it is still valid. Otherwise, it will look very rude to close a
 ticket without an explanation.
 
 BTW, what I just recommended was done by JBoss Hibernate and Spring
 Framework when they cleared out their old tickets. It was great to know
 their reasoning.
 
 
 On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io
 wrote:
 
 Ok, I'm going to pull the ripcord tonight (8 hours from now).
 
 On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote:
 
 So after looking at the issues more closely even at the 5 year-old
 mark
 there are still too many. At the 2 year-old mark it's a bit more
 reasonable. If I close all issues older than 2 years-old which are not
 assigned thats 415 so we would be left with 220 open issues which
 after a
 week or two I can probably get through, faster with some help. But
 that's
 probably reasonable as more recent issues are pertinent to 3.x as I
 myself
 am probably not going to dig back into 2.x issues and fix them.
 
 So I propose sending a note to the dev and user list stating that
 we're
 trying to get the JIRA issue under control. We're closing all
 unassigned
 issues older than 2 years but people are free to reopen issues for
 bugs if
 they follow a process of providing a working stand-alone example of
 the
 problem.
 
 This will at least start the cleanup process.
 
 How's that sound?
 
 On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'll write something up and send it to the user and dev list.
 
 On Jan 20, 2014, at 2:17 PM, Benson Margulies 
 bimargul...@gmail.com
 wrote:
 
 +1 here.
 
 On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net
 wrote:
 +1 on clean up if we communicate this (and explain why).
 0 on move
 
 /Anders
 
 
 On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi 
 d...@fortysix.ch
 wrote:
 
 +1 cleanup is a really good idea!
 
 On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com
 wrote:
 
 +1 with a jira cleanup (but documented and announced to users to
 let them
 understand what we do and why)
 +1 to move to ASF
 
 
 
 
 On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io
 
 wrote:
 
 Works for me to just start over on the ASF JIRA. There are a
 couple
 issues
 I'd move but we can migrate a issues easily. What can't
 continue
 is the
 complete, incomprehensible mess that is there now.
 
 On Jan 20, 2014, at 12:32 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
 
 If we are going wholesale dumping issues (and I am not against
 that), I
 have a more radical suggestion... let's just move core to the
 ASF
 JIRA...
 with next to no issues needing migration it would be easy ;-)
 
 
 On 20 January 2014 17:23, Jason van Zyl ja...@takari.io
 wrote:
 
 Really, it's more about dropping a nuclear bomb on JIRA.
 While
 trying
 to
 sift through it this weekend it's clear to me it's less than
 ideal in
 there.
 
 There are issues that are 12 years old and while there might
 be
 some
 useful information in there that we hand select, I think
 anything that
 is
 older than 5 years we should just close as incomplete because
 with the
 great deal of change that's happened with 3.x most of it
 isn't
 relevant
 and
 if it is, and someone cares that much then it can be reopened
 with a
 stand-alone working example of the problem.
 
 Now, as to the requirements for a stand-alone working
 example I
 think
 we
 should enforce

Re: JIRA Cleanup

2014-01-23 Thread Mirko Friedenhagen

Jason,

the wiki page is a really good writeup and I like the strategy to force
reporters to create a simple project which will reproduce their issue.

Regards
Mirko
-- 
Sent from my mobile
On Jan 23, 2014 3:33 AM, Jason van Zyl ja...@takari.io wrote:

 I changed the strategy slightly as I thought it might be crappy if the
 issue was created 5 years ago, but the person updated it 2 months ago. So I
 took all the issues that have not been updated in the last year and
 unassigned and closed those out. Got to about the same number and thought
 this more fair.

 I referred anyone looking at the comment to
 https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014

 I'll start sifting through what remains tomorrow.

 On Jan 22, 2014, at 1:02 PM, Jason van Zyl ja...@takari.io wrote:

  Yup, it's very straight forward to add a comment to each of the issues
 that will be closed. When I publish the accompanying documentation I can
 point the comment at the documentation. Good call.
 
  On Jan 22, 2014, at 12:16 PM, Jason van Zyl ja...@takari.io wrote:
 
  Sure, good idea. I assume there's a relatively straight forward way to
 do that with a bulk operation.
 
  On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org
 wrote:
 
  I advise that we add a comment in each closing issue explaining that
 it was
  closed specifically because it's more than 2 years old and to re-open
 it
  only if it is still valid. Otherwise, it will look very rude to close a
  ticket without an explanation.
 
  BTW, what I just recommended was done by JBoss Hibernate and Spring
  Framework when they cleared out their old tickets. It was great to know
  their reasoning.
 
 
  On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io
 wrote:
 
  Ok, I'm going to pull the ripcord tonight (8 hours from now).
 
  On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote:
 
  So after looking at the issues more closely even at the 5 year-old
 mark
  there are still too many. At the 2 year-old mark it's a bit more
  reasonable. If I close all issues older than 2 years-old which are not
  assigned thats 415 so we would be left with 220 open issues which
 after a
  week or two I can probably get through, faster with some help. But
 that's
  probably reasonable as more recent issues are pertinent to 3.x as I
 myself
  am probably not going to dig back into 2.x issues and fix them.
 
  So I propose sending a note to the dev and user list stating that
 we're
  trying to get the JIRA issue under control. We're closing all
 unassigned
  issues older than 2 years but people are free to reopen issues for
 bugs if
  they follow a process of providing a working stand-alone example of
 the
  problem.
 
  This will at least start the cleanup process.
 
  How's that sound?
 
  On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote:
 
  Ok, I'll write something up and send it to the user and dev list.
 
  On Jan 20, 2014, at 2:17 PM, Benson Margulies 
 bimargul...@gmail.com
  wrote:
 
  +1 here.
 
  On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net
  wrote:
  +1 on clean up if we communicate this (and explain why).
  0 on move
 
  /Anders
 
 
  On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi 
 d...@fortysix.ch
  wrote:
 
  +1 cleanup is a really good idea!
 
  On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com
  wrote:
 
  +1 with a jira cleanup (but documented and announced to users to
  let them
  understand what we do and why)
  +1 to move to ASF
 
 
 
 
  On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io
 
  wrote:
 
  Works for me to just start over on the ASF JIRA. There are a
 couple
  issues
  I'd move but we can migrate a issues easily. What can't
 continue
  is the
  complete, incomprehensible mess that is there now.
 
  On Jan 20, 2014, at 12:32 PM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
  If we are going wholesale dumping issues (and I am not against
  that), I
  have a more radical suggestion... let's just move core to the
 ASF
  JIRA...
  with next to no issues needing migration it would be easy ;-)
 
 
  On 20 January 2014 17:23, Jason van Zyl ja...@takari.io
 wrote:
 
  Really, it's more about dropping a nuclear bomb on JIRA.
 While
  trying
  to
  sift through it this weekend it's clear to me it's less than
  ideal in
  there.
 
  There are issues that are 12 years old and while there might
 be
  some
  useful information in there that we hand select, I think
  anything that
  is
  older than 5 years we should just close as incomplete because
  with the
  great deal of change that's happened with 3.x most of it
 isn't
  relevant
  and
  if it is, and someone cares that much then it can be reopened
  with a
  stand-alone working example of the problem.
 
  Now, as to the requirements for a stand-alone working
 example I
  think
  we
  should enforce this because personally I'm not going to
 check out
  someone's
  project, figure

Re: JIRA Cleanup

Ok, I'm going to pull the ripcord tonight (8 hours from now).

On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote:

 So after looking at the issues more closely even at the 5 year-old mark there 
 are still too many. At the 2 year-old mark it's a bit more reasonable. If I 
 close all issues older than 2 years-old which are not assigned thats 415 so 
 we would be left with 220 open issues which after a week or two I can 
 probably get through, faster with some help. But that's probably reasonable 
 as more recent issues are pertinent to 3.x as I myself am probably not going 
 to dig back into 2.x issues and fix them.
 
 So I propose sending a note to the dev and user list stating that we're 
 trying to get the JIRA issue under control. We're closing all unassigned 
 issues older than 2 years but people are free to reopen issues for bugs if 
 they follow a process of providing a working stand-alone example of the 
 problem.
 
 This will at least start the cleanup process.
 
 How's that sound?
 
 On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'll write something up and send it to the user and dev list.
 
 On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote:
 
 +1 here.
 
 On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote:
 +1 on clean up if we communicate this (and explain why).
 0 on move
 
 /Anders
 
 
 On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch 
 wrote:
 
 +1 cleanup is a really good idea!
 
 On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote:
 
 +1 with a jira cleanup (but documented and announced to users to let them
 understand what we do and why)
 +1 to move to ASF
 
 
 
 
 On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote:
 
 Works for me to just start over on the ASF JIRA. There are a couple
 issues
 I'd move but we can migrate a issues easily. What can't continue is the
 complete, incomprehensible mess that is there now.
 
 On Jan 20, 2014, at 12:32 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
 
 If we are going wholesale dumping issues (and I am not against that), I
 have a more radical suggestion... let's just move core to the ASF
 JIRA...
 with next to no issues needing migration it would be easy ;-)
 
 
 On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote:
 
 Really, it's more about dropping a nuclear bomb on JIRA. While trying
 to
 sift through it this weekend it's clear to me it's less than ideal in
 there.
 
 There are issues that are 12 years old and while there might be some
 useful information in there that we hand select, I think anything that
 is
 older than 5 years we should just close as incomplete because with the
 great deal of change that's happened with 3.x most of it isn't
 relevant
 and
 if it is, and someone cares that much then it can be reopened with a
 stand-alone working example of the problem.
 
 Now, as to the requirements for a stand-alone working example I think
 we
 should enforce this because personally I'm not going to check out
 someone's
 project, figure out how to interpret it in relation to the actual
 problem
 in Maven and then create a project I can turn into an IT. I'm just not
 going to do it generally. There might be exceptions but I don't want
 to
 read a textual examples or try to figure out snippets of a production
 project that can't be shared. In m2e we require a working example
 project
 to even look at a problem and if the issue sits there for a year with
 a
 working sample project we close it.
 
 Having an issue tracking system with 700 open issues is useless, so I
 would like to do a mass purge. It shouldn't really get beyond 50 open
 issues or it's just impossible to manage effectively.
 
 Not sure what anyone else thinks but our JIRA situation is just not
 effective. I'm thinking anything over 5 years old that isn't assigned
 to a
 core developer we just close as incomplete and then see what we're
 left
 with. If anyone complains then we point them at doco (I'll write it)
 about
 creating a stand-alone project because otherwise it become
 impossible. I
 spent 8 hours over the weekend looking at issues trying to interpret
 what
 someone was trying to say and I don't want to guess. If the user cares
 enough they can make an example project.
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 happiness is like a butterfly: the more you chase it, the more it will
 elude you, but if you turn your attention to other things, it will
 come
 and sit softly on your shoulder ...
 
 -- Thoreau
 
 
 
 
 
 
 
 
 
 
 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 believe nothing

Re: JIRA Cleanup

2014-01-22 Thread Paul Benedict

I advise that we add a comment in each closing issue explaining that it was
closed specifically because it's more than 2 years old and to re-open it
only if it is still valid. Otherwise, it will look very rude to close a
ticket without an explanation.

BTW, what I just recommended was done by JBoss Hibernate and Spring
Framework when they cleared out their old tickets. It was great to know
their reasoning.


On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote:

 Ok, I'm going to pull the ripcord tonight (8 hours from now).

 On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote:

  So after looking at the issues more closely even at the 5 year-old mark
 there are still too many. At the 2 year-old mark it's a bit more
 reasonable. If I close all issues older than 2 years-old which are not
 assigned thats 415 so we would be left with 220 open issues which after a
 week or two I can probably get through, faster with some help. But that's
 probably reasonable as more recent issues are pertinent to 3.x as I myself
 am probably not going to dig back into 2.x issues and fix them.
 
  So I propose sending a note to the dev and user list stating that we're
 trying to get the JIRA issue under control. We're closing all unassigned
 issues older than 2 years but people are free to reopen issues for bugs if
 they follow a process of providing a working stand-alone example of the
 problem.
 
  This will at least start the cleanup process.
 
  How's that sound?
 
  On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote:
 
  Ok, I'll write something up and send it to the user and dev list.
 
  On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com
 wrote:
 
  +1 here.
 
  On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net
 wrote:
  +1 on clean up if we communicate this (and explain why).
  0 on move
 
  /Anders
 
 
  On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch
 wrote:
 
  +1 cleanup is a really good idea!
 
  On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com
 wrote:
 
  +1 with a jira cleanup (but documented and announced to users to
 let them
  understand what we do and why)
  +1 to move to ASF
 
 
 
 
  On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io
 wrote:
 
  Works for me to just start over on the ASF JIRA. There are a couple
  issues
  I'd move but we can migrate a issues easily. What can't continue
 is the
  complete, incomprehensible mess that is there now.
 
  On Jan 20, 2014, at 12:32 PM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
  If we are going wholesale dumping issues (and I am not against
 that), I
  have a more radical suggestion... let's just move core to the ASF
  JIRA...
  with next to no issues needing migration it would be easy ;-)
 
 
  On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote:
 
  Really, it's more about dropping a nuclear bomb on JIRA. While
 trying
  to
  sift through it this weekend it's clear to me it's less than
 ideal in
  there.
 
  There are issues that are 12 years old and while there might be
 some
  useful information in there that we hand select, I think
 anything that
  is
  older than 5 years we should just close as incomplete because
 with the
  great deal of change that's happened with 3.x most of it isn't
  relevant
  and
  if it is, and someone cares that much then it can be reopened
 with a
  stand-alone working example of the problem.
 
  Now, as to the requirements for a stand-alone working example I
 think
  we
  should enforce this because personally I'm not going to check out
  someone's
  project, figure out how to interpret it in relation to the actual
  problem
  in Maven and then create a project I can turn into an IT. I'm
 just not
  going to do it generally. There might be exceptions but I don't
 want
  to
  read a textual examples or try to figure out snippets of a
 production
  project that can't be shared. In m2e we require a working example
  project
  to even look at a problem and if the issue sits there for a year
 with
  a
  working sample project we close it.
 
  Having an issue tracking system with 700 open issues is useless,
 so I
  would like to do a mass purge. It shouldn't really get beyond 50
 open
  issues or it's just impossible to manage effectively.
 
  Not sure what anyone else thinks but our JIRA situation is just
 not
  effective. I'm thinking anything over 5 years old that isn't
 assigned
  to a
  core developer we just close as incomplete and then see what
 we're
  left
  with. If anyone complains then we point them at doco (I'll write
 it)
  about
  creating a stand-alone project because otherwise it become
  impossible. I
  spent 8 hours over the weekend looking at issues trying to
 interpret
  what
  someone was trying to say and I don't want to guess. If the user
 cares
  enough they can make an example project.
 
  Thanks,
 
  Jason

Re: JIRA Cleanup

Sure, good idea. I assume there's a relatively straight forward way to do that 
with a bulk operation.

On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org wrote:

 I advise that we add a comment in each closing issue explaining that it was
 closed specifically because it's more than 2 years old and to re-open it
 only if it is still valid. Otherwise, it will look very rude to close a
 ticket without an explanation.
 
 BTW, what I just recommended was done by JBoss Hibernate and Spring
 Framework when they cleared out their old tickets. It was great to know
 their reasoning.
 
 
 On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'm going to pull the ripcord tonight (8 hours from now).
 
 On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote:
 
 So after looking at the issues more closely even at the 5 year-old mark
 there are still too many. At the 2 year-old mark it's a bit more
 reasonable. If I close all issues older than 2 years-old which are not
 assigned thats 415 so we would be left with 220 open issues which after a
 week or two I can probably get through, faster with some help. But that's
 probably reasonable as more recent issues are pertinent to 3.x as I myself
 am probably not going to dig back into 2.x issues and fix them.
 
 So I propose sending a note to the dev and user list stating that we're
 trying to get the JIRA issue under control. We're closing all unassigned
 issues older than 2 years but people are free to reopen issues for bugs if
 they follow a process of providing a working stand-alone example of the
 problem.
 
 This will at least start the cleanup process.
 
 How's that sound?
 
 On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'll write something up and send it to the user and dev list.
 
 On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com
 wrote:
 
 +1 here.
 
 On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net
 wrote:
 +1 on clean up if we communicate this (and explain why).
 0 on move
 
 /Anders
 
 
 On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch
 wrote:
 
 +1 cleanup is a really good idea!
 
 On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com
 wrote:
 
 +1 with a jira cleanup (but documented and announced to users to
 let them
 understand what we do and why)
 +1 to move to ASF
 
 
 
 
 On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io
 wrote:
 
 Works for me to just start over on the ASF JIRA. There are a couple
 issues
 I'd move but we can migrate a issues easily. What can't continue
 is the
 complete, incomprehensible mess that is there now.
 
 On Jan 20, 2014, at 12:32 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
 
 If we are going wholesale dumping issues (and I am not against
 that), I
 have a more radical suggestion... let's just move core to the ASF
 JIRA...
 with next to no issues needing migration it would be easy ;-)
 
 
 On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote:
 
 Really, it's more about dropping a nuclear bomb on JIRA. While
 trying
 to
 sift through it this weekend it's clear to me it's less than
 ideal in
 there.
 
 There are issues that are 12 years old and while there might be
 some
 useful information in there that we hand select, I think
 anything that
 is
 older than 5 years we should just close as incomplete because
 with the
 great deal of change that's happened with 3.x most of it isn't
 relevant
 and
 if it is, and someone cares that much then it can be reopened
 with a
 stand-alone working example of the problem.
 
 Now, as to the requirements for a stand-alone working example I
 think
 we
 should enforce this because personally I'm not going to check out
 someone's
 project, figure out how to interpret it in relation to the actual
 problem
 in Maven and then create a project I can turn into an IT. I'm
 just not
 going to do it generally. There might be exceptions but I don't
 want
 to
 read a textual examples or try to figure out snippets of a
 production
 project that can't be shared. In m2e we require a working example
 project
 to even look at a problem and if the issue sits there for a year
 with
 a
 working sample project we close it.
 
 Having an issue tracking system with 700 open issues is useless,
 so I
 would like to do a mass purge. It shouldn't really get beyond 50
 open
 issues or it's just impossible to manage effectively.
 
 Not sure what anyone else thinks but our JIRA situation is just
 not
 effective. I'm thinking anything over 5 years old that isn't
 assigned
 to a
 core developer we just close as incomplete and then see what
 we're
 left
 with. If anyone complains then we point them at doco (I'll write
 it)
 about
 creating a stand-alone project because otherwise it become
 impossible. I
 spent 8 hours over the weekend looking at issues trying to
 interpret
 what
 someone was trying to say and I don't want to guess. If the user
 cares

Re: JIRA Cleanup

Yup, it's very straight forward to add a comment to each of the issues that 
will be closed. When I publish the accompanying documentation I can point the 
comment at the documentation. Good call.

On Jan 22, 2014, at 12:16 PM, Jason van Zyl ja...@takari.io wrote:

 Sure, good idea. I assume there's a relatively straight forward way to do 
 that with a bulk operation.
 
 On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org wrote:
 
 I advise that we add a comment in each closing issue explaining that it was
 closed specifically because it's more than 2 years old and to re-open it
 only if it is still valid. Otherwise, it will look very rude to close a
 ticket without an explanation.
 
 BTW, what I just recommended was done by JBoss Hibernate and Spring
 Framework when they cleared out their old tickets. It was great to know
 their reasoning.
 
 
 On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'm going to pull the ripcord tonight (8 hours from now).
 
 On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote:
 
 So after looking at the issues more closely even at the 5 year-old mark
 there are still too many. At the 2 year-old mark it's a bit more
 reasonable. If I close all issues older than 2 years-old which are not
 assigned thats 415 so we would be left with 220 open issues which after a
 week or two I can probably get through, faster with some help. But that's
 probably reasonable as more recent issues are pertinent to 3.x as I myself
 am probably not going to dig back into 2.x issues and fix them.
 
 So I propose sending a note to the dev and user list stating that we're
 trying to get the JIRA issue under control. We're closing all unassigned
 issues older than 2 years but people are free to reopen issues for bugs if
 they follow a process of providing a working stand-alone example of the
 problem.
 
 This will at least start the cleanup process.
 
 How's that sound?
 
 On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote:
 
 Ok, I'll write something up and send it to the user and dev list.
 
 On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com
 wrote:
 
 +1 here.
 
 On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net
 wrote:
 +1 on clean up if we communicate this (and explain why).
 0 on move
 
 /Anders
 
 
 On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch
 wrote:
 
 +1 cleanup is a really good idea!
 
 On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com
 wrote:
 
 +1 with a jira cleanup (but documented and announced to users to
 let them
 understand what we do and why)
 +1 to move to ASF
 
 
 
 
 On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io
 wrote:
 
 Works for me to just start over on the ASF JIRA. There are a couple
 issues
 I'd move but we can migrate a issues easily. What can't continue
 is the
 complete, incomprehensible mess that is there now.
 
 On Jan 20, 2014, at 12:32 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:
 
 If we are going wholesale dumping issues (and I am not against
 that), I
 have a more radical suggestion... let's just move core to the ASF
 JIRA...
 with next to no issues needing migration it would be easy ;-)
 
 
 On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote:
 
 Really, it's more about dropping a nuclear bomb on JIRA. While
 trying
 to
 sift through it this weekend it's clear to me it's less than
 ideal in
 there.
 
 There are issues that are 12 years old and while there might be
 some
 useful information in there that we hand select, I think
 anything that
 is
 older than 5 years we should just close as incomplete because
 with the
 great deal of change that's happened with 3.x most of it isn't
 relevant
 and
 if it is, and someone cares that much then it can be reopened
 with a
 stand-alone working example of the problem.
 
 Now, as to the requirements for a stand-alone working example I
 think
 we
 should enforce this because personally I'm not going to check out
 someone's
 project, figure out how to interpret it in relation to the actual
 problem
 in Maven and then create a project I can turn into an IT. I'm
 just not
 going to do it generally. There might be exceptions but I don't
 want
 to
 read a textual examples or try to figure out snippets of a
 production
 project that can't be shared. In m2e we require a working example
 project
 to even look at a problem and if the issue sits there for a year
 with
 a
 working sample project we close it.
 
 Having an issue tracking system with 700 open issues is useless,
 so I
 would like to do a mass purge. It shouldn't really get beyond 50
 open
 issues or it's just impossible to manage effectively.
 
 Not sure what anyone else thinks but our JIRA situation is just
 not
 effective. I'm thinking anything over 5 years old that isn't
 assigned
 to a
 core developer we just close as incomplete and then see what
 we're
 left
 with. If anyone complains then we

Re: JIRA Cleanup