On Thu, 29 Jul 2004 10:30:52 -0400, Tim Daly <daly@xxxxxxxxxxxxxxxxxxxxx> wrote: > Jeff, > > Your three items would clearly be tasks for the various maintainers. I didn't say it wasn't their job. I'm saying these are the harder issues in the set. And not necessarily the obvious ones. > I'm a little puzzled by your third task where you write: > > > 3)making sure that the C continuum install media sets ALL come with > > tools that understand how to use Core and Extras to get updates AND > > additional software, not just from the internet but also from media. > > First, you're still maintaining the concept of Core and Extras. > That's gone. Becuase Core as one installable distribution in the continuum is going to drive the release and testing cycle for Fedora development, simply becuase its the one installable distribution that Red Hat has primary interest in, and Red Hat makes the final say. Core isn't gone, a rose by any other name....still has thorns. Red Hat's compelling interest are going to be embodied in something akin to what is called Core now even in the contiuum model. The volunteer efforts of red hat employees to maintain other installable collections inside Fedora aside, the compelling business interests at Red Hat, are still going to be focused on one specific point in the continuum. That one point in the continuum is going to drive the release and testing cycles. Call it core, or whatever, it will be a singularity in the continuum and it will carry weight beyond which other continuum distributions have when its time to think about delays in the development cycle. > Second, why would vendors care? The maintainer concept is "downstream". Vendors... as in people selling install media to users who do not have the network connectivity to do online installs or upgrades. Fedora.redhat.com has a whole page dedicated to a list of these entities. Its not so much that vendors care, but that people care about being able to get access to media sets to install from, media sets with a small finite number of discs. > > For instance, I have an interest in a platform that supports computational > mathematics. So I'm volunteered as the CA maintainer. My job is to define, > tag, configure, test, and maintain a CA distribution. (See Quantian at > http://dirk.eddelbuettel.com/quantian.html). This is a fully configured > system that specializes in computational mathematics packages. Are you suggesting that other points in the continuum are not going to be synced with the 6month-ish release cycle that Core (or whatever you want to call it that Fedora development tree is patterned to release against). I really don't think any debian based downstream distribution example is a good example for the types of problems any fedora downstream distribution is going to face. Fedora development moves FAST. If other points in the continuum can not sync'd to that fast pace, thats going to be a problem, if the intent is to have all points in the Fedora continuum trying to use the same package updates that live inside Fedora's package set. If each point in the continuum is just going to end up having its own release cycle and its own set of package updates...they might as well just fork and be seperate distributions and not even try to use the fedora build system or use the fedora name, they will diverge quickly. Debian's glacial release cycle gives something like Quantian a lot of leeway to upgrade packages as needed without conflicting with the debian base from which its derived. Trying to base anything of Fedora with its quicker time-based 'Core' release cycle pretty much demands that releases of a Fedora collection be in sync with the Fedora base time cycle. If knoppix and quantian had to deal with a stable debian branch that churned every 6 months... they'd fork and maintain seperate development of packages completely. > In the "maintainer world", the standard install menu could include > the tag install lists maintained by special interests. this assume anaconda will be the installer for all points in the continuum, this isnt going to be the case. There has already been repeated gnashing of teeth about making room in Fedora for non-anaconda based install media using something like rule. > Thus, a > "computational mathematics" install item would install all of the > items that are included in Quantian plus any system tools and libraries > needed to support the goal. Since a Quantian-like install is KDE based > then KDE would be implied. >From what set of install media? Being able to select any continuum member from the installer means you have to have ALL fedora packages on hand on media. That's just not practical. Every continuum member will need its own set of install media to be practical, to prevent people from having to have 17 cdroms on hand during media based installs. No one is going to want to have their point in the continuum need stuff off of disk 17 to do a media based anaconda install. > Lugs could have their own maintainers (the NYLUG branch). Pretty sure this comment comes from a misunderstand of what i meant by vendor. > > The Linus of the maintainer world only deals with maintainers. Let me just point out.. since you brought up the kernel development as a model. "downstream" maintainership of the kernel is something fedora development has explicitly working to avoid becuase of its burdens. I'm not sure encouraging a "downstream" distribution maintainership model inside fedora makes for a consistent world view when "upstream upstream upstream!!!!" is such a frequently heard chant. I think its a bit misleading to setup a system that expects volunteer downstream maintainers to build a distribution as an achievable goal, when upstream is where fedora developer's place their efforts. > > The current Core+Extras cannot satisfy any possible subset of users. > Since "advocacy is volunteering" we can make complaints work for us. > If you want a specialized build that includes tuxracer because you > teach a newbie class then either contact the current "newbie" maintainer > or become the "newbie" maintainer. Since maintaining a distribution is > a lot of hard work there will be very few people who will step up to the > task of being a maintainer. This works quite well in the linux build > process and is clearly socially acceptable. Why not use it here? Yes... advoocacy IS volunterring. But, its one must not encourage volunteers to tackle tasks that we know are beyond reasonable efforts to accomplish, becuase that is the best way to have volunteers burn out and cripple the volunteer efforts completely. I'm not sure you have heard my rant about the lack of planning and management of volunteers that fedora continues to not have a solution for, I'll gladly rant about that to you if you want. But for now let me just restate that your kernel development analogy you used has a darker intepretation concerning the burden of "downstream" maintainership versus "upstream." And if the fedora developers know better and they know "upstream" maintainership is prefered, we should not as a matter of policy build a system inside fedora where "downstream" maintainership of alternative package collections is encouraged if we know "downstream" maintainership leads to significant burdens. The conspiracy theorist in me, would say that such a system would only serve to shut volunteers up by encouraging them to toil on an unaccomplishable task. I definitely want to see someone inside the fenceline at Red Hat use this "downstream" maintainership model long enough to see 2 or 3 'Core' releases to gauge the robustness of the "downstream" distribution focus, before encouraging any bright shiny new volunteer to attempt this. -jef"about as bright and shiny as a 1902 penny, dug up from an unused new york sewer pipe"spaleta
