migration to git / intermediate summary
My summary of this intermediate time for the migration-to-git-thread (not dividing into binding/non-binding votes): Ant +1: antoine, jhm, bodewig, Per Arnold Blaasmo, boudart, conor, Michael Clarke, Charles Duffy (8) +0: ddevienne, Nicolas Lalevee, Matt (3) Ivy +1: antoine, Per Arnold Blaasmo, boudart, conor, Charles Duffy (5) +0: jhm, bodewig, ddevienne, Nicolas Lalevee, Michael Clarke, Matt (6) IvyDE +1: antoine, Per Arnold Blaasmo, boudart, conor (4) +0: jhm, bodewig, ddevienne, Nicolas Lalevee, Michael Clarke, Matt, Charles Duffy (7) EasyAnt +1: antoine, Per Arnold Blaasmo, boudart, conor (4) +0: jhm, bodewig, ddevienne, Nicolas Lalevee, Michael Clarke, Matt, Charles Duffy (7) Antlibs +1: antoine, jhm, bodewig, Per Arnold Blaasmo, boudart, conor (6) +0: ddevienne, Nicolas Lalevee, Michael Clarke, Matt, Charles Duffy (5) Sandbox Keeps in SVN for saving the work of migration and because there were only a few projects in the past which promoted to "real projects". Migration to git will be done when the project is promoted. Having on git repo for the whole sandbox will be difficult if one project will be promoted: "extract only a part of the project with its history". Homepage Keeps in SVN as svnpubsub is the only supported mechanism (besides CMS). gitpubsub is not supported. Help Michael Clarke would be "happy to help with any migration or post migration cleanup of docs/processes, but is only properly familiar with the Ant core so may not be much help with the likes of Ivy but can give it a shot if needed." Infra is providing their own migration tool. Jan
AW: How to submit a change for AntUnit?
The process is the same as for Ant itself: create a bugzilla issue and attach your patch. Jan > -Ursprüngliche Nachricht- > Von: chris.hol...@awltux.com [mailto:chris.hol...@awltux.com] > Gesendet: Montag, 28. April 2014 22:05 > An: dev@ant.apache.org > Betreff: How to submit a change for AntUnit? > > Hi, > > I realise the AntUnit project is pretty quiet, but I have a fix I'd > like to submit. > > The LogCapturer currently concatenates all messages onto the same line. > Not very readable when you send the log to file. > > I've added an EOL to each append in method: > LogCapturer.messageLogged(BuildEvent event) > > How do I go about submitting this fix? > > Regards, > Chris Holman > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional > commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: How to submit a change for AntUnit?
Hello Chris, I wonder whether the current behavior of the LogCapturer has a rationale and whether a backward compatibility needs to be preserved for this aspect. To submit a patch, the best is to create a bugzilla issue on http://issues.apache.org/bugzilla and to attach the output of svn diff -u . Regards, Antoine On Apr 28, 2014, at 4:05 PM, chris.hol...@awltux.com wrote: > Hi, > > I realise the AntUnit project is pretty quiet, but I have a fix I'd like to > submit. > > The LogCapturer currently concatenates all messages onto the same line. Not > very readable when you send the log to file. > > I've added an EOL to each append in method: > LogCapturer.messageLogged(BuildEvent event) > > How do I go about submitting this fix? > > Regards, > Chris Holman > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
In fact I have to correct this. I just contacted infra via freenode and I was told that they have their own migration tools and that they do not need subgit. There will certainly be other pre or post migration tasks :-) Antoine On Apr 28, 2014, at 10:46 PM, Antoine Levy Lambert wrote: > Hello Charles, > > On Apr 28, 2014, at 11:07 AM, Charles Duffy wrote: > >> +1 for Ant and Ivy, +0 elsewhere. >> >> If we wanted to do a history-preserving transform (with branches, merges >> &c. faithfully preserved), I'd be happy to help with the configuration and >> use of SubGit (which, while typically a commercially-licensed tool, has >> zero-cost licenses available for OSS projects) for this purpose; in my >> experience, it results in a considerably higher-quality transform than the >> competing git-svn tooling. (SubGit also offers bidirectional translation >> support, but I'm wary of the deployment requirements of same, and have >> concerns as to whether making proprietary tooling a dependency of Apache's >> ongoing infrastructure would be acceptable or wise). > nice to offer that sure, we will certainly be interested. > > Antoine >> > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
migration to git and web site publication
Hello Jan, On Apr 28, 2014, at 1:29 AM, Jan Matèrne (jhm) wrote: > > > >> The web sites will remain in svn in any event because svnpubsub is the >> only supported mechanism to maintain web sites AFAIK. > > I havent looked at the current svnpubsub, but there is also one with that > name for git > https://www.apache.org/dev/gitpubsub.html > > I would appreciate to have the same scm. > Could we start a new git repo for tests and vote later after the > git/gitpubsub is working? Apache Infra does not support gitpubsub for the purpose of maintaining an Apache web site. I asked confirmation of that on the #asfinfra All Apache web sites are in svn and use svnpubsub. git is not the tool of choice to deal with large files such as the ones on dist.apache.org. That might be part of the reason why infra supports only svn for the web site. > > > Jan > > Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
Hello Charles, On Apr 28, 2014, at 11:07 AM, Charles Duffy wrote: > +1 for Ant and Ivy, +0 elsewhere. > > If we wanted to do a history-preserving transform (with branches, merges > &c. faithfully preserved), I'd be happy to help with the configuration and > use of SubGit (which, while typically a commercially-licensed tool, has > zero-cost licenses available for OSS projects) for this purpose; in my > experience, it results in a considerably higher-quality transform than the > competing git-svn tooling. (SubGit also offers bidirectional translation > support, but I'm wary of the deployment requirements of same, and have > concerns as to whether making proprietary tooling a dependency of Apache's > ongoing infrastructure would be acceptable or wise). nice to offer that sure, we will certainly be interested. Antoine > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
How to submit a change for AntUnit?
Hi, I realise the AntUnit project is pretty quiet, but I have a fix I'd like to submit. The LogCapturer currently concatenates all messages onto the same line. Not very readable when you send the log to file. I've added an EOL to each append in method: LogCapturer.messageLogged(BuildEvent event) How do I go about submitting this fix? Regards, Chris Holman - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
migration to git and sandbox
On 2014-04-28, Nicolas Lalevée wrote: > Le 28 avr. 2014 à 07:29, Jan Matèrne (jhm) a écrit : >> Why not having one sandbox repo? New projects could be added there as >> one directory, if creating a gitmodule would enforce infra to act. > What would be the process of a sandbox project becoming "mainstream" > with a one for all ? In the "upgrade", we would want a standalone repo > for it. Cloning the sandbox would mean having the full history of > every other sandbox project in there. Would that work well ? I'd rather keep the sandboxes in svn and only migrate to git once they are promoted. We haven't promoted any sandbox in years, so we are likely saving work by not migrating the repo at all :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
+1 for Ant and Ivy, +0 elsewhere. If we wanted to do a history-preserving transform (with branches, merges &c. faithfully preserved), I'd be happy to help with the configuration and use of SubGit (which, while typically a commercially-licensed tool, has zero-cost licenses available for OSS projects) for this purpose; in my experience, it results in a considerably higher-quality transform than the competing git-svn tooling. (SubGit also offers bidirectional translation support, but I'm wary of the deployment requirements of same, and have concerns as to whether making proprietary tooling a dependency of Apache's ongoing infrastructure would be acceptable or wise). On Sun, Apr 27, 2014 at 10:02 PM, Antoine Levy Lambert wrote: > Hi, > > Let's vote about migrating to git : > > - Ant > > - Ivy > > - easyant > > - Ivyde > > - the antlibs > > I am not including the sandbox in the thread intentionally. > > The web sites will remain in svn in any event because svnpubsub is the > only supported mechanism to maintain web sites AFAIK. > > [] Yes > [] No > > > Let me start with my +1 > > Antoine > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
Re: Ivy slow resolution
On Mon, Apr 28, 2014 at 10:13 AM, Nicolas Lalevée < nicolas.lale...@hibnet.org> wrote: > > Le 28 avr. 2014 à 13:59, Josh Suereth a écrit : > > > On a whim, I implemented parallel download of artifacts by hooking the > > downloadArtifacts > > method of Resolve engine. While this can potentially speed up download > > performance, the resolution times (getDepedencies) still dominates (of > > course). Parallel downloads is an often requested feature of sbt, so we > > may still release this hook for our users, as they request it, but I > think > > the *really* just want faster resolution times. > > > > We may be doing some investigation into improving the performance of > > getDependencies (and most importantly fetchDependencies). I was curious > if > > anyone else in the Ivy community has attempted this before and what sorts > > of guidance they could offer before we dig in. > > This has been discussed, but AFAIR nothing has been done other than > discussing the potential issues to tackle. > > Things which would require some attention would be to find a way to > properly report the progress of the parallel download: in the console when > it's done via Ant or via the listeners for IvyDE. > A thing that is worrying me, is that Ivy is quite sensitive to which > thread is actually working on the resolve, see IvyContext's thread local. > So a parallelization may not be a very upper level than the artifact > downloading. > > Totally understand. I haven't had time to check if my resolution on different threads has mucked up the ivy context, but I know I can propagate context as needed, as long as downloading artifacts is idempotent (i.e. no changes to artifacts). The first implementation just defers reporting all progress until AFTER the entire download, then notifies, which probably breaks IvyDE, except I'm only overriding this in sbt itself, so there is no IvyDE there :). So, if this was something to contribute back to ivy (which I'm not sure it is, given the lack of real speed-up we're seeing), I'd have to figure out how to maintain the progress reporting notifications with the IvyContext, possibly adapting my worker pool such that we register a thread-safe IvyContext locally for the reporting events to get fired out of? Does the event model, as it exist, prevent parallelism? In terms of resolution improvements, mostly I was hoping that some memoization/cache of immutable graph pieces could help avoid re-resolving the same bits of the graph repeatedly. Again, I haven't dug fully into the details of IvyNode, ResolveData + VisitNode, but it seems likely to me that we should be able to avoid calling "resolve" for an artifact (the same ModuleRevisionId) more than once during full graph resolution, which (and I may be wrong) appears to be the case when we profile Ivy. I'm mostly concerned with this aspect, and was wondering if anyone else has seen this or if we're doing something very wrong in sbt.
Re: Ivy slow resolution
Le 28 avr. 2014 à 13:59, Josh Suereth a écrit : > On a whim, I implemented parallel download of artifacts by hooking the > downloadArtifacts > method of Resolve engine. While this can potentially speed up download > performance, the resolution times (getDepedencies) still dominates (of > course). Parallel downloads is an often requested feature of sbt, so we > may still release this hook for our users, as they request it, but I think > the *really* just want faster resolution times. > > We may be doing some investigation into improving the performance of > getDependencies (and most importantly fetchDependencies). I was curious if > anyone else in the Ivy community has attempted this before and what sorts > of guidance they could offer before we dig in. This has been discussed, but AFAIR nothing has been done other than discussing the potential issues to tackle. Things which would require some attention would be to find a way to properly report the progress of the parallel download: in the console when it's done via Ant or via the listeners for IvyDE. A thing that is worrying me, is that Ivy is quite sensitive to which thread is actually working on the resolve, see IvyContext's thread local. So a parallelization may not be a very upper level than the artifact downloading. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
Le 28 avr. 2014 à 07:29, Jan Matèrne (jhm) a écrit : >> Let's vote about migrating to git : >> - Ant > > +1 > >> - Ivy > > +0, because I dont work on that codebase and therefore dont want to > influence these committers. > >> - easyant > > +0, same as for Ivy > > >> - Ivyde > > +0, dito > > >> - the antlibs > > +1 > > > >> I am not including the sandbox in the thread intentionally. > > Why not having one sandbox repo? New projects could be added there as one > directory, if creating a gitmodule would enforce infra to act. What would be the process of a sandbox project becoming "mainstream" with a one for all ? In the "upgrade", we would want a standalone repo for it. Cloning the sandbox would mean having the full history of every other sandbox project in there. Would that work well ? Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
On Apr 27, 2014 10:03 PM, "Antoine Levy Lambert" wrote: > > Hi, > > Let's vote about migrating to git : > > - Ant > > - Ivy > > - easyant > > - Ivyde > > - the antlibs > > I am not including the sandbox in the thread intentionally. > > The web sites will remain in svn in any event because svnpubsub is the only supported mechanism to maintain web sites AFAIK. > > [] Yes > [] No > +0 for all Matt > > Let me start with my +1 > > Antoine > > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org >
Re: [VOTE] migration to git
+1 from me for Ant, +0 for the other associated projects. I'm happy to help with any migration or post migration cleanup of docs/processes, but am only properly familiar with the Ant core so may not be much help with the likes of Ivy but can give it a shot if needed. > On 28 Apr 2014, at 13:32, "Nicolas Lalevée" > wrote: > > >> Le 28 avr. 2014 à 05:02, Antoine Levy Lambert a écrit : >> >> Hi, >> >> Let's vote about migrating to git : >> >> - Ant >> >> - Ivy >> >> - easyant >> >> - Ivyde >> >> - the antlibs >> >> I am not including the sandbox in the thread intentionally. >> >> The web sites will remain in svn in any event because svnpubsub is the only >> supported mechanism to maintain web sites AFAIK. >> >> [] Yes >> [] No > > +0 for all. > > It's not a +1 because even if I like git more than svn, I am not sure of the > amount of work required afterwards (documentation update, CI, release > scripts, etc…), so I don't want my vote to be counted as important as the > vote of someone who doesn't want to make the transition. > > But it's a positive 0 as I would gladly follow any decision taken by the PMC, > especially on IvyDE. > > Nicolas > > > - > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] migration to git
Le 28 avr. 2014 à 05:02, Antoine Levy Lambert a écrit : > Hi, > > Let's vote about migrating to git : > > - Ant > > - Ivy > > - easyant > > - Ivyde > > - the antlibs > > I am not including the sandbox in the thread intentionally. > > The web sites will remain in svn in any event because svnpubsub is the only > supported mechanism to maintain web sites AFAIK. > > [] Yes > [] No +0 for all. It's not a +1 because even if I like git more than svn, I am not sure of the amount of work required afterwards (documentation update, CI, release scripts, etc…), so I don't want my vote to be counted as important as the vote of someone who doesn't want to make the transition. But it's a positive 0 as I would gladly follow any decision taken by the PMC, especially on IvyDE. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Ivy slow resolution
On a whim, I implemented parallel download of artifacts by hooking the downloadArtifacts method of Resolve engine. While this can potentially speed up download performance, the resolution times (getDepedencies) still dominates (of course). Parallel downloads is an often requested feature of sbt, so we may still release this hook for our users, as they request it, but I think the *really* just want faster resolution times. We may be doing some investigation into improving the performance of getDependencies (and most importantly fetchDependencies). I was curious if anyone else in the Ivy community has attempted this before and what sorts of guidance they could offer before we dig in. Thanks! - Josh
Re: [VOTE] migration to git
On Mon, Apr 28, 2014 at 8:54 AM, Conor MacNeill wrote: > On 28 April 2014 13:02, Antoine Levy Lambert wrote: >> Let's vote about migrating to git : +0 on all. --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
