comps and spin-kickstarts migration this friday (2016-05-13)

[Kevin Fenzi]

Greetings.

This friday (2016-05-13) at 16UTC we will be migrating: 

https://fedorahosted.org/comps/
https://fedorahosted.org/spin-kickstarts/

to

https://pagure.io/fedora-comps/
https://pagure.io/fedora-kickstarts/

With this migration we will be changing the workflow for 
changes to these repositories from a simple commit model 
to a pull request model. This means in order to make some 
change you should submit a pull request, which will be reviewed
by at least one other person and then pushed live into the 
repo. Initially commit on these new repos will be set to 
the pagure releng group, but more people will be added as needed.

This model will allow us to run CI tests on Pull Requests and 
confirm that they are not going to cause syntax errors 
or other simple breakage. Additionally, this will allow us 
to properly handle changes to these repos during milestone
Freezes (getting approval for a freeze break before pushing 
changes, etc). 

With the migration of the fedora-kickstarts project we will
also be trying to identify owner(s) for each kickstart file. 
This will allow us to properly assign issues to the 
folks that can address them. 

Thanks, 

kevin

[Bruno Wolff III]

On Mon, May 09, 2016 at 10:59:02 -0600,
  Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> This model will allow us to run CI tests on Pull Requests and
> confirm that they are not going to cause syntax errors
> or other simple breakage. Additionally, this will allow us
> to properly handle changes to these repos during milestone
> Freezes (getting approval for a freeze break before pushing
> changes, etc). 
Is there documentation on how to mark requests as requesting a freeze break 
as opposed to ones that can wait?

Are there going to be some rough guidelines for fixes that fix one spin, 
but break others? For example fixes for livebase or xfce have been known 
to put the games spin over size. The games spin is just a lab, so I think it 
is expected to adjust, but sometimes the changes come very late in the process 
and it can be hard to react in time to make cuts to get games back under 
size.

[Kevin Fenzi]

On Mon, 9 May 2016 13:08:12 -0500
Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  On Mon, May 09, 2016 at 10:59:02 -0600,
>    Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  >
>  >This model will allow us to run CI tests on Pull Requests and
>  >confirm that they are not going to cause syntax errors
>  >or other simple breakage. Additionally, this will allow us
>  >to properly handle changes to these repos during milestone
>  >Freezes (getting approval for a freeze break before pushing
>  >changes, etc).  
>  
>  Is there documentation on how to mark requests as requesting a freeze
>  break as opposed to ones that can wait? 
Well, I guess we need to bring that up with QA, but right now the
freeze process only uses bugzilla. So you would need to file a bugzilla
bug and mention the PR or the like on it. 

>  Are there going to be some rough guidelines for fixes that fix one
>  spin, but break others? For example fixes for livebase or xfce have
>  been known to put the games spin over size. The games spin is just a
>  lab, so I think it is expected to adjust, but sometimes the changes
>  come very late in the process and it can be hard to react in time to
>  make cuts to get games back under size.  
Well, I was hoping to make labels for each ks, so you could watch for
bugs with the label(s) you care about. If you saw a Xfce PR that came
in and affects games, you could comment on it before it's merged. 

kevin

[Bruno Wolff III]

On Mon, May 09, 2016 at 13:17:15 -0600,
  Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> Well, I guess we need to bring that up with QA, but right now the
> freeze process only uses bugzilla. So you would need to file a bugzilla
> bug and mention the PR or the like on it. 
But how are the people doing the PRs going to know? Are they expected to 
go look at the blocker bugs and see which are attached to PRs? That doesn't 
seem good. So I guessing there would need to be some comment on the pull 
request that says it's a blocker or freeze exception and points to the bug.

> Well, I was hoping to make labels for each ks, so you could watch for
> bugs with the label(s) you care about. If you saw a Xfce PR that came
> in and affects games, you could comment on it before it's merged. 
That would help. It isn't always clear that some change is going to add 
a lot of space (and some package updates do this as well) and it may not 
be obvious until the compose is done, and there may not be time to do 
another compose. Obviously, the earlier changes get made, the more time 
there is to adjust to downstream affects of those changes.

For games, I'd be interested in an automated warning about size since it 
happens so often. Though 4 GiB and 4.7 GB are starting to be less critical 
as people aren't using FAT and DVDs as much now. Once your over 4 GB, 
typically you need an 8GB USB flash drive, and Games is normally over 4 GB. 
I don't think we want it to get too large though, for mirroring reasons. But 
I do dislike having to make more cuts every release (except for the one when we 
got xz kernel support).

[Peter Robinson]

> > Well, I guess we need to bring that up with QA, but right now
> the
> > freeze process only uses bugzilla. So you would need to file a bugzilla
> > bug and mention the PR or the like on it.
>
>
>  But how are the people doing the PRs going to know? Are they expected to go
>  look at the blocker bugs and see which are attached to PRs? That doesn't
>  seem good. So I guessing there would need to be some comment on the pull
>  request that says it's a blocker or freeze exception and points to the bug. 
In the case of kickstarts it'll be rel-eng, we also do the composes, I
think we can put two and two together :-)

>> Well, I was hoping to make labels for each ks, so you could watch for
>> bugs with the label(s) you care about. If you saw a Xfce PR that came
>> in and affects games, you could comment on it before it's merged.
>
>
> That would help. It isn't always clear that some change is going to add a
> lot of space (and some package updates do this as well) and it may not be
> obvious until the compose is done, and there may not be time to do another
> compose. Obviously, the earlier changes get made, the more time there is to
> adjust to downstream affects of those changes.
>
> For games, I'd be interested in an automated warning about size since it
> happens so often. Though 4 GiB and 4.7 GB are starting to be less critical
> as people aren't using FAT and DVDs as much now. Once your over 4 GB,
> typically you need an 8GB USB flash drive, and Games is normally over 4 GB.
> I don't think we want it to get too large though, for mirroring reasons. But
> I do dislike having to make more cuts every release (except for the one when
> we got xz kernel support).
>
> _______________________________________________
> spins mailing list
> spins(a)lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/[e-mail]

[Kevin Fenzi]

On Mon, 9 May 2016 14:26:24 -0500
Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  On Mon, May 09, 2016 at 13:17:15 -0600,
>    Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  >
>  >Well, I guess we need to bring that up with QA, but right now the
>  >freeze process only uses bugzilla. So you would need to file a
>  >bugzilla bug and mention the PR or the like on it.  
>  
>  But how are the people doing the PRs going to know? Are they expected
>  to go look at the blocker bugs and see which are attached to PRs?
>  That doesn't seem good. So I guessing there would need to be some
>  comment on the pull request that says it's a blocker or freeze
>  exception and points to the bug. 
Sure, we will have to work out an exact process that works here... but
IMHO having a process instead of none at all will be a improvement. 

>  For games, I'd be interested in an automated warning about size
> since
>  it happens so often. Though 4 GiB and 4.7 GB are starting to be less
>  critical as people aren't using FAT and DVDs as much now. Once your
>  over 4 GB, typically you need an 8GB USB flash drive, and Games is
>  normally over 4 GB. I don't think we want it to get too large though,
>  for mirroring reasons. But I do dislike having to make more cuts
>  every release (except for the one when we got xz kernel support). 
Well, I am not sure how to do that... sounds more like a taskotron task
or a openqa test could be useful here. 

kevin

[Bruno Wolff III]

On Mon, May 09, 2016 at 13:54:07 -0600,
  Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> On Mon, 9 May 2016 14:26:24 -0500
> Bruno Wolff III <bruno(a)wolff.to&gt; wrote:
>
> > For games, I'd be interested in an automated warning about size since
> > it happens so often. Though 4 GiB and 4.7 GB are starting to be less 
> Well, I am not sure how to do that... sounds more like a taskotron task
> or a openqa test could be useful here. 
Yeah, that would be where I would expect it to be.

[Dennis Gilmore]

On Monday, May 9, 2016 2:26:24 PM CDT Bruno Wolff III wrote:
>  On Mon, May 09, 2016 at 13:17:15 -0600,
>  
>    Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  >Well, I guess we need to bring that up with QA, but right now the
>  >freeze process only uses bugzilla. So you would need to file a bugzilla
>  >bug and mention the PR or the like on it.
>  
>  But how are the people doing the PRs going to know? Are they expected to
>  go look at the blocker bugs and see which are attached to PRs? That doesn't
>  seem good. So I guessing there would need to be some comment on the pull
>  request that says it's a blocker or freeze exception and points to the bug.
>  
>  >Well, I was hoping to make labels for each ks, so you could watch for
>  >bugs with the label(s) you care about. If you saw a Xfce PR that came
>  >in and affects games, you could comment on it before it's merged.
>  
>  That would help. It isn't always clear that some change is going to add
>  a lot of space (and some package updates do this as well) and it may not
>  be obvious until the compose is done, and there may not be time to do
>  another compose. Obviously, the earlier changes get made, the more time
>  there is to adjust to downstream affects of those changes.
>  
>  For games, I'd be interested in an automated warning about size since it
>  happens so often. Though 4 GiB and 4.7 GB are starting to be less critical
>  as people aren't using FAT and DVDs as much now. Once your over 4 GB,
>  typically you need an 8GB USB flash drive, and Games is normally over 4 GB.
>  I don't think we want it to get too large though, for mirroring reasons. But
>  I do dislike having to make more cuts every release (except for the one
>  when we got xz kernel support). 
There was a chaneg in lorax that switches the filesystem to UDF if it is 
bigger than 4GiB so there should be no failures for going too big anymore.  
Have you seen any recently? if so can you point me to them so  we can get the 
bug updated.

Dennis

[Bruno Wolff III]

On Mon, May 09, 2016 at 18:15:26 -0500,
  Dennis Gilmore <dennis(a)ausil.us&gt; wrote:
> There was a chaneg in lorax that switches the filesystem to UDF if it is
> bigger than 4GiB so there should be no failures for going too big anymore.
> Have you seen any recently? if so can you point me to them so  we can get the
> bug updated. 
Builds work, but the only cases I saw had bad kernels, so I only tested as 
far as the bootloader menu, but it seemed to work as far as it got, and it 
seems likely it would finish booting with the current kernels.

The 4 GiB limit I was talking about in this thread was a limit imposed 
by the spins SIG when it was functional, several years ago. The lead at 
that time was concerned about Windows users not being able to successfully 
download images over 4 GiB because of file system limitations. I don't 
think that is a big worry today, but since the policy never was changed 
I have tried to keep Games under it. Also, if I hadn't made cuts, the 
Games spin would be much larger than 4 GiB as some of the games have 
gotten much larger, plus the base distribution has gotten significantly 
larger.

[Bruno Wolff III]

On Mon, May 09, 2016 at 13:17:15 -0600,
  Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> Well, I was hoping to make labels for each ks, so you could watch for
> bugs with the label(s) you care about. If you saw a Xfce PR that came
> in and affects games, you could comment on it before it's merged. 
Are commits going to still be sent to the spins list once they are 
pulled into the project?

I'm not sure that is necessary if people can get them sent directly to 
them from pagure.

Do the labels need to be set up by an admin, or can one go into pagure 
and flag which files for which you want to get notified of changes?

[Kevin Fenzi]

On Tue, 10 May 2016 10:45:33 -0500
Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  On Mon, May 09, 2016 at 13:17:15 -0600,
>    Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  >
>  >Well, I was hoping to make labels for each ks, so you could watch for
>  >bugs with the label(s) you care about. If you saw a Xfce PR that came
>  >in and affects games, you could comment on it before it's merged.  
>  
>  Are commits going to still be sent to the spins list once they are 
>  pulled into the project? 
Either way. I guess I would say we should since people expect that from
the way things are now?
>  
>  I'm not sure that is necessary if people can get them sent directly
>  to them from pagure. 
True... but I dont think it's too much burden either way. 

>  Do the labels need to be set up by an admin, or can one go into
>  pagure and flag which files for which you want to get notified of
>  changes?  
Yeah, I need to go setup the labels. There's no way to flag files to
notify that I know of. 

kevin

[Wolfgang Ulbrich]

Does that mean i need to do a PR as owner of mate-desktop and mate spin on every single
commit to comps and and fedora-kickstarts.
If yes....
-1 from me....
I'm maintaining all this alone and this steps makes all complicated and all takes more
time.

Wolfgang

[Bruno Wolff III]

On Mon, May 09, 2016 at 18:55:46 -0000,
  Wolfgang Ulbrich <raveit65(a)fedoraproject.org&gt; wrote:
> Does that mean i need to do a PR as owner of mate-desktop and mate
> spin on every single commit to comps and and fedora-kickstarts. 
A pull request is a request to merge a branch. As such it can include multiple 
commits. So technically, you don't need to do a pull request per commit. 
However, for spins where often commits are widely separated in time, in 
practice it might end up being a pull request per commit most of the time.

[Kevin Fenzi]

On Mon, 09 May 2016 18:55:46 -0000
"Wolfgang Ulbrich" <raveit65(a)fedoraproject.org&gt; wrote:

>  Does that mean i need to do a PR as owner of mate-desktop and mate
>  spin on every single commit to comps and and fedora-kickstarts. If
>  yes.... -1 from me....
>  I'm maintaining all this alone and this steps makes all complicated
>  and all takes more time. 
Yes, it would... but I don't think it's that much more work and it
would allow others to review changes and run checks on commits before
they land. 

You have commited 2 x to spin-kickstarts this year so far and 7 times
to comps, that doesn't sound like too many PRs to me... 

I suppose we could look at just granting maintainers of ks'es commit,
but the problem there is that we would be back to not having a way to
queue up changes during freeze. 

kevin

[Bruno Wolff III]

On Mon, May 09, 2016 at 13:20:06 -0600,
  Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> I suppose we could look at just granting maintainers of ks'es commit,
> but the problem there is that we would be back to not having a way to
> queue up changes during freeze. 
Having a way to take only some changes (in any order) is important. I don't 
think we want to give that up.

The other way to do that would be to have a separate branch for each freeze. 
But I think that would end being more work trying to cherry pick changes 
into and they would probably end up being dead end branches unless we 
wanted to do even more work merging the develoment and freeze branches 
back together after each freeze.

I don't see the pull requests as being a big deal for development, since it 
won't add too much work to the occasional fix, and for bigger projects 
where their are many commits, they can be batched together. Getting code 
reviewed outside of freezes might be a problem. For spins without multiple 
active developers, recruiting help for reviews might end up being a pain.

[Kevin Fenzi]

On Mon, 9 May 2016 14:37:45 -0500
Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  On Mon, May 09, 2016 at 13:20:06 -0600,
>    Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  >
>  >I suppose we could look at just granting maintainers of ks'es commit,
>  >but the problem there is that we would be back to not having a way to
>  >queue up changes during freeze.  
>  
>  Having a way to take only some changes (in any order) is important. I
>  don't think we want to give that up.
>  
>  The other way to do that would be to have a separate branch for each
>  freeze. But I think that would end being more work trying to cherry
>  pick changes into and they would probably end up being dead end
>  branches unless we wanted to do even more work merging the develoment
>  and freeze branches back together after each freeze. 
Pull requests are really basically this, just with a branch in a users
forked version of the repo instead of cluttering up the repo
directly. ;) 

>  I don't see the pull requests as being a big deal for
> development,
>  since it won't add too much work to the occasional fix, and for
>  bigger projects where their are many commits, they can be batched
>  together. Getting code reviewed outside of freezes might be a
>  problem. For spins without multiple active developers, recruiting
>  help for reviews might end up being a pain. 
Well, releng is owning the project, so releng is also commiting to
reviewing PR's in a timely manner. If they aren't getting reviewed in a
timely manner we should revisit how the workflow is setup. 

kevin

[Peter Robinson]

> > I suppose we could look at just granting maintainers of ks'es
> commit,
> > but the problem there is that we would be back to not having a way to
> > queue up changes during freeze.
>
>
>  Having a way to take only some changes (in any order) is important. I don't
>  think we want to give that up. 
We don't have a way to take it in any order now, we take it from the
branch head, that goes in the order that things are landed into git.

The advantage of the new way is that rel-eng or QA can hold pull
requests that aren't blockers until post freeze and can apply the PRs
that are needed for a blocking issue which actually gives us more
flexibility on what lands and what doesn't so I actually think the new
method is actually more flexible for this.

>  The other way to do that would be to have a separate branch for each
> freeze.
>  But I think that would end being more work trying to cherry pick changes
>  into and they would probably end up being dead end branches unless we wanted
>  to do even more work merging the develoment and freeze branches back
>  together after each freeze. 
Yes, and it doesn't provide us more than complexity, the PRs can act
as a a gating mechanism that would provide similar functionality with
no extra complexity.

>  I don't see the pull requests as being a big deal for
> development, since it
>  won't add too much work to the occasional fix, and for bigger projects where
>  their are many commits, they can be batched together. Getting code reviewed
>  outside of freezes might be a problem. For spins without multiple active
>  developers, recruiting help for reviews might end up being a pain. 
There really isn't that much churn in the kickstarts compared to other
areas of the project, I don't see this to be a major problem, if it is
we can adjust the process, it's not set in stone and we can evolve it
as necessary.

Peter

[Bruno Wolff III]

On Mon, May 09, 2016 at 20:56:54 +0100,
  Peter Robinson <pbrobinson(a)gmail.com&gt; wrote:
> >> I suppose we could look at just granting maintainers of
> ks'es commit,
> >> but the problem there is that we would be back to not having a way to
> >> queue up changes during freeze.
> >
> >
> > Having a way to take only some changes (in any order) is important. I don't
> > think we want to give that up.
>
> We don't have a way to take it in any order now, we take it from the
> branch head, that goes in the order that things are landed into git. 
The context I was talking about was with the new system. I was arguing against 
allow ks owners direct commit access.

> The advantage of the new way is that rel-eng or QA can hold pull
> requests that aren't blockers until post freeze and can apply the PRs
> that are needed for a blocking issue which actually gives us more
> flexibility on what lands and what doesn't so I actually think the new
> method is actually more flexible for this. 
I agree that this is a very nice improvement over what is there today.

> > The other way to do that would be to have a separate branch for each freeze.
> > But I think that would end being more work trying to cherry pick changes
> > into and they would probably end up being dead end branches unless we wanted
> > to do even more work merging the develoment and freeze branches back
> > together after each freeze.
>
> Yes, and it doesn't provide us more than complexity, the PRs can act
> as a a gating mechanism that would provide similar functionality with
> no extra complexity. 
That is more or less what I meant. That saving a little work for the spin 
owners was going to create significantly more work for other people. I think 
we owners need to take on a little more work to have a better product 
without taking up even more of relengs time. As releng time is a critical 
resource.

[Amit Saha]

Hi Kevin,

On Tue, May 10, 2016 at 2:59 AM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  Greetings.
>
>  This friday (2016-05-13) at 16UTC we will be migrating:
>
>  https://fedorahosted.org/comps/
>  https://fedorahosted.org/spin-kickstarts/
>
>  to
>
>  https://pagure.io/fedora-comps/
>  https://pagure.io/fedora-kickstarts/ 
+1, https://pagure.io/fedora-kickstarts/ gives me 404?


>  With this migration we will be changing the workflow for
>  changes to these repositories from a simple commit model
>  to a pull request model. This means in order to make some
>  change you should submit a pull request, which will be reviewed
>  by at least one other person and then pushed live into the
>  repo. Initially commit on these new repos will be set to
>  the pagure releng group, but more people will be added as needed.
>
>  This model will allow us to run CI tests on Pull Requests and
>  confirm that they are not going to cause syntax errors
>  or other simple breakage. Additionally, this will allow us
>  to properly handle changes to these repos during milestone
>  Freezes (getting approval for a freeze break before pushing
>  changes, etc).
>
>  With the migration of the fedora-kickstarts project we will
>  also be trying to identify owner(s) for each kickstart file.
>  This will allow us to properly assign issues to the
>  folks that can address them.
>
>  Thanks,
>
>  kevin
>
>  _______________________________________________
>  spins mailing list
>  spins(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]
>  


-- 
http://echorand.me

[Bruno Wolff III]

On Tue, May 10, 2016 at 09:28:08 +1000,
  Amit Saha <amitsaha.in(a)gmail.com&gt; wrote:
> Hi Kevin,
>
> On Tue, May 10, 2016 at 2:59 AM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> > Greetings.
> >
> > This friday (2016-05-13) at 16UTC we will be migrating:
> >
>
> +1, https://pagure.io/fedora-kickstarts/ gives me 404? 
The change doesn't happen until Friday.

[Kevin Fenzi]

On Mon, 9 May 2016 20:08:16 -0500
Bruno Wolff III <bruno(a)wolff.to&gt; wrote:

>  On Tue, May 10, 2016 at 09:28:08 +1000,
>    Amit Saha <amitsaha.in(a)gmail.com&gt; wrote:
>  >Hi Kevin,
>  >
>  >On Tue, May 10, 2016 at 2:59 AM, Kevin Fenzi <kevin(a)scrye.com&gt;
>  >wrote:  
>  >> Greetings.
>  >>
>  >> This friday (2016-05-13) at 16UTC we will be migrating:
>  >>  
>  >
>  >+1, https://pagure.io/fedora-kickstarts/ gives me 404?  
>  
>  The change doesn't happen until Friday. 
Yeah, I did create the project, but I haven't configured it yet. 

It turns out https://pagure.io/fedora-kickstarts/ won't work, but
https://pagure.io/fedora-kickstarts will (trailing slash). I guess
thats a pagure bug... 

kevin

[Luya Tshimbalanga]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/05/16 09:59 AM, Kevin Fenzi wrote:
>  Greetings. > > This friday (2016-05-13) at 16UTC we will be
> migrating: > > 
https://fedorahosted.org/comps/ >
https://fedorahosted.org/spin-kickstarts/ > > to > >
https://pagure.io/fedora-comps/ > https://pagure.io/fedora-kickstarts/ >
>  With this migration we will be changing the workflow for > changes
> to 
these repositories from a simple commit model > to a pull request model.
This means in order to make some > change you should submit a pull
request, which will be reviewed > by at least one other person and then
pushed live into the > repo. Initially commit on these new repos will be
set to > the pagure releng group, but more people will be added as
needed. > > This model will allow us to run CI tests on Pull Requests
and > confirm that they are not going to cause syntax errors > or other
simple breakage. Additionally, this will allow us > to properly handle
changes to these repos during milestone > Freezes (getting approval for
a freeze break before pushing > changes, etc).
Hopefully the migration addresses one of Ananconda issue that prevents
Design Suite to properly build since Beta Test 1.6.
http://koji.fedoraproject.org/koji/getfile?taskID=13993067&name=livem...

- -- 
Luya Tshimbalanga
Graphic & Web Designer
E: luya(a)fedoraproject.org
W: http://www.coolest-storm.net
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJXMh2vAAoJEF5SgXTYomCazbAH/Rda+nIV4brMlNJ8BPrpD2IO
> jVbR6HsGAl9VVTPiToaP4hUaktBs/tI9lGUEPRACJR/sMeFF0Q0dLFrgUg7D47E2
> oD++8mBsA+ySFVsbqDIGI/8vw6UvEZoTR15/VnpzdVpppUE42oCTQ++VoGpJMvbN
> EaccBPAwxHc2pmmaXiAbd9aAvgMIwoHZZ7bjVrTr587b3Vvki5GNAs3ZOGIYjMPK
> 6S1B62AiqbF/vpZF895mZ6683YpL2U+69b5Mtr0iLOSuClNjiatUic92kFsQ1cxF
> VM1DhMl3qzDDmFR0BI+7C3ObbVzV1Q7IPiUxKjln0MfspUou8tQ/4STuoNqv2vw=
> =uefG
> -----END PGP SIGNATURE-----

[Kevin Fenzi]

On Tue, 10 May 2016 10:43:14 -0700
Luya Tshimbalanga <luya(a)fedoraproject.org&gt; wrote:

>  Hopefully the migration addresses one of Ananconda issue that
> prevents
>  Design Suite to properly build since Beta Test 1.6.
>
> http://koji.fedoraproject.org/koji/getfile?taskID=13993067&name=livem...
Nope, it has nothing to do with that... thats a bug in lorax or
something deeper. 

https://bugzilla.redhat.com/show_bug.cgi?id=1315541

But that bug is proposed as a final blocker now. 

kevin