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

[Oulds, Jonathan]

I'd like to add my vote for a 2.4.1 release.  We don't want to raise the 
expectation that there will be substantial new functionality (which would 
warrant a 2.5.0 version).

However, if the 2.4.1 release goes well I would certainly suggest that we aim 
for a 2.5.0 release in the second half of 2017.

Longer term I would suggest that we try to maintain a regular release schedule 
ideally two per year as below:
Q1 - Bug fix:
Q3 - Bug fix plus at least one new feature:



Jonathan Oulds
Snr. Software Engineer
McAfee


-Original Message-
From: J Pai [mailto:jai.forums2...@gmail.com] 
Sent: Wednesday, December 14, 2016 4:11 AM
To: Ant Developers List ; Maarten Coene 

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

Maarten, thanks for volunteering to review the PRs. One of them has a test 
case. I will add a test for the other one.

It looks like you have been involved with Ivy development and releases before, 
so I think you would be in a better position to decide if it should be 2.5.0 or 
2.4.1. I personally prefer 2.4.1 because we are focussing on fixing some 
reported issues rather than introducing some new features.

As for the release timeline, the reason I asked for a March 2017 date is to 
make sure we have a realistic goal in mind of releasing it instead of a open 
ended one which drags can potentially drag on for a while given the current 
state of the project. Having said that, you and others in ant-dev team who have 
been involved in previous releases can decide what makes sense in terms of 
release commitments. My whole goal is to try and get a usable bug fix release 
out soon, since the last one was 2 years back.

-Jaikiran

On Monday, December 12, 2016, Maarten Coene 
wrote:
> Thanks Jaikran,
> I will look at your patches, I'll try to do it this week.If possible,
please attach a junit test as well to reproduce the problem.
>
> About the release, the master branch already contains some fixes since
the 2.4.0 release. They are listed in the release-notes.html in the 'doc'
directory. If we want to create a 2.4.1 release, we should merge all these 
changes (and all upcomming patches) into the 2.4.x branch as well. If we decide 
to create a 2.5.0 release, this merging isn't necessary. I wouldn't pin on an 
exact timing, we can create a release any time when we think the codebase is 
ready for it.
>
> We also have to find a release manager. I did it in the past when we 
> were
on SVN, but I don't have enough GIT knowledge (and I don't have the time to 
look into it) to do a new release.
>
> Maarten
>
>   Van: Jaikiran Pai 
>  Aan: dev@ant.apache.org
>  Verzonden: zondag 11 december 15:22 2016
>  Onderwerp: Ivy - Proposal for reviving the project and moving towards 
> a
release
>
> 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]
>

RE: Ivy - any future or is it also going to be retired?

[Oulds, Jonathan]

Nicolas raises some great ideas,

I would suggest that we get those into Jira and try to cut a release from the 
current code (just to test the release process).  If that works let's try to 
address one or two simple to fix issues (just to give the release some value) 
and push out 2.4.1.

If there is enough interest we can start implementing some bigger features and 
plan for a 2.5 release next year.



Jonathan Oulds
Snr. Software Engineer
McAfee

-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: Wednesday, December 7, 2016 10:56 AM
To: dev@ant.apache.org
Subject: Re: Ivy - any future or is it also going to be retired?

On 2016-12-06, Nicolas Lalevée wrote:

> These are just ideas poping up my mind to show that if people are 
> enough motivated, they can make things happen. And obviously, if 
> things work well, credentials will be granted.

Yes, of course.

> I think this is the same for IvyDE, but it requires much more effort 
> because the build is broken since we migrated to git, and so the 
> release process has to be reviewed. Too much effort for me.

If our transition to git is causing problems we didn't foresee, we can 
certainly (partially) revert it. Nobody says we need to use the same scm for 
all subprojects of Ant.

Stefan

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

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

RE: Ivy - any future or is it also going to be retired?

[Oulds, Jonathan]

We use Ant + Ivy extensively in our build system.  I too have noticed the lack 
of development within the Ivy project which is why I recently re-joined the 
community.

I would be happy to contribute patches and or ideas for future development if 
the project is to continue.

Please bear in mind when considering the future status of Ivy that the ideas 
that have been developed within this project have been adopted by others such 
as Gradle and Artifactory, as such it would be a shame to see the end of such 
an influential project.



Jonathan Oulds
Snr. Software Engineer
McAfee


-Original Message-
From: Jan Matèrne (jhm) [mailto:apa...@materne.de] 
Sent: Monday, December 5, 2016 12:47 PM
To: 'Ant Developers List' 
Subject: AW: Ivy - any future or is it also going to be retired?

> If you want to push Ivy, you need integrations with IDE. 

Yes, I agree. But the problem getting developers to improve IvyDE.


> IMHO, IvyDE works well with Eclipse;

IvyDE will be available as it is. We don't delete releases as they are archived 
in the Apache archive. 


> perhaps its [IvyDE] release cycle needs to be synced with Ivy release cycle 
> (which is roughly biannual a this point).

Nice idea - but without enough developers impossible. 


> Is there a release plan for Ivy, by the way? 

No.


> When will this  fix be 
> released?

Marten has commented "it will be fixed in the next release."
So first step is getting the change into the code base. 2nd step is getting a 
release out.

I don't know the actual status of #1.
Currently there is no release planed. 


> I don't know what a -1 (which is what I would have voted) would do in 
> reality. 

A '-1' is basically a vote 'against' the suggestion [1]. It must be explained 
so that we could react on the arguments privded. Basically a -1 could be 
overriden by enough +1s.

If the decision requires consensus, then its called 'veto' and could not be 
overridden.
But only the removal of a committer or PMC member requires consesus [2].

[1] http://ant.apache.org/bylaws.html#Voting
[2] http://ant.apache.org/bylaws.html#Actions


> So on one hand I want that project to stay (and hope to be actively 
> developed) and on the other I don't think that's going to be happen even if 
> it isn't retired.

Same with us. We don't want to retire subprojects. But have to face the facts 
and get the consequences.


> Second, I'm guessing the ivy (and ant) project would very much welcome extra 
> hands. 
> So if this project is important to you, and you want a release to happen ...
> why don't you join the effort and help drive it.

Thanks, you're right. ;) 


> If right now the problem is "there is noone able to create / manage new 
> releases" 
> (but some people are still around to watch over the code and fix 
> bugs), maybe someone can step up specifically for the job of release manager 
> ...

That's the plan, or the intention ;)


> Like I said in my mails, I've tried [contributing]. 
> Anyway, here's some previous mails where I tried [1] [2] [3].
> [1] http://marc.info/?l=ant-dev=143702067424412=2
> [2] http://marc.info/?l=ant-dev=143765756710466=2
> [3] http://marc.info/?l=ant-dev=144026083515049=2

Maybe we were sleeping some time. But we are waking up. 
#1 was started on 2015-07-16 and a patch was merged on 2015-08-30.
#2 was started on 2015-07-23 and last response by Nicolas was that it breaks on 
Windows.
#3 was started on 2015-08-22 and last answer on 2015-08-30. 


> Me? I can provide patches and fixes and enhancements for whatever 
> little knowledge I gain by looking at existing code, but my experience 
> with Ivy is just limited to the past few years when I started using it as a 
> user.

Experience comes naturally by working with and for Ivy. So creating and 
providing patches further.  
With Ant I started with answering user questions on the user-list. Then 
providing some patches.


> there's really nothing to look forward to in terms of roadmap or releases or 
> development.

I think the problem is that we lost most of the core developers of Ivy in a 
short timeframe.
So every development/planning stoped. (Just my personal point of view.) Now we 
are trying to reactivate 'old', aquire 'new' committers and getting 'existing' 
(Ant)commmiters be more familiar with the Ivy codebase, so that we could do 
more here.
(Also my personal point of view.)



Jan 
  




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

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of 

Conflict

[Oulds, Jonathan]

Hello there,

Is it possible to define a conflict manager only for a specific configuration?

When building a module we resolve the "build" configuration of our module, this 
works fine.  However, once the module has been built we sometimes perform some 
post build steps that perform an inline resolve on the module that is now in 
our repository.  However during this post build process we want to resolve a 
different configuration, because of the way that this configuration is defined 
it is possible that we will fall foul of our conflict manager setting which we 
set to default.

As such we would like "strict" to only apply when resolving "build" 
configurations whilst "all" should apply to the configuration we use during 
post-build testing.



Jonathan Oulds
Snr. Software Engineer

Solution PSC Lead (PerDP)
Next Gen Data Protection

[::6. McAfee_Letterhead:McAfee_logo.jpg]

Email: jonathan.ou...@intel.com
Web: www.intelsecurity.com

The information contained in this email message may be privileged, confidential 
and protected from disclosure. If you are not the intended recipient, any 
review, dissemination, distribution or copying is strictly prohibited. If you 
have received this email message in error, please notify the sender by reply 
email and delete the message and any attachments.

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.