Here's the weekly chat log from Monday 27th November.
The M2 release was the only topic discussed, the main points were: - There's a problem with the current AXIOM release which causes Tuscany to have a SNAPSHOT dependency. Should we release M2 anyway, or wait for a new AXIOM release, or pull the Tuscany Axis2 binding from M2? - Then there was some discussion around what Tuscany jars are released as part of M2 into the maven repository. Currently everything in the Tuscany build is released, should that be trimmed to only those things that we want to say are ready? Simon is going to create a patch to the build to make this possible. ...ant Session Start: Mon Nov 27 16:26:47 2006 Session Ident: #tuscany * Now talking in #tuscany * jboynes has joined #tuscany * rfeng has joined #tuscany * Amita has joined #tuscany * halehM has joined #tuscany * cr22rc_away is now known as cr22rc <rfeng> hi, all. <kgoodson> hi <meerajk> hi <ant_> hi <cr22rc> hi <halehM> hi <rfeng> there are a few issues around M2, should we talk about it? <cr22rc> sounds appropriate <rfeng> 1) build break: axis2 1.1 references org.apache.woden:woden-1.00M6but it is now withdrawn from the central maven repo <ant_> i've fixed that i think <rfeng> ok <rfeng> I think you fixed some license issues as well <ant_> yes <rfeng> what's the process here? fix the code in the M2 banches and re-tag them? <ant_> there's still a few other issues i think, just going through the thread... <rfeng> 2) license issues (I assume it's fixed by ant) <ant_> Does any one else see the references to axiom-api:SNAPSHOT when running the ws samples? <halehM> Can we talk through each issue and see if needs to be addressed or can be postponed to M3? <rfeng> ant_, I created a JIRA against Axiom 1.2 <rfeng> WSCOMMONS-131 <halehM> is this an axis problem or ours? <rfeng> axiom <rfeng> 3) should we have source distro for the SCA spec, commonj spec, etc? <ant_> which axiom release do the samples endup using, a SNAPSHOT one? <rfeng> the problem is in the parent/pom.xml for axiom 1.2 release <rfeng> the dependencyManagement still points to SNAPSHOT versions <halehM> Is it ok for us to release with that or not? <rfeng> I think it will give us troubles <halehM> why? from correctness perspective? <rfeng> as axiom SNAPSHOT moves up every day and it could potentially breaks the build <halehM> or from bundling? There was some discussion on the general mailing list about using snapshots <rfeng> by that pom, axiom-impl 1.2 will have dependency on axiom-api SNAPSHOT <cr22rc> our m2 could be rendered useless if some incompatibility is put in the axiom snapshot is added. <rfeng> yes <halehM> Do we know when they can fix this? <rfeng> no repsonse for the JIRA so far <rfeng> but it seems that they are planning axis2 1.1.x for some other issues <halehM> We don't want to have another dependency on axis at this time. Jeremy, what do you recommend as the RM? <rfeng> Jim suggested that we release axis2 binding separately for the long term <cr22rc> can we release with this and be committed to fixing it if it breaks ? M2.1 ? <cr22rc> not something I look forward to but it is alternative, I think. <ant_> cr22rc, +1. Maybe they'll fix it for 1.1.1 and we pick that up, but otherwise lets just get M2 out <halehM> Can we take a snapshot and of what works and stick to it for M2? <rfeng> it will work for the binary distro, but not for maven artifacts <cr22rc> rfeng: is that response to me or halehM ? <halehM> it looks like cr22rc's choice is the only one at this point <jboynes> halehM: no, we can wait <rfeng> BTW axis2 1.1.1 will fix a few other maven issues as well <ant_> jboynes, +1. and we've still whatever other remaining issues to fix so maybe by the time we do them this will be fixed. should we just revist this once eveything else is done? <jboynes> what else needs to be done? <cr22rc> has axis given a time frame for 1.1.1 ? * simonnash has joined #Tuscany <ant_> last week they said early this week <jboynes> I'd hope it would be quick - this is a pretty major problem <ant_> i need to go see if there's been any follow up mails <cr22rc> ok if it's that soon. <halehM> we are taking a risk with Axis. The last release took a while. <rfeng> how can we make sure that WSCOMMONS-131 will be fixed, no response on my post and JIRA <rfeng> ? <jboynes> halehM: what risk? what we have now is permanently broken <jboynes> rfeng: send them a patch? <jboynes> there is no downside here <rfeng> but it's against a released pom <cr22rc> that's pretty simple just a change in pom ... right? <halehM> can Dims help push this through? <ant_> the emails about axis2 1.1.1 also mentioned an axiom release <rfeng> cr22rc, yes but it can only apply to axiom 1.2.1 <cr22rc> there is also a small risk that we break ... don't know how much 1.1.1 changes and we'll need to retest all samples with axis. <jboynes> there is certainty we will break if we stick with 1.1 <jboynes> unless they NEVER do another snapshot <jboynes> but even that is risky <simonnash> sorry that I was late joining (on vacation today).. why are we broken if we stay with 1.1? <jboynes> I don't see any choice here <cr22rc> are 1.1.1 snapshots available ? <ant_> isn't it more, its very likely the Tuscany Axis2 binding will break eventually. But does that matter if the rest of Tuscany keeps working and we've a likely a tuscany M3 coming up <jboynes> strictly yes but we're not separating the axis2 binding from the M2 release <jboynes> so people will consider our whole release bad <ant_> simonnash, there's a problem with the axiom builds so they casue a SNAPSHOT dependency on axiom <jboynes> I think we could do what ant_ suggests if we were releasing modularly <cr22rc> we'll have to wait on released snapshot of 1.1.1 ? a vote on axis 1.1.1? final 1.1.1 in a repo. hmmm ... don't see that happening all this week. <rfeng> right, it takes a while to get the artifacts into maven repo <jboynes> cr22rc: yes, I reckon it will be at least a week <halehM> jboynes, can we make axis binding release separate? <jboynes> halehM: technicall yes, but that's not what we wanted to do <ant_> how about releasing M2 like this and then release a new tuscany axis2 binding whenthis problem is fixed? <halehM> ant, that seems reasonable. <simonnash> yes I think that makes sense, if we are not broken today but only when Axiom does another snapshot <cr22rc> will there really be that much interest wo axis binding? or are we causing more work for ourselfs than just waiting? <simonnash> is that correct? that we work today but will break in the near future? <jboynes> yes <jboynes> near being next time there's a change in the axiom api <jboynes> potentially tonight <jboynes> problably not, but ... <simonnash> canwe get Axiom to hold off from breaking us until they have delivered 1.1.1 and we have re-released on that? <ant_> only a non backward compatable API change <cr22rc> I see an easier path is just release. have axis then update again as as whole <jboynes> yep but history shows we get quite a few of those :( <jboynes> why the rush to put out a broken release? <jboynes> I like the idea of releasing the axis binding separately <simonnash> i'm trying to explore the extent of brokenness <cr22rc> it's not a certainty it broken, right? <jboynes> scale down the distro to just the M2 core and release the bindings as needed <jboynes> we can keep axis2 as a snapshot until we get a stable version of axiom <simonnash> if we can stay working long enough to re-release an update to Axis2 binding then I think that is better than removing the Axis2 binding <meerajk> i think as jmarino suggested on the ml, long term we need to have a modular release plan because of the way we do extensions <simonnash> an M2 core on its own will not be of very much interest to users. <jboynes> sure, but it's a core that works with plugins <simonnash> long term yes, but we have not prepared the m2 release to be that way <jboynes> and the combination is <jboynes> simonnash: technically we have, the only thing coupling it together is because we wanted to release it that way <simonnash> yes, and we prepared samples and docs with that assumption. this is what I mean. <cr22rc> so do we remove from the samples all the axis2 ones? <cr22rc> not release the samples ? <jboynes> the samples are source for people to use <jboynes> they can pick and choose what they build from them <simonnash> i am not sure why we need to do this. if the current binding works at the present time. <cr22rc> but there won't be an axis binding? or am I missing something? <simonnash> it does nt make sense to release a release containing samples taht cannot run on the delivered release <jboynes> the release does not contain the samples, they are separate <jboynes> and can be revved separately <simonnash> they were proposed as part of the M2 release for voting <jboynes> the source was, no binary <simonnash> the question at the moment is what do we want to say constitutes our M2 release <jboynes> yes <simonnash> yes, the source was. and all the samples in that source would have run on the released M2 artifacts, <jboynes> sigh <cr22rc> so for this go around remove the samples that are axis based from the sample src distro? <simonnash> i understand that we can change all this... but I am not convinced yet that we cannot work around the problem <halehM> If I understand this correctly, this is a build issue. Can we include everything in binary so that users have a running version and fix the build issues as they come up? Just a suggestion. Maybe a bad one <jboynes> simonnash: we can - we wait until axis2 1.1.1 comes out <jboynes> halehM: it's a runtime issue <simonnash> as I said earlier I believe we can still run today until something happens in Axiom-land to break us <simonnash> so my suggestion id to release in that state and rev the Axis binding asap <jboynes> do you not think building a timebomb into a release is a bad idea? <simonnash> the question is how likely it is to explode before we can defuse it <jboynes> simonnash: the "release" will not pick up the new axis version <simonnash> i am trying to understand whether we can do that <jboynes> so it will be there forever <simonnash> yes but hopefully by the time the bomb goes off we will have a new rev of the Axis2 binding that is effetively a mandatory patch to the M2 release <simonnash> we can document this clearly on our web site <rfeng> what's the open source way to provide fixes to a release? a new point release? <jboynes> rfeng: yes that's what we're waiting for axis to do <halehM> do point releases have to go through the voting process? <jboynes> yes <jboynes> the question is about whether we are willing to put out a broken release <jboynes> remember, 3 +1's is all it takes <halehM> We have talked about a couple of options now. Maybe we should recap all the options and choose <simonnash> a release containing one component taht will become broken in the future, by which time a fix should be available.. no-one has told me this is not correct <jboynes> we have two: wait until axis2 has a good release, or release what we can that doesn't depend on axis <simonnash> or do what I suggested <rfeng> so 3 options <simonnash> ie release what we have, document the issue with Axis2, and rev the Axis2 binding asap <halehM> should this voting be done on the mailing list? <jboynes> needs to be <halehM> will you do it jboynes? <meerajk> somonnah: aren't the opions 10 relese what we have 20 release without axis, 3) wait till axis is fixed? <meerajk> sorry, bad typing :) <simonnash> yes but under 1 I am adding that we document the issue and provide a fix asap <halehM> Ant, does axis 1.1.1 have a release candidate? <ant_> not yet. but they may not, or it may not be very long btw any RC and the final release. <halehM> Can we build our release against the RC and asked them to leave it there for a while? Their RC would be the same as their release but has not gone through all the voting process, etc. Just an option <simonnash> halehM, this sounds like meeraj's option 3 to wait... bu twith some parallel processing to minimize the wait <halehM> except that we are releasing with the RC for 1.1.1 - we are not waiting. <jboynes> halehM: we shouldn't have dependencies on unofficial artifacts <jboynes> and if they take down the RC then our release is broken <halehM> OK, then we have the 3 options that Meeraj listed. <jboynes> there's a fourth - fork axis and depend on that <halehM> Hmm. good idea in my mind. It gives us a stable version for M2, removes the need of spending more time on M2(fix things) <jboynes> not a good option IMO, but an option none the less <simonnash> that one sounds bad (the F word) <meerajk> i like option 2, which can set a precedent for modularized releases in the future <halehM> It seems like we seriously need to consider more modularization moving forward. <simonnash> i think the probloem with option 2 is that we will be doing it is haste rather than with due consideration <simonnash> ..in haste.. <jboynes> rotfl <simonnash> sorry I am not familiar with that acronym <meerajk> rolling on the floor laughing :) <cr22rc> http://www.learnthenet.com/English/glossary/rotfl.htm <simonnash> thanks * Amita has quit IRC <simonnash> we do have a modular arachitecture but we have not yet created a modular release structure <jboynes> simonnash: and giyf http://www.google.com/search?q=rotfl <simonnash> agreed that it will be needed. but it will take a bit of time to reorganize things this way and agree on the details. <jboynes> sure - but it sounds like we agree we need to do it anyway <jboynes> so that is no time lost <jboynes> s/time/effort/ <simonnash> in the longer term yes. it just delays delivering the funcitonality we currently have working. <jboynes> and if axis2 1.1.1 comes out in the meantime we can release what we have updated to use that <jboynes> we're only talking a few days <simonnash> exactly. you are right about effort. but we lose a bit of elapsed time for the current delivery <jboynes> what "delivery" <simonnash> M2 <jboynes> we're talking about getting a release out <simonnash> yes <jboynes> preferably one that's not broken <jboynes> it does this project no good to put out a broken release <jboynes> especially when we know that before we actually release it <jboynes> all for the sake of either waiting a few days for axis2 to fix itself, or for the effort to fix the dependency on a broken artifcat <ant_> it doesn't do the project much good to be taking solong to get an M2 out either <jboynes> nope <ant_> but I am hopeful axis2 1.1.1 will be quite soon <cr22rc> I thought the alternatives were going to the ML, for a vote. <jboynes> and the big delay has bee in waiting for all the dependencies to come together <jboynes> it is the dependency matrix that is causing the probles * kgoodson is now known as kgoodson_away <jboynes> and I think we agree the answer is to modularize it <jboynes> it's just now the question is when do we do that <simonnash> agreed, that is the question we need to decide on the ML. <cr22rc> that's a lofty goal ... and the Achilles heel is that the SPI/API stays sound. Otherwise modularizing I don't think buys too much <jboynes> cr22rc: yes <simonnash> i understand the arguments for not shipping something we know to be broken <halehM> My only hesitation is that Axis did not leave a good track record with the previous drop being on time. I think we are just getting into another long trip <simonnash> also on the subject of modular releases. this works if we can keep compatibilty as new modules (core or plugin) are released <jboynes> halehM: there's a difference in scale <jboynes> 1.1 was a major functional change <jboynes> 1.1.1 should just be a quick patch release <halehM> we hope <jboynes> well, 3 +1's remember <cr22rc> I have the same concerns as halehM ... why I suggested just go with what we have now. but admit teetering <jboynes> WE can do the patches, to the proofing and ask the WS-PMC to vote on it <ant_> fwiw, i'd prefer to do any modularization after M2 if possible. either waiting for 1.1.1 or releasing what we have now seem better <jboynes> s/to/do/ <simonnash> i am with ant on this <cr22rc> me2 * YangZHONG has joined #tuscany <halehM> Meanwhile, do we have all the questions that were raised on the mailing list for our own M2 addressed? Should we discuss those here? <jboynes> so do we agree the next release should be modular? <simonnash> i have not seen an answer to the points I raised <rfeng> +1 <cr22rc> let's get his release out and bring this up on the ML as a seperate point <simonnash> yes, i agree taht after M2 we should work out a modular release process that works well for Tuscany developers and Tuscany users <meerajk> +1 (jboynes) <jboynes> I've lost correlation on the +1's <ant_> jboynes, i agree we should be able to release things seperately, but it still seems like having some sort of bundle distro release of compatable things could be useful <meerajk> ant_: between the two, i prefer waiting for 1.1.1 <meerajk> to releasing what we have <cr22rc> I think we're going beyond discussing on important issues that all should partake <rfeng> back to the issues raised by simon, do we want to ship sca spec and commonj spec source/javadoc distro? <jboynes> yes <simonnash> i think the bundle distro discussion is one of the things we need to settle as part of the modularity discussion. there needs to be some easy way for users to get a comaptible set of modular parts. <jboynes> simonnash: I look forward to your proposals <jboynes> especially on how they address the matrix problem we're seeing now <jboynes> rfeng: I think those are additive to what we have <simonnash> it will not be easy to solve all the problems. this is why I think we need a bit of time to consider this. <jboynes> aren't they just source/javadoc archives that need to added to the vote? <rfeng> I think so <jboynes> perhaps a separate vote as I think we're going to need to abandon the current one <jboynes> and those don't depend on axis <simonnash> the spec binaries are already published on maven. i could not work out how that happened. <simonnash> i did not see a vote to release these <jboynes> my guess would be kgoodson_away posted them by accident <jboynes> the files are owned by him and dated 10/31 <simonnash> that would explain it.. but I did check the SDO vote to see if they had been included there. presumably we will just include them in the next SCA M2 vote. <simonnash> i could not see the file ownership. some day you can teahc me how to do that. <jboynes> you need access to the server - i.e. as a committer :) <simonnash> ahh <simonnash> what about my other question on contrib/maven consistency? <jboynes> so we just vote those spec jars out <simonnash> yes, and add the source and javadoc for the spec jars as appropriate. <simonnash> i think the contents of contrib should match what we publish on maven unless there is a particular reason for there to be a difference <jboynes> what's in contrib is what we decided to bundle <simonnash> agreed... so I ma puzzled to see a lot of other things go onto maven <halehM> so, this would be a change from what we had decided already? <jboynes> yes <simonnash> no i think the change is that many other things ar ebeing released on maven <halehM> should we stay with what we decided already and make changes if we want into m3 <simonnash> i am not sure why all of those would be pubslihed as binaries on maven <jboynes> maven contains what is part of the build <jboynes> simonnash: if you want something different, please give us a patch for the build to build it as YOU want it <simonnash> i was trying to agree the intention. if we can agree that then I will gladly supply a patch to implement that intention. <jboynes> you're changing what we have <jboynes> now is not really a good time to do that <simonnash> the first mention of what would be published on maven appeared in the release vote last Tuesday <ant_> it was never all that clear (to me anyway) what was being released to maven <jboynes> everything we build <simonnash> until then I was expecting it would be the files from contrib <jboynes> otherwise we're into building every module separately <jboynes> and I am not doing that <simonnash> is it necessary for every module that is built to also be published to maven? <jboynes> "otherwise we're into building every module separately" <jboynes> this is what happens when you don't have a modular build <jboynes> so, what gets built is what gets deployed <jboynes> simple really <ant_> isn't there any way to exclude a few modules you don't want, even if its ust editing them out of the poms on the last release build? <jboynes> we can restructure the build that way <simonnash> i am trying to understand why it is necessary for built==deployed. i do not know very much about how the build is structured so please excuse dumb questions. could some modules be built and not always deployed? <jboynes> that is basically the proposal for modualarity <simonnash> thanks ant for putting into words what I was struggling to express <jboynes> but you're the guys saying we don't want to do that <simonnash> no i did not say i don't want to do that. the previous discussion on modularity was around the release content not the build process * meerajk is now known as meerajk_away <jboynes> the two are related <jboynes> as you have to build the release at some point <simonnash> so in building the release I would expect to select a subset of all available modules and copy those selected modules into contrib and also deploy htem to maven <jboynes> patches welcome <simonnash> ok i will do what I can. any help from others will be appreciated. <jboynes> we done? <halehM> Simon/Jboynes.. do we need to sync up binary dist against maven for M2? Can't we make it clear in the readme that we support what is put out through binary? <ant_> so whats happening about the axiom problem, are we just waiting, having a vote to decide, something else? <simonnash> i will work on a patch for the build <simonnash> yes we need to have a ML vote on the axiom issue <halehM> Simon why do we need to do what you are suggesting? <simonnash> which suggestion? <halehM> your patch for M2. Why is that necessary? <simonnash> because otherwise we publish binaries that are not of interest to users and are not truly part of our release <halehM> How do we know this is not something that developers would like to see? We already made a decision <simonnash> no we did not already make the decision about maven <halehM> we will document what we support in M2 <simonnash> we decided about contrib <halehM> why is leaving it in Maven an issue? <simonnash> let's move this to the ML <halehM> OK. The point is we should get M2 out and not introduce more stuff at the last minute. Let's learn and improve in the next release. <ant_> I have to go. Should I post the chat log? <ant_> (if we're done) <halehM> yes please <ant_> ok. bye. * ant_ is now known as ant_away * simonnash has quit IRC ("Bye") * matthieur has joined #tuscany * matthieur has quit IRC (Remote closed the connection) * cr22rc is now known as cr22rc_away * kgoodson_away has quit IRC (Read error: 145 (Connection timed out)) Session Time: Tue Nov 28 00:00:00 2006 * Disconnected Session Close: Tue Nov 28 00:02:05 2006
