Kyle Maxwell wrote:
But some decisions are starting to leave me in the cold
Err..well...i'm going to give red hat a pretty long lead time on when I expect them to get this whole external communication thing close to the right ballpark. I'm not prepared to read anything sinister into why rhl is down or whatever.Hell I'm shocked it had as much information as it did for the 3.2 days it was up (almost like they knew what they were getting into...they know better now i think :->). But if a significant amount of discussion was generated by the "right" people during those 3.2 days, enough to make a significant portion of that written material inconsistant with bleeding edge ideas...then I say its better to pull the site down..better no info than misleading info. The keys to the kingdom haven't changed hands yet....i'd rather see some significant fits and starts early on...than a big badass policy gotcha later.
Beginnings are hard...this shift towards rhl-"the project" is going to probably need a significant honeymoon window where users and developers..especially the more fervent ones...are going to have to allow for some really bone-headed obvious mistakes from people who live on that corporate side of the fence. I have no expectation that this is going to be a smooth transition during this beta phase. Consider this a proto-project phase....or maybe it would be best to call the project concept alpha level...where the project framework isn't stable enough to make it worth professional documentation. I fervently hope that the machinery for this "project" will be in place by the end of this beta phase.
I've beat the trademark dead horse only because its an existing policy that red hat's to make sure is updated to make sense in terms of the lack of boxsets in the upcoming release. A lot of the other issues that people seem to have with red hat right now on how to effectively communicate with the community are new issues that need new policy... and i get the feeling the hatters didn't shine the flashlight that far ahead when taking that first step towards the project concept. This isn't going to be a linear progression from closed to open...consider the loss of rhl site as the first coffeetable red hat stumbled into and had to backup to step around while groping for a plan. Luckily I don't have to worry about production systems. But as it stands...is anything all that different than a year ago when it comes to deciding if you were going to deploy the next red hat release (other than the lack of boxsets and the oem issues that causes)? I think it helps to think of this beta as still a traditional beta....the community project still needs a lot of flushing out...as a concept its alpha. I can just imagine how much internal discussion is being generated....and I can only hope the hatters show as good a sense of knowing how to schedule a "release" of the project framework as they do about pushing out distro releases.
-jef"i love it when a plan comes together...now...if we only had a plan...though I'd settle for a plan for making a plan"spaleta
On 14 Aug 2003, Jef Spaleta wrote:
Kyle Maxwell wrote:
But some decisions are starting to leave me in the cold
Err..well...i'm going to give red hat a pretty long lead time on when I expect them to get this whole external communication thing close to the right ballpark.
One of the reasons why things are taking a while is that everybody was away, first in Otawa for OLS and then at Linuxworld in California.
I think it helps to think of this beta as still a traditional beta....the community project still needs a lot of flushing out...as a concept its alpha.
Indeed, since the project went live around the same time as the Severn beta (beta == code freeze) this time the core release probably won't have all that much community input. Personally I hope this will result in a culture of using external repositories so the core distribution for the next version could be shrunk ;))
Of course I'm a kernel guy and mostly an onlooker when it comes to the distribution. I wouldn't be surprised if the people who are doing the actual work of putting together the distro ended up taking the decision of putting more cool stuff in their own repository, grabbing it from external repositories. On the other hand, I wouldn't be surprised by a "move stuff into external repositories and out of the core distro" movement, either.
I am very curious which of the two will happen, though...
I can just imagine how much internal discussion is being generated....
We are trying to discuss all the technical things in public, though. On the rhl-devel-list and also in threads on this list.
and I can only hope the hatters show as good a sense of knowing how to schedule a "release" of the project framework as they do about pushing out distro releases.
That is one of our requirements. We want this distribution to be at least as good for our own personal use as Red Hat Linux has been. That doesn't just mean a regular stable release with "fresh bits"; for me personally it also means being able to point the same update tool I use for the core distribution at other repositories, like freshrpms, fedora and a repository with some of my own RPMS.
Note that even though I work at Red Hat, I don't think I will be trying to get the RPMS I am interested in into the core distribution. I want to publish the stuff I want to do in an external repository in order to: 1) have freedom on how I maintain things 2) run my own release schedule, independant of the core distribution and, most importantly 3) not hold up the core distribution when my packages lag because I'm busy with the kernel
In short, I want to have all the benefits of a stable and regularly updated core distribution, while not adding the maintenance burden of my personal packages wishlist to that core distribution.
On Thu, 2003-08-14 at 00:55, Rik van Riel wrote:
Indeed, since the project went live around the same time as the Severn beta (beta == code freeze) this time the core release probably won't have all that much community input. Personally I hope this will result in a culture of using external repositories so the core distribution for the next version could be shrunk ;))
Am I the only one who reels in horror at this thought? I can't see any outcome from doing this other then encouraging even more slightly incompatible competing external repositories. None of them having everything you want or need, causing you to either have to 'graft' in parts of one into another or grab the most you can from one and having to play with spec files and building your own packages for the other.
Have you gone through the horror of getting XD2, fedora, freshrpms, and a couple others working on the same system without weird application behaviors, crashes, and apt/yum freaking out?
Sorry if this was beaten to death already in past threads but my interested in "RHL: The Project" centers around the hope these external repositories are (for the most part) _eliminated_ and we have one central repository where library versions and other dependencies, etc all match.
We need a sane dependency tree for the vast amount of software out there for Red Hat that doesn't require "--forcing" and "--nodeps" or end-users spending time with "rpmbuild". (Small repositories will of course still exist for those _really_ niche packages). Encouraging the development of even more external repositories sounds like a sure way of increasing the pain of "RPM dependency hell".
As a former Gentoo developer (I'm not trying to make that sound like it means something in this forum, I'm only to provide an example from personal experience), I found Gentoo initially attractive because it allowed for a configurable feature set and flexible dependency tree system but it was _one repository_... one tree.
I moved back to Red Hat from Gentoo due to a lack of time and not wanting to worry about such things. As a Red Hat user I gave up some flexibility with the hope of saving time and using a stable and integrated system ("It just works") or at least one that was predictable broken ("Well... it doesn't work but I can count on being broken the same on every version X system and this workaround will work on most/all of them..."). Having to depend on external repositories that can (and have proven to be historically) not "integrated" between themselves and incompatible with constantly changing versions for key libraries and applications destroys that advantage.
Basically, in my view, it creates anarchy where I don't want to be exposed to such anarchy. Distributions were originally supposed to be tested snapshots of software from the open source world and not just a means to sell a support contract right?... right?! <Joke> The conspiracy theorist in me could argue Red Hat was expecting this anarchy and wants it because it would help push their Enterprise product to people who couldn't afford to deploy it on every machine... :P </Joke>
On the plus side though, I have been very impressed by willingness of Red Hat employees to discuss things that would have been 'confidential information' only a short time ago. Thanks.
Le jeu 14/08/2003 à 07:44, Bruce A. Locke a écrit :
On Thu, 2003-08-14 at 00:55, Rik van Riel wrote: [...] Basically, in my view, it creates anarchy where I don't want to be exposed to such anarchy.
I you don't want anarchy, don't use XD2 or freshrpms, etc...
Two facts : - RedHat resource is finite. - You and/or RedHat can force everybody to work with RedHat.
I was worry with RHEL. With RHLP redhat take the right direction to reassure the community. And i trust Redhat and contributors to bring one of the best distribution. It's also in the interest of RedHat.
On Thu, 2003-08-14 at 02:45, Féliciano Matias wrote:
Le jeu 14/08/2003 à 07:44, Bruce A. Locke a écrit :
On Thu, 2003-08-14 at 00:55, Rik van Riel wrote: [...] Basically, in my view, it creates anarchy where I don't want to be exposed to such anarchy.
I you don't want anarchy, don't use XD2 or freshrpms, etc...
Ok. XD2 is a bad example because it replaces functionality that is provided by Red Hat (GNOME). Freshrpms, etc are not bad examples because they provide functionality that Red Hat doesn't provide or can't provide (Multimedia apps, etc).
Two facts :
- RedHat resource is finite.
- You and/or RedHat can force everybody to work with RedHat.
I understand that. Red Hat, Inc. of course will choose what it decides to focus on. I'm just concerned about Red Hat, Inc. only worrying about defining a "core" and pushing functionality out into a "community" where multiple (fragmented) competing repositories exist. Thus end users become reliant on them and gets bit by "RPM dependency hell".
I'm personally hoping Red Hat "gives its blessing" to one project like Fedora and encourages the development of one central repository of "non-core" software. I'd also hope a couple Red Hat full time employees with extensive experience in distribution maintenance could give some leadership/mentorship/experience to this project and encourage needed "integration", testing, etc.
Thus providing a stable "core", a well maintained and extensive "external repository". Maintainers of niche interest repositories, upstreams who maintain their own packages, etc could then be encouraged to keep their packages fully "compatible" with the core and the "sanctioned" repository.
Of course other approaches could work just as well or better but thats the only situation I could think of that might work. But what do I know. :)
I was worry with RHEL. With RHLP redhat take the right direction to reassure the community. And i trust Redhat and contributors to bring one of the best distribution. It's also in the interest of RedHat.
I'm a Red Hat user at both work and home and I'm hoping for the best. :)
On Thu, 14 Aug 2003, Bruce A. Locke wrote:
We need a sane dependency tree for the vast amount of software out there for Red Hat that doesn't require "--forcing" and "--nodeps" or end-users spending time with "rpmbuild". (Small repositories will of course still exist for those _really_ niche packages). Encouraging the development of even more external repositories sounds like a sure way of increasing the pain of "RPM dependency hell".
I agree with you that we need to avoid an RPM dependency hell. However, I do not agree with you that the only way to do it is to have all packages shipped by one central organisation.
Instead, we need to work on some software that can detect dependency conflicts between the external repository and the core distribution and rebuilds the RPMS in the repository.
Of course, this software would be run by the people who maintain the package repositories, so the repositories are in sync with the core distribution.
Nothing like a cron job to automatically keep the RPMS in the repositories up to date with the core distribution ;)
It really isn't hard to automatically bump the release number and rebuild the RPM, nor should it be very hard to figure out when exactly it is needed ... right at the point when apt-get starts complaining ;)
Now we just need to write this software ...
On Thu, Aug 14, 2003 at 12:55:52AM -0400, Rik van Riel wrote:
Of course I'm a kernel guy and mostly an onlooker when it comes to the distribution. I wouldn't be surprised if the people who are doing the actual work of putting together the distro ended up taking the decision of putting more cool stuff in their own repository, grabbing it from external repositories. On the other hand, I wouldn't be surprised by a "move stuff into external repositories and out of the core distro" movement, either.
I am very curious which of the two will happen, though...
My guess is that the right answer is in between; that we have a common set of policies, build tools, CVS server, universe of package names, release process, etc. (all the infrastructure that makes it nice to work together). However, the set of packages using this common infrastructure may be subdivided in various ways ("core" vs. various add-on package sets).
That's what I'd like to see. While I think we should support "some dude built a package in a haphazard way on their own system and put it on their web site," personally I want to have lots of RPMs available with higher standards than that.
If the infrastructure (cvs, build, etc.) and policies are replicable so people can host their own copy of it for their own package set, that's all the better.
Havoc
On Thu, Aug 14, 2003 at 01:44:48AM -0400, Bruce A. Locke wrote:
Am I the only one who reels in horror at this thought? I can't see any outcome from doing this other then encouraging even more slightly incompatible competing external repositories. None of them having everything you want or need, causing you to either have to 'graft' in parts of one into another or grab the most you can from one and having to play with spec files and building your own packages for the other.
Those kinds of problems are generally from poor segregation rather than pure externalism. Having *core* components in external respositories doesn't make much sense; that's what creates the kinds of problems you have seen, IMHO. But there are lots of kinds of functionality where there really isn't any particular need to tie them into a distro release.
I will clearly say that there is not a Red Hat policy to try to move most of the distro out into external repositories; that's been mentioned in several threads on these lists before. We have explicitly stated that our expectation starting this process was that the distro is more likely to grow than to shrink by this process.
However, it absolutely is important to Red Hat to enable external repositories -- and we want to make it easier to do right, as well.
On the plus side though, I have been very impressed by willingness of Red Hat employees to discuss things that would have been 'confidential information' only a short time ago. Thanks.
Thanks, I'm glad it's been clear that this is the case. It feels good to us, too. :-)
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
On Thu, 14 Aug 2003, Michael K. Johnson wrote:
I will clearly say that there is not a Red Hat policy to try to move most of the distro out into external repositories; that's been mentioned in several threads on these lists before. We have explicitly stated that our expectation starting this process was that the distro is more likely to grow than to shrink by this process.
For the confused onlookers, get used to the fact that Red Hat employees have different opinions on different stuff. Now the externally visible discussions will no longer be limited to software development, but it'll also happen in on topics such as the distribution and updating ;)
Of course in this case the people who do the work will automagically win any argument. If people want to grow the distribution I am certainly not going to stop them; I like having more stuff as much as the next guy ;)
Le jeu 14/08/2003 à 19:06, Havoc Pennington a écrit :
On Thu, Aug 14, 2003 at 12:55:52AM -0400, Rik van Riel wrote:
Of course I'm a kernel guy and mostly an onlooker when it comes to the distribution. I wouldn't be surprised if the people who are doing the actual work of putting together the distro ended up taking the decision of putting more cool stuff in their own repository, grabbing it from external repositories. On the other hand, I wouldn't be surprised by a "move stuff into external repositories and out of the core distro" movement, either.
I am very curious which of the two will happen, though...
My guess is that the right answer is in between; that we have a common set of policies, build tools, CVS server,
Have you considering using subversion ?
universe of package names, release process, etc. (all the infrastructure that makes it nice to work together). However, the set of packages using this common infrastructure may be subdivided in various ways ("core" vs. various add-on package sets).
That's what I'd like to see. While I think we should support "some dude built a package in a haphazard way on their own system and put it on their web site," personally I want to have lots of RPMs available with higher standards than that.
If the infrastructure (cvs, build, etc.) and policies are replicable so people can host their own copy of it for their own package set, that's all the better.
Havoc
-- Rhl-beta-list mailing list Rhl-beta-list@redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list
Féliciano Matias (feliciano.matias@free.fr) said:
My guess is that the right answer is in between; that we have a common set of policies, build tools, CVS server,
Have you considering using subversion ?
It's been considered. One advantage of CVS is that it lowers the entry barrier for those wanting to view/checkout/etc.
Bill
Le ven 15/08/2003 à 04:22, Bill Nottingham a écrit :
Have you considering using subversion ?
It's been considered. One advantage of CVS is that it lowers the entry barrier for those wanting to view/checkout/etc.
Sorry, i don't understand. Do you mean subversion is less popular than CVS ? If so, i agree.
Bill
On Thu, 2003-08-14 at 22:22, Bill Nottingham wrote:
Féliciano Matias (feliciano.matias@free.fr) said:
My guess is that the right answer is in between; that we have a common set of policies, build tools, CVS server,
Have you considering using subversion ?
It's been considered. One advantage of CVS is that it lowers the entry barrier for those wanting to view/checkout/etc.
Bill
As RHL9, and TNV (presumably RHL10) ship with subversion, is the barrier that high? There is also the web interface, which has no real barrier for entry.
Phil
On Fri, 2003-08-15 at 05:51, Phillip Compton wrote:
On Thu, 2003-08-14 at 22:22, Bill Nottingham wrote:
Féliciano Matias (feliciano.matias@free.fr) said:
My guess is that the right answer is in between; that we have a common set of policies, build tools, CVS server,
Have you considering using subversion ?
It's been considered. One advantage of CVS is that it lowers the entry barrier for those wanting to view/checkout/etc.
Bill
As RHL9, and TNV (presumably RHL10) ship with subversion, is the barrier that high? There is also the web interface, which has no real barrier for entry.
IIRC, older subversion clients aren't compatible to newer subversion servers so you would have to provide newer subversion packages for RHL9.
I'd love to use subversion, but it still has some deficiencies over CVS:
- Missing "svn obliterate". If you really have to delete something completely and permanently from the repository (as in "when a court orders you to do so", I'll leave it to your imagination why that could be), you can do it in CVS easily -- just remove the file from the repository. With subversion, all is in a database so it would be very tedious if not impossible to accomplish this.
- Missing "svn annotate".
I'd say that we should wait a bit, as we can easily cvs2svn the stuff when we feel the time has come to use subversion.
Nils
-
Bill Nottingham -
Bruce A. Locke -
Féliciano Matias -
Havoc Pennington -
Jef Spaleta -
Michael K. Johnson -
Nils Philippsen -
Phillip Compton -
Rik van Riel