With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
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.
Ideally id like to make the change quickly and transparently. Right now im aiming to do it on a saturday in march. it will mean that we take plague downa nd disable builds in koji. we need to import epel into koji at that point in time. once everthing is imported and tagged, building can be enabled. All developers at that point in time will need to update there common checkouts to be able to build.
This email is intended to start discussion on the migration and allow people to bring up any concerns that they have.
Dennis
On Wed, Feb 25, 2009 at 09:12:07AM -0600, Dennis Gilmore wrote:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
For those of us who are weekend packagers and not super familiar with Koji, it'd be helpful to see an example or two of how I can test build some of my packages against these new targets. Can I do this with arguments to 'make' or do I need to call the koji cli client directly?
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.
Ideally id like to make the change quickly and transparently. Right now im aiming to do it on a saturday in march. it will mean that we take plague downa nd disable builds in koji. we need to import epel into koji at that point in time. once everthing is imported and tagged, building can be enabled. All developers at that point in time will need to update there common checkouts to be able to build.
This email is intended to start discussion on the migration and allow people to bring up any concerns that they have.
Ray
On Wednesday 25 February 2009 10:27:18 am Ray Van Dolson wrote:
On Wed, Feb 25, 2009 at 09:12:07AM -0600, Dennis Gilmore wrote:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
For those of us who are weekend packagers and not super familiar with Koji, it'd be helpful to see an example or two of how I can test build some of my packages against these new targets. Can I do this with arguments to 'make' or do I need to call the koji cli client directly?
koji build dist-5E-epel --scratch <srpm> koji build dist-4E-epel --scratch <srpm>
Dennis
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.
Can we have a separate releng-epel group that can add packages to buildroots in epel, do bodhi pushes, etc?
-Toshio
On Wednesday 25 February 2009 10:42:46 am Toshio Kuratomi wrote:
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.
Can we have a separate releng-epel group that can add packages to buildroots in epel, do bodhi pushes, etc?
-Toshio
Checking into this, there are some finer grained acls in the new koji but i dont not fully understand them. so im not sure if this is possible.
Luke says that bodhi should be fine.
I need to setup an epel signing box in phx to sign the packages on.
we will continue to use the epel_signers group for epel releng
Dennis
On 25.02.2009 16:12, Dennis Gilmore wrote:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
Sounds good.
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.
[...]
Cu knurd
Thorsten Leemhuis wrote:
On 25.02.2009 16:12, Dennis Gilmore wrote:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
Sounds good.
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.
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.... likely there would need to be guidance on whether it's proper usage of the testing repo to leave a package in there forever.
-Toshio
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?
BTW, does the EPEL Steering Committee actually care about that or are they fine with a steady update stream instead of monthly pushes?
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 :-/
likely there would need to be guidance on whether it's proper usage of the testing repo to leave a package in there forever.
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?
BTW, does the EPEL Steering Committee still exist/meet at all?
Cu knurd
On Wed, Feb 25, 2009 at 8:11 PM, Thorsten Leemhuis fedora@leemhuis.info 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....
+1
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.
On Wed, Feb 25, 2009 at 08:11:23PM +0100, Thorsten Leemhuis 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?
Yes, the signer/pusher has full control over what updates they are pushing.
The following ticket contains details on what needs to happen to get bodhi to push updates for EPEL:
https://fedorahosted.org/fedora-infrastructure/ticket/1230
luke
On Wed, Feb 25, 2009 at 10:08 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 25.02.2009 16:12, Dennis Gilmore wrote:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
Sounds good.
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.
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
On Thu, Feb 26, 2009 at 5:13 PM, Stephen John Smoogen smooge@gmail.com wrote:
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
What about packages that don't get wide exposure? Are they to be forever barred from EPEL (they would be under this proposal)?
On Thu, Feb 26, 2009 at 05:47:36PM -0500, Jon Stanley wrote:
On Thu, Feb 26, 2009 at 5:13 PM, Stephen John Smoogen smooge@gmail.com wrote:
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
What about packages that don't get wide exposure? Are they to be forever barred from EPEL (they would be under this proposal)?
Yep, shoot.. I'd say most of my Fedora packages are niche enough that the users that do exist certainly know nothing of bodhi nor of how to give my update karma. :)
Even fewer on the EPEL front.
We'd all just be bugging each other to vote for our own updates :)
On Thu, 2009-02-26 at 15:13 -0700, Stephen John Smoogen wrote:
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
Small note, it was overly protective processes like these that contributed to the fall of Fedora Legacy. It's a really really hard balance to strike :/
2009/2/26 Jesse Keating jkeating@redhat.com:
On Thu, 2009-02-26 at 15:13 -0700, Stephen John Smoogen wrote:
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
Small note, it was overly protective processes like these that contributed to the fall of Fedora Legacy. It's a really really hard balance to strike :/
Well I didn't think of it as overly protective when I wrote it, but that is normally the case isnt it.
I figured we have a small subset of packages that we maintain... and we have a process where stuff may sit in testing for a month but we have no feedback on whats there. Instead I figured we could have a process where we could see that a package was tested, by whom, and with what and could be considered 'stable'.
My current I-havent-had-a-good-night-sleep-in-a-week feeling is that calling our repositories testing and stable is misleading. They are just snapshots that are more accurately called "this-month" and "next-month". My guess is that going further than that would require the resources that people pay Red Hat for :).
Stephen John Smoogen wrote:
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
You don't have a big enough community for any such process to work well. EPEL user and contributor base is still small. You should keep things relaxed up atleast until you get a larger base to cover.
Rahul
On 27.02.2009 00:11, Rahul Sundaram wrote:
Stephen John Smoogen wrote:
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
You don't have a big enough community for any such process to work well.
I tend to agree.
EPEL user and contributor base is still small. You should keep things relaxed up atleast until you get a larger base to cover.
Even then I'd say it bureaucracy that is better avoided.
Cu knurd
On Fri, Feb 27, 2009 at 2:25 AM, Thorsten Leemhuis fedora@leemhuis.info wrote:
On 27.02.2009 00:11, Rahul Sundaram wrote:
Stephen John Smoogen wrote:
Well I would like to have it that it actually has bodhi votes before it can be moved. We can have a process for the number of votes needed, but I would rather have something getting a couple of +1's that can be tracked than a 1 month timeframe and no one looking at it.
You don't have a big enough community for any such process to work well.
I tend to agree.
EPEL user and contributor base is still small. You should keep things relaxed up atleast until you get a larger base to cover.
Even then I'd say it bureaucracy that is better avoided.
Ok the definition of a bureaucracy from wikipedia is:
Bureaucracy is the structure and set of regulations in place to control activity, usually in large organizations and government. As opposed to adhocracy, it is represented by standardized procedure (rule-following) that dictates the execution of most or all processes within the body, formal division of powers, hierarchy, and relationships. In practice the interpretation and execution of policy can lead to informal influence.
My guess is that the group would prefer an adhocracy
Adhocracy is a type of organization being antonymous to bureaucracy. The term was first popularized in 1970 by Alvin Toffler[1], and has since become often used in the theory of management of organizations (particularly online organizations), further developed by academics such as Henry Mintzberg.
http://en.wikipedia.org/wiki/Adhocracy
It requires sophisticated and often automated technical systems to develop and thrive.[1]
Characteristics of an adhocracy:
* highly organic structure[2] * little formalization of behavior[2][1] * job specialization based on formal training[2] * a tendency to group the specialists in functional units for housekeeping purposes but to deploy them in small, market-based project teams to do their work[2] * a reliance on liaison devices to encourage mutual adjustment, the key coordinating mechanism, within and between these teams[2][3] * low standardization of procedures, because they stifle innovation[1] * roles not clearly defined[1] * selective decentralization[1] * work organization rests on specialized teams[1] * power-shifts to specialized teams * horizontal job specialization[3] * high cost of communication[3] * culture based on democratic and non-bureaucratic work [3]
If that is what people are wanting.. then we will need to show how we are considering these packages Enterprise ready... otherwise lets get rid of the pretext of 'stable' and push towards making the tools to make it work.
On Feb 25, 2009, at 7:12 AM, Dennis Gilmore wrote:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
Dennis, this is awesome, thanks for your work on getting EPEL cured of the plague!
-Jeff
2009/2/25 Dennis Gilmore dennis@ausil.us:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
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.
Ideally id like to make the change quickly and transparently. Right now im aiming to do it on a saturday in march. it will mean that we take plague downa nd disable builds in koji. we need to import epel into koji at that point in time. once everthing is imported and tagged, building can be enabled. All developers at that point in time will need to update there common checkouts to be able to build.
Would you mind file tickets on that, i'll take some.
This email is intended to start discussion on the migration and allow people to bring up any concerns that they have.
Do we have packages awaiting push from epel_signers ? if so, we should run that push then freeze updates before import epel to koji.
[/me is thinking about other possible phases...]
On Wednesday 25 February 2009 03:24:48 pm Xavier Lamien wrote:
2009/2/25 Dennis Gilmore dennis@ausil.us:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji. I have set up some tags and targets for doing EPEL scratch builds. right now you can scratch build to dist-5E-epel and dist-4E-epel. there is an issue i need to work around with EL-4 the old hack we used to provide a kernel to ppc doesnt work. I am working on a solution to that.
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.
Ideally id like to make the change quickly and transparently. Right now im aiming to do it on a saturday in march. it will mean that we take plague downa nd disable builds in koji. we need to import epel into koji at that point in time. once everthing is imported and tagged, building can be enabled. All developers at that point in time will need to update there common checkouts to be able to build.
Would you mind file tickets on that, i'll take some.
This email is intended to start discussion on the migration and allow people to bring up any concerns that they have.
Do we have packages awaiting push from epel_signers ? if so, we should run that push then freeze updates before import epel to koji.
This is how i saw it going down
1) shut down plague 2) do epel push 3) manually run the sync one last time from buildsys to the primary mirror 3) import packages from primary mirror into koji 4) tag packages as appropriate in koji. 5) make changes to Makefile.common 6) send out notice that builds are open 7) do stable and testing composes from koji and verify that they are the same as whats on the primary mirror (one caveat there will only be the latest pkg not latest2) 8) profit 9) switch off buildsys.fp.o
before we get there we need. compose box bodhi to know about EPEL some testing of compose process's
Dennis
On Wed, Feb 25, 2009 at 11:15 PM, Dennis Gilmore dennis@ausil.us wrote:
On Wednesday 25 February 2009 03:24:48 pm Xavier Lamien wrote:
Do we have packages awaiting push from epel_signers ? if so, we should run that push then freeze updates before import epel to koji.
This is how i saw it going down
+ 0) send out notice that build are closed
- shut down plague
- do epel push
- manually run the sync one last time from buildsys to the primary mirror
- import packages from primary mirror into koji
- tag packages as appropriate in koji.
- make changes to Makefile.common
- send out notice that builds are open
- do stable and testing composes from koji and verify that they are the same
as whats on the primary mirror (one caveat there will only be the latest pkg not latest2) 8) profit 9) switch off buildsys.fp.o
Excellent.
before we get there we need. compose box
How many ? afaik, most of our plague builders also do koji or will we need new setup for EPEL support ?.
bodhi to know about EPEL
Luke, how much time do you need to make that happen ? Feel free to ask if you need any help.
some testing of compose process's
+ some testing of signing process's + some testing of push from bodhi
Thanks for the migration step,
On Wednesday 25 February 2009 04:45:53 pm Xavier Lamien wrote:
On Wed, Feb 25, 2009 at 11:15 PM, Dennis Gilmore dennis@ausil.us wrote:
On Wednesday 25 February 2009 03:24:48 pm Xavier Lamien wrote:
Do we have packages awaiting push from epel_signers ? if so, we should run that push then freeze updates before import epel to koji.
This is how i saw it going down
- send out notice that build are closed
There will need to be a few announcement emails sent out but yes :)
- shut down plague
- do epel push
- manually run the sync one last time from buildsys to the primary
mirror 3) import packages from primary mirror into koji 4) tag packages as appropriate in koji. 5) make changes to Makefile.common 6) send out notice that builds are open 7) do stable and testing composes from koji and verify that they are the same as whats on the primary mirror (one caveat there will only be the latest pkg not latest2) 8) profit 9) switch off buildsys.fp.o
Excellent.
before we get there we need. compose box
How many ? afaik, most of our plague builders also do koji or will we need new setup for EPEL support ?.
1 box to use for signing packages and doing sanity checks etc.
bodhi to know about EPEL
Luke, how much time do you need to make that happen ? Feel free to ask if you need any help.
some testing of compose process's
- some testing of signing process's
- some testing of push from bodhi
Thanks for the migration step,
On Wed, Feb 25, 2009 at 09:12:07AM -0600, Dennis Gilmore wrote:
With the koji upgrade on the weekend support was deployed for external repos. this enables building of EPEL in koji.
I'd just like to say .. Horray!
Rich.
epel-devel@lists.fedoraproject.org
-
Dennis Gilmore -
Jeff Sheltren -
Jesse Keating -
Jon Stanley -
Luke Macken -
Rahul Sundaram -
Ray Van Dolson -
Richard W.M. Jones -
Stephen John Smoogen -
Thorsten Leemhuis -
Toshio Kuratomi -
Xavier Lamien