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? > 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. > 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. > 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. > 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.) > 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. > 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. 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. 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
