Eric S. Raymond wrote:
These both seem like readily solvable problems to me.
I'm of the opinion that some issues are complex enough to allow for perfectly valid and completely opposite points of view. And I'm also of the opinion that some issues are dominated more by historical precedent and "i was here first, automatically respect my claim on mindshare in this space" attitudes than on sound logic and a willingness to compromise on arguable less important priorities to meet the most important priorities. And I'm of the opinion that sometimes people just can not agree on what the priorities are.
So lets get down to to it shall we? Let's look at the history of the repository space. Red Hat, in the past, for reasons of their own, have neglected to foster any sort of policy or guidelines about how 3rd party repositories should be structured. As a result what sprang up has been a very fractured collection of one person or very small group efforts to provide a needed community service to provide additional packages to the userbase. Some have become quite popular and to their credit became popular because they did indeed have a measure of quality in their packaging that the userbase grew to respect..but the fact is, it was a very fractured landscape, leading to real package conflict problems across repositories, and end-user difficulties when trying to reach out and get all the packages they wanted, from multiple repos. I would describe the situation as loosely related bands of nomadic tribes of packages. Sometimes their were inter-tribal marriages and sometimes there where blood feuds.
I'm not going to take anything away from someone who is able to build 500 packages and place them into a repository and build a userbase. That is an accomplishment of merit. But its not a community effort. 2 such people who have the ability to build their own 500 package repository as they see fit is not a community...neither is 5 or 10 or 20 or 40 or 17 billion. A community effort MUST have guidelines and policies to follow and their MUST be peer review, and a sense that interested people can walk into the process and learn how to be active in it, a way to mentor such people and teach them how to do things in the best ways following best practices and a sense that they can earn a place in the process. There needs to be a sense that if one person steps out of the process for whatever reason the community effort will continue. There must be a sense that everyone involved is valued...but not indispensable. An archipelago of one man repositories doesn't really convey this sort of sense of community. If for some reason, god forbid, Dag had to stop producing packages for personal reasons, that's a big blow to the archipelago concept since there are no written policies that I know of that others can follow to reproduce what he has accomplished.
I'm not a scholar of the history, but the first noteworthy example I noticed of defining ANY packaging and QA standard for Red Hat rpm repos was fedora.us. It's pretty clear to me that fedora.us policy that we see now, has prioritized around the concept of building an actual community process that in the long run can be reproduced and re-implemented from the written policy guidelines....and not from a cult of personality.
And now we come to the crux of the issue. Coming to a consensus among ALL the interested parties about what the actually priorities are in the process pretty much defines what the packaging community is going to look like: How transparent do the QA processes NEED to be? How much input from the community does there NEED to be? How hard do you want to try to make sure all the packages meet the same level of quality? How important is it to make sure all the packagers are using common conventions and best practices when writing build scripts?
And i see the current split in the world views as coming down to prioritizing the first couple of questions in the list. Fedora.us ranks transparent QA and the NEED (not just a token desire) for community input on how packages are built very highly. I don't see the one man repository islands making these things a priority. And thus, the discussion can not get past that split in world views. If people in the discussion can not agree on the priorities...there is a clear difference of opinion at the basic level of belief at how the world is suppose to work. Pretending that you can get people who have VASTLY different priorities to come together for a consensus is a foolish naive dream. I'm pretty sure its been stated already somewhere in the fedora lists, that there was internal Red Hat debate about joining debian, but because the list of priorities as Red Hat understood them differed significantly from the priorities debian has...we have the Fedora effort instead.
And in a not so dissimilar way, we stand now with 2 opposing view about what community packaging should look like. The pre-existing archipelago of one made repos loosely working together with community input welcome but not really necessarily. And the 'new' concept of fedora.us which places a HIGH value on making community involvement as part of the packaging process a priority. Different world views....and i would strongly argue that a continued refinement of how fedora.us tries to do things is in the long run the stronger more robust community process. A process that not only creates high quality packages, but provides a clear way for new and interested community participants to get engaged and invovled and to mentor them so they learn via communication with other community members how to do packaging better. It provides strong lines of communication so that best practices in regard to how to package things are not horded by the 'professionals' as a secret sauce knowledge but focuses instead of making it possible to document those best practices so that new people can learn them.
Is there room for improvement on how the fedora.us policies work... of course. But to make constructive forward looking changes to the process, you have to value the core objectives that the fedora.us process is trying to meet. And in my mind the core objective for the fedora.us process is not to package up the world as quickly as possible...the focus is on building and documenting a community process for building high quality packages that other people can follow and use as a guideline. And I personally think if the new Fedora Extras process doesn't continue to make transparent QA a priority...and doesn't continue to demand community involvement as part of the packaging process, but instead allows 'trusted' packagers to do whatever they want without peer review....the overall Fedora effort will be losing a very good process for educating and mentoring NEW community members who want to get involved with packaging. A community process NEEDS to be as much about educating and mentoring NEW community members so they can continue on with the work..as it is producing a work at all.
-jef"and that was me trying to be nice..."spaleta
On Thu, Jan 08, 2004 at 12:14:24AM -0500, Jef Spaleta wrote:
And I personally think if the new Fedora Extras process doesn't continue to make transparent QA a priority...and doesn't continue to demand community involvement as part of the packaging process, but instead allows 'trusted' packagers to do whatever they want without peer review....the overall Fedora effort will be losing a very good process for educating and mentoring NEW community members who want to get involved with packaging. A community process NEEDS to be as much about educating and mentoring NEW community members so they can continue on with the work..as it is producing a work at all.
Very well said. I agree 100%.
On Thu, 08 Jan 2004 00:14:24 -0500, Jef Spaleta wrote:
I'm not going to take anything away from someone who is able to build 500 packages and place them into a repository and build a userbase.
But is it a userbase that uses all 500 packages? Or is it a userbase that uses only a fraction of the available packages? IMHO, it is the latter. If Joe User is smart enough to install and configure a package tool to point it to one repository, he's also smart enough to point it to a different repository in case the former one provides a non-working package. Don't count on Joe User to take the time and submit a bug report by private mail or via a mailing-list. He would rather proceed and try an alternative package or downgrade or build from tarball. It's a similar scenario when Joe looks for a newer version. If repo X doesn't include it, he takes it from repo Y. If he's courageous enough at all, he posts in a web-based message board and is pointed to an arbitrary package offered at some site which is reported as working. It is a common attitude that plain users expect the developers to fix problems automatically, disregarding the possibility that the developers might not even know about a problem.
If for some reason, god forbid, Dag had to stop producing packages for personal reasons, that's a big blow to the archipelago concept since there are no written policies that I know of that others can follow to reproduce what he has accomplished.
Excellent example. One can argue whether all of Dag's tools are available and documented and whether someone could mirror the src.rpms and take over the repository in such a case. But one would still need to duplicate the infrastructure, the man-power and the commitment which is required to maintain all that.
And now we come to the crux of the issue. Coming to a consensus among ALL the interested parties about what the actually priorities are in the process pretty much defines what the packaging community is going to look like: How transparent do the QA processes NEED to be?
QA is a _huge_ problem, in particular if there is no complete list of what to check, but also if there is a list and reviewers go through it step by step and don't develop a feeling for what other issues could be important. Package reviewers have a very different point of view with regard to package quality. Some would want to actually test-drive the built software for an extensive time while others would concentrate on technical details.
How much input from the community does there NEED to be?
Certainly bug reports, RFEs and communication/feedback from users.
How hard do you want to try to make sure all the packages meet the same level of quality?
Define "quality".
How important is it to make sure all the packagers are using common conventions and best practices when writing build scripts?
The user doesn't care about technical issues, such as spec files or included patches and integration work. But if multiple developers are supposed to maintain a package, they better agree on how to package everything.
Fedora.us supplies a spec file template. A skeleton of how an initial spec could/should look like and what is considered readable and clear. But it should not be misunderstood to such a degree that upon minor package upgrades, packagers start changing indentation style and order of spec file fields to match the latest template closely.
Packaging is not "art", it is an engineering task. We should focus on packaging software correctly, not on beautifying a build script. We should avoid trying to be overly smart and not use lots of macros or conditionals to make a package build on more than our target platforms. Spec files should contain comments where it helps to understand the process of setting up and building a piece of software.
On Thu, Jan 08, 2004 at 07:47:02AM +0100, Michael Schwendt wrote:
Packaging is not "art", it is an engineering task. We should focus on packaging software correctly, not on beautifying a build script.
I'm glad I'm not the only one who feels like this. My earlier "pain in the ass" comment about getting packages in fedora.us mostly came as a result of someone commenting on one of my perl module packages, saying it didn't match the templates and should be redone.
I only have two complaints about the fedora.us QA process right now. As near as I can tell, the only review that has happened of any of the packages I've submitted so far has been a couple of people picking apart my spec files for issues of style, not correctness. Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
My only other complaint, and it really is more of a suggestion, is that it would be *really* nice if the easy things (like "does this package build") were automated. It would be *really* nice if the automatically-built packages were put into a repository (accompanied by USE AT YOUR OWN RISK warnings) that reviewers could download and test from. At that point it becomes almost zero effort for interested people (like me) to install a package on a test box and let it run for a while.
Steve
On Thursday 08 January 2004 18:32, Steven Pritchard wrote:
On Thu, Jan 08, 2004 at 07:47:02AM +0100, Michael Schwendt wrote:
Packaging is not "art", it is an engineering task. We should focus on packaging software correctly, not on beautifying a build script.
I'm glad I'm not the only one who feels like this. My earlier "pain in the ass" comment about getting packages in fedora.us mostly came as a result of someone commenting on one of my perl module packages, saying it didn't match the templates and should be redone.
I only have two complaints about the fedora.us QA process right now. As near as I can tell, the only review that has happened of any of the packages I've submitted so far has been a couple of people picking apart my spec files for issues of style, not correctness. Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
Absolutely, a working package is far more important than a beautyful spec file.
My only other complaint, and it really is more of a suggestion, is that it would be *really* nice if the easy things (like "does this package build") were automated. It would be *really* nice if the automatically-built packages were put into a repository (accompanied by USE AT YOUR OWN RISK warnings) that reviewers could download and test from. At that point it becomes almost zero effort for interested people (like me) to install a package on a test box and let it run for a while.
IMHO this auto-built repository is the only testing repository needed. People could test packages from there and than vote for inclusion in "stable" repo. This would simplify QA in a great way. The difference between "testing" and "unstable" is far from obvious and two testing repositories are really not needed.
On Thu, 2004-01-08 at 13:01, Ronny Buchmann wrote:
On Thursday 08 January 2004 18:32, Steven Pritchard wrote:
My only other complaint, and it really is more of a suggestion, is that it would be *really* nice if the easy things (like "does this package build") were automated. It would be *really* nice if the automatically-built packages were put into a repository (accompanied by USE AT YOUR OWN RISK warnings) that reviewers could download and test from. At that point it becomes almost zero effort for interested people (like me) to install a package on a test box and let it run for a while.
IMHO this auto-built repository is the only testing repository needed. People could test packages from there and than vote for inclusion in "stable" repo. This would simplify QA in a great way.
It took me a while to see this, but there really is a need for a two step QA/testing process -- at least when you involve an autobuilder: Pre-build: Check for trojans and compromise attempts. Auto-Builder: Does it build? Post-build: Check for proper operation of program.
You have to check the package for possible compromises of your autobuilder before you send it to be built.
What makes things interesting is that package QA consists of additional checks (look for unintentional security holes, check for enabled features at build time, spec file is "well engineered", secure default configuration, etc) as well. In fedora.us, these are done pre-autobuilder as well. I suppose the rationale for that could be, we have to take a look at the spec/patches/source/build to make sure the package isn't going to crack our autobuilder so we might as well do these other checks while we're at it.
=== There could be parallel testing of package security and package functionality if the tester received the prebuilt binary from the package author (AT YOUR OWN RISK). I'm not currently prepared to decide whether that would be a good idea or undermine the idea of QA, though....
-Toshio
Toshio wrote:
On Thu, 2004-01-08 at 13:01, Ronny Buchmann wrote:
On Thursday 08 January 2004 18:32, Steven Pritchard wrote:
My only other complaint, and it really is more of a suggestion, is that it would be *really* nice if the easy things (like "does this package build") were automated. It would be *really* nice if the automatically-built packages were put into a repository (accompanied by USE AT YOUR OWN RISK warnings) that reviewers could download and test from. At that point it becomes almost zero effort for interested people (like me) to install a package on a test box and let it run for a while.
IMHO this auto-built repository is the only testing repository needed. People could test packages from there and than vote for inclusion in "stable" repo. This would simplify QA in a great way.
It took me a while to see this, but there really is a need for a two step QA/testing process -- at least when you involve an autobuilder: Pre-build: Check for trojans and compromise attempts.
This isn't that difficult. At Mandrake a diff of the changes (patches and .spec file) are put into the e-mail announcing the change. This gives the reader a quick & clear overview of what has changed. For the sources I would say: let the automated rebuild download them from the original place, and check the signatures.
Auto-Builder:
Check out SlBd: http://qa.mandrakesoft.com/twiki/bin/view/Main/SlBd at Mandrake this tool is used to automatically rebuild the ports (alpha, amd64, sparc and sparc64).
Does it build? Post-build: Check for proper operation of program.
You have to check the package for possible compromises of your autobuilder before you send it to be built.
What makes things interesting is that package QA consists of additional checks (look for unintentional security holes, check for enabled features at build time, spec file is "well engineered", secure default configuration, etc) as well. In fedora.us, these are done pre-autobuilder as well. I suppose the rationale for that could be, we have to take a look at the spec/patches/source/build to make sure the package isn't going to crack our autobuilder so we might as well do these other checks while we're at it.
=== There could be parallel testing of package security and package functionality if the tester received the prebuilt binary from the package author (AT YOUR OWN RISK). I'm not currently prepared to decide whether that would be a good idea or undermine the idea of QA, though....
-Toshio
On Thu, 2004-01-08 at 14:05, Stefan van der Eijk wrote:
Toshio wrote:
It took me a while to see this, but there really is a need for a two step QA/testing process -- at least when you involve an autobuilder: Pre-build: Check for trojans and compromise attempts.
This isn't that difficult. At Mandrake a diff of the changes (patches and .spec file) are put into the e-mail announcing the change. This gives the reader a quick & clear overview of what has changed. For the sources I would say: let the automated rebuild download them from the original place, and check the signatures.
This isn't secure. If I, the packager, am trying to crack your autobuilder, I can use a Source0: http://cracks.com/autorootkit-1.0.tar.gz whose "make all" tries to crack the machine. A human needs to take at look at the package to filter out active attempts to compromise the build machine.
An even more insidious compromise could be: source0: http://www.not-apache-org.com/apache-2.0.48.tar.gz which builds a http server with intentional security holes. One hopes that a QA reviewer would see that the package came from a non-canonical location but in the case of lesser known software, this kind of Trojan could get all the way to an end-user's computer....
Hmmm... Email diffs could be useful when a package was an update of a previous package. Hopefully, someone would notice that the "canonical" Source URL had changed.... Perhaps having the autobuilder not build new packages or packages with new Source URLs (hosts?) without having peer review done first would be sufficient?
toshio@tiki-lounge.com (Toshio) writes:
This isn't secure. If I, the packager, am trying to crack your autobuilder, I can use a Source0: http://cracks.com/autorootkit-1.0.tar.gz
A buildsystem MUST resist against such attacks. See the "upstream author" part in
http://www.tu-chemnitz.de/~ensc/fedora.us-build/html/index.html
Despite this, there must be made some precautions to limit effects of exploits. Recent events do not give me a good feeling regarding Linux's resistance against local exploits.
Enrico
Toshio wrote:
On Thu, 2004-01-08 at 14:05, Stefan van der Eijk wrote:
Toshio wrote:
It took me a while to see this, but there really is a need for a two step QA/testing process -- at least when you involve an autobuilder: Pre-build: Check for trojans and compromise attempts.
This isn't that difficult. At Mandrake a diff of the changes (patches and .spec file) are put into the e-mail announcing the change. This gives the reader a quick & clear overview of what has changed. For the sources I would say: let the automated rebuild download them from the original place, and check the signatures.
This isn't secure. If I, the packager, am trying to crack your autobuilder, I can use a Source0: http://cracks.com/autorootkit-1.0.tar.gz whose "make all" tries to crack the machine. A human needs to take at look at the package to filter out active attempts to compromise the build machine.
Fair. But having a user submit a src.rpm is even worse. It's better to let the rebuilding bot download it, eventhough it may be fooled this way. At least you can trace back when something went wrong --> better audit trails.
Of course, if the source is already in the repository, there is no need to get a new copy.
An even more insidious compromise could be: source0: http://www.not-apache-org.com/apache-2.0.48.tar.gz which builds a http server with intentional security holes. One hopes that a QA reviewer would see that the package came from a non-canonical location but in the case of lesser known software, this kind of Trojan could get all the way to an end-user's computer....
Hmmm... Email diffs could be useful when a package was an update of a previous package.
That's how it's done at Mandrake. I can forward one of their changelog e-mails as an example.
Hopefully, someone would notice that the "canonical" Source URL had changed.... Perhaps having the autobuilder not build new packages or packages with new Source URLs (hosts?) without having peer review done first would be sufficient?
My experience is that doing a peer review first is difficult. You won't get that many eyeballs, and the eyeballs that should be doing the (boring?) job will get tired and let things through.
Better is to: - make the process as transparent as possible - have good audit trails in place - and be able to roll-back a change at any time.
of course, easier said than done.
regards,
Stefan
On Thu, Jan 08, 2004 at 03:04:15PM -0500, Toshio wrote:
Source URL had changed.... Perhaps having the autobuilder not build new packages or packages with new Source URLs (hosts?) without having peer review done first would be sufficient?
You could still have the package served by a CGI that returns a malicious version of the archive if and only if being fetched from the host(s) the autobuilder runs on, while handing everyone else the benign version.
Rudi
On Thu, 8 Jan 2004 19:01:11 +0100, Ronny Buchmann wrote:
My only other complaint, and it really is more of a suggestion, is that it would be *really* nice if the easy things (like "does this package build") were automated. It would be *really* nice if the automatically-built packages were put into a repository (accompanied by USE AT YOUR OWN RISK warnings) that reviewers could download and test from. At that point it becomes almost zero effort for interested people (like me) to install a package on a test box and let it run for a while.
IMHO this auto-built repository is the only testing repository needed. People could test packages from there and than vote for inclusion in "stable" repo. This would simplify QA in a great way.
Except that it doesn't make technical reviews superfluous. To build a binary package you could also use a tool like checkinstall and be done. But for a src.rpm to be maintainable or "correct", a second or even third pair of eyes sometimes does wonders. Once a package has been published in "stable", it may be too late [or unclean] to fix some issues that have been missed by testing prebuilt binaries only.
The difference between "testing" and "unstable" is far from obvious and two testing repositories are really not needed.
Agreed, except that the split between testing and unstable is a bit more cautious than putting software which is known to crash randomly into "testing".
On Thu, 8 Jan 2004 11:32:12 -0600, Steven Pritchard wrote:
On Thu, Jan 08, 2004 at 07:47:02AM +0100, Michael Schwendt wrote:
Packaging is not "art", it is an engineering task. We should focus on packaging software correctly, not on beautifying a build script.
I'm glad I'm not the only one who feels like this. My earlier "pain in the ass" comment about getting packages in fedora.us mostly came as a result of someone commenting on one of my perl module packages, saying it didn't match the templates and should be redone.
Could be that I've seen that comment, too, recently. I don't remember right now. Feel free to add "rh0212ms@arcor.de" to the Cc field, though I cannot promise to work on it soon due to time constraints.
I only have two complaints about the fedora.us QA process right now. As near as I can tell, the only review that has happened of any of the packages I've submitted so far has been a couple of people picking apart my spec files for issues of style, not correctness. Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
Where necessary, I like to point out that some comments during a package review are _recommendations_ (suggestions) and not blocker criteria. When "must fix" issues are found, that is the chance to add some improvements which are considered good packaging practise. Or if a package summary is wrong or a description contains many errors or if the package includes makefiles or executable documentation files, I don't really see why to not fix such minor issues sooner than later [or forget about them and make a package appear sloppy].
I think some requirements, such as a standard Buildroot definition, look a bit unfortunate, but are due to the current build system and human resources performing the builds.
--
steve@silug.org (Steven Pritchard) writes:
Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
The current fedora.us way were only positively reviewed packages are published is the right one.
My only other complaint, and it really is more of a suggestion, is that it would be *really* nice if the easy things (like "does this package build") were automated.
Agreed, but there is infrastructure missing for fedora.us to provide such a service. I am not sure if it would be worth to spent time into the implementation of a package-database + improved QA methods, since Red Hat never told its requirements. So it may be, that they are saying "nice work, but in the last months we developed our own methods/tools which are obsoleting yours", or "your stuff is voilating our ideas and can not be used for Fedora Extras".
It would be *really* nice if the automatically-built packages were put into a repository (accompanied by USE AT YOUR OWN RISK warnings) that reviewers could download and test from. At that point it becomes almost zero effort for interested people (like me) to install a package on a test box and let it run for a while.
Current fedora.us procedure implements the reverse way: at first, QA people are doing functionality and buildtests (inclusive spec-file auditing), a testpackage will be built and packager has to verify it.
Perhaps, the first stage should be shortened to buildtests and spec-file auditing only. Then the verification phase should be replaced by a second cycle which is doing QA tests only.
But I am not sure if this would shorten the QA process... ;)
Enrico
On Thursday 08 January 2004 20:56, Enrico Scholz wrote:
steve@silug.org (Steven Pritchard) writes:
Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone or they didn't really exist or the reporter has no real interest in it. None would be a reason not to publish the package for testing. Testing is not for the faint of heart. Why should Fedora Extras testing be more stable than Fedora Core testing (aka Rawhide)?!
ronny-vlug@vlugnet.org (Ronny Buchmann) writes:
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone
A basic package like 'procps' is broken for nearly two months already...
or they didn't really exist or the reporter has no real interest in it.
What can a reporter do? Shall he setup a cronjob which enters "problem still exists" comments regularly?
But it is true; when a bug is ignored in rawhide for a certain time I begin to use workarounds and can not answer later questions since reproducing the problem would lead to painful reconfigurations.
None would be a reason not to publish the package for testing.
'testing' in fedora.us terminology means: "I am not sure if it is stable or unstable". Coming back to 'procps': this package is neither stable nor unstable, just unusable and should never have entered a public repository.
I remember other packages like sudo or vixie-cron which were given in the same, non-functional state into rawhide.
Therefore it is important that there is a QA which tests packages before they will be published at a public place.
Testing is not for the faint of heart. Why should Fedora Extras testing be more stable than Fedora Core testing (aka Rawhide)?!
Because packages will stay there forever (like in the current fedora.us QA queue) and people will begin to use this repository by default. And rawhide like repositories are nothing for Joe User...
Enrico https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110263
On Friday 09 January 2004 01:42, Enrico Scholz wrote:
ronny-vlug@vlugnet.org (Ronny Buchmann) writes:
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone
A basic package like 'procps' is broken for nearly two months already...
in Extras you could fix it yourself and your (newer) package would eventually be voted to stable
or they didn't really exist or the reporter has no real interest in it.
What can a reporter do? Shall he setup a cronjob which enters "problem still exists" comments regularly?
this may sometimes help ;) but for Extras this is (would be) different, see above
But it is true; when a bug is ignored in rawhide for a certain time I begin to use workarounds and can not answer later questions since reproducing the problem would lead to painful reconfigurations.
None would be a reason not to publish the package for testing.
'testing' in fedora.us terminology means: "I am not sure if it is stable or unstable". Coming back to 'procps': this package is neither stable nor unstable, just unusable and should never have entered a public repository.
I remember other packages like sudo or vixie-cron which were given in the same, non-functional state into rawhide.
The problem is not the non-functional state, but that nobody in the position to make a new package feels the urgent need to do so. I hope this will change sometime. For Extras this is already now a different situation. Everybody can make a new package.
Therefore it is important that there is a QA which tests packages before they will be published at a public place.
Testing is not for the faint of heart. Why should Fedora Extras testing be more stable than Fedora Core testing (aka Rawhide)?!
Because packages will stay there forever (like in the current fedora.us QA queue) and people will begin to use this repository by default. And rawhide like repositories are nothing for Joe User...
If package QA is fast and easy (I think voting would be good) they will not stay in testing. Voting can also be based on spec file style. Some Vetoing would be useful to stop clear bugs in the spec.
On Fri, 9 Jan 2004 09:22:20 +0100, Ronny Buchmann wrote:
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone
A basic package like 'procps' is broken for nearly two months already...
in Extras you could fix it yourself and your (newer) package would eventually be voted to stable
No. Don't expect Extras to be permitted to upgrade Core. There won't be competition between Extras and Core. Extras are really just add-ons.
On Fri, 9 Jan 2004, Michael Schwendt wrote:
On Fri, 9 Jan 2004 09:22:20 +0100, Ronny Buchmann wrote:
in Extras you could fix it yourself and your (newer) package would eventually be voted to stable
No. Don't expect Extras to be permitted to upgrade Core. There won't be competition between Extras and Core. Extras are really just add-ons.
I think what Ronny wants is the Fedora Alternatives project (which is planned but not yet implemented).
-- Elliot At the School of Hard Knocks, tuition is always high.
On Fri, 9 Jan 2004 10:06:25 -0500 (EST), Elliot Lee wrote:
On Fri, 9 Jan 2004, Michael Schwendt wrote:
On Fri, 9 Jan 2004 09:22:20 +0100, Ronny Buchmann wrote:
in Extras you could fix it yourself and your (newer) package would eventually be voted to stable
No. Don't expect Extras to be permitted to upgrade Core. There won't be competition between Extras and Core. Extras are really just add-ons.
I think what Ronny wants is the Fedora Alternatives project (which is planned but not yet implemented).
Except for fedora.us' "patches" repository.
On Fri, 9 Jan 2004, Michael Schwendt wrote:
On Fri, 9 Jan 2004 09:22:20 +0100, Ronny Buchmann wrote:
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone
A basic package like 'procps' is broken for nearly two months already...
in Extras you could fix it yourself and your (newer) package would eventually be voted to stable
No. Don't expect Extras to be permitted to upgrade Core. There won't be competition between Extras and Core. Extras are really just add-ons.
Yep, Extras can never get into way of Core. Packages that replace things in Core are allowed in Fedora Alternatives however.
- Panu -
On Friday 09 January 2004 15:59, Michael Schwendt wrote:
On Fri, 9 Jan 2004 09:22:20 +0100, Ronny Buchmann wrote:
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone
A basic package like 'procps' is broken for nearly two months already...
in Extras you could fix it yourself and your (newer) package would eventually be voted to stable
No. Don't expect Extras to be permitted to upgrade Core. There won't be competition between Extras and Core. Extras are really just add-ons.
Oh, I didn't mean this specific case.
I meant if procps were in Extras (not Core) you could fix it yourself.
But I hope it will be possible for non-RH people to contribute to Core also (so that i.e. you could fix procps).
On Fri, Jan 09, 2004 at 10:28:01PM +0100, Ronny Buchmann wrote:
But I hope it will be possible for non-RH people to contribute to Core also (so that i.e. you could fix procps).
Yes, that is the intent. The differentiation between Core and Extras is not who works on it, but characterization of the software. There will be Red Hat folks working on some Extras, I'm sure, and external folks who can work on Core.
michaelkjohnson
"He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/
Le ven 09/01/2004 à 00:50, Ronny Buchmann a écrit :
On Thursday 08 January 2004 20:56, Enrico Scholz wrote:
steve@silug.org (Steven Pritchard) writes:
Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone or they didn't really exist or the reporter has no real interest in it.
Or the reporter has no wish to make a pest of himself. I've personally open enough bugzilla entries in different systems over the years to be confident my reports can be exploited. When I open a bug I follow it and answer whatever questions the developer has. Now more than once I had questions asked after I opened a bug, and nothing happened after I answered them (sometimes just a few hours after they were submitted).
At this point I won't waste my time prodding the developer anymore. Hell, by the time I've written up a report I usually have one or two ugly workarounds I'm making use of. I'm usually not opening bugs because I'm stuck. I'm opening them to improve the overall Fedora/Red Hat quality because I'm grateful for the service they provide, and I don't pay for the systems I install on my personal computers. It's up to the distribution QA to follow up on my reports. If they choose not to do it, I certainly won't try to force them.
(and when I can't follow on a bug I write it but this only happened to me once or twice so far)
Cheers,
On Friday 09 January 2004 10:43, Nicolas Mailhot wrote:
Le ven 09/01/2004 à 00:50, Ronny Buchmann a écrit :
On Thursday 08 January 2004 20:56, Enrico Scholz wrote:
steve@silug.org (Steven Pritchard) writes:
Personally, I think style issues should be reserved for *after* any package has made it into testing, at least.
No, when a package is in a public repository it is too late. People will begin to use this repository as default one since it has lots of cool packages. Since packages are already published, bugreports will have a low priority for the packagers and bugs stay forever (rawhide is a good example).
I don't think this is a problem. When rawhide bugs are not maintained this mostly means they are gone or they didn't really exist or the reporter has no real interest in it.
Or the reporter has no wish to make a pest of himself. I've personally open enough bugzilla entries in different systems over the years to be confident my reports can be exploited. When I open a bug I follow it and answer whatever questions the developer has. Now more than once I had questions asked after I opened a bug, and nothing happened after I answered them (sometimes just a few hours after they were submitted).
At this point I won't waste my time prodding the developer anymore. Hell, by the time I've written up a report I usually have one or two ugly workarounds I'm making use of. I'm usually not opening bugs because I'm stuck. I'm opening them to improve the overall Fedora/Red Hat quality because I'm grateful for the service they provide, and I don't pay for the systems I install on my personal computers. It's up to the distribution QA to follow up on my reports. If they choose not to do it, I certainly won't try to force them.
(and when I can't follow on a bug I write it but this only happened to me once or twice so far)
Yes, current RH bugzilla can be really annoying. But we are discussing about fedora.us / the future.
ronny