On Sun, 2007-06-03 at 17:29 +0200, Patrice Dumas wrote: > On Sun, Jun 03, 2007 at 11:08:23AM -0400, Jesse Keating wrote: > > /topic RELENG-Meeting - Updates Policy - JesseKeating > > About update policy, first I think that it should be easy to do > something like: > > make go-to-release > > which would use the changelog entry (or something similar). If I recall > well this is already more or less agreed. Yes. I think Luke is working on a bodhi command line client (or will be) that could be wrapped in the makefiles. > It should also be possible for a maintainer to decide what amount of > time the package should stay in the testing repo. The default would be > something reasonable (one week?). The rel-eng team could have the > possibility to block the update at any time if they find something is > abnormal. > > For example > make go-to-release 1 > would make the package stay 1 day in testing repo. That would be the point that needs the most discussion. > And there should be automatic checks for broken deps, for duplicated > provides, for upgrade path. That is planned. Just needs coding. I think everyone agrees that would be a very good thing to have. > > /topic RELENG-Meeting - Freeze Policy - JesseKeating > > On that topic, I think that during a freeze there shouldn't be a need to > mail to rel-eng to push to the frozen collection. It should be a > specific target, so for example to push to the frozen collection one > should do > > make build > make go-to-freeze > > Then the rel-eng would see that (together with the changelog entry), and > block if something seems dubious, or if it is too late in the freeze. It Their ability to do that, under those circumstances, might be limited. Rel-eng doesn't immediately know if it's too invasive, which is why a request is sent. Not all changelogs are descriptive. But perhaps something better could be done, yes. Also remember there will be a point in time where things are completely frozen so that ISOs can be made. During that (relatively) short period of time, the push feature would be disabled. josh -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
