Re: Pungi 4 milestone builds: proposals
by Adam Williamson
On Mon, 2016-03-14 at 07:29 -0400, Kamil Paral wrote:
> >
> > releng flipped any necessary switches for
> > 'release' behaviour.
> I think this is the only meaningful argument for having TC/RC
> distinction. Personally I'm fine with it both ways. It's nice to see
> which images are the ones "almost ready", but I'm not sure it's worth
> having more bits for releng to remember and flip.
>
> >
> >
> > >
> > > TC's
> > > alpha-0.1
> > > alpha-0.2
> > > alpha-0.3
> > > alpha-0.4
> > > beta-0.1
> > > beta-0.2
> > > beta-0.3
> > > RC-0.1
> > > RC-0.2
> > >
> > > legit RC's
> > > alpha-1.1
> > > alpha-1.2
> > > alpha-1.3
> > > alpha-1.4
> > > beta-1.1
> > > beta-1.2
> > > beta-1.3
> > > RC-1.1
> > > RC-1.2
> If we keep the TC/RC separation, I like the approach above.
>
> >
> >
> > I think this still works a bit better if we add a 'Final' milestone
> > rather than using the 'RC' milestone, but yeah, this isn't bad.
> "Final" would be nice.
So just as an update on this: Dennis and I had a chat about it this
morning, and it's difficult to be totally sure how we want to handle it
ahead of time, so for now we're inclined to keep it as simple as
possible. I'm going to file a request for an Alpha 'candidate' and
suggest it simply be labelled Alpha-1.1 , and we're going to work on
the assumption we will ditch the TC/RC distinction at least so far as
compose creation goes. We'll do Alpha-1.1, Alpha-1.2, Alpha-1.3 and so
on, without worrying about the TC/RC distinction.
At least that's the initial plan - once we've actually done a couple of
composes and seen what exactly comes out of the sausage machine, and
we've tried to set up validation events for them and seen how it works
for real testing, we can see if anything didn't turn out too well and
needs to change.
For now I'm inclined to similarly try and keep the validation stuff as
simple as possible, so I won't try to recreate the 'TC' / 'RC'
distinction at the validation event level, but instead the events will
follow the Pungi compose versioning quite closely, so we'll have
something like Test Results:Fedora 24 Alpha 1.1 Installation . If that
seems terrible to anyone, please yell now. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8 years, 1 month
#6262: drop rawhide-stable tag and consider master branch to be always stable
by Fedora Release Engineering
#6262: drop rawhide-stable tag and consider master branch to be always stable
-------------------------+------------------------
Reporter: till | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: | Component: other
Keywords: meeting | Blocked By:
Blocking: |
-------------------------+------------------------
Since we require patch reviews for the rel-eng pagure repo and use it for
running buildbranched/buildrawhide, we can IMHO drop using the rawhide-
stable tag and just consider the master branch to be always stable enough
to run the scripts from it directly.
AFAICS only ansible needs to be adjusted to change the crontab to not
checkout rawhide-stable but master for primary and secondaries systems.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6262>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8 years, 1 month
#6367: Remove mod_revocator from multilib list
by Fedora Release Engineering
#6367: Remove mod_revocator from multilib list
-----------------------------+------------------------
Reporter: rcritten | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
We have been getting a daily e-mail that the i686 version of mod_revocator
isn't installable in x86_64. This is apparently due to the fact that i686
httpd isn't available in x86_64 either (and this change seems to have been
made sometime after F23).
So can you remove mod_revocator from the multilib list? I don't see why
anyone would want to run 32-bit mod_revocator on a 64-bit system anyway.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6367>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8 years, 1 month
Re: #6152: Fedora 23 move to pungi 4
by Fedora Release Engineering
#6152: Fedora 23 move to pungi 4
------------------------------+-----------------------
Reporter: ausil | Owner: rel-eng@…
Type: task | Status: closed
Milestone: Fedora 23 Alpha | Component: koji
Resolution: fixed | Keywords: planning
Blocked By: | Blocking:
------------------------------+-----------------------
Changes (by ausil):
* status: new => closed
* resolution: => fixed
Comment:
I think we can consider this done now, at least from the primary
perspective, the work is all being tracked upstream
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6152#comment:1>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8 years, 1 month
#6363: up-to-date rawhide debuginfo unavailable from mirrors -and-
fedora directly
by Fedora Release Engineering
#6363: up-to-date rawhide debuginfo unavailable from mirrors -and- fedora directly
-----------------------------+------------------------
Reporter: fche | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The current kernel on rawhide, as per yum, is
4.5.0-0.rc6.git0.1.fc25.x86_64.
The latest kernel-debuginfo is .rc5 - whether with mirrors enabled or
bypassed in /etc/yum.repos.d/fedora-rawhide.repo . Without this
discrepancy
corrected, users cannot debug fresh rawhide materials.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6363>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8 years, 1 month
#6346: Don't include 32-bit krb5-server{,-ldap} in 64-bit trees
by Fedora Release Engineering
#6346: Don't include 32-bit krb5-server{,-ldap} in 64-bit trees
-----------------------------+------------------------
Reporter: rharwood | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: mash
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
The plugins in krb5-server and krb5-server-ldap are only used by the KDC,
so there's no point in including versions of them that don't match
architecture of the KDC binary. To that end, could we stop distributing
the 32bit version of krb5-server and krb5-server-ldap (i.e.
krb5-server.i686, krb5-server.s390, krb5-server.ppc) in the 64-bit tree?
Thanks!
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6346>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8 years, 1 month
#6362: PHP and multilib issue
by Fedora Release Engineering
#6362: PHP and multilib issue
-----------------------------+------------------------
Reporter: remi | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 24 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Since this night I receive tons of notifications about broken dependency,
e.g. :
{{{
php-pecl-judy has broken dependencies in the rawhide tree:
On x86_64:
php-pecl-judy-devel-1.0.2-9.fc24.i686 requires php-devel(x86-32)
php-pecl-igbinary has broken dependencies in the rawhide tree:
On x86_64:
php-pecl-igbinary-devel-1.2.1-4.fc24.i686 requires php-
devel(x86-32)
php-pecl-msgpack has broken dependencies in the rawhide tree:
On x86_64:
php-pecl-msgpack-devel-0.5.7-3.fc24.i686 requires php-
devel(x86-32)
...
}}}
Don't know what have changed, but PHP have never be multilib, and I dont
see any reason to have pecL devel packageS duplicated IN x86_64 tree.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6362>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
8 years, 1 month
Pungi 4 milestone builds: proposals
by Adam Williamson
Hi folks!
So we're now frozen for Alpha and we have an anaconda build with
blocker fixes in updates-testing...I guess this means it's a good time
to decide what to do about milestone builds with Pungi 4. :)
I'm assuming here that we're going to use more or less the same "TCs
and RCs" approach for F24 and just try to adapt it to Pungi 4. It seems
a bit late to make radical changes to the process itself at this point.
I have a couple of ideas. I'm gonna recap, briefly, what (as I
understand it) Pungi 4 expects us to do for milestone builds:
We're expected to run 'pungi-koji --label foo', where 'foo' is a
compose 'label' in Pungi's expected format. AIUI, this is the format
Pungi expects for a compose 'label':
MILESTONE-N.R
where MILESTONE is the milestone (there is a list of valid milestones;
for our purposes we're likely to use Alpha, Beta and RC), 'N' is the
release number, and 'R' is a respin number. Both N and R have to be
integers (though they can have multiple digits; Alpha-11.23 would be a
valid label).
Fedora does not do numbered milestone releases; we just have Alpha,
Beta and Final. RHEL does, which is why the label format has 'N'. In
the RHEL process, as I understand it, they build "Alpha-1.1", then if
it passes whatever requirements are needed for an "Alpha 1" release,
they ship it as Alpha 1; otherwise they build "Alpha-1.2" and ship that
if it passes, etc etc. The "respin" value is considered "private", and
respins are used for about the same purpose we use TCs/RCs.
It *is* possible to do a 'production' compose with no label, I believe,
by calling 'pungi-koji --no-label'. It would *also* be technically
possible to add new label formats to Pungi. So we do have three options
at the high level:
a. Work with Pungi's currently-expected label format
b. Patch Pungi to support a more Fedora-y label format
c. Don't apply a label to our TC/RC composes at all
I would suggest that a is the best practical choice, though, because we
know this is how Pungi is kind of expected to be used. b is likely to
take time to work out any kinks, and c seems unnecessarily extreme; we
should be able to come up with a usable label format that gives us
valuable information.
So assuming we go with 1) at the high level, I see a few possibilities
for how to do this.
== 1. Just use one value ==
In this design, we'd set one of the numbers to 1 (or I guess 0) for
every single Fedora compose, and just increment the other. I was
thinking we'd lock down the release number (N) and just increment the
respin (R) - so we'd do Alpha-1.1 then Alpha-1.2 then Alpha-1.3 and so
on.
This seems like it'd work fine for Alpha and Beta but be a little odd
for Final. 'Final' is not a valid milestone for Pungi 4, it expects you
to use 'RC' as a milestone and build 'RC1.1', 'RC1.2', 'RC1.3', 'RC2.1'
etc etc. It'd be a bit odd for us to have 'RC1.1' as 'Final TC1',
'RC1.2' as 'Final TC2', 'RC1.3' as 'Final RC1', etc. So we could
instead lock down R and only increment N, so we'd do 'RC 1.1', 'RC
2.1', 'RC 3.1' and so on. The build called 'RC 1.1' would likely not
really be a "real" RC (in the sense it'd happen while we were not
frozen and not have all blocker bugs fixed), but that's not horrible. I
suppose we could relatively easily add 'Final' to Pungi's list of
milestones too, if we wanted (or 'TC', come to that).
The other possible problem with this is it makes it hard to keep the
TC/RC distinction. We could build the composes as 'Alpha 1.1', 'Alpha
2.1', 'Alpha 3.1' and put 'Alpha 1.1' in a directory called
'Alpha_TC1', 'Alpha 2.1' in 'Alpha_TC2', and 'Alpha 3.1' in 'Alpha_RC1'
if we wanted, but you couldn't easily map from one name to the other,
because there's no way to know the cutoff where we switched over - if
you only know you're dealing with 'Alpha 2.1', you can't tell if that's
'Alpha TC2' or 'Alpha RC1'.
The question then is, do we actually need the TC/RC distinction for
anything? I'm not sure we really do. But if we want to keep it, we
could try...
== 2. N indicates TC/RC, R indicates number ==
In this scheme, we'd build e.g. 'Alpha 1.1' (Alpha TC1), 'Alpha 1.2'
(Alpha TC2), 'Alpha 2.1' (Alpha RC1), 'Alpha 2.2' (Alpha RC2).
This seems like the closest possible way to map to our current system.
Again it's a bit weird at Final because there is no 'Final' milestone,
only 'RC', so 'RC1.1' would be 'TC1' and 'RC2.1' would be 'RC1', which
is kinda strange; again we could add a 'Final' milestone to Pungi, I
guess.
I'm just not sure, as per 1), if we really *need* to maintain the TC/RC
distinction at least in terms of how the composes are labelled and
distributed.
== 3. Some kinda hybrid ==
We could combine things, so we do 1.n for Alpha and Beta, then n.1 for
RC (so we have Alpha 1.1, Alpha 1.2, Alpha 1.3, Alpha 1.4, Beta 1.1,
Beta 1.2, Beta 1.3, RC1.1, RC2.1, RC3.1 etc). This is viable, but I'm
not really sure it's necessary. It seems simpler to pick some variant
of 1 or 2.
There's a final question, which is whether we adopt the Pungi 'label'
naming format for all purposes - so we put the composes in directories
named Alpha-1.1, Alpha-1.2, Alpha-1.3 and so on, and we call the
validation events something like 'Test Results:Fedora 24 Alpha 1.1'
rather than 'Test Results:Fedora 24 Alpha TC1'. It's probably simpler
to just go with the label names, but if people are really used to the
TC/RC names we can stick with them if we choose option 2 or 3. It would
be difficult to keep them with option 1. I'm not sure what Dennis'
thoughts are on this.
As a final note, just so people are aware: all Pungi 4 composes have
compose IDs, so a 'production' compose with a label has *both* a
compose ID *and* a label. The compose ID for a production compose is, I
believe, something like 'Fedora-24-20160309.0' - it looks quite a lot
like a nightly compose ID, but without the '.n.' that denotes nightly.
There is no letter identifier for 'production' composes, they just omit
it entirely. This is mostly a thing for me to deal with in tooling,
though...
-- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net
8 years, 1 month
