Re: Ivy - Proposal for reviving the project and moving towards a release

[J Pai]

Sounds fine then.

-Jaikiran

On Monday, December 12, 2016, Matt Sicker  wrote:
> Issues in the release process? Those would be handled by multiple release
> candidates. People normally only use alphas and betas for new projects or
> new major versions of projects at Apache.
>
> On 11 December 2016 at 19:53, J Pai  wrote:
>
>> I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is
to
>> iron out any issues involved in the process itself which, from what I
read
>> in the other thread, might involve certain challenges for the first time.
>>
>> -Jaikiran
>>
>> On Sunday, December 11, 2016, Matt Sicker  wrote:
>> > Do we really need a beta release? If you're working on bugfixes first,
>> then
>> > a regular 2.4.1 release would be great. It would go through the normal
>> > Apache release candidate process, and perhaps we could get some Gradle
>> > developers to test it out as well since they still seem to be big users
>> of
>> > Ivy.
>> >
>> > Any committer to the Ant project could prepare the release and be a
>> release
>> > manager. The only requirements involving PMCs is to vote on approving
the
>> > release; adding your GPG key to the KEYS file (only PMCs can commit to
>> that
>> > repository involved); and committing the artifacts to the release svn
>> > repository (again, PMCs). I'm also not a committer, but if you're
>> > interested enough in maintaining Ivy, I'd guess that the PMCs may wish
to
>> > bring you on board to do so.
>> >
>> >
>> > On 11 December 2016 at 08:22, Jaikiran Pai 
>> wrote:
>> >
>> >> First off, I'm not an Ivy or Ant committer. The proposal that I make
>> below
>> >> for an Ivy release is based on what was discussed in a recent mail
>> thread
>> >> about the future of Ivy https://www.mail-archive.com/d
>> >> e...@ant.apache.org/msg45078.html. There was a suggestion that someone
>> from
>> >> community volunteer to try and bring in some activity into the project
>> and
>> >> see if we can create a release after triaging the JIRA issues.
>> >>
>> >>
>> >> I have had a look at the open issues in JIRA today and decided to
filter
>> >> out issues that are open, updated since Jan 2014 and affects versions
>> 2.1,
>> >> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
>> select
>> >> a few that I thought can be considered "active". This [1] returns 57
>> >> issues. I went ahead and looked at those issues today and have asked
for
>> >> more information in the JIRAs wherever relevant and have sent a couple
>> of
>> >> pull requests [2] [3] to fix some straightforward ones. I also have
>> another
>> >> PR that I opened this week to fix one other issue. Out of those 57
>> issues,
>> >> many are no longer relevant or don't have enough details. I don't have
>> JIRA
>> >> privileges to label them, share filters or even assign some to myself
to
>> >> track them better. So I think for now, we can rely on that JIRA search
>> >> query [1].
>> >>
>> >> At this point, I think, if we can target March 2017 for releasing a
>> >> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
>> good
>> >> start. Some of the issues noted in that JIRA are indeed important ones
>> and
>> >> would need some review/help in fixing them correctly, which
essentially
>> >> means, we need at least one person who has had experience with the Ivy
>> code
>> >> and its design details and also has the committer rights.
>> >>
>> >>
>> >> Does any of this look feasible? Let me know if this isn't enough to
move
>> >> things forward - I don't want to end up sending PRs and spending time
on
>> >> this if there's no way we can get to a proper release in the next few
>> >> months.
>> >>
>> >>
>> >> [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project%
>> >> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
>> >> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
>> >> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
>> >> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>> >>
>> >> [2] https://github.com/apache/ant-ivy/pull/11
>> >>
>> >> [3] https://github.com/apache/ant-ivy/pull/12
>> >>
>> >> -Jaikiran
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> >> For additional commands, e-mail: dev-h...@ant.apache.org
>> >>
>> >>
>> >
>> >
>> > --
>> > Matt Sicker 
>> >
>>
>
>
>
> --
> Matt Sicker 
>

Re: Ivy - Proposal for reviving the project and moving towards a release

[Matt Sicker]

Issues in the release process? Those would be handled by multiple release
candidates. People normally only use alphas and betas for new projects or
new major versions of projects at Apache.

On 11 December 2016 at 19:53, J Pai  wrote:

> I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is to
> iron out any issues involved in the process itself which, from what I read
> in the other thread, might involve certain challenges for the first time.
>
> -Jaikiran
>
> On Sunday, December 11, 2016, Matt Sicker  wrote:
> > Do we really need a beta release? If you're working on bugfixes first,
> then
> > a regular 2.4.1 release would be great. It would go through the normal
> > Apache release candidate process, and perhaps we could get some Gradle
> > developers to test it out as well since they still seem to be big users
> of
> > Ivy.
> >
> > Any committer to the Ant project could prepare the release and be a
> release
> > manager. The only requirements involving PMCs is to vote on approving the
> > release; adding your GPG key to the KEYS file (only PMCs can commit to
> that
> > repository involved); and committing the artifacts to the release svn
> > repository (again, PMCs). I'm also not a committer, but if you're
> > interested enough in maintaining Ivy, I'd guess that the PMCs may wish to
> > bring you on board to do so.
> >
> >
> > On 11 December 2016 at 08:22, Jaikiran Pai 
> wrote:
> >
> >> First off, I'm not an Ivy or Ant committer. The proposal that I make
> below
> >> for an Ivy release is based on what was discussed in a recent mail
> thread
> >> about the future of Ivy https://www.mail-archive.com/d
> >> e...@ant.apache.org/msg45078.html. There was a suggestion that someone
> from
> >> community volunteer to try and bring in some activity into the project
> and
> >> see if we can create a release after triaging the JIRA issues.
> >>
> >>
> >> I have had a look at the open issues in JIRA today and decided to filter
> >> out issues that are open, updated since Jan 2014 and affects versions
> 2.1,
> >> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
> select
> >> a few that I thought can be considered "active". This [1] returns 57
> >> issues. I went ahead and looked at those issues today and have asked for
> >> more information in the JIRAs wherever relevant and have sent a couple
> of
> >> pull requests [2] [3] to fix some straightforward ones. I also have
> another
> >> PR that I opened this week to fix one other issue. Out of those 57
> issues,
> >> many are no longer relevant or don't have enough details. I don't have
> JIRA
> >> privileges to label them, share filters or even assign some to myself to
> >> track them better. So I think for now, we can rely on that JIRA search
> >> query [1].
> >>
> >> At this point, I think, if we can target March 2017 for releasing a
> >> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
> good
> >> start. Some of the issues noted in that JIRA are indeed important ones
> and
> >> would need some review/help in fixing them correctly, which essentially
> >> means, we need at least one person who has had experience with the Ivy
> code
> >> and its design details and also has the committer rights.
> >>
> >>
> >> Does any of this look feasible? Let me know if this isn't enough to move
> >> things forward - I don't want to end up sending PRs and spending time on
> >> this if there's no way we can get to a proper release in the next few
> >> months.
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project%
> >> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
> >> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
> >> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
> >> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
> >>
> >> [2] https://github.com/apache/ant-ivy/pull/11
> >>
> >> [3] https://github.com/apache/ant-ivy/pull/12
> >>
> >> -Jaikiran
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> >> For additional commands, e-mail: dev-h...@ant.apache.org
> >>
> >>
> >
> >
> > --
> > Matt Sicker 
> >
>



-- 
Matt Sicker 

Re: Ivy - Proposal for reviving the project and moving towards a release

[J Pai]

I'm fine calling it a 2.4.1. The only reason I mentioned it as a beta is to
iron out any issues involved in the process itself which, from what I read
in the other thread, might involve certain challenges for the first time.

-Jaikiran

On Sunday, December 11, 2016, Matt Sicker  wrote:
> Do we really need a beta release? If you're working on bugfixes first,
then
> a regular 2.4.1 release would be great. It would go through the normal
> Apache release candidate process, and perhaps we could get some Gradle
> developers to test it out as well since they still seem to be big users of
> Ivy.
>
> Any committer to the Ant project could prepare the release and be a
release
> manager. The only requirements involving PMCs is to vote on approving the
> release; adding your GPG key to the KEYS file (only PMCs can commit to
that
> repository involved); and committing the artifacts to the release svn
> repository (again, PMCs). I'm also not a committer, but if you're
> interested enough in maintaining Ivy, I'd guess that the PMCs may wish to
> bring you on board to do so.
>
>
> On 11 December 2016 at 08:22, Jaikiran Pai 
wrote:
>
>> First off, I'm not an Ivy or Ant committer. The proposal that I make
below
>> for an Ivy release is based on what was discussed in a recent mail thread
>> about the future of Ivy https://www.mail-archive.com/d
>> e...@ant.apache.org/msg45078.html. There was a suggestion that someone from
>> community volunteer to try and bring in some activity into the project
and
>> see if we can create a release after triaging the JIRA issues.
>>
>>
>> I have had a look at the open issues in JIRA today and decided to filter
>> out issues that are open, updated since Jan 2014 and affects versions
2.1,
>> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just
select
>> a few that I thought can be considered "active". This [1] returns 57
>> issues. I went ahead and looked at those issues today and have asked for
>> more information in the JIRAs wherever relevant and have sent a couple of
>> pull requests [2] [3] to fix some straightforward ones. I also have
another
>> PR that I opened this week to fix one other issue. Out of those 57
issues,
>> many are no longer relevant or don't have enough details. I don't have
JIRA
>> privileges to label them, share filters or even assign some to myself to
>> track them better. So I think for now, we can rely on that JIRA search
>> query [1].
>>
>> At this point, I think, if we can target March 2017 for releasing a
>> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a
good
>> start. Some of the issues noted in that JIRA are indeed important ones
and
>> would need some review/help in fixing them correctly, which essentially
>> means, we need at least one person who has had experience with the Ivy
code
>> and its design details and also has the committer rights.
>>
>>
>> Does any of this look feasible? Let me know if this isn't enough to move
>> things forward - I don't want to end up sending PRs and spending time on
>> this if there's no way we can get to a proper release in the next few
>> months.
>>
>>
>> [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project%
>> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
>> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
>> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
>> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>>
>> [2] https://github.com/apache/ant-ivy/pull/11
>>
>> [3] https://github.com/apache/ant-ivy/pull/12
>>
>> -Jaikiran
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>
>
> --
> Matt Sicker 
>

Re: Ivy - Proposal for reviving the project and moving towards a release

[Matt Sicker]

Do we really need a beta release? If you're working on bugfixes first, then
a regular 2.4.1 release would be great. It would go through the normal
Apache release candidate process, and perhaps we could get some Gradle
developers to test it out as well since they still seem to be big users of
Ivy.

Any committer to the Ant project could prepare the release and be a release
manager. The only requirements involving PMCs is to vote on approving the
release; adding your GPG key to the KEYS file (only PMCs can commit to that
repository involved); and committing the artifacts to the release svn
repository (again, PMCs). I'm also not a committer, but if you're
interested enough in maintaining Ivy, I'd guess that the PMCs may wish to
bring you on board to do so.


On 11 December 2016 at 08:22, Jaikiran Pai  wrote:

> First off, I'm not an Ivy or Ant committer. The proposal that I make below
> for an Ivy release is based on what was discussed in a recent mail thread
> about the future of Ivy https://www.mail-archive.com/d
> e...@ant.apache.org/msg45078.html. There was a suggestion that someone from
> community volunteer to try and bring in some activity into the project and
> see if we can create a release after triaging the JIRA issues.
>
>
> I have had a look at the open issues in JIRA today and decided to filter
> out issues that are open, updated since Jan 2014 and affects versions 2.1,
> 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to just select
> a few that I thought can be considered "active". This [1] returns 57
> issues. I went ahead and looked at those issues today and have asked for
> more information in the JIRAs wherever relevant and have sent a couple of
> pull requests [2] [3] to fix some straightforward ones. I also have another
> PR that I opened this week to fix one other issue. Out of those 57 issues,
> many are no longer relevant or don't have enough details. I don't have JIRA
> privileges to label them, share filters or even assign some to myself to
> track them better. So I think for now, we can rely on that JIRA search
> query [1].
>
> At this point, I think, if we can target March 2017 for releasing a
> 2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a good
> start. Some of the issues noted in that JIRA are indeed important ones and
> would need some review/help in fixing them correctly, which essentially
> means, we need at least one person who has had experience with the Ivy code
> and its design details and also has the committer rights.
>
>
> Does any of this look feasible? Let me know if this isn't enough to move
> things forward - I don't want to end up sending PRs and spending time on
> this if there's no way we can get to a proper release in the next few
> months.
>
>
> [1] https://issues.apache.org/jira/browse/IVY-1553?jql=project%
> 20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%
> 20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%
> 20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%
> 20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC
>
> [2] https://github.com/apache/ant-ivy/pull/11
>
> [3] https://github.com/apache/ant-ivy/pull/12
>
> -Jaikiran
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Matt Sicker 

Re: IvyDE status (Was: VOTE Retire IvyDE)

[Gintautas Grigelionis]

A short report on status (and more detailed answers to Nicholas questions):

   - the doc builds correctly once I clone ant-xooki repository on Github
   into doc/xooki;
   - the style clone on Github is empty; I did "wget -np -nd -r
   https://svn.apache.org/repos/asf/ant/site/ivyde/sources/style/
   "
   following developer doc, but I cannot find xmlverbatim.css and
   background.png in there (both files are referred to by style.css and
   print-style.css);
   - the Subversion-specific part of packaging is "svn export" which has an
   equivalent in Git: "git archive"; fairly straightforward to replace once
   the details of the distribution process with Git are clear;
   - setting up Eclipse PDE is more tricky nowadays because some components
   (notably WTP and GEF) are only released as update sites, which complicates
   a fully automated setup.

I have a question, too: perhaps the entire ivyde site repo could be
converted to Git?

Gintas

Ivy - Proposal for reviving the project and moving towards a release

[Jaikiran Pai]

First off, I'm not an Ivy or Ant committer. The proposal that I make 
below for an Ivy release is based on what was discussed in a recent mail 
thread about the future of Ivy 
https://www.mail-archive.com/dev@ant.apache.org/msg45078.html. There was 
a suggestion that someone from community volunteer to try and bring in 
some activity into the project and see if we can create a release after 
triaging the JIRA issues.



I have had a look at the open issues in JIRA today and decided to filter 
out issues that are open, updated since Jan 2014 and affects versions 
2.1, 2.2, 2.3 and 2.4. I decided to use this as a filter criteria to 
just select a few that I thought can be considered "active". This [1] 
returns 57 issues. I went ahead and looked at those issues today and 
have asked for more information in the JIRAs wherever relevant and have 
sent a couple of pull requests [2] [3] to fix some straightforward ones. 
I also have another PR that I opened this week to fix one other issue. 
Out of those 57 issues, many are no longer relevant or don't have enough 
details. I don't have JIRA privileges to label them, share filters or 
even assign some to myself to track them better. So I think for now, we 
can rely on that JIRA search query [1].


At this point, I think, if we can target March 2017 for releasing a 
2.4.1-Beta-1 with fixes from the list of JIRAs I think that would be a 
good start. Some of the issues noted in that JIRA are indeed important 
ones and would need some review/help in fixing them correctly, which 
essentially means, we need at least one person who has had experience 
with the Ivy code and its design details and also has the committer rights.



Does any of this look feasible? Let me know if this isn't enough to move 
things forward - I don't want to end up sending PRs and spending time on 
this if there's no way we can get to a proper release in the next few 
months.



[1] 
https://issues.apache.org/jira/browse/IVY-1553?jql=project%20%3D%20IVY%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20affectedVersion%20in%20(2.1.0%2C%202.2.0%2C%202.3.0%2C%202.4.0%2C%202.4.0-RC1)%20AND%20updated%20%3E%3D%202014-01-01%20ORDER%20BY%20updated%20DESC


[2] https://github.com/apache/ant-ivy/pull/11

[3] https://github.com/apache/ant-ivy/pull/12

-Jaikiran

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

[GitHub] ant-ivy pull request #12: IVY-1482 Fix potential NPE in XmlReportOutputter

[jaikiran]

GitHub user jaikiran opened a pull request:

https://github.com/apache/ant-ivy/pull/12

IVY-1482 Fix potential NPE in XmlReportOutputter

The commit here adds a null check to prevent potential NPE reported in JIRA 
https://issues.apache.org/jira/browse/IVY-1482


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

$ git pull https://github.com/jaikiran/ant-ivy ivy-1482

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

https://github.com/apache/ant-ivy/pull/12.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 #12


commit 0dc25d1d378861f2528b3de655afbced7c2f5a06
Author: Jaikiran Pai 
Date:   2016-12-11T08:48:37Z

IVY-1482 Fix potential NPE in XmlReportOutputter




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

[GitHub] ant-ivy pull request #11: IVY-1499 Prevent potential NPE during retrieve

[jaikiran]

GitHub user jaikiran opened a pull request:

https://github.com/apache/ant-ivy/pull/11

IVY-1499 Prevent potential NPE during retrieve

The commit here adds a null check to prevent a potential NPE that is 
reported in JIRA https://issues.apache.org/jira/browse/IVY-1499

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

$ git pull https://github.com/jaikiran/ant-ivy ivy-1499

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

https://github.com/apache/ant-ivy/pull/11.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 #11


commit c4dcddee47e560e8c768b5987fd96caffe85c673
Author: Jaikiran Pai 
Date:   2016-12-11T08:07:32Z

IVY-1499 Prevent potential NPE during retrieve




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