Re: RFC: Primary architecture promotion requirements

[Adam Williamson]

On Mon, 2012-04-23 at 12:59 -0700, Brendan Conoboy wrote:

> It's not about anaconda specifically, it's about having a standard 
> installer experience across all PAs to the extent technically sensible. 
>   Maybe something else will supplant anaconda in time.

FWIW, in writing the QA release criteria, we used the generic term 'the
installer' rather than the specific 'anaconda' to avoid this kind of
ambiguity. In general I tend to prefer the use of generic terms in this
kind of policy document for exactly this reason - to acknowledge and
protect against the possibility of the currently-favoured implementation
of any particular thing changing in future.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jared K. Smith]

On Tue, Apr 24, 2012 at 1:05 PM, Brian C. Lane  wrote:
> That's why I recently added EC2 support to livemedia-creator. Since I
> don't have an EC2 account it is untested -- help would be appreciated.

Awesome.  I'll try to check it out in the next week or so.

> We should be able to make images using livemedia-creator -- It needs to
> be run on the target hardware though, currently there is no cross-arch
> support. The last I heard from ARM was that Anaconda wasn't built for
> ARM.

I know the folks up at Seneca have been working on building it for ARM
-- I've been a bit out of the ARM loop the last couple of weeks, so I
don't know the very latest status.  I'll try to find out in tomorrow's
ARM meeting.

> The goal of creating lmc was to use Anaconda's logic for all installs,
> including creating system images or live media.. This will increase
> reliability and cut down on the number of bugs we see because
> livecd-creator really is just a wrapper around a yum chroot install.

Yes, I'm well aware of the goals behind lmc, and I think it's
definitely a better way forward.

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brian C. Lane]

On Mon, Apr 23, 2012 at 04:13:40PM -0400, Jared K. Smith wrote:
> On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett  wrote:
> > Because if you have hardware that can install via Anaconda and you don't
> > support installing via Anaconda, you're not Fedora.
> 
> Just for the sake of argument, our Amazon EC2 images aren't using
> Anaconda for installation, but they're still considered part of
> Fedora.

That's why I recently added EC2 support to livemedia-creator. Since I
don't have an EC2 account it is untested -- help would be appreciated.

> 
> I agree with the sentiment that Anaconda should be a requirement for
> instances where it makes sense to boot from bootable media
> (DVD/CD/USB) and install via Anaconda, but in the case of ARM, the
> traditional installation method is often "copy an image to an SD (or
> micro-SD) card and then boot from that card.  Just to make sure I'm
> clear, are you insisting that the software tool that puts the image on
> the SD card be Anaconda, or are you OK with some other Fedora-approved
> tool for doing so?

We should be able to make images using livemedia-creator -- It needs to
be run on the target hardware though, currently there is no cross-arch
support. The last I heard from ARM was that Anaconda wasn't built for
ARM.

The goal of creating lmc was to use Anaconda's logic for all installs,
including creating system images or live media.. This will increase
reliability and cut down on the number of bugs we see because
livecd-creator really is just a wrapper around a yum chroot install.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


pgpcYXr3qDGUi.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 10:08:54PM +, "Jóhann B. Guðmundsson" wrote:

> What is the justification for the need for the seperation in the firstplace?

You'd be fine with Fedora m68k? We have the separation because it's not 
just about scratching your own itch. Each additional supported 
architecture means that teams who are already overworked have to look 
after even more moving parts. Architecture-specific bugs are a pain for 
package maintainers to deal with. Attaching the Fedora name to poorly 
maintained ports weakens our brand. If we're going to support an 
architecture then its maintainers need to prove that they can maintain 
it.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 09:07 PM, Bill Nottingham wrote:

Fedora's about providing a consistent experience wherever possible; this
means using consistent interactive installation tools


It's not enough to always be using the same tools but those tools need 
to be consitent in usage as well so for your noble goal now try putting 
consistency and Anaconda in the same sentence =)


All jokes aside and focusing on a bit more broader but fundemental 
question so I and perhaps some others can get a better understanding why 
things are as they are in the 21 first century.


Why do we distinquish between architectures in the first place and what 
do we hope to achive or otherwise gain from doing that in a community 
that first and foremost is about scratching your own itch ( at least for 
some of us )?


What is the justification for the need for the seperation in the firstplace?

JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> On 04/23/2012 08:14 PM, Jared K. Smith wrote:
> >>>  Fesco is saying that if you have hardware that can install via Anaconda,
> >>>  you must support installing via Anaconda. It's legitimate for you to
> >>>  also have other install mechanisms, and hardware that's incapable of
> >>>  supporting Anaconda installs isn't required to have them.
> >Thanks for the clarification.  I just wanted to make sure I understood that.
> 
> FESCo should make that more clear in the requirements but even if
> they do they still make secondary architecture solely depended upon
> the will and the time of someone within the "Installer team" to
> implement the solution required to install Fedora for their
> architecture before they can become primary architecture.

There are these magical things called patches that can be submitted.
Much like the secondary arch team would need to do so for the kernel
(also mentioned in the guidelines), the X maintainers (also mentioned
in the guidelines), etc. Unless you're suggesting secondary arch
maintainers are somehow unable to do so?

Fedora's about providing a consistent experience wherever possible; this
means using consistent interactive installation tools, consistent image
creation tools, and so on.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 08:57:47PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 08:14 PM, Jared K. Smith wrote:
> >>>  Fesco is saying that if you have hardware that can install via Anaconda,
> >>>  you must support installing via Anaconda. It's legitimate for you to
> >>>  also have other install mechanisms, and hardware that's incapable of
> >>>  supporting Anaconda installs isn't required to have them.
> >Thanks for the clarification.  I just wanted to make sure I understood that.
> 
> FESCo should make that more clear in the requirements but even if
> they do they still make secondary architecture solely depended upon
> the will and the time of someone within the "Installer team" to
> implement the solution required to install Fedora for their
> architecture before they can become primary architecture.

Yes, in the same way that they need someone in the kernel team to build 
them a kernel. It's a package. It's under active development. It just 
needs someone on the architecture to write the code.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 08:14 PM, Jared K. Smith wrote:

>  Fesco is saying that if you have hardware that can install via Anaconda,
>  you must support installing via Anaconda. It's legitimate for you to
>  also have other install mechanisms, and hardware that's incapable of
>  supporting Anaconda installs isn't required to have them.

Thanks for the clarification.  I just wanted to make sure I understood that.


FESCo should make that more clear in the requirements but even if they 
do they still make secondary architecture solely depended upon the will 
and the time of someone within the "Installer team" to implement the 
solution required to install Fedora for their architecture before they 
can become primary architecture.


That can mean from never to having to wait for several release cycles 
before becoming primary architecture for the distribution.


From my point of view that makes absolutly no sense and the 
requirements should be refactored to require an working installation 
method...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 08:29:59PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 07:45 PM, Bill Nottingham wrote:
> >We shouldn't be promoting anything to primary arch that you can't install.
> 
> Valid point but it still does not explain why FESCo chose to limit
> that exclusively to Anaconda and the "Installer team" and their
> installation methods or lack there of.

ARM is moving into the server and laptop space. There's an expectation 
that devices of that nature can be installed using Anaconda. If a port 
is only supporting embedded devices where Anaconda makes no sense then 
that's fine, but if it's supporting other hardware classes then it needs 
to have a working Anaconda. I've no idea why this is controversial.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 07:45 PM, Bill Nottingham wrote:

We shouldn't be promoting anything to primary arch that you can't install.


Valid point but it still does not explain why FESCo chose to limit that 
exclusively to Anaconda and the "Installer team" and their installation 
methods or lack there of.



Sorry guys your arch will have to wait to become primary until Anaconda 
and the "Installer team" has


a) Decided
b) Designed
c) Implemented

How to install your arch.



But our user base already can install via this method here and we 
actually preferred they did..



Sorry no flag no country those are the rules so if you want to sail 
under the Fedora flag you have to ride the snake...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jon Ciesla]

On Mon, Apr 23, 2012 at 3:13 PM, Jared K. Smith
 wrote:
> On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett  wrote:
>> Because if you have hardware that can install via Anaconda and you don't
>> support installing via Anaconda, you're not Fedora.
>
> Just for the sake of argument, our Amazon EC2 images aren't using
> Anaconda for installation, but they're still considered part of
> Fedora.

I think that's more akin to a spin.

> I agree with the sentiment that Anaconda should be a requirement for
> instances where it makes sense to boot from bootable media
> (DVD/CD/USB) and install via Anaconda, but in the case of ARM, the
> traditional installation method is often "copy an image to an SD (or
> micro-SD) card and then boot from that card.  Just to make sure I'm
> clear, are you insisting that the software tool that puts the image on
> the SD card be Anaconda, or are you OK with some other Fedora-approved
> tool for doing so?
>
> --
> Jared Smith
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jared K. Smith]

On Mon, Apr 23, 2012 at 4:00 PM, Matthew Garrett  wrote:
> Fesco is saying that if you have hardware that can install via Anaconda,
> you must support installing via Anaconda. It's legitimate for you to
> also have other install mechanisms, and hardware that's incapable of
> supporting Anaconda installs isn't required to have them.

Thanks for the clarification.  I just wanted to make sure I understood that.

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jared K. Smith]

On Mon, Apr 23, 2012 at 3:42 PM, Matthew Garrett  wrote:
> Because if you have hardware that can install via Anaconda and you don't
> support installing via Anaconda, you're not Fedora.

Just for the sake of argument, our Amazon EC2 images aren't using
Anaconda for installation, but they're still considered part of
Fedora.

I agree with the sentiment that Anaconda should be a requirement for
instances where it makes sense to boot from bootable media
(DVD/CD/USB) and install via Anaconda, but in the case of ARM, the
traditional installation method is often "copy an image to an SD (or
micro-SD) card and then boot from that card.  Just to make sure I'm
clear, are you insisting that the software tool that puts the image on
the SD card be Anaconda, or are you OK with some other Fedora-approved
tool for doing so?

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 07:54:57PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 07:42 PM, Matthew Garrett wrote:
> >Because if you have hardware that can install via Anaconda and you don't
> >support installing via Anaconda, you're not Fedora.
> So FESCo is in otherwords saying that other installers and even
> installing methods ( think like the distribution would be flashed to
> a device in the maybe not to distant future instead of being
> installed in the traditional sense as we know it to be ) are not
> allowed or otherwise considered to be part of the distribution
> should some community members want to writer and or package an
> alternative installer to ship and use on their spin?

Fesco is saying that if you have hardware that can install via Anaconda, 
you must support installing via Anaconda. It's legitimate for you to 
also have other install mechanisms, and hardware that's incapable of 
supporting Anaconda installs isn't required to have them.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 04/23/2012 12:54 PM, "Jóhann B. Guðmundsson" wrote:

So FESCo is in otherwords saying that other installers and even
installing methods ( think like the distribution would be flashed to a
device in the maybe not to distant future instead of being installed in
the traditional sense as we know it to be ) are not allowed or otherwise
considered to be part of the distribution should some community members
want to writer and or package an alternative installer to ship and use
on their spin?


It's not about anaconda specifically, it's about having a standard 
installer experience across all PAs to the extent technically sensible. 
 Maybe something else will supplant anaconda in time.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jon Ciesla]

2012/4/23 "Jóhann B. Guðmundsson" :
> On 04/23/2012 07:42 PM, Matthew Garrett wrote:
>>
>> Because if you have hardware that can install via Anaconda and you don't
>> support installing via Anaconda, you're not Fedora.
>
> So FESCo is in otherwords saying that other installers and even installing
> methods ( think like the distribution would be flashed to a device in the
> maybe not to distant future instead of being installed in the traditional
> sense as we know it to be ) are not allowed or otherwise considered to be
> part of the distribution should some community members want to writer and or
> package an alternative installer to ship and use on their spin?

I think it wasn't so much forbidding alternate methods as requiring
that the primary one be supported.

-J

> JBG
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

-d. bowie
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 07:42 PM, Matthew Garrett wrote:

Because if you have hardware that can install via Anaconda and you don't
support installing via Anaconda, you're not Fedora.
So FESCo is in otherwords saying that other installers and even 
installing methods ( think like the distribution would be flashed to a 
device in the maybe not to distant future instead of being installed in 
the traditional sense as we know it to be ) are not allowed or otherwise 
considered to be part of the distribution should some community members 
want to writer and or package an alternative installer to ship and use 
on their spin?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johan...@gmail.com) said: 
> On 04/23/2012 07:00 PM, Matthew Garrett wrote:
> >After some tweaking, these are now accepted as
> >https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements
> >
> 
> Fail to see the reasoning why Anaconda and the "Installer team" are
> involved in these requirements care to elaborate how/why FESCo fits
> them into the bigger picture?

We shouldn't be promoting anything to primary arch that you can't install.

Bill
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Mon, Apr 23, 2012 at 07:33:44PM +, "Jóhann B. Guðmundsson" wrote:
> On 04/23/2012 07:00 PM, Matthew Garrett wrote:
> >After some tweaking, these are now accepted as
> >https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements
> >
> 
> Fail to see the reasoning why Anaconda and the "Installer team" are
> involved in these requirements care to elaborate how/why FESCo fits
> them into the bigger picture?

Because if you have hardware that can install via Anaconda and you don't 
support installing via Anaconda, you're not Fedora.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jóhann B. Guðmundsson]

On 04/23/2012 07:00 PM, Matthew Garrett wrote:

After some tweaking, these are now accepted as
https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements



Fail to see the reasoning why Anaconda and the "Installer team" are 
involved in these requirements care to elaborate how/why FESCo fits them 
into the bigger picture?


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

After some tweaking, these are now accepted as 
https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Miloslav Trmač]

On Mon, Apr 2, 2012 at 4:45 PM, Matthew Garrett  wrote:
> Now at
> http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29

FESCo would welcome more discussion of this draft, and plans to vote
on it next week.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Wed, Mar 28, 2012 at 10:11:35PM +0100, Matthew Garrett wrote:
> I'm planning on moving this to the Wiki (as a draft) at the end of the 
> week, so if people have any further feedback please let me know.

Now at 
http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

I'm planning on moving this to the Wiki (as a draft) at the end of the 
week, so if people have any further feedback please let me know.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Kevin Kofler]

drago01 wrote:

> On Thu, Mar 22, 2012 at 1:56 AM, Kevin Kofler 
> wrote:
>> I'm surprised emulating ARM in QEMU is so much faster than qemu-system-
>> x86_64
>> (which was how I measured the 50 times).
> 
> Given that x86_64 is way more complex then ARM it is not *that*
> surprising.

I think the fact that they're using userspace emulation rather than system 
emulation is actually the biggest difference to the setup I was using, and 
accounts for a significant part of the difference in slowdown. (Note that 
userspace emulation wasn't an option at all in my setup, for x86_64 on 32-
bit x86.) To know for sure, we'd have to measure how long it takes to do 
builds with qemu-system-arm, assuming we can get that to work at all.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Richard W.M. Jones]

On Wed, Mar 21, 2012 at 01:11:27PM -0500, Dennis Gilmore wrote:
> I have spoken with the OpenSUSE guys they dont use qemu-system-arm but
> rather qemu-arm and lay out things and build using a hybrid
> environment  thats also how they build ppc s390 and other arches. the
> only build hardware they have is x86. doing full system emulation will
> be slower. 

In case it's not clear to the peanut gallery, qemu-system-arm and
qemu-arm work in different ways. 

qemu-system-arm emulates a complete machine, so your ARM kernel is
also running and being emulated.  qemu-arm just emulates the userspace
part of the program, but translates system calls from the program and
runs them against the regular (x86-64 in this case) kernel.

qemu-arm should be a lot faster, since the kernel part is running at
full speed.  On the other hand, there's some start-up overhead for
every process run this way.

I should also say that in both cases qemu's "TCG" emulation is
reasonably smart, and recompiles guest ARM code on the fly down to
native (x86-64 in this case) code.  Recommended reading:
http://lugatgt.org/content/qemu_internals/downloads/slides.pdf

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jon Masters]

On 03/20/2012 06:51 PM, Brendan Conoboy wrote:
> On 03/20/2012 03:33 PM, Jesse Keating wrote:

>> "doing all of these things" doesn't happen magically just because the
>> board/fesco grants that ARM is suddenly a primary arch. If we made arm a
>> primary arch tomorrow, you'd still have to solve all the above issues,
>> only now you've got hundreds of very angry developers who's workflow is
>> now severely interrupted, and they're all calling for your head. Doesn't
>> it make more sense to solve these issues /before/ doing the promotion?
>> Figure out how to make the car go 60mph before taking it onto the
>> freeway, else you'll piss off all the other cars on the freeway.
> 
> Absolutely.  We're having this discussion as a way to solve the issues 
> before promotion.  None of us expect ARM to be promoted today, or 
> tomorrow, but perhaps 3-5 months from now is realistic.  Or maybe that's 
> too soon.  The bottom line is that there are issues to be worked out and 
> that's what has prompted the discussion.

I think this is the best takeway from the thread I've seen so far. We're
trying to figure out where to go to get to PA. If it turns out F18 is
wildly optimistic, ok, no problem. We'll come back later after we get
all the kinks ironed out. But the past few days have provided invaluable
initial input as we figure out how to drive at 60mph, while also giving
you greater than 60mpg in power/performance :)

Jon.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Martin Langhoff]

On Wed, Mar 21, 2012 at 6:07 AM, Jaroslav Reznik  wrote:
> Maybe a distribution of PandaBoards/R-Pi for every FAS account holder could
> help, any sponsor? :D

OLPC is starting mass production of XO-1.75 units, based on an ARMv7
Marvell Armada 610. School kids in Uruguay and Nicaragua will start
their school year with them, using a F14 ARM build. Peter Robinson has
been instrumental in making this happen (and of course thanks to all
the ARM porters).

We have free units for Fedora developers that are interested -- we'll
ship them for free anywhere in the world. The numbers are limited (we
are a non-profit), apply for units here:

  http://wiki.laptop.org/go/Contributors_program#FAQ

Some additional discussion:
http://lists.fedoraproject.org/pipermail/arm/2011-July/001661.html

In the form, you can state that your project is porting Fedora to
ARMv7 ensuring it runs great on XO-1.75 :-) and mention what packages
you're working on, or if you are or intend to be part of the Fedora
ARM porters team, state so. We're on the fedora-arm mailing list,
we'll know you :-)

F17 upgrade is coming midyear, which will give these units a big kick
in the pants in terms of performance. After that, we are cooking some
bold sw+hw plans for the future. All based on ARM.

cheers,



m
-- 
 martin.langh...@gmail.com
 mar...@laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Chris Murphy]

On Mar 22, 2012, at 5:33 AM, Peter Robinson wrote:
> 
> That depends, in the developed western world probably not, in the
> developing world most users are just going straight to smartphones and
> tablets and not bothering with desktops/laptops at all. The reasons
> for this is low power and price.

Exactly. Power, price, infrastructure, space. 

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Thu, Mar 22, 2012 at 11:27 AM, Tomas Mraz  wrote:
> On Thu, 2012-03-22 at 12:57 +0200, Nikos Roussos wrote:
>> On Tue, Mar 20, 2012 at 7:54 PM, Kevin Kofler 
>> wrote:
>>         > What do people buy these days? Phones, tablets, and TVs. Not
>>         desktop
>>         > computers.
>>
>>
>>         Citation needed. Desktop/notebook computers aren't going to go
>>         away any time
>>         soon.
>>
>> http://www.economist.com/node/21531109
>> with some interesting charts
>
> Which is actually confirmation of the previous sentence. The
> smartphones, tablets and similar devices together are growing much much
> faster than desktops and notebooks and are already much bigger market
> but they are not replacement for the desktops and notebooks.

That depends, in the developed western world probably not, in the
developing world most users are just going straight to smartphones and
tablets and not bothering with desktops/laptops at all. The reasons
for this is low power and price. In those areas desktops are dead and
the increase in usage in this markets is 100s of millions of devices
are year and for a lot of users it's their only means of accessing the
internet and associated information.

> Which also supports the idea of having Fedora support both of these
> groups of computing devices well.

Exactly one of the primary drivers for us to open up the discussion.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Tomas Mraz]

On Thu, 2012-03-22 at 12:57 +0200, Nikos Roussos wrote: 
> On Tue, Mar 20, 2012 at 7:54 PM, Kevin Kofler 
> wrote:
> > What do people buy these days? Phones, tablets, and TVs. Not
> desktop 
> > computers.
> 
> 
> Citation needed. Desktop/notebook computers aren't going to go
> away any time
> soon. 
>  
> http://www.economist.com/node/21531109
> with some interesting charts

Which is actually confirmation of the previous sentence. The
smartphones, tablets and similar devices together are growing much much
faster than desktops and notebooks and are already much bigger market
but they are not replacement for the desktops and notebooks.

Which also supports the idea of having Fedora support both of these
groups of computing devices well. 
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Nikos Roussos]

On Tue, Mar 20, 2012 at 7:54 PM, Kevin Kofler wrote:

> > What do people buy these days? Phones, tablets, and TVs. Not desktop
> > computers.
>
> Citation needed. Desktop/notebook computers aren't going to go away any
> time
> soon.


http://www.economist.com/node/21531109
with some interesting charts

-- 
Nikos Roussos 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[drago01]

On Wed, Mar 21, 2012 at 7:59 PM, Brendan Conoboy  wrote:
> On 03/21/2012 11:18 AM, drago01 wrote:
>>
>> But there seems to be a huge oppositions against that in Fedora.
>> How does Ubuntu build there ARM builds? Native or using cross compilers?
>
>
> Native.

OK kind of unexpected though.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[drago01]

On Thu, Mar 22, 2012 at 8:32 AM, drago01  wrote:
> On Thu, Mar 22, 2012 at 1:56 AM, Kevin Kofler  wrote:
>> drago01 wrote:
>>> Those numbers look way better then Kevin's "50x slower without any
>>> citation" ... thanks for getting this numbers.
>>
>> I'm surprised emulating ARM in QEMU is so much faster than qemu-system-
>> x86_64
>> (which was how I measured the 50 times).
>
> Given that x86_64 is way more complex then ARM it is not *that* surprising.
>
>>Are they really using QEMU
>> for everything or are they actually using host or cross tools (and QEMU only
>> for when the build process is trying to run a just built binary)?
>
> The later i.e cross tools + user emulation for binaries.

OK as Dennis said it seems they also run the compilers through qemu.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[drago01]

On Thu, Mar 22, 2012 at 1:56 AM, Kevin Kofler  wrote:
> drago01 wrote:
>> Those numbers look way better then Kevin's "50x slower without any
>> citation" ... thanks for getting this numbers.
>
> I'm surprised emulating ARM in QEMU is so much faster than qemu-system-
> x86_64
> (which was how I measured the 50 times).

Given that x86_64 is way more complex then ARM it is not *that* surprising.

>Are they really using QEMU
> for everything or are they actually using host or cross tools (and QEMU only
> for when the build process is trying to run a just built binary)?

The later i.e cross tools + user emulation for binaries.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 22 Mar 2012 02:02:59 +0100
Kevin Kofler  wrote:

> Jesse Keating wrote:
> > Arm emulation would go a long way toward validating produced install
> > images too.  Those of us that validate x86 images depend heavily on
> > KVM and the like.
> 
> But full system emulation is slower by a LARGE factor, not merely the
> 2 to 4 Jaroslav quoted for OBS, which (according to Dennis) is using
> a hybrid setup including some host and cross tools and QEMU userspace
> emulation as a fallback, NOT full system emulation.
> 
> Kevin Kofler
> 

its not using cross tools at all and i never said it is. They use
qemu-arm to run the processes they run all arm binaries. rather than
emulating the full system they run the processes emulated.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9qpwQACgkQkSxm47BaWff+GgCfcmHo7SspYuQXZDsxceXyU9VY
pZsAoJH9xJcN6b4zJ/LgPtYtNN2n+Xlb
=JO5R
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Kevin Kofler]

Jesse Keating wrote:
> Arm emulation would go a long way toward validating produced install
> images too.  Those of us that validate x86 images depend heavily on KVM
> and the like.

But full system emulation is slower by a LARGE factor, not merely the 2 to 4 
Jaroslav quoted for OBS, which (according to Dennis) is using a hybrid setup 
including some host and cross tools and QEMU userspace emulation as a 
fallback, NOT full system emulation.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Kevin Kofler]

drago01 wrote:
> Those numbers look way better then Kevin's "50x slower without any
> citation" ... thanks for getting this numbers.

I'm surprised emulating ARM in QEMU is so much faster than qemu-system-
x86_64 (which was how I measured the 50 times). Are they really using QEMU 
for everything or are they actually using host or cross tools (and QEMU only 
for when the build process is trying to run a just built binary)?

That said, a factor of 2 to 4 is still too slow!

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Dennis Gilmore]

Actually debian hfp is built on efika smart tops. They have a 8gb ssd attached 
using pata and 512mb ram.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Brendan Conoboy  wrote:

On 03/21/2012 02:13 PM, Peter Robinson wrote:
> As do Debian I believe. I think, but aren't 100% sure, that all major
> distributions except suse build as native.

At the last Linaro Connect the Debian guys said they're building 
natively on i.MX53 boards (Which are cool because they have real SATA).

-- 
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/21/2012 02:13 PM, Peter Robinson wrote:

As do Debian I believe. I think, but aren't 100% sure, that all major
distributions except suse build as native.


At the last Linaro Connect the Debian guys said they're building 
natively on i.MX53 boards (Which are cool because they have real SATA).


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Wed, Mar 21, 2012 at 6:59 PM, Brendan Conoboy  wrote:
> On 03/21/2012 11:18 AM, drago01 wrote:
>>
>> But there seems to be a huge oppositions against that in Fedora.
>> How does Ubuntu build there ARM builds? Native or using cross compilers?
>
>
> Native.

As do Debian I believe. I think, but aren't 100% sure, that all major
distributions except suse build as native.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/21/2012 11:18 AM, drago01 wrote:

But there seems to be a huge oppositions against that in Fedora.
How does Ubuntu build there ARM builds? Native or using cross compilers?


Native.

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[drago01]

On Wed, Mar 21, 2012 at 7:11 PM, Dennis Gilmore  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Wed, 21 Mar 2012 06:07:57 -0400 (EDT)
> Jaroslav Reznik  wrote:
>
>> - Original Message -
>>
>> > Maybe it's worth to ask them (or look at for example Mer builds)
>> > what's
>> > the difference in build times.
>>
>> A few statistics from build.meego.com - using the OBS and building in
>> qemu. These are really just approximate numbers, built in different
>> times with probably a different load...
>>
> I have spoken with the OpenSUSE guys they dont use qemu-system-arm but
> rather qemu-arm and lay out things and build using a hybrid
> environment  thats also how they build ppc s390 and other arches. the
> only build hardware they have is x86. doing full system emulation will
> be slower.

Which is exactly what I proposed ... i.e use cross compilers and
really on qemu to run stuff that gets generated and run during build.

But there seems to be a huge oppositions against that in Fedora.
How does Ubuntu build there ARM builds? Native or using cross compilers?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 21 Mar 2012 10:12:58 -0400
Josh Boyer  wrote:

> On Wed, Mar 21, 2012 at 9:52 AM, Peter Jones 
> wrote:
> > On 03/21/2012 09:21 AM, Josh Boyer wrote:
> >
> >> Except when people are forced to look at it, their solution was
> >> often ExcludeArch for PPC.  As I said in the other thread, you
> >> cannot force people to care about an architecture they don't know
> >> or want to learn.
> >
> >
> > That suggests we need a FTBFS-like nightly test that lets us know
> > about new, unexpected ExcludeArches in the distro.
> 
> Possibly.  There are ExcludeArch trackers that people are supposed to
> make their bugs block and that was normally sufficient to give the
> arch team a heads up.  However, I'm sure there were packages that
> didn't have bugs filed like that.

the main issue is that we need to have tracking in place that doesnt
require people do anything. because people dont do what they should.  I
see it all the time when dealing with mass rebuilds etc  people do one
or 2 of the steps to remove a package, but quite often do not do all
3.  We do have plans to redo it to make it a single step.  the more we
can automate the tracking of it the better we will nknow the full
extent of where things are. if we can cut down on what people have to
do the more likely it will be that we have true representation of the
data.

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9qG08ACgkQkSxm47BaWfcgZwCfUKuV7OhzKPIqvVQGMAmKb/Hf
dPgAoKD8T6bqeLYKMXxvJJHQiINoxOFQ
=pYET
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 21 Mar 2012 06:07:57 -0400 (EDT)
Jaroslav Reznik  wrote:

> - Original Message -
> 
> > Maybe it's worth to ask them (or look at for example Mer builds)
> > what's
> > the difference in build times.
> 
> A few statistics from build.meego.com - using the OBS and building in
> qemu. These are really just approximate numbers, built in different
> times with probably a different load...
> 
I have spoken with the OpenSUSE guys they dont use qemu-system-arm but
rather qemu-arm and lay out things and build using a hybrid
environment  thats also how they build ppc s390 and other arches. the
only build hardware they have is x86. doing full system emulation will
be slower. 

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9qGdQACgkQkSxm47BaWfcQ3gCfWys0mvR6MOKZRTj9hcopT92C
OMgAn1/jXyJdJ7tvJAVsZiLZCU7MvJTk
=6tKT
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/21/2012 06:26 AM, Peter Robinson wrote:

Thanks Adam, this is the first real use case where speed of builds is
important for something other than keeping the developer happy.


Other points raised on the list are:

1. The nature of chainbuilds would feel slowed build times particularly. 
 This is more of a multi-developer happy item.


2. Total turnaround time on security updates.

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jesse Keating]

On 3/21/12 10:36 AM, Brendan Conoboy wrote:

The main place I see ARM emulation being useful is in allowing any
packager with an x86 host to boot a simulated ARM host to resolve build
failures in their package.  That's not ideal- ideal is every package
owner has an ARM system they can use, but it's perhaps a starting point.
  If other people have feedback on this point I'd be interested to hear
their take on it.  I think a combination of ARM emulation and providing
a network-accessible set of test machines will go along way toward
giving packagers what they need and plan to update the proposal to say
so, subject to the feedback we get on this point.


Arm emulation would go a long way toward validating produced install 
images too.  Those of us that validate x86 images depend heavily on KVM 
and the like.


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jesse Keating]

On 3/21/12 6:52 AM, Peter Jones wrote:

On 03/21/2012 09:21 AM, Josh Boyer wrote:


Except when people are forced to look at it, their solution was often
ExcludeArch for PPC. As I said in the other thread, you cannot force
people to care about an architecture they don't know or want to learn.


That suggests we need a FTBFS-like nightly test that lets us know about
new,
unexpected ExcludeArches in the distro.



This sounds like the perfect use case for a SCM feature I haven't had 
the time to work on.


If all commit diffs are sent to a message bus by way of a git hook, then 
one consumer on the bus could be canning for additions of ExcludeArch. 
When these are discovered a bug could be filed automatically, or some 
group would get notified, basically something would happen, and we 
wouldn't depend on a human noticing the change or following policy to 
file a bug.


In the short term, if this is something we see high value in tracking, 
we can just add another git hook to do this directly, rather than 
relying on a message bus.


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/21/2012 05:25 AM, Chris Tyler wrote:

Fully-emulated actually fits into the "Native Builds" guideline, but it
hasn't been economical to use this approach because there's no hardware
support for ARM emulation on x86 (the way that there is hardware
acceleration for x86 virtualization on x86) and it therefore requires a
very fast/expensive x86 box to emulate a slow/cheap ARM box.


The main place I see ARM emulation being useful is in allowing any 
packager with an x86 host to boot a simulated ARM host to resolve build 
failures in their package.  That's not ideal- ideal is every package 
owner has an ARM system they can use, but it's perhaps a starting point. 
 If other people have feedback on this point I'd be interested to hear 
their take on it.  I think a combination of ARM emulation and providing 
a network-accessible set of test machines will go along way toward 
giving packagers what they need and plan to update the proposal to say 
so, subject to the feedback we get on this point.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Dave Jones]

On Wed, Mar 21, 2012 at 11:32:04AM -0400, Zach Brown wrote:
 > On 03/21/2012 10:58 AM, Dave Jones wrote:
 > > On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote:
 > >   >  All sorts of things can speed it up, most of the Fedora builders are
 > >   >  currently loopback ext4 over NFS over 100Mb ethernet over USB. Not
 > >   >  optimal.
 > >
 > > Just switching them to ext2 would save a ton of IO.
 > 
 > You could also turn off the journal in ext4.  That'd lose the journal IO
 > and stalls waiting for it and you'd still get the block mapping IO
 > savings of delalloc and extents.

Yes, that would be even better. (Hi Zab!)

Dave

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Zach Brown]

On 03/21/2012 10:58 AM, Dave Jones wrote:

On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote:
  >  All sorts of things can speed it up, most of the Fedora builders are
  >  currently loopback ext4 over NFS over 100Mb ethernet over USB. Not
  >  optimal.

Just switching them to ext2 would save a ton of IO.


You could also turn off the journal in ext4.  That'd lose the journal IO
and stalls waiting for it and you'd still get the block mapping IO
savings of delalloc and extents.

- z
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jaroslav Reznik]

> > So probably using Qemu could speed it up quite a lot. Also OBS
> > offers
> > quite a lot of flexibility to decouple arch builds, disable
> > selected
> > archs etc. But I'm not sure about the processes for chain builds,
> > updates, how they make the builds consistent (if one arch fails)...
> 
> All sorts of things can speed it up, most of the Fedora builders are
> currently loopback ext4 over NFS over 100Mb ethernet over USB. Not
> optimal. Add to that 1Gb of RAM and swap the problem gets worse. The
> devices we're looking at have proper SATA ports (not over USB) and
> quad core 4GB RAM and the time to build is an order of magnitude
> faster, and those boards aren't overly stable as they're not
> production level HW so once we get our hands on production level
> versions of that HW we can start to properly test the difference in
> large packages such as gcc, qt, libreoffice and the kernel and will
> be
> able to much better ascertain the impact. I believe that should be
> "soon" although I'm not in direct contact.

It was more argument about real qemu speed from real deployment. Not
bashing the current setup.

It's better to have real data over just talking here :)

R.

> Peter
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Wed, Mar 21, 2012 at 2:58 PM, Dave Jones  wrote:
> On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote:
>  > All sorts of things can speed it up, most of the Fedora builders are
>  > currently loopback ext4 over NFS over 100Mb ethernet over USB. Not
>  > optimal.
>
> Just switching them to ext2 would save a ton of IO. The buildroots
> get regenerated every time anyway, so journalling isn't really getting
> you anything. If a builder crashes, you probably want to throw the
> old buildroot away and start over anyway.
>
> out of curiousity, Is the setup of the builders documented somewhere ?

I believe it is somewhere, the reference I had is completely out of
date. The current configuration would not be the configuration used in
primary arch but ultimately it was the best we could do with the
platforms that were available 12-18 months ago. A lot has changed in
that time.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Dave Jones]

On Wed, Mar 21, 2012 at 01:27:04PM +, Peter Robinson wrote:
 > All sorts of things can speed it up, most of the Fedora builders are
 > currently loopback ext4 over NFS over 100Mb ethernet over USB. Not
 > optimal.

Just switching them to ext2 would save a ton of IO. The buildroots
get regenerated every time anyway, so journalling isn't really getting
you anything. If a builder crashes, you probably want to throw the
old buildroot away and start over anyway.

out of curiousity, Is the setup of the builders documented somewhere ?

Dave
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Josh Boyer]

On Wed, Mar 21, 2012 at 9:52 AM, Peter Jones  wrote:
> On 03/21/2012 09:21 AM, Josh Boyer wrote:
>
>> Except when people are forced to look at it, their solution was often
>> ExcludeArch for PPC.  As I said in the other thread, you cannot force
>> people to care about an architecture they don't know or want to learn.
>
>
> That suggests we need a FTBFS-like nightly test that lets us know about new,
> unexpected ExcludeArches in the distro.

Possibly.  There are ExcludeArch trackers that people are supposed to make
their bugs block and that was normally sufficient to give the arch team a
heads up.  However, I'm sure there were packages that didn't have bugs filed
like that.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Wed, Mar 21, 2012 at 1:52 PM, Peter Jones  wrote:
> On 03/21/2012 09:21 AM, Josh Boyer wrote:
>
>> Except when people are forced to look at it, their solution was often
>> ExcludeArch for PPC.  As I said in the other thread, you cannot force
>> people to care about an architecture they don't know or want to learn.
>
>
> That suggests we need a FTBFS-like nightly test that lets us know about new,
> unexpected ExcludeArches in the distro.

TBH we need someone to take over the FTBFS things that Matt use to do,
there's still 400+ packages that are FTBFS on x86 primary arch post
the F-17 gcc 4.7 mass rebuild and even some going all the way back to
the F-12 mass rebuilt (yes 3 mass rebuilds ago!). that number was
actually much closer to 600 but the ARM team have fixed well over 100
of those on mainline because they were blocking what we were doing on
ARM. Then once that is in place a means of tracking
ExcludeArch/ExclusiveArch would be an excellent and very useful tool
for all arches, primary or otherwise IMO.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Jones]

On 03/21/2012 09:21 AM, Josh Boyer wrote:


Except when people are forced to look at it, their solution was often
ExcludeArch for PPC.  As I said in the other thread, you cannot force
people to care about an architecture they don't know or want to learn.


That suggests we need a FTBFS-like nightly test that lets us know about new,
unexpected ExcludeArches in the distro.

--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Wed, Mar 21, 2012 at 01:26:58PM +, Peter Robinson wrote:
> On Wed, Mar 21, 2012 at 11:39 AM, Matthew Garrett  wrote:
> > The expectation would be that the architecture maintainers have fixed
> > everything before moving to being a primary architecture, so this should
> > only be an issue if maintainers or upstream manage to come up with new
> > breakage. But yes, it forces people to care about something they might
> > previously have ignored, so I guess that's an advantage.
> 
> And we've already being doing that with the vast majority of issues
> already fixed and committed to mainline.

Agreed. I just mean that it's not a terribly significant benefit to 
becoming a primary architecture.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Wed, Mar 21, 2012 at 7:13 AM, David Tardon  wrote:
> On Tue, Mar 20, 2012 at 12:52:58PM -0700, Brendan Conoboy wrote:
>> On 03/20/2012 12:44 PM, Chris Murphy wrote:
>> >Now the ultra ridiculous: How about secondary architecture requirements 
>> >demoted as-is to tertiary. And create substantially more aggressive 
>> >requirements for secondary architecture (in which ARM would be placed), yet 
>> >are not identical requirements to primary architecture requirements?
>>
>> Yes, the all-or-nothing mindset between secondary and primary is
>> almost certainly the root of the problem.  We want more
>> representation in Fedora than being a secondary connotes,
>
> Maybe you should begin by convincing package maintainers that ARM is a
> good platform (if it is; I do not know) and that they want to use it,
> instead of (figuratively speaking) shoving it down their throats by
> means of FESCo decision to promote ARM to primary arch. If you attract
> enough people, the transition may just happen "naturally"...

There is no doubt it is a good platform, it's not about shoving it
down people's throats, it's about making Fedora available on millions
of devices that are cheap and low power. The transition is happening
already and it happening due to cost and power, whether that be in the
data centre running on servers or in the developing world. You just
have to look at the millions of ARM based devices being sold in China,
India and other parts of Asia.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Wed, Mar 21, 2012 at 10:07 AM, Jaroslav Reznik  wrote:
> - Original Message -
>
>> Maybe it's worth to ask them (or look at for example Mer builds)
>> what's
>> the difference in build times.
>
> A few statistics from build.meego.com - using the OBS and building in
> qemu. These are really just approximate numbers, built in different
> times with probably a different load...
>
> I took Qt as an example as it's a package I know.
>
> -- build.meego.com ---
> http://build.meego.com/package/show?package=qt&project=Trunk
> armv8el
> build19 started "build qt.spec" at Sat Nov  5 02:09:33 UTC 2011.
> build19 finished "build qt.spec" at Sat Nov  5 03:01:43 UTC 2011.
>
> approx. 1 hour
>
> i586
> build17 started "build qt.spec" at Fri Nov  4 23:33:24 UTC 2011.
> build17 finished "build qt.spec" at Sat Nov  5 00:05:03 UTC 2011.
>
> approx. half hour (1/2)
>
> armv8el vs i586 factor of 2
>
> http://build.meego.com/package/show?package=qt&project=home%3Arrojfors%3Abranches%3AMeeGo%3A1.1%3ACore
> armv7el
> build42 started "build qt.spec" at Thu May 12 08:49:50 UTC 2011.
> build42 finished "build qt.spec" at Thu May 12 10:42:21 UTC 2011.
>
> approx. 2 hours
>
> i586
> build11 started "build qt.spec" at Thu May 12 08:49:48 UTC 2011.
> build11 finished "build qt.spec" at Thu May 12 09:09:47 UTC 2011.
>
> approx.
>
> armv7el vs i586 factor of 4
>
>
> -- Fedora --
> i686
> 2012-02-20 14:31:51,510 - Mock Version: 1.1.18
> 2012-02-20 15:05:21,089 - State Changed: end
>
> approx. half hour
>
> armv7hl
> 2012-03-18 17:58:09,566 - Mock Version: 1.1.18
> 2012-03-19 04:53:07,593 - State Changed: end
>
> better not calculating...
>
> So probably using Qemu could speed it up quite a lot. Also OBS offers
> quite a lot of flexibility to decouple arch builds, disable selected
> archs etc. But I'm not sure about the processes for chain builds,
> updates, how they make the builds consistent (if one arch fails)...

All sorts of things can speed it up, most of the Fedora builders are
currently loopback ext4 over NFS over 100Mb ethernet over USB. Not
optimal. Add to that 1Gb of RAM and swap the problem gets worse. The
devices we're looking at have proper SATA ports (not over USB) and
quad core 4GB RAM and the time to build is an order of magnitude
faster, and those boards aren't overly stable as they're not
production level HW so once we get our hands on production level
versions of that HW we can start to properly test the difference in
large packages such as gcc, qt, libreoffice and the kernel and will be
able to much better ascertain the impact. I believe that should be
"soon" although I'm not in direct contact.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Wed, Mar 21, 2012 at 11:39 AM, Matthew Garrett  wrote:
> On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote:
>> On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett  
>> wrote:
>> > I think you're looking at this in slightly the wrong way. Being a
>> > primary architecture isn't meant to be a benefit to the port - it's
>> > meant to be a benefit to Fedora. Adding arm to the PA list means you'll
>> > have to take on a huge number of additional responsibilities, deal with
>> > more people who are unhappy about the impact upon their packages and so
>> > on. You get very little out of it except that there's more people to
>> > tell you that something's broken.
>>
>> I don't think this is true: On a primary architecture, every package
>> maintainer is be expected to handle their own packages; this should
>> actually significantly decrease the load on the "architecture
>> maintainers".
>
> The expectation would be that the architecture maintainers have fixed
> everything before moving to being a primary architecture, so this should
> only be an issue if maintainers or upstream manage to come up with new
> breakage. But yes, it forces people to care about something they might
> previously have ignored, so I guess that's an advantage.

And we've already being doing that with the vast majority of issues
already fixed and committed to mainline.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Robinson]

On Tue, Mar 20, 2012 at 11:46 PM, Adam Williamson  wrote:
> On Tue, 2012-03-20 at 12:08 -0400, Josh Boyer wrote:
>
>> 2) Updates.  Submitting updates requires the entire build to be complete
>> which means you have to wait for the slowest thing to finish.  Having to
>> wait for 12 hours effectively means you can't even test your update until
>> the next day, and then after you test it you can submit it.  Again, this
>> is mostly compounded for large packages, but it does impact workflow.
>
> From a QA perspective, there's a fairly important instance of this case.
> We sometimes wind up working on very compressed timescales in validation
> sprints. We don't get very long to do validation.
>
> So it's not unusual for me to be bugging, say, the kernel team to give
> us a new kernel build that fixes a blocker bug, so we can do a new
> release candidate, so we can test the release candidate in twelve hours,
> so we can make the go/no-go meeting deadline the next morning.
>
> If builds get significantly slower, that could have a concrete impact on
> the release validation process: it's plausible that we'd either need to
> extend the validation period somewhat - earlier freezes - or we would
> have to eat a somewhat higher likelihood of release slippages.

Thanks Adam, this is the first real use case where speed of builds is
important for something other than keeping the developer happy.

Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Josh Boyer]

On Wed, Mar 21, 2012 at 7:39 AM, Matthew Garrett  wrote:
> On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote:
>> On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett  
>> wrote:
>> > I think you're looking at this in slightly the wrong way. Being a
>> > primary architecture isn't meant to be a benefit to the port - it's
>> > meant to be a benefit to Fedora. Adding arm to the PA list means you'll
>> > have to take on a huge number of additional responsibilities, deal with
>> > more people who are unhappy about the impact upon their packages and so
>> > on. You get very little out of it except that there's more people to
>> > tell you that something's broken.
>>
>> I don't think this is true: On a primary architecture, every package
>> maintainer is be expected to handle their own packages; this should
>> actually significantly decrease the load on the "architecture
>> maintainers".
>
> The expectation would be that the architecture maintainers have fixed
> everything before moving to being a primary architecture, so this should
> only be an issue if maintainers or upstream manage to come up with new
> breakage. But yes, it forces people to care about something they might
> previously have ignored, so I guess that's an advantage.

Except when people are forced to look at it, their solution was often
ExcludeArch for PPC.  As I said in the other thread, you cannot force
people to care about an architecture they don't know or want to learn.

That's not to say there weren't a large number of people that _did_
try and fix things.  It's just not a clear cut "this arch is primary
so package maintainers will fix arch issues".

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Chris Tyler]

On Wed, 2012-03-21 at 05:04 -0400, Jaroslav Reznik wrote:
> - Original Message -
> > just a side note - I was told by an OpenSUSE on ARM person that they
> > use
> > x86 boxes with the user-space qemu virtual machine. It works quite
> > fast,
> > but still needs some hacking eg. in test-suites
> 
> Yep, OpenSUSE uses qemu - it's sometimes not as stable as it should be,
> I saw a few strange random crashes in qemu but usually it works. I 
> talked with them once, they were surprised by our "native builds" policy.
> 
> Maybe it's worth to ask them (or look at for example Mer builds) what's
> the difference in build times.

Fully-emulated actually fits into the "Native Builds" guideline, but it
hasn't been economical to use this approach because there's no hardware
support for ARM emulation on x86 (the way that there is hardware
acceleration for x86 virtualization on x86) and it therefore requires a
very fast/expensive x86 box to emulate a slow/cheap ARM box.

-Chris

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[drago01]

On Wed, Mar 21, 2012 at 11:07 AM, Jaroslav Reznik  wrote:
> - Original Message -
>
>> Maybe it's worth to ask them (or look at for example Mer builds)
>> what's
>> the difference in build times.
>
> A few statistics from build.meego.com - using the OBS and building in
> qemu. These are really just approximate numbers, built in different
> times with probably a different load...
>
> I took Qt as an example as it's a package I know.
>
> -- build.meego.com ---
> http://build.meego.com/package/show?package=qt&project=Trunk
> armv8el
> build19 started "build qt.spec" at Sat Nov  5 02:09:33 UTC 2011.
> build19 finished "build qt.spec" at Sat Nov  5 03:01:43 UTC 2011.
>
> approx. 1 hour
>
> i586
> build17 started "build qt.spec" at Fri Nov  4 23:33:24 UTC 2011.
> build17 finished "build qt.spec" at Sat Nov  5 00:05:03 UTC 2011.
>
> approx. half hour (1/2)
>
> armv8el vs i586 factor of 2
>
> http://build.meego.com/package/show?package=qt&project=home%3Arrojfors%3Abranches%3AMeeGo%3A1.1%3ACore
> armv7el
> build42 started "build qt.spec" at Thu May 12 08:49:50 UTC 2011.
> build42 finished "build qt.spec" at Thu May 12 10:42:21 UTC 2011.
>
> approx. 2 hours
>
> i586
> build11 started "build qt.spec" at Thu May 12 08:49:48 UTC 2011.
> build11 finished "build qt.spec" at Thu May 12 09:09:47 UTC 2011.
>
> approx.
>
> armv7el vs i586 factor of 4
>
>
> -- Fedora --
> i686
> 2012-02-20 14:31:51,510 - Mock Version: 1.1.18
> 2012-02-20 15:05:21,089 - State Changed: end
>
> approx. half hour
>
> armv7hl
> 2012-03-18 17:58:09,566 - Mock Version: 1.1.18
> 2012-03-19 04:53:07,593 - State Changed: end
>
> better not calculating...
>
> So probably using Qemu could speed it up quite a lot. Also OBS offers

Those numbers look way better then Kevin's "50x slower without any
citation" ... thanks for getting this numbers.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Wed, Mar 21, 2012 at 10:41:33AM +0100, Miloslav Trmač wrote:
> On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett  wrote:
> > I think you're looking at this in slightly the wrong way. Being a
> > primary architecture isn't meant to be a benefit to the port - it's
> > meant to be a benefit to Fedora. Adding arm to the PA list means you'll
> > have to take on a huge number of additional responsibilities, deal with
> > more people who are unhappy about the impact upon their packages and so
> > on. You get very little out of it except that there's more people to
> > tell you that something's broken.
> 
> I don't think this is true: On a primary architecture, every package
> maintainer is be expected to handle their own packages; this should
> actually significantly decrease the load on the "architecture
> maintainers".

The expectation would be that the architecture maintainers have fixed 
everything before moving to being a primary architecture, so this should 
only be an issue if maintainers or upstream manage to come up with new 
breakage. But yes, it forces people to care about something they might 
previously have ignored, so I guess that's an advantage.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jaroslav Reznik]

- Original Message -

> Maybe it's worth to ask them (or look at for example Mer builds)
> what's
> the difference in build times.

A few statistics from build.meego.com - using the OBS and building in
qemu. These are really just approximate numbers, built in different
times with probably a different load...

I took Qt as an example as it's a package I know.

-- build.meego.com ---
http://build.meego.com/package/show?package=qt&project=Trunk
armv8el
build19 started "build qt.spec" at Sat Nov  5 02:09:33 UTC 2011.
build19 finished "build qt.spec" at Sat Nov  5 03:01:43 UTC 2011.

approx. 1 hour

i586
build17 started "build qt.spec" at Fri Nov  4 23:33:24 UTC 2011.
build17 finished "build qt.spec" at Sat Nov  5 00:05:03 UTC 2011.

approx. half hour (1/2)

armv8el vs i586 factor of 2

http://build.meego.com/package/show?package=qt&project=home%3Arrojfors%3Abranches%3AMeeGo%3A1.1%3ACore
armv7el
build42 started "build qt.spec" at Thu May 12 08:49:50 UTC 2011.
build42 finished "build qt.spec" at Thu May 12 10:42:21 UTC 2011.

approx. 2 hours

i586
build11 started "build qt.spec" at Thu May 12 08:49:48 UTC 2011.
build11 finished "build qt.spec" at Thu May 12 09:09:47 UTC 2011.

approx.

armv7el vs i586 factor of 4


-- Fedora --
i686
2012-02-20 14:31:51,510 - Mock Version: 1.1.18
2012-02-20 15:05:21,089 - State Changed: end

approx. half hour

armv7hl
2012-03-18 17:58:09,566 - Mock Version: 1.1.18
2012-03-19 04:53:07,593 - State Changed: end

better not calculating...

So probably using Qemu could speed it up quite a lot. Also OBS offers
quite a lot of flexibility to decouple arch builds, disable selected
archs etc. But I'm not sure about the processes for chain builds,
updates, how they make the builds consistent (if one arch fails)...

From package POV:
* the KDE stack would suffer a lot of slow builds due to dependencies,
even now it can take half day to have all bootstrapped
* currently we omit all ARM patches available in upstreams as we don't 
need them and we don't have a chance to test even the patch is needed :(
* for fixing bugs, we could always try to reach any ARM guy to help with

Maybe a distribution of PandaBoards/R-Pi for every FAS account holder could
help, any sponsor? :D

/me is going to order R-pi soon :)

R.

> R.
> 
> > 
> > 
> > Dan
> > 
> > 
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Miloslav Trmač]

On Tue, Mar 20, 2012 at 10:58 PM, Matthew Garrett  wrote:
> I think you're looking at this in slightly the wrong way. Being a
> primary architecture isn't meant to be a benefit to the port - it's
> meant to be a benefit to Fedora. Adding arm to the PA list means you'll
> have to take on a huge number of additional responsibilities, deal with
> more people who are unhappy about the impact upon their packages and so
> on. You get very little out of it except that there's more people to
> tell you that something's broken.

I don't think this is true: On a primary architecture, every package
maintainer is be expected to handle their own packages; this should
actually significantly decrease the load on the "architecture
maintainers".
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jaroslav Reznik]

- Original Message -
> just a side note - I was told by an OpenSUSE on ARM person that they
> use
> x86 boxes with the user-space qemu virtual machine. It works quite
> fast,
> but still needs some hacking eg. in test-suites

Yep, OpenSUSE uses qemu - it's sometimes not as stable as it should be,
I saw a few strange random crashes in qemu but usually it works. I 
talked with them once, they were surprised by our "native builds" policy.

Maybe it's worth to ask them (or look at for example Mer builds) what's
the difference in build times.

R.

> 
> 
> Dan
> 
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Tomas Mraz]

On Tue, 2012-03-20 at 13:44 -0600, Chris Murphy wrote:
> Now the ultra ridiculous: How about secondary architecture
> requirements demoted as-is to tertiary. And create substantially more
> aggressive requirements for secondary architecture (in which ARM would
> be placed), yet are not identical requirements to primary architecture
> requirements?

Yes, this might be actually the best short-term path. Or rather than
demoting the other secondary architectures to tertiary status just have
different scale for various secondary architectures in terms of official
infrastructure support. I can see automatic spawning of secondary builds
for ARM in the main koji instance, use of main bodhi, etc., etc.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[David Tardon]

On Tue, Mar 20, 2012 at 12:52:58PM -0700, Brendan Conoboy wrote:
> On 03/20/2012 12:44 PM, Chris Murphy wrote:
> >Now the ultra ridiculous: How about secondary architecture requirements 
> >demoted as-is to tertiary. And create substantially more aggressive 
> >requirements for secondary architecture (in which ARM would be placed), yet 
> >are not identical requirements to primary architecture requirements?
> 
> Yes, the all-or-nothing mindset between secondary and primary is
> almost certainly the root of the problem.  We want more
> representation in Fedora than being a secondary connotes,

Maybe you should begin by convincing package maintainers that ARM is a
good platform (if it is; I do not know) and that they want to use it,
instead of (figuratively speaking) shoving it down their throats by
means of FESCo decision to promote ARM to primary arch. If you attract
enough people, the transition may just happen "naturally"...

D.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jesse Keating]

On 3/20/12 5:14 PM, Adam Williamson wrote:

But sure, in theory, we can do just about anything for a secondary arch
that we do for a primary arch, I don't think there's any technical
barrier to us doing update karma for ARM and test days for ARM and a
release validation process for ARM and all the rest of it. It's just a
question of motivation and personpower.


My point is that the motivation and personpower can come independent of 
whether arm is a PA or an SA.  As you say, no technical barrier.


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Al Dunsmuir]

On Tuesday, March 20, 2012, 7:21:25 PM, Ralf Corsepius wrote:
> On 03/20/2012 05:46 PM, Richard W.M. Jones wrote:
>> On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote:
>>> On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy  wrote:
 On 03/20/2012 09:21 AM, Ralf Corsepius wrote:
>
> That said, I considera cross-building environment for secondary arch to
> be inevitable, which would at least help for the class of issues, I am
> referring to above.

 I'm a big fan of cross compilation, but introducing it into Fedora in order
 to support ARM seems unlikely to succeed for too many reasons to go into.
>>>
>>> The reasons are? 
>>
>> We use cross-compilation right now for mingw-* packages (for Windows).
>> However you cannot use cross-compilation to create a foo-*.armv7hl.rpm
>> package.  That's because our entire toolchain, from RPM through Koji,
>> simply does not understand cross-compilation properly.

> Well, the mock/rpm part is the smaller part of the issues (I use 
> customized mock setups on Fedora to build mingw-* and cygwin-* packages).

>> Solvable, but undoubtedly a ton of work for everyone.

> The real issue would be to re-utilize "foreign native rpms" (here 
> *.arm.rpms) to install them in sys-roots on x86.

> (Fedora's mingw*-toolchains are explictly packaged to fit into x86)
> Ralf

On  July  7th,  2009, Mark Salter made a post "crossbuilding rpms with
koji" on the fedora-buildsys-list" where he described a project to add
cross-building support to koji/moc/rpm/etc.

The post in archived post is at
http://www.redhat.com/archives/fedora-buildsys-list/2009-July/msg0.html

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Adam Williamson]

On Tue, 2012-03-20 at 13:03 -0700, Jesse Keating wrote:

> > Subject
> > to applicability, the same QE mechanisms being employed.
> 
> I don't see SA/PA mattering as much here.  It's up to QE what they want 
> to take on and what they point automated tooling at.

In theory...yeah. In boring every day practice, we'd take a lot more
heat for 'not QAing a primary arch' than we would for 'not QAing a
secondary arch'.

I mean, right now, Fedora QA does just about zip for PPC or ARM. And
no-one not directly involved in PPC or ARM has ever complained to us
about that.

If ARM were a primary arch, I rather suspect they would.

But sure, in theory, we can do just about anything for a secondary arch
that we do for a primary arch, I don't think there's any technical
barrier to us doing update karma for ARM and test days for ARM and a
release validation process for ARM and all the rest of it. It's just a
question of motivation and personpower.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Adam Williamson]

On Tue, 2012-03-20 at 13:50 -0500, Chris Adams wrote:
> Once upon a time, Brendan Conoboy  said:
> > Indeed, targeting mobile devices on day 1 is beyond the scope of the 
> > proposal.  The first step is the eat-our-own-dogfood target, which is 
> > self-hosting ARM servers.  Mobile devices are a natural direction for 
> > Fedora ARM, of course, but as with every new direction there are a 
> > different set of challenges to be worked through.  For now we're just 
> > talking about the core OS.
> 
> Okay, but how many ARM servers are in widespread use?  For the resources
> required as a primary arch, there should be a large expected user base.
> The first sentence of the detailed description on the feature page is
> "ARM processors are the most popular CPUs in the world." but that is
> entirely irrelevant if you aren't targeting a significant number of
> those CPUs.

...yet, is the word you're missing, which changes things quite a bit.
What the ARM project is currently targeting is what Brendan referred to
as the 'core OS' - making Fedora run on ARM. Any ARM.

It just _happens_ that making the 'core OS' work gives you a reasonable
chance at making, say, a basic web server fly than it does making a
multitouch desktop operating system fly. So it kind of 'looks' right now
like Fedora ARM is more for a web server than it is for a multitouch
desktop OS. But that's kind of misleading. The fact is that the 'core
OS' needs to be there for both, so working on the 'core OS' is really
working on both use cases. It just happens to be the case that one of
the two use cases looks pretty viable almost as soon as the 'core OS' is
done, and the other doesn't. The project is still, in the end, working
on both.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 04:43 PM, Xose Vazquez Perez wrote:

ARMv8 will be 64-bit and faster:
http://en.wikipedia.org/wiki/ARM_architecture#ARMv8_and_64-bit
http://www.arm.com/files/downloads/ARMv8_Architecture.pdf

It should be ready for servers and desktops, maybe, in three-four years.
But not today.


ARMv8 is not contemplated in this proposal as it is so far out.

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Adam Williamson]

On Tue, 2012-03-20 at 12:08 -0400, Josh Boyer wrote:

> 2) Updates.  Submitting updates requires the entire build to be complete
> which means you have to wait for the slowest thing to finish.  Having to
> wait for 12 hours effectively means you can't even test your update until
> the next day, and then after you test it you can submit it.  Again, this
> is mostly compounded for large packages, but it does impact workflow.

From a QA perspective, there's a fairly important instance of this case.
We sometimes wind up working on very compressed timescales in validation
sprints. We don't get very long to do validation.

So it's not unusual for me to be bugging, say, the kernel team to give
us a new kernel build that fixes a blocker bug, so we can do a new
release candidate, so we can test the release candidate in twelve hours,
so we can make the go/no-go meeting deadline the next morning.

If builds get significantly slower, that could have a concrete impact on
the release validation process: it's plausible that we'd either need to
extend the validation period somewhat - earlier freezes - or we would
have to eat a somewhat higher likelihood of release slippages.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Xose Vazquez Perez]

Chris Adams wrote:

> Okay, but how many ARM servers are in widespread use?  For the resources
> required as a primary arch, there should be a large expected user base.
> The first sentence of the detailed description on the feature page is
> "ARM processors are the most popular CPUs in the world." but that is
> entirely irrelevant if you aren't targeting a significant number of
> those CPUs.

ARMv8 will be 64-bit and faster:
http://en.wikipedia.org/wiki/ARM_architecture#ARMv8_and_64-bit
http://www.arm.com/files/downloads/ARMv8_Architecture.pdf

It should be ready for servers and desktops, maybe, in three-four years.
But not today.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Ralf Corsepius]

On 03/20/2012 07:05 PM, Brendan Conoboy wrote:

On 03/20/2012 10:44 AM, drago01 wrote:

On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboy wrote:

Please, please, no. Cross compilation for Fedora cannot and will not
ever
get a secondary arch to primary. We're talking man-decades of
engineering
time to solve all the problems. Decades.


Sorry I am not buying that.


Because you have vast experience to the contrary? Look, even x86_64 is
topping out on speed and moving to a more-core and more-systems-per-rack
model. Cross compilation solves yesterday's problem, not tomorrow's.

Today's problem are:

1. sufficiently performant arms are not wide-spread
and
2. today's code is hardly tested on arms.


IMO, wrt. Fedora, unless a solution to 1. can be provided to the Fedora 
developer community, 2. can not be achieved and arm-Fedora will remain 
an illusion.



If
build speed truly is a fundamental issue to becoming PA the answer is to
harness multiple systems for a single build, not to use a somewhat
faster system to make up for the speed of a somewhat slower system.
Scaling across more cores than fit in a single SMP Linux environment is
the only sensible approach to future build speedups. Though is an
interesting challenge, it is completely beyond the scope of primary
architecture requirements. Please, let's drop talk of cross compilation.


I agree insofar as cross-compilation is a band-aid. However, sometimes, 
band-aids are inevitable.


Ralf


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Ralf Corsepius]

On 03/20/2012 05:46 PM, Richard W.M. Jones wrote:

On Tue, Mar 20, 2012 at 05:37:10PM +0100, drago01 wrote:

On Tue, Mar 20, 2012 at 5:34 PM, Brendan Conoboy  wrote:

On 03/20/2012 09:21 AM, Ralf Corsepius wrote:


That said, I considera cross-building environment for secondary arch to
be inevitable, which would at least help for the class of issues, I am
referring to above.



I'm a big fan of cross compilation, but introducing it into Fedora in order
to support ARM seems unlikely to succeed for too many reasons to go into.


The reasons are? 


We use cross-compilation right now for mingw-* packages (for Windows).
However you cannot use cross-compilation to create a foo-*.armv7hl.rpm
package.  That's because our entire toolchain, from RPM through Koji,
simply does not understand cross-compilation properly.


Well, the mock/rpm part is the smaller part of the issues (I use 
customized mock setups on Fedora to build mingw-* and cygwin-* packages).



Solvable, but undoubtedly a ton of work for everyone.


The real issue would be to re-utilize "foreign native rpms" (here 
*.arm.rpms) to install them in sys-roots on x86.


(Fedora's mingw*-toolchains are explictly packaged to fit into x86)

Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 03:33 PM, Kevin Kofler wrote:

You haven't answered his question: why would ARM-as-primary come before
Fedora-on-tablets and Fedora-on-cellphones? Those can be perfectly supported
using the secondary architecture infrastructure (or if not, we need to
improve that infrastructure).


That's two questions.  I'll answer the first one: ARM Server 
semiconductors are more amenable to open source licensing than embedded 
& telecommunication companies, so getting a complete open source ARM 
Server running is simple compared to getting an ARM Linux tablet or cell 
phone running.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 03:33 PM, Jesse Keating wrote:

So in principle, do you object to the same koji hub being used for ARM
if ARM is still SA?


I'm not really sure how to process that question. As a current secondary
arch, the primary hub is still the trigger point for the vast majority
of the builds that will happen for arm. A successful build on the
primary hub will trigger (through koji-shadow) a build on the secondary
arches. I'm sure you're (painfully) aware of this.
I don't understand how the same koji hub could be used for arm while arm
is still SA differently than above.


Context for the question: One of the benefits to PA that I see is that 
PA's infrastructure is really good.  I mean, the reliability is 
outstanding.  Kudos to all involved.  To what extent can a secondary 
sharing in that bliss?  Machines in the same racks? Services on the same 
machines?  The same koji hub, but treating failed SA builds differently 
than failed PA builds?  How close can we get to treating a secondary 
architecture like a primary, as far as that infrastructure goes?  Is the 
limit, again, as close as we want up to the point of it affecting 
primary programmatically?   Or should there be a separation, even if 
it's technically feasible to combine the services for both SA and PA?



Mostly. It'll take effort on the part of the secondary arch to engage
these other parts of the Fedora project to convince them to pay
attention to your arch. If you were a primary, they're essentially
forced to care. Enticing them to care as a secondary arch goes a long
long way to show that you're ready to be a primary arch and that the
promotion would not cause much ripple effect.


Agreed.  We definitely want promotion, in the end, to be a small ripple, 
if little notice because the hard parts are already done.



That does seem right. Just like the old adage, dress for the job you
want, not the one you have, or do the work for the promotion you want,
and you'll earn the promotion, the same applies here. Show that the
secondary arch can function well as a primary arch without significant
burden to the rest of the project and then it's a much easier decision
to make the promotion.


Yes...


"doing all of these things" doesn't happen magically just because the
board/fesco grants that ARM is suddenly a primary arch. If we made arm a
primary arch tomorrow, you'd still have to solve all the above issues,
only now you've got hundreds of very angry developers who's workflow is
now severely interrupted, and they're all calling for your head. Doesn't
it make more sense to solve these issues /before/ doing the promotion?
Figure out how to make the car go 60mph before taking it onto the
freeway, else you'll piss off all the other cars on the freeway.


Absolutely.  We're having this discussion as a way to solve the issues 
before promotion.  None of us expect ARM to be promoted today, or 
tomorrow, but perhaps 3-5 months from now is realistic.  Or maybe that's 
too soon.  The bottom line is that there are issues to be worked out and 
that's what has prompted the discussion.



Fair enough, I honestly didn't think you had ignored it, and it was rude
of me to suggest otherwise. I apologize for that.


Thanks-  I didn't think your replies mean spirited and very much 
appreciate your taking the time to think about the issues with the 
proposal.  It's a work in progress and it will certainly be a while 
before it's complete enough that to be approved.  We're charting a 
course toward primary and these threads are simply a way of drawing up 
the map we'll be taking.



"fedora-devel" doesn't really have anything of the "authoritative" sort,
we just have a lot of subscribers and opinions. Those opinions are
usually considered by FESCo when FESCo makes a decision, and generally
considered by those proposing something and asking for feedback on their
way to a FESCo decision.


Yep.  Regards,

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Kevin Kofler]

Brendan Conoboy wrote:

> On 03/20/2012 12:03 PM, Chris Adams wrote:
>> Okay, but why is ARM-as-primary-arch an early step, and not near the
>> end?  Increasing the developer and engineering burden across the whole
>> project should not be done for a small target audience.
> 
> Really there is no beginning and no end, so we're somewhere in the
> middle ;-)  ARM-as-secondary was earlier.  ARM-as-primary is next.
> Fedora-on-tablets is later.  Fedora-on-cellphones is later.  The bottom
> line is that Fedora is an rpm-based native-built operating system, so
> ARM servers come first.  Fedora isn't currently built to run efficiently
> and smoothly on embedded devices.  That's okay, it's nice to have
> followup projects.  Meanwhile ARM servers are going to be important too.

You haven't answered his question: why would ARM-as-primary come before 
Fedora-on-tablets and Fedora-on-cellphones? Those can be perfectly supported 
using the secondary architecture infrastructure (or if not, we need to 
improve that infrastructure).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jesse Keating]

On 3/20/12 2:33 PM, Brendan Conoboy wrote:

On 03/20/2012 01:03 PM, Jesse Keating wrote:

As an example, the same koji server handling x86 builds handling ARM
builds.


Only the koji hub would be the same, the arm builders would be different
machines. This isn't all that different from having the primary hub
trigger the arm hub to start a build on the arm builders.


So in principle, do you object to the same koji hub being used for ARM
if ARM is still SA?


I'm not really sure how to process that question.  As a current 
secondary arch, the primary hub is still the trigger point for the vast 
majority of the builds that will happen for arm.  A successful build on 
the primary hub will trigger (through koji-shadow) a build on the 
secondary arches.  I'm sure you're (painfully) aware of this.


I don't understand how the same koji hub could be used for arm while arm 
is still SA differently than above.





The PPC builders are there, or at least were at some point, why not
propose moving some arm stuff there for the arm secondary arch effort?


...


I don't see SA/PA mattering as much here. It's up to QE what they want
to take on and what they point automated tooling at.


The sense I'm getting from your reply is that the PA/SA designation is
almost decorative, that a secondary can do anything a primary can,
except inhibit the progress of builds.


Mostly.  It'll take effort on the part of the secondary arch to engage 
these other parts of the Fedora project to convince them to pay 
attention to your arch.  If you were a primary, they're essentially 
forced to care.  Enticing them to care as a secondary arch goes a long 
long way to show that you're ready to be a primary arch and that the 
promotion would not cause much ripple effect.



So, if the Fedora ARM team fixes
all broken builds, brings in all the QE mechanisms, engages the Fedora
system at every level of the organization, solves the the build time
performance issue, and otherwise keep at it until we're functionally
indistinguishable from PA, *then* it's time to have the PA/SA
discussion.  Is that right?


That does seem right.  Just like the old adage, dress for the job you 
want, not the one you have, or do the work for the promotion you want, 
and you'll earn the promotion, the same applies here.  Show that the 
secondary arch can function well as a primary arch without significant 
burden to the rest of the project and then it's a much easier decision 
to make the promotion.



Speaking for myself, I see most of these
things as a benefit of membership in PA rather than prerequisites. Or
more to the point, transitioning from SA to PA means doing all of these
things, so it's really just an order of operations that needs to be
agreed upon.


"doing all of these things" doesn't happen magically just because the 
board/fesco grants that ARM is suddenly a primary arch.  If we made arm 
a primary arch tomorrow, you'd still have to solve all the above issues, 
only now you've got hundreds of very angry developers who's workflow is 
now severely interrupted, and they're all calling for your head. 
Doesn't it make more sense to solve these issues /before/ doing the 
promotion?  Figure out how to make the car go 60mph before taking it 
onto the freeway, else you'll piss off all the other cars on the freeway.





That's set by you, as a secondary arch. Why not pin it to the Fedora
release schedule and see how well you do?


We're quite close, though clearly the QE is different.


That said, within the websites group perhaps there is room for a
featured secondary arch, with high visibility. Having something to point
to first would help.


Fair enough.


Did you just ignore the emails starting these two threads by mjg and
pjones? I believe they outlined some very good requirements for getting
a secondary arch into primary. These longer threads have been debating
some of the finer points of those proposals.


On the contrary, mjg and pjones' emails are just the sort of
constructive and thoughtful feedback I'm looking for. If the points
they've raised (which they also raised yesterday) speak to everybody's
concerns, then I'm happy to view them as the authoritative feedback of
Fedora-devel for our planning purposes. On the other hand, if they've
left anything out that should be considered in this plan, I'd like to
see it.



Fair enough, I honestly didn't think you had ignored it, and it was rude 
of me to suggest otherwise.  I apologize for that.


"fedora-devel" doesn't really have anything of the "authoritative" sort, 
we just have a lot of subscribers and opinions.  Those opinions are 
usually considered by FESCo when FESCo makes a decision, and generally 
considered by those proposing something and asking for feedback on their 
way to a FESCo decision.


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Matthew Garrett]

On Tue, Mar 20, 2012 at 02:33:57PM -0700, Brendan Conoboy wrote:

> The sense I'm getting from your reply is that the PA/SA designation
> is almost decorative, that a secondary can do anything a primary
> can, except inhibit the progress of builds.  So, if the Fedora ARM
> team fixes all broken builds, brings in all the QE mechanisms,
> engages the Fedora system at every level of the organization, solves
> the the build time performance issue, and otherwise keep at it until
> we're functionally indistinguishable from PA, *then* it's time to
> have the PA/SA discussion.  Is that right?  Speaking for myself, I
> see most of these things as a benefit of membership in PA rather
> than prerequisites.  Or more to the point, transitioning from SA to
> PA means doing all of these things, so it's really just an order of
> operations that needs to be agreed upon.

I think you're looking at this in slightly the wrong way. Being a 
primary architecture isn't meant to be a benefit to the port - it's 
meant to be a benefit to Fedora. Adding arm to the PA list means you'll 
have to take on a huge number of additional responsibilities, deal with 
more people who are unhappy about the impact upon their packages and so 
on. You get very little out of it except that there's more people to 
tell you that something's broken. The question is whether making arm a 
primary architecture makes Fedora a better distribution, and yes, in an 
ideal world arm would demonstrate that it was just as functional as x86 
before we had to make that decision.

The only reward you'll get from being a primary architecture is basking 
in the knowledge that the project thinks your work is good enough to be 
a primary architecture. The better you can demonstrate that in advance, 
the easier the process will be.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 01:03 PM, Jesse Keating wrote:

As an example, the same koji server handling x86 builds handling ARM
builds.


Only the koji hub would be the same, the arm builders would be different
machines. This isn't all that different from having the primary hub
trigger the arm hub to start a build on the arm builders.


So in principle, do you object to the same koji hub being used for ARM 
if ARM is still SA?



The PPC builders are there, or at least were at some point, why not
propose moving some arm stuff there for the arm secondary arch effort?


...


I don't see SA/PA mattering as much here. It's up to QE what they want
to take on and what they point automated tooling at.


The sense I'm getting from your reply is that the PA/SA designation is 
almost decorative, that a secondary can do anything a primary can, 
except inhibit the progress of builds.  So, if the Fedora ARM team fixes 
all broken builds, brings in all the QE mechanisms, engages the Fedora 
system at every level of the organization, solves the the build time 
performance issue, and otherwise keep at it until we're functionally 
indistinguishable from PA, *then* it's time to have the PA/SA 
discussion.  Is that right?  Speaking for myself, I see most of these 
things as a benefit of membership in PA rather than prerequisites.  Or 
more to the point, transitioning from SA to PA means doing all of these 
things, so it's really just an order of operations that needs to be 
agreed upon.



That's set by you, as a secondary arch. Why not pin it to the Fedora
release schedule and see how well you do?


We're quite close, though clearly the QE is different.


That said, within the websites group perhaps there is room for a
featured secondary arch, with high visibility. Having something to point
to first would help.


Fair enough.


Did you just ignore the emails starting these two threads by mjg and
pjones? I believe they outlined some very good requirements for getting
a secondary arch into primary. These longer threads have been debating
some of the finer points of those proposals.


On the contrary, mjg and pjones' emails are just the sort of 
constructive and thoughtful feedback I'm looking for.  If the points 
they've raised (which they also raised yesterday) speak to everybody's 
concerns, then I'm happy to view them as the authoritative feedback of 
Fedora-devel for our planning purposes.  On the other hand, if they've 
left anything out that should be considered in this plan, I'd like to 
see it.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 01:48 PM, Richard W.M. Jones wrote:

I would suggest -- in order to move the present discussion on -- that
you try using various methods to speed up an ARM build of (eg) glibc.
distcc, some sort of demo cross-compilation, etc.  What works, what
doesn't work, what needs more work?


Distcc suffers from a fatal flaw: You can't reproduce the build. 
Transient failures and corruption cannot be tracked down.  We've done 
lots of experimentation with distcc, even using distcc + a cross 
compiler.  It does great stuff to build time performance, but it 
sacrifices build integrity for performance and that's not an acceptable 
condition for PA.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 01:32 PM, Przemek Klosowski wrote:

Is cross-compile an option? if it is, how long does it take to
cross-compile in an x86_64 environment?


Discussed elsewhere in this thread.  Not an option.

--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Richard W.M. Jones]

On Tue, Mar 20, 2012 at 11:05:20AM -0700, Brendan Conoboy wrote:
> On 03/20/2012 10:44 AM, drago01 wrote:
> >On Tue, Mar 20, 2012 at 5:56 PM, Brendan Conoboy  wrote:
> >>Please, please, no.  Cross compilation for Fedora cannot and will not ever
> >>get a secondary arch to primary.  We're talking man-decades of engineering
> >>time to solve all the problems.  Decades.
> >
> >Sorry I am not buying that.
> 
> Because you have vast experience to the contrary?  Look, even x86_64
> is topping out on speed and moving to a more-core and
> more-systems-per-rack model.  Cross compilation solves yesterday's
> problem, not tomorrow's. If build speed truly is a fundamental issue
> to becoming PA the answer is to harness multiple systems for a
> single build, not to use a somewhat faster system to make up for the
> speed of a somewhat slower system. Scaling across more cores than
> fit in a single SMP Linux environment is the only sensible approach
> to future build speedups.

This is a sound observation, but it doesn't apply to Fedora on ARM
unless you can demonstrate a system where rpmbuild scales well across
multiple ARM cores/servers/whatever.

I would suggest -- in order to move the present discussion on -- that
you try using various methods to speed up an ARM build of (eg) glibc.
distcc, some sort of demo cross-compilation, etc.  What works, what
doesn't work, what needs more work?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Richard W.M. Jones]

On Tue, Mar 20, 2012 at 06:54:07PM +0100, Kevin Kofler wrote:
> Michael Cronenworth wrote:
> > Kevin, you don't know what you are talking about. Every cell phone has
> > an ARM cpu in it. Smart phone or otherwise. Almost every HDTV has an ARM
> > cpu in it. Almost every tablet has an ARM cpu in it.
> 
> Several of those are not suitable devices to run a general purpose GNU/Linux 
> distribution on, and even for those which are, why would they be our primary 
> target?

It's a matter of time, and not very much time at that.

My £400 tablet has plenty enough power, storage and whatever else to
run Fedora.  Fedora works pretty well on £200 Trim Slice servers.
Fedora is going to be shipped with £25 Raspberry Pi devices in the
near future.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Przemek Klosowski]

On 03/20/2012 12:15 PM, Jakub Jelinek wrote:


Looking at last gcc build times (not unusual, though I really remember
arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours
on both arm architectures), from
http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log
 :
i6864h18m
x86_64  1h25m

...

armv5tel26h20m
armv7hl 24h17m


Is cross-compile an option? if it is, how long does it take to 
cross-compile in an x86_64 environment?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 01:14 PM, Andy Grover wrote:

Can Koji use distcc for ARM arches? Would that speedup be enough to make
ARM build competitive with others?


I believe this is a non-starter for rel-eng.  The ARM team are not 
recommending this path.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Andy Grover]

On 03/20/2012 09:15 AM, Jakub Jelinek wrote:
> Looking at last gcc build times (not unusual, though I really remember
> arm taking much longer than that, e.g. 4.7.0-0.11.fc17 took almost 17 hours
> on both arm architectures), from
> http://*koji.fedoraproject.org/packages/gcc/4.7.0/0.20.fc17/data/logs/*/state.log
>  :
> i686  4h18m
> x86_641h25m
> ppc   4h12m
> ppc64 4h16m
> s390  6h27m
> s390x 6h04m
> armv5tel  26h20m
> armv7hl   24h17m
> 
> So even speeding this up twice means it is still 2x slower than the
> slowest other secondary architecture.

Can Koji use distcc for ARM arches? Would that speedup be enough to make
ARM build competitive with others?

-- Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Chris Murphy]

On Mar 20, 2012, at 1:52 PM, Brendan Conoboy wrote:

>> 
> 
> Yes, the all-or-nothing mindset between secondary and primary is almost 
> certainly the root of the problem.

Well that and I think there's some resistance at the notion that for the 
massive consumer market, the desktop is a dead platform. Not quite letter type 
dead. Yet. But it basically just experienced a drive by shooting in 2011, and 
it's just a matter of time before the patient bleeds out.

I actually find mobile and tablet quite irritating as a platform, presently. 
Nevertheless, desktop is rapidly becoming more of an anchor, than a mountain to 
be climbed.

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Jesse Keating]

On 3/20/12 12:32 PM, Brendan Conoboy wrote:

On 03/20/2012 12:19 PM, Jesse Keating wrote:

What does "better than secondary arch" mean to you? I'm really
struggling here.


As an example, the same koji server handling x86 builds handling ARM
builds.


Only the koji hub would be the same, the arm builders would be different 
machines.  This isn't all that different from having the primary hub 
trigger the arm hub to start a build on the arm builders.



The same facilities providing power, cooling, storage.


The PPC builders are there, or at least were at some point, why not 
propose moving some arm stuff there for the arm secondary arch effort?



Subject
to applicability, the same QE mechanisms being employed.


I don't see SA/PA mattering as much here.  It's up to QE what they want 
to take on and what they point automated tooling at.



The same
release schedule.


That's set by you, as a secondary arch.  Why not pin it to the Fedora 
release schedule and see how well you do?



Comparable positioning on the Fedora downloads pages.


That's a big ball of "another issue" there.  That's a constant fight 
within the spins of the primary arch products, and from what I've seen, 
Arm products are more closely aligned with spins than anything else.


That said, within the websites group perhaps there is room for a 
featured secondary arch, with high visibility.  Having something to 
point to first would help.



Primary and secondary are night-and-day different, it isn't just the
integrated build system being disconnected, it's end-to-end.


We as a group have identified many of the roadblocks or pain points of
bringing arm into primary arch.


What pain points have been described other than "I am concerned about
the impact of builds on the whole running slower than they do now"? This
is not a facetious question, this is really what we're trying to get
from the thread.



Did you just ignore the emails starting these two threads by mjg and 
pjones?  I believe they outlined some very good requirements for getting 
a secondary arch into primary.  These longer threads have been debating 
some of the finer points of those proposals.


--
Jesse Keating
Fedora -- Freedom² is a feature!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Chris Murphy]

On Mar 20, 2012, at 1:14 PM, Kevin Kofler wrote:
>> 
> 
> It doesn't make sense to discuss requirements for becoming a primary 
> architecture without discussing whether it should be considered in the first 
> place.

Seems requirements are needed to have the discussion, to have metrics based 
rather than emotion based consideration. Actively pushing that adrenaline 
button as a significant means of making decisions might be entertaining, but 
eventually a real conversation is the goal.

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Aleksandar Kurtakov]

- Original Message -
> From: "Brendan Conoboy" 
> To: devel@lists.fedoraproject.org
> Sent: Tuesday, March 20, 2012 9:14:11 PM
> Subject: Re: RFC: Primary architecture promotion requirements
> 
> On 03/20/2012 12:05 PM, Jesse Keating wrote:
> > So if you're willing to live like that, I must ask again, what do
> > you
> > think you'll be getting out of being a primary arch?
> 
> I'm willing to temporarily do better than secondary and worse than
> primary on the road to becoming primary.  This is a huge transition-
> identifying the right path to make that transition is part of what
> this
> is about.  The whole point of this thread is to establish
> requirements
> for promotion.  Part of that discussion logically includes the steps
> to
> get there.  Currently what I hear is "be as good as x86 and you're
> there."  That's not productive.  There are legitimate issues with
> moving
> to PA so we're having this discussion to identify them and ultimately
> work through them.

If we really have to set requirements for proposals I see one thing totally 
missed from the discussion up to now. 
Is the SA ready? And giving a definition for being ready:
* does it release together with the PAs? 
* has it ever released without a significant delay? define delay - 1 month?, 3 
months?
* does it have the majority of the packages readgy? 70? 80? 90%? 
* name yours

I really think that before promoting SA to PA it should have at least one 
release being done together with the PAs with a sufficient feature set. Nothing 
prevents SA to prove that it can deliver on time much like the PA do now.

Alex


> 
> --
> Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Peter Jones]

On 03/20/2012 03:32 PM, Brendan Conoboy wrote:
> On 03/20/2012 12:19 PM, Jesse Keating wrote:
>> What does "better than secondary arch" mean to you? I'm really
>> struggling here.
> 
> As an example, the same koji server handling x86 builds handling ARM
> builds. The same facilities providing power, cooling, storage.
> Subject to applicability, the same QE mechanisms being employed. The
> same release schedule. Comparable positioning on the Fedora downloads
> pages. Primary and secondary are night-and-day different, it isn't
> just the integrated build system being disconnected, it's
> end-to-end.

So, what we really need to talk about is how to make it possible to live
as a secondary arch with stricter requirements than some secondaries have.

Ultimately here the question is how to make graduated transitions from
one to the other.  But the reasons to be a primary arch can't be as a
mechanism to become good enough to be a primary arch.

Forgive me for an extended metaphor, but this is like minor league baseball.
Nobody gets promoted to the majors to learn how to be good enough for the
majors.  Exactly the same situation exists between being a secondary arch
vs a primary one - which means we need to do a much better job in
secondary land of being able to prepare something for the time when it's
appropriate to make it a primary arch. But promoting something to primary
shouldn't be the mechanism to /prepare/ it for a higher level of expectations.

>> We as a group have identified many of the roadblocks or pain points of
>> bringing arm into primary arch.
> 
> What pain points have been described other than "I am concerned about
> the impact of builds on the whole running slower than they do now"?
> This is not a facetious question, this is really what we're trying to
> get from the thread.

Also the things I've listed before involving shared maintainership of the
whole as opposed to effectively having arch maintainers, the installation
question, and the question of what the test plans look like.  Right now
those are questions you're taking back to work on, and I understand that,
but I think it's probably the sort of thing people refer to when they say
things like the above.

-- 
Peter

What we need is either less corruption, or more chances to participate in it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Brendan Conoboy]

On 03/20/2012 12:44 PM, Chris Murphy wrote:

But this *requirements* thread is about acclimation, planning and anticipating 
the challenges of the climb. Serious climbs may involve days or months of this. 
So if the analogy holds, a lot of advance work has to be done before ARM 
actually is promoted to primary. This isn't the go, no-go meeting, or gear-up 
time. This is the shopping list.


Thank you :-)


Now the ultra ridiculous: How about secondary architecture requirements demoted 
as-is to tertiary. And create substantially more aggressive requirements for 
secondary architecture (in which ARM would be placed), yet are not identical 
requirements to primary architecture requirements?


Yes, the all-or-nothing mindset between secondary and primary is almost 
certainly the root of the problem.  We want more representation in 
Fedora than being a secondary connotes, but at the same time, ARM today 
does not fulfill every aspect of what PA means.  The discussion is about 
what is required, how to get there.  There has to be a way to represent 
Fedora's architectural support as a spectrum of features, not simply a 
binary assessment.  I absolutely do want to get ARM onto the same koji 
build system, but don't want to make ARM the mortal enemy of every 
packager whose workflow is materially hampered.  This discussion has 
been quite useful in shaping my opinion that we need to improve the koji 
portion of the proposal (Principally because of chain builds), but how 
to make those improvements needs to be worked out.


--
Brendan Conoboy / Red Hat, Inc. / b...@redhat.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: RFC: Primary architecture promotion requirements

[Chris Murphy]

On Mar 20, 2012, at 1:03 PM, Jesse Keating wrote:

> I hate analogies, but no, the first step is working out in a gym to make sure 
> you're in fit enough shape to go up the mountain.

As a distractor from long, heated threads, and mountain person - gym bunnies 
get to altitude and implode routinely. If you want to be in shape for 
mountains, climb lots of stairs. I guess gyms have stair masters. Even dinky 
hills around here in Aspen get the heart to 90% MHR easily. So you need to work 
at getting to and maintaining high heart rates. Advance acclimation helps also.

But this *requirements* thread is about acclimation, planning and anticipating 
the challenges of the climb. Serious climbs may involve days or months of this. 
So if the analogy holds, a lot of advance work has to be done before ARM 
actually is promoted to primary. This isn't the go, no-go meeting, or gear-up 
time. This is the shopping list.

Now the ultra ridiculous: How about secondary architecture requirements demoted 
as-is to tertiary. And create substantially more aggressive requirements for 
secondary architecture (in which ARM would be placed), yet are not identical 
requirements to primary architecture requirements?

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel