Re: RPM submission procedure
by Jef Spaleta
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
20 years, 5 months
CUPS freezing on boot-up when using SMP kernel
by lee connell
I am using the fedora 2.4 kernel and I have a P4 HT processor. In order to
boot into SMP I have to boot it with the option acpi=on for thread safety.
Now my issue is that when booting the SMP kernel, when it trys to start
CUPS, it locks the whole system down and is unresponsive. So I decided to
stop CUPS from starting and then it froze on another service at startup.
Any ideas on what's going on?
Thanks
_________________________________________________________________
Working moms: Find helpful tips here on managing kids, home, work and
yourself. http://special.msn.com/msnbc/workingmom.armx
20 years, 5 months
Re: QA process was Re: RPM submission procedure
by Jef Spaleta
Karl DeBisschop wrote:
> If packagers from different distros eschew that tpe of
> cooperation, then the developer either sees silence or a "do
> things my way because that's our policy" from 20 different camps
> pulling the project in all different ways.
I'm confused..
Do you want policy and guidelines or a free4all?
Because as it stands right I'm not aware of stated guidelines for
'community' packaging beyond the efforts at fedora.us and jpackage
to document a process that other people can pick up and use.
What appears to be happening at the moment are a lots of little
of different ways of packaging are in use...but nobody is actually
documenting those practices..they are all some form of evolved mess of
'this works for us' and 'this is what we are using.'
You want to get to a distro agnostic packaging standard...the distros
need to layout a guidelines for how packaging is being done right now,
and start making sure their own packages conform to that documented
system. Then everyone can sit down and compare notes...and start working
towards a common specification. This is not a working from scratch
situation...there must be an effort to document the current practices,
then we can talk about making a best effort attempt at defining a
comprehensive set of 'best practices'.
If you are serious about support an agnostic effort than you will
package for projects that have stated packaging guidelines and shun
situations that do not make an effort to document how its suppose to
work.
-jef"to quote someone else 'its about showing people how to do
it....'"spaleta
20 years, 5 months
rawhide report: 20040109 changes
by Build System
Removed package redhat-config-boot
Removed package imap
Updated Packages:
alchemist-1.0.30-1
------------------
* Thu Jan 08 2004 Tim Waugh <twaugh(a)redhat.com> 1.0.30-1
- Fix several accidental bitwise operations.
- Unnest a function (bug #110691).
apr-util-0.9.4-5
----------------
* Thu Jan 08 2004 Joe Orton <jorton(a)redhat.com> 0.9.4-5
- fix DB library detection
cups-1.1.20-2
-------------
* Wed Jan 07 2004 Tim Waugh <twaugh(a)redhat.com> 1:1.1.20-2
- Try harder to find a translated page for the web interface (bug #107619).
- Added build_as_pie conditional to spec file to facilitate debugging.
eruby-1.0.5-1
-------------
* Fri Jan 09 2004 Akira TAGOH <tagoh(a)redhat.com> 1.0.5-1
- New upstream release.
fedora-release-0.96-1
---------------------
gawk-3.1.3-5
------------
* Fri Jan 09 2004 Florian La Roche <Florian.LaRoche(a)redhat.de>
- add a "make check"
gdb-6.0post-0.20031117.7
------------------------
* Thu Jan 08 2004 Elena Zannoni <ezannoni(a)redhat.com> 0.20031117.7
- Add fixes for ppc32 support on ppc64 platform, from Andrew Cagney.
* Tue Jan 06 2004 Elena Zannoni <ezannoni(a)redhat.com> 0.20031117.6
- Add patch to have unique binary names in the testsuite.
- Disable s390/s390x pthread.exp test (FIXME)
- Don't install any info files for the ppc platform. Let's take them
from the ppc64 one (or we get install conflicts).
- Remove generated info files from the source tree. They are generated
as part of the FSF snapshot process.
* Mon Nov 24 2003 Elena Zannoni <ezannoni(a)redhat.com> 0.20031117.5
- Add patches from old rpm for i386 support on x86_64.
- Add build dependency on libunwind for ia64.
gedit-2.4.0-4
-------------
* Thu Jan 08 2004 Dan Williams <dcbw(a)redhat.com> 1:2.4.0-4
- Remeber file selector size and last directory on open/save
(gnome.org #123787)
- Small hack to work around switch from autotools 1.7 - 1.8
im-sdk-11_4-4
-------------
* Fri Jan 09 2004 Yu Shao <yshao(a)redhat.com> r11_4-4
- fixed packages requirements
kdebase-3.1.94-0.4
------------------
* Thu Jan 08 2004 Than Ngo <than(a)redhat.com> 6:3.1.94-0.4
- added kdebase-3.1.94-kpersonalizer.patch (bluecurve as default)
kinput2-v3.1-13
---------------
* Thu Jan 08 2004 Akira TAGOH <tagoh(a)redhat.com> v3.1-13
- kinput2-v3.1-Xsji3clib-fix-typo.patch: applied a patch from Dave Jones to fix a typo.
* Wed Nov 05 2003 Akira TAGOH <tagoh(a)redhat.com> v3.1-12.EL
- rebuilt
lm_sensors-2.8.2-1
------------------
* Thu Jan 08 2004 Phil Knirsch <pknirsch(a)redhat.com> 2.8.2-1
- Update to latest upstream version 2.8.2
- Fixed wrong & usage in if expression.
- Included several new perl tools.
mkinitrd-3.5.18-1
-----------------
* Thu Jan 08 2004 Jeremy Katz <katzj(a)redhat.com> 3.5.18-1
- new-kernel-pkg: add a --kernel-arguments option (#113125)
nvi-m17n-1.79-20011024.16
-------------------------
* Thu Jan 08 2004 Akira TAGOH <tagoh(a)redhat.com> 1.79-20011024.16
- rebuilt
pccts-1.33mr33-7
----------------
* Thu Jan 08 2004 Karsten Hopp <karsten(a)redhat.de> 1.33mr33-7
- add fix from Dave Jones
policy-1.4.5-1
--------------
* Sat Jan 08 2005 Dan Walsh <dwalsh(a)redhat.com> 1.4.4-4
- First version of minimal policy
* Wed Jan 07 2004 Dan Walsh <dwalsh(a)redhat.com> 1.4.4-3
- Add My own mods
* Wed Jan 07 2004 Dan Walsh <dwalsh(a)redhat.com> 1.4.4-2
- Add run daemon patch
rpm-4.3-0.6
-----------
* Mon Jan 05 2004 Jeff Johnson <jbj(a)redhat.com> 4.2-0.6
- selinux phases 1 and 2 delivered.
* Tue Dec 23 2003 Jeff Johnson <jbj(a)redhat.com> 4.2-0.5
- plug some rpmbuild memory leaks.
- file security contexts added to package header.
* Mon Dec 22 2003 Jeff Johnson <jbj(a)redhat.com> 4.2-0.4
- test build with methods needed for selinux.
rpmdb-fedora-1.90-0.20040109
----------------------------
squirrelmail-1.4.2-1
--------------------
* Thu Jan 08 2004 Gary Benson <gbenson(a)redhat.com> 1.4.2-1
- upgrade to 1.4.2.
- tighten up permissions on /etc/squirrelmail/config.php (#112774).
system-config-date-1.7.1-1
--------------------------
* Thu Jan 08 2004 Brent Fox <bfox(a)redhat.com> 1.7.1-1
- apply patch from bug #109803
system-config-kickstart-2.5.4-1
-------------------------------
* Thu Jan 08 2004 Brent Fox <bfox(a)redhat.com> 2.5.4-1
- only add --default to langsupport if more than one lang is selected (bug #111600)
* Tue Jan 06 2004 Brent Fox <bfox(a)redhat.com> 2.5.3-1
- add a requires for system-config-language
- get list of langs from system-config-language
webalizer-2.01_10-18
--------------------
* Thu Jan 08 2004 Joe Orton <jorton(a)redhat.com> 2.01_10-18
- update default config
* Thu Jan 08 2004 Joe Orton <jorton(a)redhat.com> 2.01_10-17
- add fix for #111433
xemacs-21.4.14-6
----------------
* Sat Dec 27 2003 Jens Petersen <petersen(a)redhat.com> - 21.4.14-6
- set EMACSLOADPATH during final make and install so that it is buildable
even when xemacs isn't installed
- disable ldap, postgresql and dbm support for now (#110649) [jwz]
* Sat Dec 13 2003 Jeff Johnson <jbj(a)jbj.org>
- rebuild against db-4.2.52.
* Fri Nov 07 2003 Jens Petersen <petersen(a)redhat.com> - 21.4.14-5
- add a "--without mule" rpmbuild option for the 8bit dead-hards (#102718)
which disables mule and Input Method support
- only load un-define in site-start.el when there is mule support
xfsprogs-2.6.0-2
----------------
* Thu Jan 08 2004 Jeremy Katz <katzj(a)redhat.com> 2.6.0-2
- add defattr (reported by Matthias)
20 years, 5 months
Re: QA process was Re: RPM submission procedure
by Jef Spaleta
Lamar Owen:
> So you're talking about something similar to how Slashdot
> moderation works with points. Then if someone wants to run
> untested code, they just drop their 'view level' to the
> appropriate place. If they want solid code, they raise the
> threshhold and don't see the cruft. In essence, at least. I like >
your idea.
No absolutely not...we aren't talking about crufty comments we are
talking about QA..QA that impacts security of the codebase. I am a FIRM
believer that end-users do not care enough about security and its up to
the development side to do the correct amount of caring.
If you give people who do NOT know what they are doing, the easy
ability, to eat packages that have not be appropriately
peer-reviewed...might as well just stop trying to do QA at all...because
end-user ASSUME that just because its in an rpm...its worth installing
and have no regard for security what so ever. Un-QA'd binaries should
not go into a repository. Users who do not know enough to roll their own
binaries, should not be expected to self-select what level of codebase
is appropriate for them...because frankly that have no real claim to
understanding what is appropriate. User who are infused with clue...can
follow-up on the transparent QA bugticket...find the src.rpm listed that
needs review and roll their own and be a part of the QA effort.
> I think that trusted people should be able to vote negatively too; > a
trusted person might +1 in error occassionally. Or maybe the
> trusted person has an interest in seeing a favorite package go
> through quickly (one would hope not,
> but facts are facts, and people sometime lose sight of the big picture when
> their pet idea or package is under fire).
What does marking someone as "trusted" mean then? Trusted people are
well.... trusted to do the right thing consistantly. A trusted person
earns 'trust' status by showing through multiple and consistent
application of the guidelines while untrusted. There is of course going
to need to be review and intervention in the 'corner case' of when a
trusted person goes postal. But the whole point of deeming someone
'trusted' is to...trust them. It should be pretty clear from the way
people interact on on QA bugtickets about whether they 'get it' and are
following the guidelines and allowing for reasonable discussion about
the technical merits of the packaging before marking something publish.
-jef"for the sake of signal to noise ratio...and to prevent slipping
into a "taste great/less filling" round robin conversation...I'm
implementing a 2 post personal limit on my replies to people in a
thread. So in this case this counts as my first reply to Owen in this
thread..I have at most one more reply and then I'm not going to reply
back in this mailinglist to Owen on this topic. And in the future I will
try to follow this guideline as much as possible to avoid getting stuck
in long threads that are doing nothing but encouraging people to ignore
the list completely. Feel free to ping me off list to remind me if I've
stepped over my personal limit in the future"spaleta
20 years, 5 months
Re: QA process was Re: RPM submission procedure
by Jef Spaleta
Panu Matilainen wrote:
> Just an off-the-cuff idea: if one trusted, or two untrusted
> developers vote a package ready to move to "upwards" it should be moved ?
> (assuming that one PUBLISH vote from untrusted developer is enough to get
> a package into testing/unstable)
So what yer saying is... if my friend and I, see something we want
sitting in QA, I can tell him, and we can make half-hearted attempts
as untrusted people to do QA and both setting the +1 publish note
without actually doing the QA checklist at all....and get it out and
built? Seems there has to be an emergency stop button somewhere to
prevent me from not making an effort to do the QA work. Seems in the
untrusted space -1 publish comments need to matter too. Because i can
certainly see user interest in short-cutting the process to get packages
out of QA faster, tempting the use of +1 publish inappropriately by
untrusted people. But I can't really see a compelling misuse of the -1
publish comment by untrusted people, holding up packages just to be an
ass, isn't really a compelling interest in more than 1 or 2 people in
the userbase( well 3 counting me).
-jef
20 years, 5 months
Re: Request for Comments: updating RPMs using binary deltas
by Jef Spaleta
Pekka Pietikainen wrote:
> I think a reasonable assumption would be that to use patch rpms
> you need the original FC<x> media (low-bandwidth users should have >
these around), and just have patch rpm for every errata.
Is providing a low bandwidth solution to updates really worth the extra
testing and the extra mirroring..the extra drain on development and
building resources. Are we saying that low bandwidth people are going to
have to choose between rpmdiff packages and being able to use custom
packages or Fedora Alternatives or 3rd party alternative rpms safely and
effectively?
And you will have to require official mirrors to carry them...i really
dont think optional carrying of this is going to really be all that
useful. And i'm not going to step into the mirroring politics side of
that argument. If official mirror maintainers see potential problems
with carrying the rpmdiffs...their expert opinions need to be taking
with grave attention.
-jef
20 years, 5 months
Fedora News Updates #1
by Colin Charles
Hello folk,
Just a round-up of the weekly (or bi-weekly) happenings in the Fedora
community, all thanks to mailing list postings. I wish for this to
continue (bi-weekly seems more reasonable) and hope for contributions
from the community as well.
http://fedoranews.org/colin/fnu/week1.html
Why it exists? We've reached a stage where there are plenty of posts and
we have plenty of resources out there. A (bi-)weekly summary seems like
the right thing to do.
Hope this is a useful resource.
Regards.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
20 years, 5 months
[Fwd: [Openswan dev] ANNOUNCE: Openswan 1.0.0 Released]
by Dax Kelson
The Super FreeSWAN patch has morphed into a full blown project of it's
own complete with road maps, mailing lists, CVS, and an IRC channel.
It would be very nice to get Openswan v2.10 included with FC2.
-----Forwarded Message-----
> From: Ken Bantoft <ken(a)xelerance.com>
> To: users(a)lists.openswan.org,
> Subject: [Openswan dev] ANNOUNCE: Openswan 1.0.0 Released
> Date: Fri, 02 Jan 2004 20:00:44 -0500
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> We are pleased to announce the 1st release of Openswan, a formal fork of
> the FreeS/WAN codebase, available through http://www.openswan.org
>
> Openswan 1.0.0 is based off the last beta of Super FreeS/WAN, and as such
> includes features like X.509 Digital Certificate support, AES and other
> ciphers, NAT Traversal, Dead Peer Detection (DPD), and adds XAUTH Server
> support.
>
> The Short Frequently Asked Questions (FAQ):
>
> 1. Is it interoperable with FreeS/WAN & Super FreeS/WAN?
>
> Openswan is 100% interoperable with FreeS/WAN, SuperFreeS/WAN, and dozens
> of other vendor implementations of the IPsec standards.
>
> 2. Does it work on Linux Kernel 2.6?
>
> The Openswan 1.x.x releases will runn on 2.0.x, 2.2.x and 2.4.x series
> only. Our 2.x.x tree is in active development, and support the 2.6
> kernels.
>
> 3. What's happening to the future of Super FreeS/WAN?
>
> There will be no future development on Super FreeS/WAN - the lastest tree
> was used to start Openswan 1.0.0 from.
>
> 4. Do my configs/scripts/tools need to be updated if I change to Openswan?
>
> Configuration + management are no different that FreeS/WAN, so config
> files do not need to be updated to upgrade to Openswan.
>
> 5. Where do I get support?
>
> Available via IRC, Mailing lists, or commercially through Xelerance
> Corporation. See http://www.openswan.org/support/ for links.
>
> 6. What's changed (Since the last release of Super FreeS/WAN)?
>
> Dead Peer Detection (DPD) fixes
> X.509 v0.9.37 merge
> 64bit cleanups for the port to ia64 (Thanks to HP for hardware)
> CryptoAPI for kernel 2.4.23 fixes (JuanJo)
> XAUTH Server Support (Thanks to Astaro for sponsoring this work. See
> README.XAUTH for details. Disabled in default build.)
>
>
> - --
> Ken Bantoft VP Business Development
> ken(a)xelerance.com Xelerance Corporation
> sip://toronto.xelerance.com http://www.xelerance.com
>
> The future is here. It's just not evenly distributed yet.
> -- William Gibson
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
>
> iD8DBQE/9hQ/PiOgilmwgkgRApswAJwK+lZtgdlRUOxy6dL1AVdWL5TA9gCgqoHW
> R8FCGX5j4esW5ZURYEq1ah4=
> =Y9/S
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Dev mailing list
> Dev(a)lists.openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
20 years, 5 months