Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by KelvinGoodson: http://wiki.apache.org/ws/Tuscany/TuscanyJava/SDOJavaReleaseSteps ------------------------------------------------------------------------------ <jboynes> so you should only need to change that once }}} + + + === And another === + {{{ + <kgoodson> jboynes, you were looking for me yesterday evening + <jboynes> yeah + <jboynes> was going to ping you on upgrading EMF + <jboynes> I went and did it anyway :) + <kgoodson> ok, great, i saw your tuscany-dev note and responded, but didn't see the IRC ping + <jboynes> I didn't make the change in the branch + <kgoodson> ok, i can do that + <jboynes> we also need to tag das for lresende + <jboynes> what do you think about the samples? + <kgoodson> so to check, we are tagging now, yes? So if a tag is pretty imutable, how do we deal with comments on the release? + <kgoodson> in what way? (samples) + <jboynes> should we move them? + <jboynes> it's really an issue for the list + <kgoodson> i think moving could be good, but i'm not sure of the risks (e.g. documentation that has http://svn style links into the repository. And to make one tree we would also have to move the spec/sdo to sdo/spec + <jboynes> re spec, IMO that should be separate + <jboynes> at least, that's the case for SCA + <kgoodson> ok, so i'm not sure of the value of moving anything unless we move everything, becuase the main motivation for me is to remove the manual steps from creating the source distribution branch/tag + <kgoodson> i got feedback from the user list that one source distro was wanted, with spec and impl together + <jboynes> that's what I mean - are the spec's part of the Tuscany distro + <kgoodson> we'll we kind of ship our own third party dependency, but when I cut RC1 is caused confusion, creating two archives + <kgoodson> s/we'll/well/ + <jboynes> what was the confusion? + <jboynes> as in, it seems to make sense to me - one spec, one impl + <kgoodson> so one user doth not a straw poll make, but I can see the point that because these two archives come from the same project its kind of off to see the source split into two + <jboynes> the spec an be used by many people + <kgoodson> ok, i think it was possily the number of files in one directory ..... zip&tgz + asc + md5 for binary, spec and impl gives 18 files + <jboynes> :) that's why m2 repos have a directory heirarchy + <kgoodson> when i combined the source distros for RC1a it certainly looked clearer + <kgoodson> ok, so if you feel stronly that we should have two source distros, i can do that, and i will explain to the user list why we have not picked up on the suggestion of having one source distro -- then that makes moving samples a useful task + <jboynes> well, jboynes does not a straw poll make either ;) + <jboynes> I come from JCP land where there is a strong isolation between spec and impl + <jboynes> so that would shape my perspective on things + <jboynes> but SDO does not have the same history + <jboynes> e.g. it used to be you /had/ to ship spec api and impl in the same jar + <kgoodson> ok, help me, I believe in spec & impl separation too, but I can see that sdo/spec and sdo/impl separates the two + <jboynes> ok + <jboynes> my Q is on what you want to tag + <jboynes> tag == release content + <jboynes> i thought we were thinking of moving samples/sdo to sdo/samples so that we can tag just by copying the sdo parent directory + <kgoodson> i had imaged that we work on the branch until we are happy and then tag the branch, but in the branch hierarchy i have replicated the structure of the overall project, e.g. spec/sdo samples/sdo + <jboynes> which would tag imp, plugins, tools and samples all at the same time + |<-- isilval_ has left irc.freenode.net ("Trillian (http://www.ceruleanstudios.com";) + <kgoodson> that would be a step in the right direction, to be hones i'm easy, and I don't know what the right thing to do is, if there is a right thing to do + <jboynes> I'm not sure what you mean by "right thing to do" + <kgoodson> best practice, i guess + <jboynes> there are things you can do to make things easier + <kgoodson> i have not been involved in projects that do source distros before + <jboynes> ok + <cr22rc> rfeng been around any? + <kgoodson> haven't seen him + <kgoodson> jboynes, you said "there are things you can do to make things easier" -- what did you mean, can you elaborate? + <jboynes> so "best practice" is that a release is a "known good" version of the development tree + <jboynes> "known good" = stable, rebuildable, less buggy, whatever criteria you apply + <kgoodson> sure, i think we have that + <jboynes> yeah + <jboynes> except we don't really have a build that does just SDO + <jboynes> it's a mix & match thing + <jboynes> so the "rebuildable" it is not quite there + <kgoodson> so if we get to the state that we have a build for SDO spec and one for SDO impl (incl samples) then thats ideal + <jboynes> ok + <jboynes> I believe the spec build is standalone + <kgoodson> good, then lets do that + <jboynes> and also the sdo impl (sans samples) + <jboynes> so we can get to that by moving the samples under sdo impl + <kgoodson> ok, you've convinced me + <jboynes> under sdo, not under sdo/impl :) + <jboynes> I think we'd also move dist/sdo to sdo/dist + <kgoodson> indeed, i was using impl in a slightly loose way, that meant impl + tools + plugins -- i.e. all our implementation related stuff + <kgoodson> yes that would be very good + <jboynes> me too (just thought I wasn't being clear) + <kgoodson> but theres still the issue of the STATUS file + <jboynes> :) + <jboynes> yeah + <kgoodson> i wonder if we had a subproject for that kind of stuff that each other sub project depenmded on + <kgoodson> could that work? + <kgoodson> is that overkill? + <jboynes> it's more the convention of how to lay out a ASF project + <jboynes> project being all of tuscany + <jboynes> and many projects don't include their STATUS file + <jboynes> I happen to think that incubator projects should + <kgoodson> its in the draft guidelines IIRC + <jboynes> as i think community status is an important aspect of incubating projects + <kgoodson> hmm, so if we cant do some kind of symbolic link trickery then I think we are into manual copying, and all the maintenance issues associated + <jboynes> well, we know symlinks don't work on windows + <jboynes> how about if we have a manual step to copy the status file when we tag + <jboynes> actually, we would /need/ to do that + <jboynes> yeah + <jboynes> so, we make whoever cuts the tag responsible for copying the STATUS file from the root into the tag + <kgoodson> in the absence of any advanced techinal trick for sharing that fle then i think that's our only option + <kgoodson> ok + <jboynes> ok + <kgoodson> so we should have a release policy in place i think, so this could be a material part of that + <jboynes> yes + <jboynes> +1 + <kgoodson> i had started collecting info on the wiki + <kgoodson> so i will make sure this is at least recorded there, and then plan to sanitize it later + <jboynes> as an aside, I like what robert did on the proposal guidelines for the incubator + <jboynes> guideline + reasoning + examples + <kgoodson> i have looked at lots of docs recently, so i'm not sure exactyly which doc you are talking about + <kgoodson> is that the http://*****/releasemanagement link + <kgoodson> ? + <jboynes> http://incubator.apache.org/guides/proposal.html + <jboynes> (sorry, went looking) + <jboynes> in the templatebit + <kgoodson> ok, i'll take a look, so did you mention that as a suggestion for the format of the release policy? + <kgoodson> yes, on first scan that looks like a useful doc + <jboynes> yes + <jboynes> I think "why" is important :) + <kgoodson> "yes" to usefulness, or proposal for format? on the "why" issue, I couldn't agree more + <jboynes> I liked the way in this document robert was able to mix guideline with "why" with an example of "how" + <jboynes> a reference on style (not content) + <kgoodson> right, i'll put the proposal element on the wiki, with a link to this doc as a style suggestion + <jboynes> thanks + <jboynes> where were we? :) + <jboynes> ok, tag by copying "sdo" + <jboynes> includes impl etc. and samples + <jboynes> and then copy in STATUS + <kgoodson> yes + <jboynes> tag spec/sdo in the same way + <jboynes> also the parent pom and the buildtools + <kgoodson> so i'll need to rearrange my branch to match the trunk + <jboynes> rm & recopy? + <kgoodson> as to the parent pom, i was planning to digest a fair chunk of the free maven book this weekend and become a power maven user, but alas that didnt work out + <jboynes> :) + <jboynes> anything I can help with (as I set that up) ? + <kgoodson> theres been no change in the samples trunk so i can rm and recopy, yes + <jboynes> I was thinking the whole thing + <jboynes> would be easy (but assumes nothing really changed in trunk( + <kgoodson> well, i can't recall exactly what my issue was wehn i had to stop on friday night, but my branch was not building correctly, because of something to do with the parent pom + <jboynes> ok + <kgoodson> in the branch, after having copied in the samples stuff and tried to build from distributuion/sdo i was getting ... + <kgoodson> [INFO] --------------------------------------------------------------------- + [ERROR] BUILD ERROR + [INFO] --------------------------------------------------------------------- + [INFO] Error building POM (may not be this project's POM). + + + Project ID: org.apache.tuscany.samples.sdo:sample-sdo:jar:1.0-incubator-M2-S + + Reason: Cannot find parent: org.apache.tuscany.samples:parent for project: o + incubator-M2-SNAPSHOT + + + [INFO] --------------------------------------------------------------------- + [INFO] For more information, run Maven with the -e switch + [INFO] --------------------------------------------------------------------- + [INFO] Total time: 26 seconds + [INFO] Finished at: Fri Sep 29 17:29:43 BST 2006 + [INFO] Final Memory: 8M/23M + [INFO] --------------------------------------------------------------------- + + C:\Development\Tortoise\distroTest3\branches\sdo-java-M2\distribution\sdo> + <kgoodson> so i figured i had to go play with the parent pom + <jboynes> I can see that + <jboynes> I think it will go away if we move samples under sdo + <jboynes> currently the parent for samples/sdo is the pom in samples + <jboynes> so that would need to be released or tagged as wel + <jboynes> if we move the samples, then the parent would be the pom in "sdo" + <kgoodson> ok, sounds good, i wan't planning on attacking that for a few hours as i have domestic duties here before bedtime --- can this wait until the morning, or is it something you could readily do? + <kgoodson> don't get me wrong, i'm happy to do this stuff, but I'm feeling a little rough round the edges at the moment + <jboynes> i can do, can you drop a note to the list so everyone knows what's going on ? + <kgoodson> will do + <jboynes> I have 8 hours on you :) + <kgoodson> :-) + <jboynes> and haven't started drinking yet + <jboynes> (it's football day - 49ers just lost 41-0) + <kgoodson> ah, its been a rugby day here, both offspring won their matches, but torrential rain didn't make it the best of days for spectating :-( + <jboynes> :) + <jboynes> up for one more question? + <kgoodson> sure + <jboynes> in the binary distro, what do you want the samples to look like? + <kgoodson> hmmm, good point + <kgoodson> i guess its usual to copy the source of the samples into a binary distro + <kgoodson> i cant recall exactly waht it looks like at the mo, i could take a look + <jboynes> ok + <jboynes> ok, I'll just move what's there around + <jboynes> thanks + <kgoodson> thank you + =-= YOU are now known as kgoodson_away + [INFO] You are now marked as away (User is away.). Click the nickname button or use the |/back| command to return from being away. + + }}} + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
