On Sat, Jun 23, 2012 at 1:01 PM, inode0 <ino...@gmail.com> wrote: > ... based on some logic we have access to replicate are part of what > you define to be RHEL that would be excellent ...
What I and others define with my customers as RHEL has been repeated viewed by many as unacceptable and/or non-authoritative. I.e., it's why I stated prior ... "What I've heard is that some here will only accept a specific, actual statement from Red Hat on its own entitlement history. So doing such, which I've also done, is moot. I.e., we continue to have a lot of interpretation." That drove why I said I've not only done it (many times in the past, and most recently last week), but any effort won't be accepted, because it's not from Red Hat, and not specifically laid out as people want it on a public page. It also re-affirmed why I only post technical specifics off-list to select people. This is not only because my work would be trashed on-list (some has been trashed enough off-list), but a few people may make it ... oh how can I say this ... "difficult." E.g., several people have me utterly confused for others inside of Red Hat, who I am not. I also don't want anything I say to be taken as policy, and go out-of-my-way to state historical information or technical issues, without defining policy. So I continue to work with people off-list. I hope some results occur soon. > Saying you can do it in 5 minutes but not doing it doesn't help anyone. I say many things here that cause people to "roll their eyes," many because people don't follow what I'm saying at all. If you are familiar with Red Hat Standard Operating Environment (SOE), like most major Red Hat accounts, they make sense. I think I used the term "Common Knowledge" prior. I should refine it to say "SOE Common Knowledge." E.g., based on my making the comment ... "Anyone with a RHN Satellite Server can do the entite media history from the Kickstartable Trees in 5 minutes" If you have SOE Common Knowledge, you'd immediately hit those Kickstart Trees (e.g., /var/satellite/rhn/kickstart). You can see the channels, the comps.xml and groupings, etc... as the media. And since it's RHN Satellite, you have the full history, right there, immediately available, for every channel you've downloaded. I hope this explains my prior, "common knowledge" statement as well. ;) If you're a longstanding enterprise, you likely have not only all the way back to at least RHEL4, if not RHEL3, but likely Extended Update Support (EUS) as well. In fact, EUS is another, historical consideration. SIDE NOTE: From a 100% technical standpoint, if you want to avoid breakage, avoiding anything also cut for EUS is ideal. This means all of the AS/AP lineage, including RHEL6's HA, LB, RS (GFS2) plus Scalable File System (XFS). Why would we want to do that? GFS2 and XFS are userspace with kernel dependencies. XFS in particular had a key, kernel-userspace change that required a userspace change. It's one thing for someone to pull userspace from an EL Rebuild or upstream and get breakage, they intentionally did it. But it's another to see it in EPEL, or in the best case, get a dependency issue as a result. All I can point to is both historical lineage and technical specifics. But until something comes directly from Red Hat, on a redhat.com page and is public, I know most will not be satisfied. Hence why my efforts have been focused on getting that, and to the specifics I've seen stated here, to help others make policy. > I haven't heard anyone here say that. From my perspective there just > needs to be some reasonable logic in where the line is drawn that EPEL > users can understand. I've provided it and it's not enough for some. I've accepted that and am working with others to see if there can be a very, very specific document released. I don't want to say more as it's not my place, and I continue to "stick my neck out" (which clearly a couple people want to chop off) trying to get people what they want. I make *0* policy. I only try to point to things that many people either don't understand, don't believe or otherwise feel is not authoritative enough. Again, I've accepted that, and am doing my best to get something more authoritative. From there, I'll let people decide what they want to do. I now go back to lurking and working on things with people off-list. -- Bryan J Smith - Professional, Technical Annoyance _______________________________________________ epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list