On Wed, 2016-03-09 at 13:26 -0500, John Dulaney wrote:
> .
> >
> >
> > == 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.
> >
> I'm a fan of this approach, personally.
With weirdly-named RCs, or by adding a 'Final' milestone to Pungi?
-- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net
#5886: need method for distributing urgent fixes... urgently
------------------------------+------------------------------
Reporter: mattdm | Owner: rel-eng@…
Type: enhancement | Status: new
Milestone: Fedora 23 Alpha | Component: mash
Resolution: | Keywords: meeting planning
Blocked By: | Blocking:
------------------------------+------------------------------
Comment (by pfrields):
dgilmore, lmacken, nirik, maxamillion and I met about this ticket earlier.
We arrived at the consensus that if we can cut mash time down, we could
have updates ready to push in less than an hour, possibly considerably
less. There are some Koji fixes headed upstream that could help here, but
we don't know how long they'll take. In the meantime though, we know what
the problem is they address (file permissions that require cp versus
hardlink), and lmacken is going to try those fixes this week in staging to
compare performance. Both dgilmore and kevin will consult on ansible
fixes, etc. to help out.
We know there is also some time needed for MirrorManager to invalidate old
cache, but there are a few things we can do there as well. May tweak
mirrormanager to in specific cases to point everything to master mirrors +
ibiblio for an hour or two, until more mirrors synced. This *might*
obviate the need for a separate repo. We're keeping the separate repo on
the table as an alternative. Everyone agreed we can and should have this
fixed before F24 Beta.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5886#comment:37>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#5846: move away from md5 for look-aside cache
-------------------+-----------------------
Reporter: till | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Resolution: | Keywords:
Blocked By: | Blocking: 6111
-------------------+-----------------------
Comment (by bochecha):
There doesn't seem to be notification emails sent when I edited the
previous comment as things got done, so here's a new one to make sure
interested folks receive an email and know where we stand. :-)
As detailed in the previous comment, we are now at the point where we
could just flip the switch in fedpkg to start using the new {{{sources}}}
file format and sha512 hashes.
At least all the client code is ready and in all Fedora/EPEL branches. The
server code is ready as well and has been used for a few months already.
Now all that remains is decide when we do that cert change (ticket #6111)
and do this at the same time.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5846#comment:24>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2016-03-07 from 10:30:00 to 11:30:00 US/Central
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Fedora Release Engineering weekly meeting
Source: https://apps.fedoraproject.org/calendar/meeting/2026/
https://lists.fedorahosted.org/archives/list/koji-devel@lists.fedorahosted.…
According to that thread, there is a strong possibility that slow upload speeds of images in koji (from client to hub) could be related to the chunk size. We're looking to get a patch soon that will make that value configurable. In the meantime, is there a test server set up where you could manually change the value and see if it makes a difference? It's not urgent. I'm just curious. :)
-- Dennis
#6342: Broken dependencies - stable release not in repository after 5 days
---------------------+------------------------
Reporter: ondrejj | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
---------------------+------------------------
According to bodhi, python-configargparse package should be in stable
repository 2 days ago and has been released 5 days ago, but still not in
testing and/or stable repositories for Fedora 23.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-291dc1c23f
[root@work ~]# dnf --disablerepo=\* --enablerepo=updates --enablerepo
=updates-testing list python2-configargparse
Last metadata expiration check performed 0:31:50 ago on Wed Jan 27
09:19:09 2016.
Installed Packages
python2-configargparse.noarch 0.9.3-3.fc23
@updates
[root@work ~]#
Should be version 0.10.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6342>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6302: Please whitelist nosync for multilib
----------------------+------------------------
Reporter: msimacek | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: mash
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
nosync is a small library used by mock. It is installed in
/usr/lib/nosync/nosync.so, because it's supposed to be used only via
LD_PRELOAD (mock first copies it to buildroot). It seems that mash doesn't
recognize it as multilib, because it's not in standard library location.
Could it be whitelisted for being multilib?
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1283736
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6302>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project