New Package Process
Greg DeKoenigsberg
gdk at redhat.com
Wed Apr 27 19:58:29 UTC 2005
On Wed, 27 Apr 2005, Ed Hill wrote:
> Yeah, this seems fundamental. So, to keep some level of quality in the
> process (creating packages that almost all work), does it follow that:
>
> - a maintainer can only properly handle so many packages and
> so many reviews of others' packages
Yep. There's probably some theoretical number "n" that represents "max
packages that one clueful person can sanely review". The better the tools
to help with review, though, the higher the value of "n" -- perhaps
dramatically higher.
> - lint-like tools and all-around better automation can help
> but they simply *cannot* replace attentive and clue-full
> reviewers and maintainers
Agreed.
> - to scale, new maintainers will *need* to be trained and
> this training process probably deserves as much attention
> as the automated tools, etc.
>
> Or am I way off-base?
I don't think so.
> ps - As a packaging newbie, I can attest that the documentation
> for packaging is damn sparse. And I made a huge mistake by
> not spending enough time reading all the existing spec files
> which, in retrospect, is perhaps the best way to see how
> things can (or ought to be) done.
There's a baseline of documentation that already exists. For instance, I
wonder how many people have read, or even know about, the Red Hat RPM
Guide book. I also wonder how useful it is.
How many of the folks on this list have read any RPM literature at all?
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
Red Hat Summit ] [
New Orleans ] [ Learn. Network. Experience Open Source.
June 1/2/3 2005 ] [ (And Make Your Boss Pay For It.)
[ http://www.redhat.com/promo/summit/
More information about the fedora-extras-list
mailing list