On Tue, 2009-05-12 at 17:59 +0200, Ralf Corsepius wrote: > > Which does nothing to help the upgrade and n-v-r case. > Only if "updates" is not activated upon installation. Anaconda doesn't support this, and even if it did, network isn't always available to people when doing the upgrade. > >> There would be times where it hardly would be used, but there can easily > >> be times, when it would be heavily used (e.g. there currently is a > >> proposal pending which would severely change perl's behavior (perl > >> module search order and file system layout), with currently unclear > >> outcome). > > > > How would one choose to use it? > > Similar to "updates-testing" > yum install --enable-repo=rawhide-testing "package-i-want-to-test" > etc. I meant how would a maintainer choose to use rawhide-testing as opposed to pure rawhide. Would they have to specifically craft a make build command with a TARGET= ? > > Why would anyone choose to use bodhi if > > they were allowed to build directly into rawhide? > You mean to push a package to rawhide-testing instead of rawhide? > > Primary reason: Because the maintainer is aware about his package > containing some "nasty"/"adventurous"/"dangerous"/"experimental" > etc. changes/bugfixes, with unclear outcome and him wanting to avoid > destabilizing the distro. > > > Should we force the > > use of bodhi during freezes, and make it optional otherwise? > IMO, maintainers need _one_ single package submission UI, which should > be used on all occasional/in all phases of development. > > ATM, this would mean making bodhi mandatory and to get rid of trac etc. My point was when do we force the use of bodhi. I would think if we forced the use of bodhi for every single package build ever we'd create a riot of angry maintainers. I agree with you that having both trac and bodhi is non-optional. We just didn't have the time/manpower to develop bodhi to a point where it could be used to drive freeze break requests. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
