> what are your particular grievences ? NantContrib needs some love - no > doubt but nant itself is fairly stable right now - or is that not your > experience ?
I'll chime in with my experiences, even though I'm not Keith. :) I think the frustrations being voiced are that (at least during the re-org) the software doesn't come build right out of the box, and once the compile error/warnings are corrected, the nantcontrib tasks (vssget at least) don't work, giving an error message "task not found" or somesuch. As someone unfamiliar with the code, it's a somewhat daunting task to fix. For my own usage, I backed off to 0.82 and a matching version of NantC, but that meant removing a bunch of code that had relied of 0.83-dev features in nant. I had to give those up because I couldn't get a working 0.83 with a <vssget> task. By "the software", I mean "nant and nantcontrib" not "nant". To my mind, end users will never care whether <gac> <vssget> <csc> <timestamp> or anything else come from nant or nantcontrib; to them (particularly to those who don't build the software but just use it), it's all just one piece of software. I'm in a position where I need to recommend a build system to my team (of >20 developers). I'm the new guy at this company, so I don't want to blow my first major decision. :) I asked myself: Is Nant/NantC stable enough for me to recommend to my team? Is it likely to continue to evolve over time, while remaining reasonably stable? At the *INSTANT* in time that I started looking at it (which happened to be right around the time of the source re-org), the answers appeared to be "NO!". Bad timing to be sure, but the tree stayed broken for weeks (and I suspect is still broken). When users are inquiring "Why couldn't there just be one tree?" I think that comes from the idea "If there were only one tree, it wouldn't stay broken for so long." (Near as I can tell, it's been about 3 weeks.) As an end user, I don't care if there are one or two trees (and I see a lot of benefit to a more "lightweight" NantC tree to let more people contribute). After all, when talking about the stable (working) trees, the build is quite easy and the end product looks like one product anyway. The problem is when something gets broken, it will stay broken longer, because a nant developer who changes something won't necessarily make the corresponding updates in contrib. Thanks for reading so far. To remove myself from the category of "idle complainer", I'd like to volunteer to help with nant[C], in particular in writing some automated self-tests for it so we can notice the breakages earlier and present a more stable product to all users. What's stopping me? Nothing; I just need to clear a few things off my plate at work and dive in. ---Jim PS: Because no one knows me from Adam, I'm a little hesitant to even write this email. I know that no one owes me anything; my offer to help fix what I see as one of the current deficiencies is not intended as a slight. PPS: In a past life, I led a team that built our own in-house proprietary automated build/version/test/package system. Boy what I wouldn't give to have those 4-5 man- years back to apply to the nant project. :) ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
