New Package Process

[Jeff Spaleta]

Greg DeKoenigsberg wrote:
> 2. A policy of "build the world".  Every package in the build system, we 
> build.  If it passes, it goes into the "untested" bucket.  This bucket 
> is also a repo, for those who dare.

In Core that's called rawhide.  Are you suggesting a rawhide like repo
for Extras for every
Core release?  Just after fc4 release, you would have a 'build the
world' extras repo for fc3 and fc4 and one tracking the deps in core
development.

I'm not sure that's such a great idea, considering the rolling release
nature of Extras. Rawhide as a tool works for Core because rawhide is
the staging area to work on integration issues before a release date
AND just as importantly has freeze out points that can be used to be
used to yank horribly broken packages out before a release of Core is
frozen out.

I'd be much more comfortable with a 'build the world' situation for
Extras, if Extras had scheduled releases that were frozen out and
associated timetables which could be used to determination points for
culling packages in the 'build the world' repo which are still too
crappy to enter the frozen Extras 'release'.  With schedules and
releases of Extras, so we can do things like an FedoraExtras blocker
bug summary to focus and organize manpower on the 'important' issues
before a designated 'release' of Extras. I think if you are going to
stick with the rolling release you have to frontload some of the QA as
a tradeoff to the rolling nature of the tree.

> 3. A mechanism for "final review" that marks the difference between "a
> package that builds" and "a package the builds and is any good".  And 
> let's think creatively about this final review: does it need to be a 
> single person who says "this is ok, I bless it"?  Or could it *also* be a 
> threshhold?  For example: we could say that any package that is installed 
> 100 times from the untested repo, without anyone voting against it, 
> is automatically promoted to the "tested" bucket.  This would provide two 
> paths: one path for packages that people are watching over, and a parallel 
> path for packages that people aren't watching over, but are still using.

i don't think your automatic threshold idea is technically feasible.
How would you determine download or mirroring from sucessful
installing?  How do you determine successful installing from usefully
working.  You aren't going to go so far as to actually require some
sort of phone-home software from the client computer are you.. because
that would be very silly.  Technical questions aside, would this
scheme work for Core rawhide?  If Core followed a similar model.. and
rawhide was the "build the world" repo, would this automatic threshold
work? I highly doubt it. If you want a 'build-the-world' playground
for package maintainers and competent package testers, structure the
development model for Extras accordingly to strongly delineate the
release tree from the build-playground.

Everyone who is happy with the idea of the build-the-world tree with
the rolling release model, is going on the list of people i'm going to
throw users at as they stumble onto the build-the-world tree and get
burned. Be prepared to spend a lot of time in fedora-list and the
forums. I am fully confident in the ability of rank-and-file fedora
packagers consumers to be easily misled into using the build-the-world
tree for Extras if it becomes available.

-jef"calling the new build-the-world tree  "happy fun ball" might not even help
       http://www.happyfunball.com/hfb.html
"spaleta