On Fri, Oct 12, 2012 at 11:11 AM, Noah Slater <nsla...@tumbolia.org> wrote: > On Fri, Oct 12, 2012 at 3:25 PM, Chip Childers > <chip.child...@sungard.com>wrote: > >> The level of detail and attention that you gave this is wonderful. I >> really want to thank you for this. >> > > No worries! Just doin mah job! ;) > > >> That being said, it's still valid for us to use this as a test target >> for ease of use. >> > > Yep totally cool with it. Just wanted a bit more visibility. > > Might be good to indicate the provenance of this image on the wiki, and > perhaps move it somewhere not on cloud.com, or am I misunderstanding what > that communicates?
I think moving it's build process to an automated approach, and hosting it somewhere on ASF infra is a great step for us to take. I tried to get things moving with the infra team on this, but then I got distracted doing other things. Perhaps we pick this back up once we hear back from the @basho team on their DevCloud build process changes? >> Actually, it shouldn't include that line at all. We aren't able to >> license the whole thing, since it's a full OS! However, this isn't a >> release artifact, so it can be ignored for the purpose of evaluating >> the release. > > > Okay. It should be removed when we get to the automated install / ASF hosting solution from above. >> I use OSX - I'll try to edit the instructions with the appropriate Mac >> Ports packages that are actually needed. I'm going to assume that the >> user already knows how to use mac ports (there's only so far I'm >> willing to go with the instructions). Alternatively, I considered >> just changing that whole section to a list of the packages that the >> user has to have installed, and assume that they figure it out for >> their own platform... but I thought better of that. A real example >> is more useful, and I'm happy to try to remember the steps for Mac for >> you. > > > I would prefer it if the instructions used Homebrew where possible. > MacPorts is kinda lame and I would prefer not to have to install it. Having > said that, beggars can't be choosers I suppose. > > As for including them or not, the goal here is to hone this test procedure > so that people can be as thorough as I am without having to think about it. > The more we can get to just a list of commands to copy and paste into a > terminal, the better. Makes things super easy to follow. Totally fair to prefer Homebrew. So here's what I'll say... I edited the instructions in an attempt to help a Mac user. If you wanted to run through the process and modify it to make it (1) more accurate and (2) work from Homebrew, that would be awesome. My machine already has everything on it, so I was struggling to remember exactly how I got things the way they are! I know I should have a better answer than that, but it's what I've got. >> Perhaps we don't need the zip format here. >> >> I was following examples like: >> http://maven.apache.org/download.html >> http://ant.apache.org/srcdownload.cgi >> >> However, I see that Hadoop only does tar.gz (well, that, plus RPM and >> DEB packages, which we're not doing officially via ASF infra). >> >> I'll start a thread specifically about this. > > > Okay, thanks. One file will make voting much less... Complicated. We're going to do 1 file in tar.bz2 format. >> The `zip` file is 16M, compared to 10M for the `tar.gz` file. Seems odd. >> >> It's not odd. They are different compression ratios. >> > > Surprising, then, through my ignorance. These were just "as I went field > notes". :) > > >> I added instructions explaining that you are looking for no output >> from the diffs. I'm going to leave the build process as-is for now. >> > > Okay. > > >> > *> Extract the source code and verify the contents: [unzip OR tar >> command]* >> > >> > This is a problem. >> > >> > People testing are instructed to only test on artefact. Either we reduce >> > our artefacts to one instead of two, or people must unpack both and test >> > both. Or we vote on them both separately. I favour having one artefact. >> >> People don't HAVE to do anything really. That being said, I >> absolutely get the point! >> > > People don't, but WE do. > > We need need to be sure our release artefacts are voted on. This isn't just > about checking boxes so the ASF will leave us alone, it is about ensuring > that we are producing the best possible releases for the community. (Hint: > We are the ASF, so this is a meaningless concept anyway. Though, I must > admit, when I was going through incubation I used to think of it in those > terms. "Bah, bloody ASF getting in my way again. Then one day, someone > kindly pointed out "ASF" included me.) I didn't imply that ASF if "getting in the way". See my reply to Will on how I look at the delegation of authority for podlings, and it's implications on what it means to vote. Like I said, I got your point about the double artifacts. That's changed now. > >> We'll probably end up releasing just the tar.gz archive version, but >> (as I said above) I'll start a different thread to get consensus on >> this. > > > No need to get consensus on everything. You should feel empowered to just > do what you think is right. We want to be careful about building a > permission culture. They are damaging and discourage contributions. When I > was talking to Prasanna on IRC earlier and he suggested posting to the list > to suggest what he thought was a good idea, I told him to Just Do It™ and > wait to see if anybody complained. Be bold. It's easier to ask forgiveness > than it is to get permission. > > That doesn't mean we should never bother talking to people, or discussing > things. That would be silly. ;) It just means, if something seems > reasonable to you, and you don't expect anyone to complain, just do it. We > have lazy consensus and version control to deal with when you make the > wrong judgement call. > > I am sure you don't need me to repeat this, but I thought it was worth > mentioning anyway. I think it will be important to the health of the > community if this principal was well understood, for both committers, and > users alike. I understand the spirit of what you are saying, but I wasn't asking for permission. I was asking for input, and John and David gave good feedback on the topic. That... we DO want to develop as a community habit. >> That's not the way we're doing it. >> > > Understood. > > Great addition! I skipped this when reviewing the couchdb example, >> specifically due to the autotools stuff. But I get the point of that >> step now. I've added it to the instructions. Done! >> > > Sweet. > > >> I don't understand the question. It is. This file is per-ASF >> guidelines, and RAT knows that a DISCLAIMER file is a NOTICE, and >> reports it as such. See the output file: target/rat.txt >> > > Understood. I have never used RAT myself, so I am unfamiliar with > specifics. Thanks for your patience with me! :) As I am sure you are > wondering, we do our own checking within the CouchDB build. Adding Java as > a build-time dependancy was not an attractive option for us. ;) > >>> KEYS >> > >> > This should not be in the repository. >> >> Interesting. OK. Where does it normally live? >> > > At the root of your dist dir. Both in your personal space on p.a.o, and our > dist dir proper. Fixed. Thanks for the explanation! > See: > > http://www.apache.org/dist/couchdb/ > > (Archived by infra, so you have nothing to worry about.) > > >> > Why are these files not picked up by RAT? >> >> Great catch. That's because some pom.xml fixes didn't get >> cherry-picked over. I'm looking at that now. The 4.0 branch has >> "exclude subprojects" set to true, which it should not. It's also >> missing some exclude directives, that are required once that flag is >> flipped. I'll get it fixed up. >> > > Thanks! > > >> >> >> patches/systemvm/debian/README >> > >> > What is this doing here? >> >> Low level instructions for using the code in that folder. Why is this an >> issue? >> > > I went through my rationale with Prasanna on IRC. > > This isn't with my mentor hat on. I just don't like README files scattered > around source trees. It's messy, and users very rarely find them. It would > be my preference to move that information to the wiki, or collect it in a > README at the root of the tree. (Perhaps using README.foo, and README.bar > as appropriate.) Exceptions have to be made for files that are required for > deb/rpm packaging, etc. Again, just a personal preference thing. Ignore me > at will. > > >> >> test/conf/README >> >> test/integration/component/README >> >> test/integration/README >> >> test/integration/smoke/README >> >> tools/devcloud/veewee/README >> > >> > Should we have this many README files? >> >> Prasanna covered this in another email. >> > > Yep, see above explanation, and rationale. > > >> >> > Moving on to a more manual check of the files... >> > >> > `waf` seems to be some sort of composite binary file. Can we ship this? >> My >> > guess is no. >> >> It's BSD licensed. >> >> http://code.google.com/p/waf/ > > > But we seem to be shipping a binary? Or is it? The head is source, but the > rest is binary. Never seen a file like that before. We should only be > shipping sources. Never compiled software. I am unsure how to categorise > this, and am looking for guidance. > > >> > LICENSE is ISO-8859 encoded. This should be changed to UTF-8 to match our >> > other text files. >> >> LICENSE is generated by Apache Whisker (using >> tools/whisker/descriptor.xml as the source). That's the format that >> it generates the file in apparently. >> > > How annoying, but okay. > > >> Do you happen to know how to convert it? I can do that after >> regenerating the files next time. > > > Hah. It's in Mac Roman (or MacroMan as I like to call it) because of one > character: § > > This would work: > > iconv -f MACROMAN -t UTF-8 LICENSE > > This is seriously nitpicky though, and certainly not a release blocker. > LMAO. :) > > Perhaps the problem is in the source configs? > > >> > Which gave me this output: >> > >> > ./awsapi/resource/AmazonEC2/xes.keystore >> > ./client/tomcatconf/cloudmanagementserver.keystore >> > ./console-proxy/certs/realhostip.keystore >> > ./utils/certs/cloud.keystore >> > >> > These files are binary. Do we need to ship the source? >> >> Yes. They are in our RAT exclude list, and are needed for the system >> to function on initial install. The software provides options for >> replacing them during a production deployment, but they are needed. >> > > Okay, I just wanted to make sure there's no "source format" we could ship > instead. Nope, those are keys. > >> Yup - that's the metadata that generates our LICENSE and NOTICE files >> in the first place! > > > Cool. > > >> > One concern is that even though I got the image to boot, I could not >> access >> > it via localhost:8080. >> >> That's because you didn't build / deploy / start the server! ;-) > > > D'oh! Heh. > > -- > NS
