<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Look, a satellite subscription, like RHEL, is for any version. You could install Satellite 5 and have a much smoother install experience, user experience, and copious, well written and updated documentation. In fact, Red Hat just released another dot update to satellite 5. However, you chose the new hotness, and with that choice comes all the stuff you're complaining about.</div><div><br></div><div>Red Hat is not alone in this. The more people you put your stuff in front of, the more flaws are exposed in the product. That's how the software industry functions. The days of developers locking themselves in a room and coming out years later with a super polished product with lovely documentation are over. Release early, release often is a mantra I hear all the time, and it means that if you want the bleeding edge, often you're the one doing the bleeding.</div><div><br></div><div>I hate to say it, but if you expect a great experience from a new (marketing speak for immature) product, you're going to live a life of constant frustration and disappointment.</div><div><br></div><div>.1 will be a significant improvement and .2 will look a lot more like your expectations.</div><div><br></div><div>As for docs, I don't know what's going on over there. Hell, if you look at the admin guide for RHEL 7, the flagship product, the section on iscsi still talks about configuring tgtd, which doesn't ship with RHEL 7...</div><div><br></div><div>-Scott<br><br></div><div><br>On Jan 21, 2015, at 9:49 PM, James Sumners <<a href="mailto:james.sumners@gmail.com">james.sumners@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 8:27 PM, Scott McBrien <span dir="ltr"><<a href="mailto:smcbrien@gmail.com" target="_blank">smcbrien@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><div>There's a reason why RH sales recommends a professional services engagement to go with the product. To be fair, they also do the same for Sat 5, but my impression is its more worth it right now for a sat6 implementation.</div><div><br></div><div>In a perfect world, yeah docs would be 100%. But if you've worked on a big software project, what happens is that the docs team is reliant on the engineering team to provide accurate, timely information. Also, it'd be nice if they also reviewed what the docs writers are writing. Sadly, when you're up against a deadline, that nice process is chucked out the window and docs writers requests are ignored and review turns into a quick glance and 'Yeah, that looks right.'</div><div><br></div><div>They're currently working on 6.1 which, from what I understand, is mostly UI and workflow improvements.</div><span class=""><font color="#888888"><div><br></div><div>-Scott<br></div></font></span></div></blockquote><div><br></div><div>I understand you're defending your coworkers. And I understand that it's no small undertaking to put out product like Satellite. But I'm not going to hold back when something is being touted so prettily on the "please buy it page" and is as expensive as it is. I don't mean any malice, I'm just stating my experience and opinion bluntly.</div><div><br></div><div>Adequate documentation does not necessarily mean 100% documentation. What is currently offered, though, is not what I consider adequate (and Ramesh seems to be agreeing with me). Here, I'll cite an example:</div><div><br></div><div>The first mention of the "Products" concept is 4 chapters into the User Guide -- <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html/User_Guide/sect-Using_Products.html">https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html/User_Guide/sect-Using_Products.html</a></div><div><br></div><div>Do you see a description of what a "Product" is? Clearly this one that can figured out by poking around the UI, but it's a clear and easy example of what I mean when I say the documentation, in its current state, is unacceptable. It gets worse when you start looking at the configuration management stuff. The configuration management has a "repositories" concept and there is no explanation about how it differs, if it even does, to a yum repository (although, I can't even find where I was reading about those now).</div><div><br></div><div>The short of it is this: documentation is not an add-on, it's a major part of the product. In fact, it's probably the most important part of the product. Sure, I have a support subscription. But I have my own deadlines and can't sit around waiting on support to read through an SOS report (or whatever) for however long it will take them just to get past something that should already be documented. An actual problem, "it be broke", is a different story. That's what support is for.</div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>James Sumners<br><a href="http://james.sumners.info/" target="_blank">http://james.sumners.info/</a> (technical profile)</div><div><a href="http://jrfom.com/" target="_blank">http://jrfom.com/</a> (personal site)</div><div><a href="http://haplo.bandcamp.com/" target="_blank">http://haplo.bandcamp.com/</a> (band page)</div></div></div></div></div>
</div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Ale mailing list</span><br><span><a href="mailto:Ale@ale.org">Ale@ale.org</a></span><br><span><a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a></span><br><span>See JOBS, ANNOUNCE and SCHOOLS lists at</span><br><span><a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a></span><br></div></blockquote></body></html>