Jesse Keating wrote:
On Mon, 2009-05-11 at 13:58 +0200, Ralf Corsepius wrote:
>> We've been trying to push F11 updates for a couple days now.
> ... but you still haven't updated fedora-release, so neither mock
> doesn't pick them up.
That's right, I wanted to make sure they hit mirrors OK before I
released a fedora-release with repo configuration pointing to them. Of
course you're free to manually turn those repos on and test it out for
yourself.
>>> * Decouple cuttings DVDs from F11 development
>> I honestly don't understand what you're proposing here. No DVD from the
release?
> No, I am proposing that rel-eng chooses a set of packages to build iso
> etc. from, while "updates" "rolls on".
>
> Or differently: rel-eng composes the "Fedora" repo from those packages
> they choose, which "updates" continues, independently from rel-eng's
> activities.
>
>> What do we have people download to get the release?
> As before ... the only difference would be "Fedora" (i.e. the set of
> packages the DVDs etc. would have been built from) would be older than
> "updates" (and/or "Everything")
Which does nothing to help the upgrade and n-v-r case.
Only if "updates"
is not activated upon installation.
>> What do
>> we hand out at events?
> Openly said, ... I would hand out netboot.img's, accompanied with a yum
> repository of "Everything" ... but that's a different topic.
>
>>> * Implement rawhide/testing
>> Is this a full time thing, you always want a rawhide, and a
>> rawhide-testing, which is driven by bodhi?
> I haven't thought about all details, but I am inclined to lean towards a
> "permanent rawhide-testing".
>
> 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.
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.
Ralf