moving to Koji

[Dennis Gilmore]

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

[Ray Van Dolson]

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

[Dennis Gilmore]

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

[Toshio Kuratomi]

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

[Dennis Gilmore]

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

[Thorsten Leemhuis]

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

[Toshio Kuratomi]

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

[Thorsten Leemhuis]

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

[Xavier Lamien]

On Wed, Feb 25, 2009 at 8:11 PM, Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 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.

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

[Luke Macken]

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

[Stephen John Smoogen]

On Wed, Feb 25, 2009 at 10:08 AM, Thorsten Leemhuis
<fedora(a)leemhuis.info&gt; 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.


-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Jon Stanley]

On Thu, Feb 26, 2009 at 5:13 PM, Stephen John Smoogen <smooge(a)gmail.com&gt; 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)?

[Ray Van Dolson]

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(a)gmail.com&gt; 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 :)

[Jesse Keating]

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 :/

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Stephen John Smoogen]

2009/2/26 Jesse Keating <jkeating(a)redhat.com&gt;:
>  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 J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Rahul Sundaram]

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

[Thorsten Leemhuis]

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

[Stephen John Smoogen]

On Fri, Feb 27, 2009 at 2:25 AM, Thorsten Leemhuis <fedora(a)leemhuis.info&gt; 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.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

[Jeff Sheltren]

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

[Xavier Lamien]

2009/2/25 Dennis Gilmore <dennis(a)ausil.us&gt;:
>  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...]

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

[Dennis Gilmore]

On Wednesday 25 February 2009 03:24:48 pm Xavier Lamien wrote:
>  2009/2/25 Dennis Gilmore <dennis(a)ausil.us&gt;:
>  > 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

[Xavier Lamien]

On Wed, Feb 25, 2009 at 11:15 PM, Dennis Gilmore <dennis(a)ausil.us&gt; 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

>  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 
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,
-- 
Xavier.t Lamien
--
http://fedoraproject.org/wiki/XavierLamien
GPG-Key ID: F3903DEB
Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB

[Dennis Gilmore]

On Wednesday 25 February 2009 04:45:53 pm Xavier Lamien wrote:
>  On Wed, Feb 25, 2009 at 11:15 PM, Dennis Gilmore
> <dennis(a)ausil.us&gt; 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 
There will need to be a few announcement
emails sent out  but yes :)

>  > 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
>
>  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,

[Richard W.M. Jones]

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.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
Read my OCaml programming blog: http://camltastic.blogspot.com/
Fedora now supports 68 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora