moving to Koji

Xavier Lamien laxathom at
Wed Feb 25 21:06:36 UTC 2009

On Wed, Feb 25, 2009 at 8:11 PM, Thorsten Leemhuis <fedora at> wrote:
> On 25.02.2009 18:21, Toshio Kuratomi wrote:
>> Thorsten Leemhuis wrote:
>>> On 25.02.2009 16:12, Dennis Gilmore wrote:
>> [...]
>>>> To move building to koji we need to get bodhi setup and redo the
>>>> release engineering process to closely match that of Fedora. What this
>>>> means is that you will need to file a ticket with releng to have a
>>>> package added to the buildroot  if you need to build against it.   it
>>>> also means that things can hit stable sooner.
>>> Ehh, do we really want that apart from security updates or important
>>> bugfixes (which we can and do push within minutes these days already if
>>> needed)?
>>> I ask because the "monthly" move from testing to the porper repos has a
>>> important side-effect: I slows everything down when compared to the
>>> quickly moving Fedora, which for EL repos IMHO is something good.
>> I think this would still be possible with bodhi by having the
>> epel_signers push to testing frequently but push to stable on a monthly
>> basis.  Have to ask releng/lmacken to be sure, though.
> Luke, can you clarify? And if above works: can one push selected packages
> (security updates and those that fix other serious bugs) at any time while
> leaving the other, regular updates for the next monthly move?

Right, a such think is (should ?) possible as pushes are done manually iirc
Track down all bodhi's security tag on EPEL packages and push them regulary.
And as said above, let epel_signers do push to make sure that packages
are really
a security update.

> BTW, does the EPEL Steering Committee actually care about that or are they
> fine with a steady update stream instead of monthly pushes?

yeah, I'd say, keep our monthly updates for enhancements and bugfixes
and improve push update for security fixes.

>> If that does work it gives packagers the ability to leave things in the
>> testing repo without having to explicitly tell people not to move it
>> everytime a new push to stable is being prepared.  Not sure if that
>> would be "abused" though....


> Yeah, it could make the whole testing repo completely useless if packagers
> push experimental updates to the testing repo with the intention to never
> move them to the stable repos  :-/

Updates have life cycle in bodhi afaik.
Packager can also remove themselves the update by revoke the request.
I think the best way to avoid a such think os to update our EPEL
guideline on push updates.

We can also do a monthly check.

>> likely there would need to be guidance on
>> whether it's proper usage of the testing repo to leave a package in
>> there forever.

Correct (though above).

> Yeah, we need to put a rule in place here afaics. A time limit maybe? Could
> the steering committee maybe put that onto its todo list?

Will do this week-end if that don't hurt anyone on the time.

> BTW, does the EPEL Steering Committee still exist/meet at all?

yeah, we're still alive ;)
Meeting ? :: it's something i think that we (should improve ?) need to
talk about.
Kevin is doing a great job by handling our meeting as far as possible.

Xavier.t Lamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB

More information about the epel-devel-list mailing list