Hello folks,
As you are aware from his earlier message, Michael Johnson has decided to move on and I have assumed the top level responsibilities for the Fedora Project. Michael has been a great asset for us (where "us" = Red Hat and the Fedora Project) and I would like to thank him for his efforts and the progress made in these past months. A good part of this progress has not been obvious to the outside world, but I know that there were a lot of logistical hurdles and behind-the-scenes requirements cleared by Michael in his time as the top Fedora wearer - which in turn will make my job that much easier. I would like to thank him for his dedication to this project.
Good luck to you, Michael!
So, who am I? I have joined Red Hat in the summer of 1997 and I have "climbed the corporate ladder" from an OS engineer to the Manager of OS Development - those "old enough" will probably remember me from those days. I then moved and started about three years ago the Red Hat Network engineering group, where I have been acting as the Director of RHN until about a year ago. In this past year, as a Red Hat Fellow, I have been known to hold strong opinions in front of various CxOs from the Red Hat's Executive team (/me tips the hat :-), while participating in various small internal projects as time permitted. And now, with Fedora, the cycle is completed and I have my chance to redeem myself for some of the things I have done during my first stint as the dude responsible for building a distribution... ;^)
I think it is important for everybody to realize that although Fedora is going at this moment through a change in leadership, there will be no change in the strategic direction and goals set by Red Hat and the Steering Committee when the project was started. And because that saves me from having to come up with a new grandiose plan ;-), I will dedicate my immediate time on some of the tasks that need to be addressed with urgency. In no particular order (since all these are qualify as "top priority"), I will attempt to make happen in the shortest possible time:
- Fedora developer and contributor forms. These include things like establishing qualifications, credentials and requirements for issuing various accounts and access levels - in short the formal aspect of getting those interested the "commit" access to Fedora Project bits;
- Installation of a CVS server and associated repositories as the primary interface for the developers. I am still in the process of reviewing the specifics of this plan, but I can share at this point that there will be two main categories of packages/projects served from this machine to our contributors (and here is the answer to a popular FAQ): - the internally maintained packages will be mirrored read-only so that external contributors can track our progress, review our changes and replicate our progress on their own systems without waiting for updates from Red Hat. - the externally maintained packages will allow read/write access to particular contributors ("owners").
We're finalizing the implementation of this server, and we'll get it online in a relatively short time. Yes, the web site promised this "before the end of 2003". That means we're behind and I personally don't like at all being behind the schedule...
- We're going to start building and deploying the necessary pieces for a build system that supports Fedora and its collaborative development paradigm. This is going to be closely linked and interfaced with the CVS server. I know some people have already proposed/implemented proof of concepts for this, and I will engage them in more detailed discussions in the next week (as I hunt them down in the mailing list archives, unless they choose to make contact with me first).
I realize that there is no shortage of people interested and willing to test-drive each of these pieces. I would like to thank you for your patience to date and I promise you that shortly you will have plenty of stuff to sink your teeth into...
In other words, my immediate attention is dedicated to the issue of physical and logistical infrastructure that would get the most developers contributing the fastest to the whole project. So, what are your expectations of this infrastructure? I can not make promises, but I know that reading your opinions will be a good opportunity to understand how relevant our current plans are.
As I come up to speed on various other bits and issues in the project, I will attempt to address those as well. I will try to capture all this into a general project-level TODO list on the web site to keep folks informed where we are on various issues, what kind of progress is being made or what's holding up the expected progress.
For the future I hold the hope that we will build not only a great project, but that we will have the chance of building strong relationships as well.
Excited, terrified, worried and hopeful - I am looking forward to it,
Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "There are two kinds of people who never amount to much: those who cannot do what they are told, and those who can do nothing else." --Cyrus Curtis
I think it is important for everybody to realize that although Fedora is going at this moment through a change in leadership, there will be no change in the strategic direction and goals set by Red Hat and the Steering Committee when the project was started. And because that saves me from having to come up with a new grandiose plan ;-),
What is the strategic direction? What are the goals? What does red hat want from fedora as a community?
This page: http://fedora.redhat.com/about/objectives.html defines the technical objectives. What are the objectives of interacting with the community? What is it that red hat wants to do?
If red hat wants people involved in fedora they need to foster an environment conducive to getting and keeping volunteers. This means giving people guidelines and guidance. This means encouraging those who are doing what is thought of as a 'small thing'. The items you outlined are priorities, and good ones but; there needs to be some social change, as well.
Making social changes means that there needs to be more active leadership of fedora. Not just by the technical lead but also by people who want to make fedora into something they want to spend their spare time working on. Leadership in the open source world, from what I've seen, means talking about and describing what's going on. It means doing the head-down work but letting people know what you're doing so they can feel invested and involved in the process. Think of it like an informal status report to the community
One of the reasons I setup the fedora people blog aggregator (http://fedora.linux.duke.edu/fedorapeople/) is that I thought it would help people know what's going on. What people are working on or thinking about. (The other reason is that I thought it was a cool idea). I think it'd be useful to have the fedora 'cheerleader' have an rss feed to let us all know things on a semi-regular basis. Even if the news is 'still in holding pattern on cvs server, legal is tied up debating contributor contracts/forms' it'd be enough to let people know what's going on and to remind them that there ARE things going on.
I was speaking with Luis Villa of the gnome board last night about planet.gnome.org. He said that he's found a number of people have told him that they feel more involved in the process and more aware of what's going on b/c they don't have to be in irc every waking minute or reading every message of every mailing list; they get the interesting and important bits from planet.gnome.org. He also said by adding someone to the rss feed lists of planet.gnome.org when they've contributed to gnome you're encouraging them to contribute more. They get fame or maybe notoriety by their blog entries but they get noticed and that's important.
So that's my suggestion: - we need to know the goals for the community not just the goals for the distro. - fedora needs active, communicative leaders - not just the technical lead. - we need an environment that is conducive to getting and keeping volunteers.
so that was somewhat more than 2cents but it probably has the same relative value..
-sv
On Sun, 25 Jan 2004, seth vidal wrote:
So that's my suggestion:
- we need to know the goals for the community not just the goals for the distro.
- fedora needs active, communicative leaders - not just the technical lead.
- we need an environment that is conducive to getting and keeping volunteers.
Agreed on all three points. I am willing to help out on the communicate-with-volunteers parts, but I think that the community goals really should be determined by the community and not prescribed by Red Hat ;)
Btw, I recently volunteered to help the Fedora project too. My goals are to get some things out there ASAP, even if it'll take a longer time to get everybody's grand master plans implemented.
On Sun, 2004-01-25 at 20:35, Rik van Riel wrote:
Agreed on all three points. I am willing to help out on the communicate-with-volunteers parts, but I think that the community goals really should be determined by the community and not prescribed by Red Hat ;)
The community can't set goals until Red Hat has everything in place so it knows what it can/can't and allowed/not-allowed to do.
--- Mike Chambers Madisonville, KY
2.4.22-1.2163.nptl #1 Fri Jan 16 13:16:46 EST 2004 i686 GNU/Linux 20:38:59 up 8:59, 1 user, load average: 1.04, 1.06, 1.02
On Sun, 25 Jan 2004, seth vidal wrote:
I think it is important for everybody to realize that although Fedora is going at this moment through a change in leadership, there will be no change in the strategic direction and goals set by Red Hat and the Steering Committee when the project was started. And because that saves me from having to come up with a new grandiose plan ;-),
What is the strategic direction? What are the goals? What does red hat want from fedora as a community?
(Apologies for the late reply. The weather had a different opinion about my plans to return back home from a weekend travel)
Now, onto the strategic direction, I think that is covered pretty well in the objectives page we have on the site currently. While the verbiage might be a tad verbose, there are two main thrusts of strategy here as far as Red Hat is concerned:
- enabling Red Hat to engage the developer community more directly and provide an integrated and (hopefully) popular platform that would bring various included projects to their maturity faster; support this by providing required resources and logistical support;
- create a test/proving ground for new technologies that allows Red Hat more flexibility in terms of how quickly can we adapt those technologies and integrate them into a distribution. Many of the internal developers here at Red Hat view this as a return to our origins. For those who remember the old days of early Red Hat Linux releases, you know that oftentimes we did not shy away from introducing new/incompatible changes from one release to another. Today people pay for support, stability, maintainability, compatibility and other *ility features - and to provide that we have to be more conservative about what we can include and when. It is not better or worse, it's just different, and the need for something like Fedora follows quite naturally.
Making social changes means that there needs to be more active leadership of fedora. Not just by the technical lead but also by people who want to make fedora into something they want to spend their spare time working on. Leadership in the open source world, from what I've seen, means talking about and describing what's going on. It means doing the head-down work but letting people know what you're doing so they can feel invested and involved in the process. Think of it like an informal status report to the community
You are absolutely right there. I will make a concentrated effort to keep folks informed of what is going on. Personally I'd like to thank you for the fedora people aggregator - I hope soon I'll be included on it as well.
For what is worth, I do believe in very active communication channels. This is why I do have a secondary agenda of figuring out how to bring your aggregator on to the fedora site to increase its visibility. It is extremely useful stuff. The same goes for the great work done by the guys running the fedoranews.org site. The fact that we have not enabled yet contributions like this on the official Fedora site looks to me as a failure on our part.
Your comments about the social change are dead on. I am aware of what should/needs to be done and I am attempting to address all that as soon as humanely possible.
Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "There are two kinds of people who never amount to much: those who cannot do what they are told, and those who can do nothing else." --Cyrus Curtis
On Sunday 25 January 2004 00:28, Cristian Gafton wrote:
- Installation of a CVS server and associated repositories as the primary interface for the developers.
Hmm... I thought RedHat was going the way of early adoption of SVN?.. *This* could be the perfect moment to start eating our own dogfood. ;-)
On Mon, Jan 26, 2004 at 07:07:56AM -0500, Alexander L. Belikoff wrote:
On Sunday 25 January 2004 00:28, Cristian Gafton wrote:
- Installation of a CVS server and associated repositories as the primary interface for the developers.
Hmm... I thought RedHat was going the way of early adoption of SVN?.. *This* could be the perfect moment to start eating our own dogfood. ;-)
I have tried out svn and like it a lot. It is still pretty slow for me and the benefits to have branches in "real trees" is not really a big improvement. You need good support for -HEAD development and everything else should be just a few important bug-fixes and security fixes. cvs does fine for that.
greetings,
Florian La Roche
On Monday 26 January 2004 07:41, Florian La Roche wrote:
On Mon, Jan 26, 2004 at 07:07:56AM -0500, Alexander L. Belikoff wrote:
On Sunday 25 January 2004 00:28, Cristian Gafton wrote:
- Installation of a CVS server and associated repositories as the
primary interface for the developers.
Hmm... I thought RedHat was going the way of early adoption of SVN?.. *This* could be the perfect moment to start eating our own dogfood. ;-)
I have tried out svn and like it a lot. It is still pretty slow for me and the benefits to have branches in "real trees" is not really a big improvement. You need good support for -HEAD development and everything else should be just a few important bug-fixes and security fixes. cvs does fine for that.
I understand, but maybe we could still give Subversion a try?.. This would have the following advantages:
- We would be eating our own dogfood. I am confident this is a vital part of the product success. SVN is provided within the product, so using it for "real" stuff would display our confidence in the product.
- It would help Subversion as a product. Not a primary goal, obviously, but a good one.
- I am sure the Subversion developers will be more than thrilled to help such a high-profile showcase of their software. Based on my experience, they've always been very helpful so we should not assume it is going to be different in this case.
- someone has to make the step and bite the bullet. Subversion needs exactly this last step that would move it into the spotlight as a legitimate successor of CVS. Redhat historically has been very brave in biting the bullet (glibc, kernel, XFree86, etc) which helped making it a popular and stable platform. This should be easier than glibc ;-)
- It would be much easier to try using it now than to switch later when the process has been established and some migration path is required.
So let me ask again - could we give it a try? If it doesn't work (and the SVN team cannot help us) - no problem, we'll go back to CVS. Obviously, by proposing this, I volunteer to help with setup, configuration, and the basic SCM process in case my help is needed.
Cheers,
No. We have thoroughly examined all alternatives to CVS and found each to be either lacking in necessary features, not mature enough, not free enough, or too inefficient. Subversion I recall fit into the "too inefficient" category.
Warren
On Tuesday 27 January 2004 02:14, Warren Togami wrote:
No. We have thoroughly examined all alternatives to CVS and found each to be either lacking in necessary features, not mature enough, not free enough, or too inefficient.
I assume it's on the list, correct? I'll do my homework tonight to see how it went.
Subversion I recall fit into the "too inefficient" category.
Do SVN people know about that? They have been pretty helpful in the past and they have a fairly aggressive development cycle (maybe a bit too aggressive IMHO esp. when it comes to backward compatibility ;-) . Has anyone showed them where their product is flawed?
On Jan 27, 2004, at 8:01 AM, Alexander L. Belikoff wrote:
On Tuesday 27 January 2004 02:14, Warren Togami wrote:
No. We have thoroughly examined all alternatives to CVS and found each to be either lacking in necessary features, not mature enough, not free enough, or too inefficient.
I assume it's on the list, correct? I'll do my homework tonight to see how it went.
Subversion I recall fit into the "too inefficient" category.
Do SVN people know about that? They have been pretty helpful in the past and they have a fairly aggressive development cycle (maybe a bit too aggressive IMHO esp. when it comes to backward compatibility ;-) . Has anyone showed them where their product is flawed?
Earlier versions of Subversion had issues with the mod_svn connectivity via httpd being quite slow. However, I have never found the native mode to be anything other than comparable to running CVS: both tunneled over an SSH connection.
As for an aggressive development cycle, the real issue was when the database schema was constantly changing. Latest releases are not focused as much on the schema, so you should be able to get some bang for your buck without having to constantly upgrade / do reimports of your repository.
Current version is 0.37, which works quite efficiently as far as I am concerned. To address each point mentioned earlier:
Free Enough: http://subversion.tigris.org/project_license.html. Judge for one's self.
Necessary Features: Comparable or better than CVS and eliminates some of the more annoying issues with CVS.
Mature Enough: I think so, but again, you would need to decide that for yourself. For a project like Fedora, I think it would be more than adequate for handling that which is required.
Efficiency: I did some perusing of the list archives looking for this discussion, and I was not able to find significant mention of this. I would be interested in seeing some related empirical data to back up statements to the inefficiency of Subversion.
CMS -- Christopher M. Smith Key ID: 0x44D59911 Fingerprint: C1A0 EBC3 B036 8037 B4FC 2108 537E A50D 44D5 9911
Title dictates behavior. --Clerks
I understand, but maybe we could still give Subversion a try?.. This would have the following advantages:
- We would be eating our own dogfood. I am confident this is a vital part of
the product success. SVN is provided within the product, so using it for "real" stuff would display our confidence in the product.
Anyone wants to improve srpm-cvs to handel cvs and subversion? I'll probably not have time during the next days, so please just give it a try.
The big benefit I see is that subversion would have some plus points if you add different products and want to compare src.rpm differences. With cvs you more or less just look at the history and branches on a per-rpm perspective.
greetings,
Florian La Roche
On Mon, 26 Jan 2004, Alexander L. Belikoff wrote:
Hmm... I thought RedHat was going the way of early adoption of SVN?.. *This* could be the perfect moment to start eating our own dogfood. ;-)
There is going to be plenty of time to play with alternative solutions once we have in place at least one. Every solution has its supporters and opposition, and we're not going to get unanimity no matter what.
I happen to know CVS and I think that most people are familiar with CVS. It is not perfect, it has its faults, but its faults are widely known. I can take few days to put out the CVS server or I can take few weeks to review other solutions that I'm not that familiar with. I'd rather have the CVS out.
Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "There are two kinds of people who never amount to much: those who cannot do what they are told, and those who can do nothing else." --Cyrus Curtis
On Tue, 27 Jan 2004, Cristian Gafton wrote:
On Mon, 26 Jan 2004, Alexander L. Belikoff wrote:
Hmm... I thought RedHat was going the way of early adoption of SVN?.. *This* could be the perfect moment to start eating our own dogfood. ;-)
There is going to be plenty of time to play with alternative solutions once we have in place at least one. Every solution has its supporters and opposition, and we're not going to get unanimity no matter what.
I happen to know CVS and I think that most people are familiar with CVS. It is not perfect, it has its faults, but its faults are widely known. I can take few days to put out the CVS server or I can take few weeks to review other solutions that I'm not that familiar with. I'd rather have the CVS out.
I'd definately go for arch. It supports signed archives, repository integrity checks, distributed development, easy branching, no special server needed (ftp, sftp, http and webdav would do).
It does not have performance issues and its design is sound and simple.
Pau
On Tue, 2004-01-27 at 18:10 +0100, Pau Aliagas wrote: [snip]
I'd definately go for arch. It supports signed archives, repository integrity checks, distributed development, easy branching, no special server needed (ftp, sftp, http and webdav would do).
https://bugzilla.fedora.us/show_bug.cgi?id=1266
A guinea pig for my package!
Thanks,
- Michel
On Tue, 2004-01-27 at 09:48, Cristian Gafton wrote:
On Mon, 26 Jan 2004, Alexander L. Belikoff wrote:
Hmm... I thought RedHat was going the way of early adoption of SVN?.. *This* could be the perfect moment to start eating our own dogfood. ;-)
There is going to be plenty of time to play with alternative solutions once we have in place at least one. Every solution has its supporters and opposition, and we're not going to get unanimity no matter what.
I happen to know CVS and I think that most people are familiar with CVS. It is not perfect, it has its faults, but its faults are widely known. I can take few days to put out the CVS server or I can take few weeks to review other solutions that I'm not that familiar with. I'd rather have the CVS out.
I agree with both of you. Nearly every Linux developer has used CVS at some point and is probably as familiar with it as they are with other common tools like make. And we (the non-redhat developers) really, really need a project server we can use. I'd say set up the CVS server tonight, but don't stop there.
CVS is pretty seriously flawed, but we've learned to work around it. It's faults are widely know, yes, but they're still in the way. It's better than nothing, but it's worse than many of its alternatives. It's mature, but it's maturely broken, and it's not ever going to get better. There's really no reason for us to stick with it any longer than we have to.
Subverion is a great program. It's being worked on pretty heavily, so if you haven't looked at it recently, you're missing a lot of the picture. It's efficient, it's stable, it does right what CVS does wrong, and it's already impressively widely adopted and heavily relied-on. The learning curve going from CVS to SVN is minimal. Once the CVS server is running, set up a parallel SVN server (on the same machine if you want), and let the developers choose where to host their project.
While I realize it's better to use only one versioning system than having the projects split between two, splitting between two versioning systems is better still than sticking with just CVS; and I think this is the best way for us to start the migration.
On Sun, 25 Jan 2004 00:28:43 -0500 (EST), Cristian Gafton wrote:
[...], I will attempt to make happen in the shortest possible time:
- Fedora developer and contributor forms. These include things like establishing qualifications, credentials and requirements for issuing various accounts and access levels - in short the formal aspect of getting those interested the "commit" access to Fedora Project bits;
I'd like to see early communication about the Fedora Extras package submission and approval policies and its development model (i.e. questions such as whether Extras will be release-based and freezed in sync with Core and who will overlook the experimental and stable stream?).
The sporadic criticism of the fedora.us QA system has not been taken as an opportunity to discuss it and develop it further or change it completely.
The community is surprisingly quiet, almost as if everyone is waiting for Red Hat to make the first step and publish something which can be torn to pieces then.
There must be developers and package maintainers [other than ESR] with precize ideas on how they would like to contribute packages. Similarly, there must be people--in particular users of the software which is being packaged--with precize ideas on how they would and could help deciding on when a package is approved and whether an updated package get released.
There is one particular thing I don't understand. Once an arbitrary repository contains a new package, people don't hesitate to download and install it. When it's broken or not as usable as expected, they either downgrade or try the next repository (this experience is based on comments seen in message boards), repeating this procedure regularly. But when a package of the same software is in a public queue of packages to be reviewed before they get published, people avoid such packages like the plague and don't give the packages a try and don't leave feedback. I think the community can do better than that. But the Fedora community has a long road to take to realize that--like with the Debian GNU/Linux project--it's better to spend a combined effort on a primary source of reliable and maintained packages than to either want everything maintained by Red Hat in "Fedora Core" or to keep an excessive list of repositories maintained by individuals and live with interoperability problems.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 26 January 2004 13:21, Michael Schwendt wrote:
seen in message boards), repeating this procedure regularly. But when a package of the same software is in a public queue of packages to be reviewed before they get published, people avoid such packages like the plague and don't give the packages a try and don't leave feedback. I think
If you mean the development branch particularly, I think Joe Q Public did not hear enough about it yet. I read fedora-list and I only realized that there was great stuff I wanted in the development branch pretty much by accident.
Somebody or "more people" should mention this, that you can get Mozilla 1.6 and KDE 3.95 right now and it is 'reasonably' stable.
The fact its marked as unstable or development or testing is interpreted as a big red flag for people, the other repos just don't mark it up as such and get more custom :-) To counter the stick of worrying labels the carrot of the availablility of this official cool new stuff needs to be put around, people will come :-)
Also if an official Redhat person said, "hey, why don't more people try development on a non mission-critical (or well backed-up) machine? We would love to hear about new troubled not already in Bugzilla." then I think that'd get a response. People have a lot of respect for @redhat.com folks, maybe so much that its a bit inhibiting playing in the same sandpit sometimes.
- -Andy
- -- Find your answer without waiting for replies.... Searchable list archives at http://marc.theaimsgroup.com/?l=fedora-list&r=1&w=2
On Mon, 26 Jan 2004 14:04:46 +0000, Andy Green wrote:
seen in message boards), repeating this procedure regularly. But when a package of the same software is in a public queue of packages to be reviewed before they get published, people avoid such packages like the plague and don't give the packages a try and don't leave feedback. I think
If you mean the development branch particularly, I think Joe Q Public did not hear enough about it yet.
No, I mean _unreleased_ packages, such as in http://www.fedora.us/QA On the contrary, the Fedora Core "development" tree contains _released_ packages.
On Mon, Jan 26, 2004 at 02:21:27PM +0100, Michael Schwendt wrote:
On Sun, 25 Jan 2004 00:28:43 -0500 (EST), Cristian Gafton wrote:
[...], I will attempt to make happen in the shortest possible time:
- Fedora developer and contributor forms. These include things like establishing qualifications, credentials and requirements for issuing various accounts and access levels - in short the formal aspect of getting those interested the "commit" access to Fedora Project bits;
The community is surprisingly quiet, almost as if everyone is waiting for Red Hat to make the first step and publish something which can be torn to pieces then.
Perhaps because, without leadership, decisions tend to turn into contraversory, endless discussion, and final death without a decision.
On Mon, 26 Jan 2004, Michael Schwendt wrote:
There must be developers and package maintainers [other than ESR] with precize ideas on how they would like to contribute packages.
I would think that for packages that fall outside Core, there would be two tracks:
1. Upstream developers who want to maintain packages for their own software (e.g, esr),
2. Interested third parties who want to maintain packages for someone else's software.
Presumably, we'd like to see as many packages as possible fall into the first category.
Realistically, of course, third parties will continue to maintain packages for a variety of reasons: the upstream developers aren't interested in maintaining an rpm and/or the administrative files associated with it (init scripts, logrotate entries, sysconfig files, etc.) or the software is written for a different platform and requires significant porting.
If the upstream developers are willing and (seemingly) able to maintain a package, it seems to me they ought to get the first nod. My hunch here is that bugfixes will get to them sooner than to anyone else, and they'll have contacts with people already running their software on a variety of platforms. This is just a hunch, however, and I'm certainly willing to stand corrected.
For interested third-party maintainers, however, things grow murky, and my thoughts aren't clear.
--Paul Heinlein heinlein@madboa.com
re: contributed packages
I'm one of those "Upstream developers who want to maintain packages for their own software" (category 1). In this case it is Axiom, a free computer algebra system. I'm awaiting some motion on the Extras branch.
Is there any schedule for Extras? Is there a way to help Extras exist? Is there a doc about packaging requirements for Extras?
Tim Daly axiom@tenkan.org
On Mon, Jan 26, 2004 at 11:08:38AM -0500, Tim Daly wrote:
Is there any schedule for Extras? Is there a way to help Extras exist? Is there a doc about packaging requirements for Extras?
Right now extras is effectively fedora.us.
As to the other stuff. We are hopefully going to get somewhere soon. The internal hurdles are hopefully close to sorted now (I wish I could be more than definite) - things like contributor paperwork that we have to put in place and requires lawyers not engineers to verify.
The doc list has been kicking around some documentation on packaging and there is good material on fedora.us about this too.
Alan
Tim Daly wrote:
re: contributed packages
I'm one of those "Upstream developers who want to maintain packages for their own software" (category 1). In this case it is Axiom, a free computer algebra system. I'm awaiting some motion on the Extras branch.
Is there any schedule for Extras? Is there a way to help Extras exist? Is there a doc about packaging requirements for Extras?
Tim Daly axiom@tenkan.org
I would suggest submitting your package to fedora.us QA. While it may not pass QA unless somebody else also cares about that package, it would at least be in the listing of available packages when someone loads this URL:
http://www.fedora.us/wiki/PackageSubmissionQAPolicy Follow these directions exactly if you wish to submit
Warren
On Mon, 26 Jan 2004, Paul Heinlein wrote:
Realistically, of course, third parties will continue to maintain packages for a variety of reasons: the upstream developers aren't interested in maintaining an rpm and/or the administrative files associated with it (init scripts, logrotate entries, sysconfig files, etc.) or the software is written for a different platform and requires significant porting.
One of the problems is that there is still a fair bit of "black magic" going on about what to do and how to package a project effectively. I think there is room for a documentation project aimed at developers about what needs to be done to create a project-x.y.z.tar.gz arcchive that can be grokked successfully by rpmbuild -ta.
I know that very few folks contact the author and send them relevant spec files, initscripts, logrotate files, etc after packaging something up. It's just easier to package it and not spend time convincing the author to include those extra files. Or, they send up a src.rpm and say "here it is" and nothing more. I know I've done it. And through this the rpm packaging continues to have this unhealthy aura of mystery.
Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "There are two kinds of people who never amount to much: those who cannot do what they are told, and those who can do nothing else." --Cyrus Curtis
On Tue, 2004-01-27 at 17:01, Cristian Gafton wrote:
One of the problems is that there is still a fair bit of "black magic" going on about what to do and how to package a project effectively. I think there is room for a documentation project aimed at developers about what needs to be done to create a project-x.y.z.tar.gz arcchive that can be grokked successfully by rpmbuild -ta.
A short way to do it:
1. edit project/Makefile.am add project.spec to EXTRA_DIST
2. edit project/configure.ac add project.spec to AC_OUTPUT(...)
3. edit spec in project/project.spec.in
4. release by issuing 'make dist'
Of course, this assumes an already working auto* project, which is probably the hardest part...
Rui
On Tue, 2004-01-27 at 12:09, Rui Miguel Seabra wrote:
On Tue, 2004-01-27 at 17:01, Cristian Gafton wrote:
One of the problems is that there is still a fair bit of "black magic" going on about what to do and how to package a project effectively. I think there is room for a documentation project aimed at developers about what needs to be done to create a project-x.y.z.tar.gz arcchive that can be grokked successfully by rpmbuild -ta.
A short way to do it:
edit project/Makefile.am add project.spec to EXTRA_DIST
edit project/configure.ac add project.spec to AC_OUTPUT(...)
edit spec in project/project.spec.in
release by issuing 'make dist'
Of course, this assumes an already working auto* project, which is probably the hardest part...
Works fine. But the problem comes when Fedora wants one spec and Mandrake wants another. As far as I can tell, if the developer provides specs, it is presently not really possible to be distribution agnostic, or even responsive to the various distributions, because they ofetn conflict.
On Tue, 2004-01-27 at 19:19, Karl DeBisschop wrote:
Works fine. But the problem comes when Fedora wants one spec and Mandrake wants another. As far as I can tell, if the developer provides specs, it is presently not really possible to be distribution agnostic, or even responsive to the various distributions, because they ofetn conflict.
Then tough luck. Unless distributions agree on a package naming convention, your SOL.
Rui
Rui Miguel Seabra wrote:
On Tue, 2004-01-27 at 19:19, Karl DeBisschop wrote:
Works fine. But the problem comes when Fedora wants one spec and Mandrake wants another. As far as I can tell, if the developer provides specs, it is presently not really possible to be distribution agnostic, or even responsive to the various distributions, because they ofetn conflict.
Then tough luck. Unless distributions agree on a package naming convention, your SOL.
I always thought the vendor-custom rpm macro issue to be more an issue than package naming.
Karl DeBisschop wrote:
Works fine. But the problem comes when Fedora wants one spec and Mandrake wants another. As far as I can tell, if the developer provides specs, it is presently not really possible to be distribution agnostic, or even responsive to the various distributions, because they ofetn conflict.
To some extent, this can be solved using various %ifdef constructions in spec file.
Kir Kolyshkin wrote:
To some extent, this can be solved using various %ifdef constructions in spec file.
How? AFAIK, there is no canonical way for the SPEC file to determine what distribution it is building on.
Ian Pilcher wrote:
Kir Kolyshkin wrote:
To some extent, this can be solved using various %ifdef constructions in spec file.
How? AFAIK, there is no canonical way for the SPEC file to determine what distribution it is building on.
If there's no canonical way or a clean solution, there is always space for ugly hacks...
Here's a short example for spec file working for various redhats and suses. Yes I know it's ugly. But you got the idea.
%if %_vendor == "redhat" # Define redhat-specific stuff here.
# If you want more precision, you can use the below define # %define rh_ver %(rpm -q --queryformat %{VERSION} redhat-release)
# The problem is nested %if's doesn't always work well, therefore %define suse_version 0 %endif
# The problem is %else doesn't work in all rpm versions, so avoid using it.
# SuSE guys made a good definition for us - so let's use it %if %suse_version = 820 # Define stuff specific for SuSE 8.2 %endif
%if %suse_version = 830 # Oh, things for SuSE 8.3 goes here %endif
On Wednesday 28 January 2004 00:55, Kir Kolyshkin wrote:
Ian Pilcher wrote:
Kir Kolyshkin wrote:
To some extent, this can be solved using various %ifdef constructions in spec file.
How? AFAIK, there is no canonical way for the SPEC file to determine what distribution it is building on.
If there's no canonical way or a clean solution, there is always space for ugly hacks...
Indeed, for example I'm using the attached shell script for adding a specific release tag when building binary packages for different rpm-based distributions.
The script is able to "detect" the following distros along with their versions: Red Hat/Fedora, Mandrake, Yellow Dog, UnitedLinux, SuSE.
But there will be a downside for this aproach: the spec files will be a little "bloated".
Mihai
Ian Pilcher wrote:
Kir Kolyshkin wrote:
To some extent, this can be solved using various %ifdef constructions in spec file.
How? AFAIK, there is no canonical way for the SPEC file to determine what distribution it is building on.
I see a var called "distribution" as well as "packager" and "vendor". Are they pervasively used?
Bryan W. Headley wrote:
I see a var called "distribution" as well as "packager" and "vendor". Are they pervasively used?
Not in an easily parseable manner.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Cristian Gafton wrote: | On Mon, 26 Jan 2004, Paul Heinlein wrote: | | |>Realistically, of course, third parties will continue to maintain |>packages for a variety of reasons: the upstream developers aren't |>interested in maintaining an rpm and/or the administrative files |>associated with it (init scripts, logrotate entries, sysconfig files, |>etc.) or the software is written for a different platform and requires |>significant porting. | | | One of the problems is that there is still a fair bit of "black magic" | going on about what to do and how to package a project effectively. I | think there is room for a documentation project aimed at developers about | what needs to be done to create a project-x.y.z.tar.gz arcchive that can | be grokked successfully by rpmbuild -ta. | | I know that very few folks contact the author and send them relevant spec | files, initscripts, logrotate files, etc after packaging something up.
Yes... this is true... as an example... the first spec file for nano (going way back) came from me. Most upstream dev's appreciate it if you contact them and make a submission.
- -- csm Lunar Linux Project Lead Disclaimer: "I am not a curmudgeon! No... really..." Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
On Mon, Jan 26, 2004 at 02:21:27PM +0100, Michael Schwendt wrote:
There must be developers and package maintainers [other than ESR] with precize ideas on how they would like to contribute packages. Similarly,
I can't speak for anyone else, but as an interested party with a few tens of packages to be unleashed (half of them Perl modules required by the main packages, *sigh*), I beg to differ with the above.
I really don't care how exactly packages are going to be contributed. All I care about is process automation. I have no time to waste filing Bugzilla entries manually, as you're supposed to do now with fedora.us. I'd rather spend whatever time I have on the actual packages, improving their quality. I know they still need attention.
I also have no time to argue whether to use CVS, SVN, Makefiles, Perl programs, shell scripts or anything else - as long as there's one quick and reliable procedure. Right now I build and maintain the packages in an automated fashion using my own shell scripts and Makefiles. I don't care what I am going to end up using; I expect having to adapt anyway. Just give me guidelines and a list of tools that work and that I can quickly install; I'll be happy with that.
But this is pretty much rehashing points from ESR's post from a few weeks ago. I'll let him, RH and anyone else working on the toolchain sort out the actual details. Hopefully the wait will be over soon.
Rudi
On Mon, 26 Jan 2004 18:43:41 +0100, Rudi Chiarito wrote:
There must be developers and package maintainers [other than ESR] with precize ideas on how they would like to contribute packages. Similarly,
I can't speak for anyone else, but as an interested party with a few tens of packages to be unleashed (half of them Perl modules required by the main packages, *sigh*),
Do these Perl modules install into vendor directories already? ;)
The fedora.us perl-MailTools spec fragment is a good example on clean Perl module packaging.
I beg to differ with the above.
Well, fine but that's not enough, since you do need to have expectations on how to interact with any people who may need to review and approve your package submissions.
I really don't care how exactly packages are going to be contributed. All I care about is process automation. I have no time to waste filing Bugzilla entries manually, as you're supposed to do now with fedora.us.
I'm also a fan of automization, but (1) you cannot automate everything, and (2) automization which saves one party time, should not increase the work-load for another party. So, afterall you must have precize ideas on how you would like to contribute packages. If, for instance, submitting automated package request tickets result in overloading the queue for reviewers or poor communication between packager and QA, that would be a bad thing. Automization seems suitable for people with commit-access to a build-system.
I'd rather spend whatever time I have on the actual packages, improving their quality. I know they still need attention.
Great! The weak part of the fedora.us system is, IMHO, that not all package maintainers like to spend time on improving packages. Or at least they have a completely different opinion on when a package is of fine or satisfactory quality.
On Mon, Jan 26, 2004 at 09:40:48PM +0100, Michael Schwendt wrote:
I'm also a fan of automization, but (1) you cannot automate everything, and (2) automization which saves one party time, should not increase the work-load for another party. So, afterall you must have precize ideas on how you would like to contribute packages. If, for instance, submitting automated package request tickets result in overloading the queue for reviewers or poor communication between packager and QA, that would be a bad thing. Automization seems suitable for people with commit-access to a build-system.
Remember that every perl package you generate means a package you have to handle bugs for and a package that may need a security audit and so on.
I agree CPAN in RPM has enormous value - providing people treat it like CPAN - ie with a lot of suspicion unles the module author is well known 8)
On Mon, 26 Jan 2004 15:47:23 -0500, Alan Cox wrote:
Remember that every perl package you generate means a package you have to handle bugs for and a package that may need a security audit and so on.
And this is not specific to perl packages. *Every* package needs an update some day or even a security fix and then requires resources to be available. At some point, a repository [or distribution] can only increase in size if more resources are available to handle it all.
On Mon, Jan 26, 2004 at 10:08:21PM +0100, Michael Schwendt wrote:
And this is not specific to perl packages. *Every* package needs an update some day or even a security fix and then requires resources to be available. At some point, a repository [or distribution] can only increase in size if more resources are available to handle it all.
Which is part of the idea of Fedora, isn't it?
On Mon, 2004-01-26 at 20:21, Michael Schwendt wrote:
There is one particular thing I don't understand. Once an arbitrary repository contains a new package, people don't hesitate to download and install it. When it's broken or not as usable as expected, they either downgrade or try the next repository (this experience is based on comments seen in message boards), repeating this procedure regularly. But when a package of the same software is in a public queue of packages to be reviewed before they get published, people avoid such packages like the plague and don't give the packages a try and don't leave feedback. I think the community can do better than that. But the Fedora community has a long road to take to realize that--like with the Debian GNU/Linux project--it's better to spend a combined effort on a primary source of reliable and maintained packages than to either want everything maintained by Red Hat in "Fedora Core" or to keep an excessive list of repositories maintained by individuals and live with interoperability problems.
Perhaps most users do not like to do the hard work of committing to QA a package without seeing it in action first?
If the CPU cycles could be spared to autobuild newly-submitted packages (under a chroot, and perhaps with a system that automatically notifies the packager when a build fails and ban him/her from further submitting new packages if X number of unbuildable packages are left unfixed), would-be testers could try out packages they are interested in, *then* review the spec.
This would have the added benefit of being certain that the package someone reviews has been known to compile in a pristine Fedora (+updates) environment. Otherwise there is the risk that a package would not build on someone's machine and that someone blamed the packaging.
My 2 cents,
- Michel
-
Alan Cox -
Alexander L. Belikoff -
Andy Green -
Bryan W. Headley -
Christopher M. smith -
Chuck Mead -
Cristian Gafton -
Florian La Roche -
George Garvey -
Ian Pilcher -
Karl DeBisschop -
Kir Kolyshkin -
Matthew Miller -
Michael Schwendt -
Michel Alexandre Salim -
Michel Alexandre Salim -
Mihai Maties -
Mike Chambers -
Pau Aliagas -
Paul Heinlein -
Rik van Riel -
Rudi Chiarito -
Rui Miguel Silva Seabra -
seth vidal -
Tim Daly -
Tyler Larson -
Warren Togami -
Warren Togami