10:10 p.m.
This is feedback vs the current version of the following web page:
http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requiremen...
It would be nice if the bullet points were numbers so they could be
referenced numerically.
Promoting an architecture to primary architecture status is a
significant responsibility. It implies that the port is sufficiently
mature that little in the way of further architecture-specific
changes or rebuilds will be required, and also that it has enough
development effort to avoid it delaying the development of other
primary architectures.
What is "...enough development effort to avoid..."? Perhaps this could
be restated for clarity as a development effort is not a unit of
measurement.
as such there are various expectations that the overall Fedora
experience will be consistent over all primary architectures.
Can we quantify what the overall experience is that must be consistent?
I understand Anaconda installations is considered a part of this...
except when it's not for EC2 images. What I'm looking for is "These 10
things are partof the Fedora experience- any PA needs to provide at
least 7 of them" or something like that.
There must be adequate representation for the architecture on the
Fedora infrastructure and release engineering teams.
This makes sense, but what is adequate? Perhaps 1 distinct person in
each group saying "I will be responsible for $ARCH?" What if only 1
person wants to be the secondary representative in both groups?
All builds must occur on Fedora-maintained build servers.
FYI, this will require an additional koji-hub for each architecture
trying to move to PA. Generally agree, though.
Where technically possible, all supported hardware targets must be
supported via Anaconda. Exceptions are limited to highly resource
constrained devices or hardware which provides no means for
simultaneous support of install and target media.
This is overloading "support" so I'm having a little trouble
understanding the intention. Let's try a thought experiment that's a
little more generic than the above. I propose any given architecture
falls into at least 1 and possibly all 4 of the following categories:
1. Specs not suited to Fedora at all (too little RAM, no MMU, etc)
2. Can run Fedora, but Anaconda installation doesn't make sense for
technical reasons.
3. Can run Fedora, would even benefit by Anaconda installation, but
requires changes to Anaconda and/or other packages to work.
4. Can run Fedora and Anaconda supports it fine.
I think what you're trying to express is that either 2 or 4 must be true
and that if 3 is true, 4 must also be true. Is that right?
All supported platforms must have kernels built from the Fedora
kernel SRPM and enabled by default in the spec file. Each kernel must
be built in a timely manner for every SRPM upload.
What exactly is timely? What margin is acceptable? Is this only for
kernel or does this apply to any package with a much-longer-than-average
build time? What would constitute being in that class? Or should the
class be critical-path packages? Something else?
Sufficient developer resources must be available to fix any
architecture-specific issues in such a way that they do not delay
overall Fedora development.
Can you quantify this and also describe how this measurement is to be
assessed? Are we saying there must be X many engineers available at any
given time to handle an architecture-specific build issue? I don't
believe there is a pool of x86 engineers hanging about waiting for
inline assembler issues to come in so some discussion of the mechanics
of what's envisioned here would be helpful. I think the notion is that
there must be a critical-mass of talent competent to help out, but how
do you define that?
It must be possible for maintainers of critical-path hardware
dependent packages to have direct access to supported hardware in
order to rectify any release-blocking issues. For example, X
maintainers must have direct access to any hardware with graphics
capabilities.
Is simulated hardware acceptable? Remote-X or VNC access? Physical
hardware? What happens when a new generation of hardware comes out?
What about architectures where there is no video at all? What about
architectures where some systems have video, others don't, but the
primary use case is systems without video?
The port must not rely on sourceless binaries unless they fall under
the generic firmware exemption. Where source and toolchain are
available, the binaries must be built in the Fedora build
infrastructure.
Yes, assuming the source is compatible with Fedora packaging guidelines.
I'm not sure there's a case where source would be incompatible but
binaries wouldn't be, but thought I'd mentioned it.
Excludearch may be used only to disable packages that are
fundamentally architecture specific.
Assuming we mean the package has architecture specific components that
either can not, or have not, been ported, agree.
Installable, testable images must be generated at the normal project
milestones in a way that conforms to release engineering and QE
requirements. Where possible, image generation should be integrated
into the existing image generation infrastructure.
As long as the RE and QE requirements are similarly defined that's fine.
The architecture must meet appropriate formal release criteria
As long as the release criteria are applicable to the architecture.
This list is not intended to be exhaustive - promotion to primary
architecture status will require agreement from the Fedora
infrastructure, release engineering, kernel and installer teams and
is subject to overall approval by the Fedora Engineering Steering
Committee, and additional criteria may be imposed if felt to be
necessary.
Let's make the list exhaustive; there needs to be a path to sure
success. This means establishing a complete procedure where when an SA
formally applies to become PA, acceptance means there is a definitive
set of steps needed to get there. This is one of the major reasons for
developing these criteria. Put another way:
FESCo and affected groups should have the ability to review whether or
not the SA has in-fact fulfilled the requirements for PA, as agreed to
by all parties at the time of application. If those requirements are
deemed to have been met, promotion is automatic.
There could be a deadline on application acceptance: EG, 12 months from
acceptance of application to fulfillment of criteria. This protects
against criteria becoming stale.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
3:01 a.m.
On 04/03/2012 03:10 AM, Brendan Conoboy wrote:
As long as the RE and QE requirements are similarly defined that's fine.
It would be good to get a clarification from fesco what they are
referring to when they speak of "QE" ( Depending on it's meaning it
might fall under the QA community ) and what they think those
requirements are...
JBG
3:03 a.m.
On 04/03/2012 03:10 AM, Brendan Conoboy wrote:
Let's make the list exhaustive; there needs to be a path to sure
success. This means establishing a complete procedure where when an
SA formally applies to become PA, acceptance means there is a
definitive set of steps needed to get there. This is one of the major
reasons for developing these criteria. Put another way:
FESCo and affected groups should have the ability to review whether or
not the SA has in-fact fulfilled the requirements for PA, as agreed to
by all parties at the time of application. If those requirements are
deemed to have been met, promotion is automatic.
There could be a deadline on application acceptance: EG, 12 months
from acceptance of application to fulfillment of criteria. This
protects against criteria becoming stale.
This sound like the most reasonable approach.
JBG
10:31 a.m.
On 04/03/2012 04:03 AM, "Jóhann B. Guðmundsson" wrote:
On 04/03/2012 03:10 AM, Brendan Conoboy wrote:
>
> Let's make the list exhaustive; there needs to be a path to sure
> success. This means establishing a complete procedure where when
> an SA formally applies to become PA, acceptance means there is a
> definitive set of steps needed to get there. This is one of the
> major reasons for developing these criteria. Put another way:
>
> FESCo and affected groups should have the ability to review whether
> or not the SA has in-fact fulfilled the requirements for PA, as
> agreed to by all parties at the time of application. If those
> requirements are deemed to have been met, promotion is automatic.
>
> There could be a deadline on application acceptance: EG, 12 months
> from acceptance of application to fulfillment of criteria. This
> protects against criteria becoming stale.
This sound like the most reasonable approach.
I actually have a pretty strong disagreement here. If we need sunset clauses,
it means that there's really not enough interaction.
Look at it this way - if an arch is following the process to become primary,
but during that process actually becomes *less* viable, or for whatever
reason farther from being reasonable as a PA, the process needs to be
such that that's something people see and discuss. If it doesn't come up,
it's because it's completely fallen off the deep end.
So I'd much rather just say that an arch that's attempting to transition
from secondary to primary needs to regularly keep FESCo and f-d-l informed
as to the status than have something like formal sunsetting. If they don't
keep us up to date, they have de facto stopped trying.
--
Peter
10:37 a.m.
On Tue, Apr 3, 2012 at 4:31 PM, Peter Jones <pjones(a)redhat.com> wrote:
On 04/03/2012 04:03 AM, "Jóhann B. Guðmundsson" wrote:
> On 04/03/2012 03:10 AM, Brendan Conoboy wrote:
>>
>> Let's make the list exhaustive; there needs to be a path to sure
>> success. This means establishing a complete procedure where when
>> an SA formally applies to become PA, acceptance means there is a
>> definitive set of steps needed to get there. This is one of the
>> major reasons for developing these criteria. Put another way:
>>
>> FESCo and affected groups should have the ability to review whether
>> or not the SA has in-fact fulfilled the requirements for PA, as
>> agreed to by all parties at the time of application. If those
>> requirements are deemed to have been met, promotion is automatic.
>>
>> There could be a deadline on application acceptance: EG, 12 months
>> from acceptance of application to fulfillment of criteria. This
>> protects against criteria becoming stale.
>
> This sound like the most reasonable approach.
I actually have a pretty strong disagreement here. If we need sunset clauses,
it means that there's really not enough interaction.
Look at it this way - if an arch is following the process to become primary,
but during that process actually becomes *less* viable, or for whatever
reason farther from being reasonable as a PA, the process needs to be
such that that's something people see and discuss. If it doesn't come up,
it's because it's completely fallen off the deep end.
So I'd much rather just say that an arch that's attempting to transition
from secondary to primary needs to regularly keep FESCo and f-d-l informed
as to the status than have something like formal sunsetting. If they don't
keep us up to date, they have de facto stopped trying.
I agree, anything that is going to take that length of time is still
really a secondary arch. Ultimately with a set of reasonably defined
criteria the request shouldn't really be made until the architecture
in question is fairly confident that they meet the criteria and then
there should be a relatively quick move one way or the other.
Obviously there's going to be some time regarding things like
infra/rel-eng etc eg for HW procurement if necessary but the overall
process side of it should be active.
Peter
4:57 a.m.
Peter Robinson wrote:
I agree, anything that is going to take that length of time is still
really a secondary arch.
Indeed, it sounds obvious to me that the only reasonable reaction to a
sunset clause is to automatically reject the promotion request, not to
automatically accept it!
Kevin Kofler
7:50 p.m.
On 04/03/2012 08:31 AM, Peter Jones wrote:
Look at it this way - if an arch is following the process to become
primary,
but during that process actually becomes *less* viable, or for whatever
reason farther from being reasonable as a PA, the process needs to be
such that that's something people see and discuss. If it doesn't come up,
it's because it's completely fallen off the deep end.
So I'd much rather just say that an arch that's attempting to transition
from secondary to primary needs to regularly keep FESCo and f-d-l informed
as to the status than have something like formal sunsetting. If they don't
keep us up to date, they have de facto stopped trying.
Okay, I'm relenting on automatic promotion. Basically, Peter is right
that communication is essential, so some guidelines on what needs to be
there would be most helpful. I would appreciate wider feedback on
message ID 4F8C8416.4000602(a)redhat.com from yesterday.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
5:43 a.m.
Brendan Conoboy wrote:
If those requirements are deemed to have been met, promotion is
automatic.
I still don't agree that this approach makes any sense whatsoever. Promotion
must be an exceptional event decided on a case-by-case basis or we may end
up with an unmaintainable skyrocketing of primary architectures.
Kevin Kofler
6:58 a.m.
On Apr 2, 2012 11:10 PM, "Brendan Conoboy" <blc(a)redhat.com> wrote:
All builds must occur on Fedora-maintained build servers.
FYI, this will require an additional koji-hub for each architecture
trying to move
to PA. Generally agree, though.
No. The additional hub is only needed while an arch is secondary.
Once it is PA it is driven from the single koji hub.
josh
9:16 a.m.
On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Apr 2, 2012 11:10 PM, "Brendan Conoboy"
<blc(a)redhat.com> wrote:
> All builds must occur on Fedora-maintained build servers.
>
> FYI, this will require an additional koji-hub for each architecture trying
> to move to PA. Generally agree, though.
No. The additional hub is only needed while an arch is secondary.
Once it is PA it is driven from the single koji hub.
That's my understanding but the bullet reads as if there's going to be
a Fedora maintained hub for the secondary arches. At the moment the
hubs for the secondary arches are maintained by the secondary arches.
So the point needs to be clarified.
Peter
10:35 a.m.
On 04/03/2012 10:16 AM, Peter Robinson wrote:
On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer <jwboyer(a)gmail.com>
wrote:
> On Apr 2, 2012 11:10 PM, "Brendan Conoboy" <blc(a)redhat.com> wrote:
>
>> All builds must occur on Fedora-maintained build servers.
>>
>> FYI, this will require an additional koji-hub for each architecture trying
>> to move to PA. Generally agree, though.
>
> No. The additional hub is only needed while an arch is secondary.
> Once it is PA it is driven from the single koji hub.
That's my understanding but the bullet reads as if there's going to be
a Fedora maintained hub for the secondary arches. At the moment the
hubs for the secondary arches are maintained by the secondary arches.
So the point needs to be clarified.
I think there are probably 3 steps here, but obviously I don't speak for
rel-eng, so I'd like to hear what they have to say. I could be wrong about
any of this due to insufficient knowledge of how koji is set up.
1) SA has its own koji hub and builders
2) rel-eng has a "staging" koji hub for arches under transition, which is really
just a temporary thing where we're setting up builders to work with
step 3
3) when we decide that it *is* a PA, transition builders from step #2 to
the primary koji hub.
--
Peter
11:07 a.m.
On Tue, Apr 3, 2012 at 11:35 AM, Peter Jones <pjones(a)redhat.com> wrote:
On 04/03/2012 10:16 AM, Peter Robinson wrote:
> On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
>> On Apr 2, 2012 11:10 PM, "Brendan Conoboy" <blc(a)redhat.com>
wrote:
>>
>>> All builds must occur on Fedora-maintained build servers.
>>>
>>> FYI, this will require an additional koji-hub for each architecture trying
>>> to move to PA. Generally agree, though.
>>
>> No. The additional hub is only needed while an arch is secondary.
>> Once it is PA it is driven from the single koji hub.
>
> That's my understanding but the bullet reads as if there's going to be
> a Fedora maintained hub for the secondary arches. At the moment the
> hubs for the secondary arches are maintained by the secondary arches.
> So the point needs to be clarified.
I think there are probably 3 steps here, but obviously I don't speak for
rel-eng, so I'd like to hear what they have to say. I could be wrong about
any of this due to insufficient knowledge of how koji is set up.
1) SA has its own koji hub and builders
2) rel-eng has a "staging" koji hub for arches under transition, which is
really just a temporary thing where we're setting up builders to work with
step 3
3) when we decide that it *is* a PA, transition builders from step #2 to
the primary koji hub.
From a koji perspective, there really isn't much benefit to step
2.
What needs to happen is the RPMs from the secondary hub need to be
copied to the primary in the correct NVR directories in the hub's
storage. That can happen in the background for quite a bit, but at
some point the hub would need to be taken offline to sync up the last
few builds, and then switch the builders over.
Having a staging hub just means you have to copy and move the builders
twice. This is mostly due to how koji builders can only talk to one
hub at a time and one hub only.
josh
11:18 a.m.
On 04/03/2012 12:07 PM, Josh Boyer wrote:
On Tue, Apr 3, 2012 at 11:35 AM, Peter Jones
<pjones(a)redhat.com> wrote:
> On 04/03/2012 10:16 AM, Peter Robinson wrote:
>> On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
>>> On Apr 2, 2012 11:10 PM, "Brendan Conoboy" <blc(a)redhat.com>
wrote:
>>>
>>>> All builds must occur on Fedora-maintained build servers.
>>>>
>>>> FYI, this will require an additional koji-hub for each architecture
trying
>>>> to move to PA. Generally agree, though.
>>>
>>> No. The additional hub is only needed while an arch is secondary.
>>> Once it is PA it is driven from the single koji hub.
>>
>> That's my understanding but the bullet reads as if there's going to be
>> a Fedora maintained hub for the secondary arches. At the moment the
>> hubs for the secondary arches are maintained by the secondary arches.
>> So the point needs to be clarified.
>
> I think there are probably 3 steps here, but obviously I don't speak for
> rel-eng, so I'd like to hear what they have to say. I could be wrong about
> any of this due to insufficient knowledge of how koji is set up.
>
> 1) SA has its own koji hub and builders
> 2) rel-eng has a "staging" koji hub for arches under transition, which is
really just a temporary thing where we're setting up builders to work with
> step 3
> 3) when we decide that it *is* a PA, transition builders from step #2 to
> the primary koji hub.
From a koji perspective, there really isn't much benefit to step 2.
What needs to happen is the RPMs from the secondary hub need to be
copied to the primary in the correct NVR directories in the hub's
storage. That can happen in the background for quite a bit, but at
some point the hub would need to be taken offline to sync up the last
few builds, and then switch the builders over.
Having a staging hub just means you have to copy and move the builders
twice. This is mostly due to how koji builders can only talk to one
hub at a time and one hub only.
Right, okay, that's a good enough description of what needs to happen
for me.
--
Peter
1:58 p.m.
On 04/03/2012 09:07 AM, Josh Boyer wrote:
From a koji perspective, there really isn't much benefit to step
2.
What needs to happen is the RPMs from the secondary hub need to be
copied to the primary in the correct NVR directories in the hub's
storage. That can happen in the background for quite a bit, but at
some point the hub would need to be taken offline to sync up the last
few builds, and then switch the builders over.
Having a staging hub just means you have to copy and move the builders
twice. This is mostly due to how koji builders can only talk to one
hub at a time and one hub only.
Where do you envision the builders being in this scenario? I see the
steps being something like this:
1. SA builders and/or hub are located outside PHX.
2 option a. Builders come up in PHX, hub stays in original location.
2 option b. Staging hub comes up in PHX, builders stay in original location.
3. Both staging hub and builders come up in PHX
4. When appropriate move from staging hub to primary hub.
Having everything take place in PHX prior to the switchover has numerous
benefits. These 3 come to mind immediately:
1. Fast local network will represent true build times (vs transfering
rpms across the external network).
2. Realistic load assessment. If, hypothetically primary koji and
staging koji are both virtual machines on the same underlying hardware
you'll know if the hardware can handle the load. Also network, disk, etc.
3. Comparable infrastructure reliability.
Switching koji hubs twice does incur a bit more work, but it may also
provide better results.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
2:05 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 03 Apr 2012 11:58:11 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
On 04/03/2012 09:07 AM, Josh Boyer wrote:
> From a koji perspective, there really isn't much benefit to step 2.
> What needs to happen is the RPMs from the secondary hub need to be
> copied to the primary in the correct NVR directories in the hub's
> storage. That can happen in the background for quite a bit, but at
> some point the hub would need to be taken offline to sync up the
> last few builds, and then switch the builders over.
>
> Having a staging hub just means you have to copy and move the
> builders twice. This is mostly due to how koji builders can only
> talk to one hub at a time and one hub only.
Where do you envision the builders being in this scenario? I see the
steps being something like this:
1. SA builders and/or hub are located outside PHX.
2 option a. Builders come up in PHX, hub stays in original location.
2 option b. Staging hub comes up in PHX, builders stay in original
location. 3. Both staging hub and builders come up in PHX
4. When appropriate move from staging hub to primary hub.
As i see it the Secondary arch will continue to run as normal.
we will get new build hardware for use in PHX, it will be brught up
and added to koji behind the scenes we will be importing the matching
latest secondary arch builds to primary koji, and signing if appropriate
At cutover date we will take a outage to make sure we have full
matching content imported. we would add the new arches to the tags and
enable building again.
at this point in time then the secondary arch koji would be considered
legacy and used only to maintain the older stable releases
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk97ShAACgkQkSxm47BaWffPRACgtlC0buQ066+CHlM1STb7rj0g
/1UAoLDyHFa4SWwK7b2MyMMZdnzTRBLf
=pdRh
-----END PGP SIGNATURE-----
2:13 p.m.
On Tue, Apr 3, 2012 at 3:05 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 03 Apr 2012 11:58:11 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
> On 04/03/2012 09:07 AM, Josh Boyer wrote:
> > From a koji perspective, there really isn't much benefit to step 2.
> > What needs to happen is the RPMs from the secondary hub need to be
> > copied to the primary in the correct NVR directories in the hub's
> > storage. That can happen in the background for quite a bit, but at
> > some point the hub would need to be taken offline to sync up the
> > last few builds, and then switch the builders over.
> >
> > Having a staging hub just means you have to copy and move the
> > builders twice. This is mostly due to how koji builders can only
> > talk to one hub at a time and one hub only.
>
> Where do you envision the builders being in this scenario? I see the
> steps being something like this:
>
> 1. SA builders and/or hub are located outside PHX.
> 2 option a. Builders come up in PHX, hub stays in original location.
> 2 option b. Staging hub comes up in PHX, builders stay in original
> location. 3. Both staging hub and builders come up in PHX
> 4. When appropriate move from staging hub to primary hub.
As i see it the Secondary arch will continue to run as normal.
we will get new build hardware for use in PHX, it will be brught up
and added to koji behind the scenes we will be importing the matching
Who is "we" in this scenario. It's the responsibility of the SA team
to provide hardware for builders, and I don't see promotion to PA as
grounds for someone other than the SA team purchasing it. Basically,
"we" here should not be "the Fedora project".
josh
2:29 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 3 Apr 2012 15:13:51 -0400
Josh Boyer <jwboyer(a)gmail.com> wrote:
On Tue, Apr 3, 2012 at 3:05 PM, Dennis Gilmore
<dennis(a)ausil.us>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 03 Apr 2012 11:58:11 -0700
> Brendan Conoboy <blc(a)redhat.com> wrote:
>
>> On 04/03/2012 09:07 AM, Josh Boyer wrote:
>> > From a koji perspective, there really isn't much benefit to
>> > step 2. What needs to happen is the RPMs from the secondary hub
>> > need to be copied to the primary in the correct NVR directories
>> > in the hub's storage. That can happen in the background for
>> > quite a bit, but at some point the hub would need to be taken
>> > offline to sync up the last few builds, and then switch the
>> > builders over.
>> >
>> > Having a staging hub just means you have to copy and move the
>> > builders twice. This is mostly due to how koji builders can only
>> > talk to one hub at a time and one hub only.
>>
>> Where do you envision the builders being in this scenario? I see
>> the steps being something like this:
>>
>> 1. SA builders and/or hub are located outside PHX.
>> 2 option a. Builders come up in PHX, hub stays in original
>> location. 2 option b. Staging hub comes up in PHX, builders stay
>> in original location. 3. Both staging hub and builders come up in
>> PHX 4. When appropriate move from staging hub to primary hub.
>
> As i see it the Secondary arch will continue to run as normal.
> we will get new build hardware for use in PHX, it will be brught up
> and added to koji behind the scenes we will be importing the
> matching
Who is "we" in this scenario. It's the responsibility of the SA team
to provide hardware for builders, and I don't see promotion to PA as
grounds for someone other than the SA team purchasing it. Basically,
"we" here should not be "the Fedora project".
josh
We would be releng importing the binaries into the primary koji.
Hardware procurement would be done to infrastructure specifications.
with support contracts, remote management etc. as to who buys it? I
would hope that the secondary arch team could negotiate donations from
vendors. since the arch would be growing and the vendors would want it
to be used as a selling point. Builder hardware today is all provided
by purchases by Red Hat, the last builder hardware was purchased by Red
Hat IT and the koji storage was a mixture of Release Engineering and
Red Hat IT. I really don't care who pays for the hardware, just that we
have hardware that meets the requirements for being in the colo.
ongoing hardware costs will likely be from one of Fedora engineering,
Release engineering or Red Hat IT's budget.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk97T6UACgkQkSxm47BaWffFXwCfVrrnAG9tt6KAif/9cv3VtDys
aZQAn1CyzOVjqiPr/Kd46rVPtZXecEW6
=/1J2
-----END PGP SIGNATURE-----
4:10 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 04/03/2012 07:29 PM, Dennis Gilmore wrote:
I really don't care who pays for the hardware, just that we
have hardware that meets the requirements for being in the colo.
ongoing hardware costs will likely be from one of Fedora engineering,
Release engineering or Red Hat IT's budget.
Just out of curiosity what's the procedure for the community to provide
releng/infrastructure with hw if it's needed?
Does there exist an paypal account or something similar to gather funds
for needed hw?
Long story put short what can we do and what cant we do in that regard?
JBG
4:21 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
2012/4/3 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
On 04/03/2012 07:29 PM, Dennis Gilmore wrote:
>
> I really don't care who pays for the hardware, just that we
> have hardware that meets the requirements for being in the colo.
> ongoing hardware costs will likely be from one of Fedora engineering,
> Release engineering or Red Hat IT's budget.
Just out of curiosity what's the procedure for the community to provide
releng/infrastructure with hw if it's needed?
Does there exist an paypal account or something similar to gather funds for
needed hw?
Long story put short what can we do and what cant we do in that regard?
I believe it depends, in the case of ARM I believe it's going to be a
combination of working with vendors and possibly some budget from with
in Red Hat (no idea of the department or where) based on discussions
had at FUDCon.
Peter
4:23 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
2012/4/3 "Jóhann B. Guðmundsson" <johannbg(a)gmail.com>:
On 04/03/2012 07:29 PM, Dennis Gilmore wrote:
>
> I really don't care who pays for the hardware, just that we
> have hardware that meets the requirements for being in the colo.
> ongoing hardware costs will likely be from one of Fedora engineering,
> Release engineering or Red Hat IT's budget.
Just out of curiosity what's the procedure for the community to provide
releng/infrastructure with hw if it's needed?
The rules are, it has to be rack mountable hardware that comes with
full warranty support. I believe it needs to also have some form of
remote management.
If it meets those rules, you can file a ticket with infrastructure and
ship it to the PHX2 datacenter. They'll let you know if there is space
and power drops in the datacenter, etc.
Does there exist an paypal account or something similar to gather
funds for
needed hw?
No Fedora sponsored PayPal account. There are various reasons that
one can't be created, similar to how you cannot donate financially to
the Fedora Project. SA teams could possibly create one themselves I
guess.
Long story put short what can we do and what cant we do in that
regard?
The need for a full warranty is usually enough of a hurdle to limit
what the community as a bunch of individuals can do. Your idea of a
community started funding account is new though I think. It might be
worth exploring.
josh
4:34 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Tue, Apr 3, 2012 at 5:29 PM, DJ Delorie <dj(a)redhat.com> wrote:
> The rules are, it has to be rack mountable hardware
Hmmm... how many Raspberry Pis can we fit in a rack?
And at $35 each, spares would be cheaper than a warranty ;-)
I don't think those were ever targetted as the ARM builder hardware
that would go in PHX2. Jon mentioned "enterprise class" ARM servers
numerous times. I was assuming that meant rack mountable.
josh
4:37 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Tue, Apr 3, 2012 at 10:34 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Tue, Apr 3, 2012 at 5:29 PM, DJ Delorie <dj(a)redhat.com>
wrote:
>
>> The rules are, it has to be rack mountable hardware
>
> Hmmm... how many Raspberry Pis can we fit in a rack?
>
> And at $35 each, spares would be cheaper than a warranty ;-)
I don't think those were ever targetted as the ARM builder hardware
that would go in PHX2. Jon mentioned "enterprise class" ARM servers
numerous times. I was assuming that meant rack mountable.
It's not, it was a joke (at least I think it was), they don't even
support ARMv7 and aren't currently completely open so aren't an option
and have never been discussed.
Peter
4:45 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
I don't think those were ever targetted as the ARM builder
hardware
that would go in PHX2. Jon mentioned "enterprise class" ARM servers
numerous times. I was assuming that meant rack mountable.
It was a joke! Don't you people have a sense of humor?
4:53 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 04/03/2012 09:23 PM, Josh Boyer wrote:
The need for a full warranty is usually enough of a hurdle to limit
what the community as a bunch of individuals can do. Your idea of a
community started funding account is new though I think. It might be
worth exploring.
Arguably we ( as a community ) should be striving to become as
independent of Red Hat as possible so it strikes me as a bit odd that we
cant by some means fund the project either by donating ourselves or by
getting other corporate sponsorship.
I think it's inevitable that there will be conflicts of interest with
Red Hat and just to give you an recent example Red Hat has stated that
it is not willing to put effort or resources into a Fedora LTS distribution.
Which means for example we ( as an community ) might need to fund and
setup our own infrastructure to host an Fedora LTS release efforts for
the project and it kinda goes with out saying that we need a way to fund
such efforts.
On and on it should be sufficient for the project I suppose to have an
community wiki page wish list with donate link(s) for various stuff like
server hw,camera's to be used to record sessions at various events for
those community members that are unable to attend, even sponsor people
to attend for that matter or any other ideas/stuff that might need funding.
Somehow other distro's have manage to find a way to fund themselves
perhaps we can adopt some of their model and implement it either
officially or unofficially...
JBG
4:57 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 4/3/12 2:53 PM, "Jóhann B. Guðmundsson" wrote:
Somehow other distro's have manage to find a way to fund
themselves
perhaps we can adopt some of their model and implement it either
officially or unofficially...
I suggest a long and depressing read of American tax law.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
9:59 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 3 April 2012 15:57, Jesse Keating <jkeating(a)j2solutions.net> wrote:
On 4/3/12 2:53 PM, "Jóhann B. Guðmundsson" wrote:
>
> Somehow other distro's have manage to find a way to fund themselves
> perhaps we can adopt some of their model and implement it either
> officially or unofficially...
I suggest a long and depressing read of American tax law.
Actually not just American tax law. European tax law (both EU and
national/provincial/etc), International trademark law (again US, EU,
and local ones), and various other corporation and non profit laws.
Basically you have to spend more time dealing with teams of lawyers
than you do coding..
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
1:23 a.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 04/04/2012 02:59 AM, Stephen John Smoogen wrote:
Actually not just American tax law. European tax law (both EU and
national/provincial/etc), International trademark law (again US, EU,
and local ones), and various other corporation and non profit laws.
Basically you have to spend more time dealing with teams of lawyers
than you do coding..
So you guys are trying to claim that taxes are what prevents the
community from contributing and for the project to accept those
contributions?
I for one would think the project could be categorized as not for profit
organization.
It may not be one today which simply begs the question what's preventing
us becoming one tomorrow...
In any case there are ways to work around Red Hat and taxes should the
community be forced to do so...
JBG
8:31 a.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 2:23 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
I for one would think the project could be categorized as not for
profit
organization.
I'm not an attorney, and don't play one on the Internet, and I don't
pretend to have a completely understanding of all the nuances and
details, but I'll share a few things I learned during my time as the
FPL. Please don't consider this as either authoritative or as legal
advice -- this is just one guy's ramblings on a subject that he's
passionate about.
First of all, let me speak to the motivation. I think there are many
people (including community members and Red Hat employees) that can
see some advantages of having a non-profit organization of some flavor
for the Fedora Projects. My understanding is that Red Hat even put a
lot of time and effort into investigating that path in the early
Fedora days.
Now, for the ugly part. One of the many complications is that if a US
non-profit receives the majority of its funding and support from a
single corporate entity, that the non-profit begins to look like a tax
shelter, and at least under US law, that causes more headaches than it
is worth. I'm sure there are other complications as well, but that's
the most obvious one to me.
I, for one, would *love* to find a way for Fedora to be able to accept
funds from outside groups. I'm not complaining about Red Hat here --
I think they've been a great corporate sponsor of the Fedora Project,
and I don't personally see the need for the Fedora Project to distance
itself from them. They continue to put a lot of resources (money,
salaried positions, legal support -- and most importantly -- trust) in
Fedora, and I'd never suggest doing anything that might jeopardize
that. I would like other organizations to be able to donate money to
Fedora too, and in an ideal world we could sell Fedora-branded items
and have a portion of the proceeds directly benefit the project. I
investigated and pushed for the ability to make this happen while I
was FPL, but the stark reality is that there's no feasible way to do
this at the present time. The easiest way for outside organizations
to help Fedora is to directly provide support at FUDCons (such as
directly paying for the catering or the internet access), or donating
hardware to the Infrastructure team (and there are certain guidelines
that the Infra team can share with you, if you're interested). It's
not an ideal situation by any stretch of the imagination, but it's the
situation we live in right now.
--
Jared Smith
8:44 a.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 04/04/2012 09:31 AM, Jared K. Smith wrote:
Now, for the ugly part. One of the many complications is that if a US
non-profit receives the majority of its funding and support from a
single corporate entity, that the non-profit begins to look like a tax
shelter, and at least under US law, that causes more headaches than it
is worth. I'm sure there are other complications as well, but that's
the most obvious one to me.
I, for one, would *love* to find a way for Fedora to be able to accept
funds from outside groups.
Could you clarify whether the problem is that there is no way to donate
at all, or that the donors cannot write the donations off their taxes?
I seem to remember that public institutions (for instance, the
government) are in general barred from accepting gifts; however, Fedora
Foundation and even RedHat are simply regular legal entities, so I'd
think that a random member of the public could donate to them, just like
they could gift another person. It's just that the gift would not be
tax-deductible.
9:04 a.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 9:44 AM, Przemek Klosowski
<przemek.klosowski(a)nist.gov> wrote:
Could you clarify whether the problem is that there is no way to
donate at
all, or that the donors cannot write the donations off their taxes?
Both. Red Hat has no way to accept outside money on behalf of Fedora,
and since Red Hat is a for-profit corporation there is no way to write
off the donations.
--
Jared Smith
12:14 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 4 April 2012 07:31, Jared K. Smith <jsmith(a)fedoraproject.org> wrote:
On Wed, Apr 4, 2012 at 2:23 AM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
Now, for the ugly part. One of the many complications is that if a
US
non-profit receives the majority of its funding and support from a
single corporate entity, that the non-profit begins to look like a tax
shelter, and at least under US law, that causes more headaches than it
is worth. I'm sure there are other complications as well, but that's
the most obvious one to me.
It is not just US law. Most countries have similar rules in place for
non-profits due a long history of them being used as fronts for
governments and corporations for tax-dodging, espionage, bribery, and
other shenanigans. In this case the US laws matter because Red Hat is
based in the US.. but the same issues would come up in the EU or
similar places.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
2:01 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 04/04/2012 05:14 PM, Stephen John Smoogen wrote:
It is not just US law. Most countries have similar rules in place
for
non-profits due a long history of them being used as fronts for
governments and corporations for tax-dodging, espionage, bribery, and
other shenanigans. In this case the US laws matter because Red Hat is
based in the US.. but the same issues would come up in the EU or
similar places.
Somehow other distribution have manage to make this work so perhaps we
need to hear from debian,gentoo etc people what process they have used
and how it has turned out to them?
Perhaps we need to separate all ( legal? ) connections to Red Hat ( Red
Hat would then just donate via the same method than anyone else ) to
make this work or directly donate money/hw/stuff directly to each
individual SIG's representatives or perhaps to ambassadors?
JBG
2:54 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 3:01 PM, "Jóhann B. Guðmundsson"
<johannbg(a)gmail.com> wrote:
Perhaps we need to separate all ( legal? ) connections to Red Hat (
Red Hat
would then just donate via the same method than anyone else ) to make this
work or directly donate money/hw/stuff directly to each individual SIG's
representatives or perhaps to ambassadors?
For what benefit? Again, if Red Hat is still providing the majority
of the funding and resources for Fedora, we still end up looking like
a tax shelter. If Red Hat isn't providing the majority of the funding
for Fedora, then unless a miracle happens and we get a *metric ton* of
other funding, we'd end up with less resources than we have now. (And
that's just speaking of the budget that Red Hat gives to Fedora, not
to mention the salaries for the FPL, members of the infrastructure
team, the colocation facilities, the legal support and defense, the
public relations help, and so on.)
Le me put it much more bluntly: I think the relationship with Red Hat
is very beneficial to Fedora, and Fedora is beneficial to Red Hat, and
trying to put significant distance between the two is going to cause
more problems than it's worth. Again, in an ideal world, we'd be able
to do more than we can now -- but there just happens to be a big gap
between theory and reality that we can't easily ignore.
--
Jared Smith
3 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 4/4/12 12:01 PM, "Jóhann B. Guðmundsson" wrote:
Somehow other distribution have manage to make this work so perhaps
we
need to hear from debian,gentoo etc people what process they have used
and how it has turned out to them?
There is no single legal entity to speak of behind these distros, let
alone one that pulls in over a billion dollars in revenue a year, that
would be a fat target for tax lawsuits.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
12:26 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 04/04/2012 03:31 PM, Jared K. Smith wrote:
I, for one, would *love* to find a way for Fedora to be able to
accept
funds from outside groups. I'm not complaining about Red Hat here --
I think they've been a great corporate sponsor of the Fedora Project,
and I don't personally see the need for the Fedora Project to distance
itself from them. They continue to put a lot of resources (money,
salaried positions, legal support -- and most importantly -- trust) in
Fedora, and I'd never suggest doing anything that might jeopardize
that. I would like other organizations to be able to donate money to
Fedora too, and in an ideal world we could sell Fedora-branded items
and have a portion of the proceeds directly benefit the project. I
investigated and pushed for the ability to make this happen while I
was FPL, but the stark reality is that there's no feasible way to do
this at the present time. The easiest way for outside organizations
to help Fedora is to directly provide support at FUDCons (such as
directly paying for the catering or the internet access), or donating
hardware to the Infrastructure team (and there are certain guidelines
that the Infra team can share with you, if you're interested). It's
not an ideal situation by any stretch of the imagination, but it's the
situation we live in right now.
--
Jared Smith
Does that mean the only cold hard cash Fedora receives is from Redhat?
Ie. all travel allownaces etc cmoe from that support?
I was recently asked in an interview what funds we (the current Fedora
project I'm working on) was looking for. And all I could say was peoples
time and knowledge :(
12:36 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 1:26 PM, Brendan Jones
<brendan.jones.it(a)gmail.com> wrote:
Does that mean the only cold hard cash Fedora receives is from
Redhat? Ie.
all travel allownaces etc cmoe from that support?
Yes. We've had other companies help sponsor FUDCon events (thank
you!) and donate equipment, bandwidth, etc., but to use your
terminology, the only cold hard cash that Fedora receives is from Red
Hat. All the travel subsidies, swag production, media production,
release parties, and so forth come from the budget we get from Red
Hat.
--
Jared Smith
1:28 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
Ok, giving money won't work, and the tax stuff is a mess. Let's
ignore that for a second.
What about equipment?
Consider: if a box showed up at PHX, which contained hardware that met
the technology requirements of PHX, with a note that said "here,
yours, no strings attached" - what would happen? Would it be
returned, or used?
1:29 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 4/4/12 11:28 AM, DJ Delorie wrote:
Ok, giving money won't work, and the tax stuff is a mess.
Let's
ignore that for a second.
What about equipment?
Consider: if a box showed up at PHX, which contained hardware that met
the technology requirements of PHX, with a note that said "here,
yours, no strings attached" - what would happen? Would it be
returned, or used?
Used. There is a process for donating hardware in place, and it's been
used before.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
1:31 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 2:29 PM, Jesse Keating <jkeating(a)j2solutions.net> wrote:
On 4/4/12 11:28 AM, DJ Delorie wrote:
>
> Ok, giving money won't work, and the tax stuff is a mess. Let's
> ignore that for a second.
>
> What about equipment?
>
> Consider: if a box showed up at PHX, which contained hardware that met
> the technology requirements of PHX, with a note that said "here,
> yours, no strings attached" - what would happen? Would it be
> returned, or used?
Used. There is a process for donating hardware in place, and it's been used
before.
To be clear, it would be used but ownership still resides with whomever
purchased the hardware. At least as far as I know. So really, it's
more akin to PHX hosting your hardware for use than it is an outright
donation. Think of it as an indefinite loan, where you don't pay for
colo space/power.
josh
1:36 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
To be clear, it would be used but ownership still resides with
whomever
purchased the hardware.
Really? You can't donate hardware, you can only let Fedora borrow it?
If you sponsor catering at a con, do you need to get the food back at
some point too? Sounds like a silly distinction.
1:43 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 4/4/12 11:36 AM, DJ Delorie wrote:
> To be clear, it would be used but ownership still resides with
whomever
> > purchased the hardware.
Really? You can't donate hardware, you can only let Fedora borrow it?
If you sponsor catering at a con, do you need to get the food back at
some point too? Sounds like a silly distinction.
Hardware is likely classified in tax code as an asset, where as food at
a conference is not. Assets being bought by somebody else and "donated"
to a commercial entity probably looks fishy.
It's tax law, it's not going to be logical.
--
Help me fight child abuse: http://tinyurl.com/jlkcourage
- jlk
1:46 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
Hardware is likely classified in tax code as an asset, where as food
at a conference is not.
Well, it's an asset until you eat it :-)
Ok, that explains things. Legal technicality, but still a workable
process.
1:40 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
Used. There is a process for donating hardware in place, and
it's been
used before.
Ok, so it sounds like there's a method in place for entities-with-cash
to use that cash to benefit Fedora, as long as they are OK with not
getting the tax break and they're willing to go through a little
effort.
So between sponsoring cons, travel, hardware, etc... what can *only*
be done with Red Hat Cash? Is there anything that an individual
cannot say "I'll pay for that (and/or buy that) for you" ?
/me wonders if this sponsor-donate path needs more coordination and
publishing, maybe a "shopping list" approach. Let "donors" choose
one
or more items for a list-of-things-we'd-otherwise-need-cash-for and
just buy them (hardware) and/or pay for them (travel etc).
2:45 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 2:40 PM, DJ Delorie <dj(a)redhat.com> wrote:
So between sponsoring cons, travel, hardware, etc... what can *only*
be done with Red Hat Cash? Is there anything that an individual
cannot say "I'll pay for that (and/or buy that) for you" ?
Absolutely. An individual or organization can say "We'll pay for
Joe's travel" or "We'll pay for lunch on Saturday" or
"We'll pay for
the internet connection" or a myriad of other things like that. They
just need to pay for those things directly -- they can't just hand
Fedora a pile of cash.
/me wonders if this sponsor-donate path needs more coordination and
publishing, maybe a "shopping list" approach. Let "donors" choose
one
or more items for a list-of-things-we'd-otherwise-need-cash-for and
just buy them (hardware) and/or pay for them (travel etc).
We've put together a prospectus for a couple of the FUDCon events to
do that very thing. Feel free to help us amplify that and make it
easier to find.
--
Jared Smith
2:54 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 04/04/2012 09:45 PM, Jared K. Smith wrote:
On Wed, Apr 4, 2012 at 2:40 PM, DJ Delorie<dj(a)redhat.com>
wrote:
> So between sponsoring cons, travel, hardware, etc... what can *only*
> be done with Red Hat Cash? Is there anything that an individual
> cannot say "I'll pay for that (and/or buy that) for you" ?
Absolutely. An individual or organization can say "We'll pay for
Joe's travel" or "We'll pay for lunch on Saturday" or
"We'll pay for
the internet connection" or a myriad of other things like that. They
just need to pay for those things directly -- they can't just hand
Fedora a pile of cash.
Does Fedora exist outside of the US (on the books)? Surely there must be
a way to dissociate Redhat US sponsorship to an international non-profit
that represents Fedora?
3:04 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 3:54 PM, Brendan Jones
<brendan.jones.it(a)gmail.com> wrote:
On 04/04/2012 09:45 PM, Jared K. Smith wrote:
>
> On Wed, Apr 4, 2012 at 2:40 PM, DJ Delorie<dj(a)redhat.com> wrote:
>>
>> So between sponsoring cons, travel, hardware, etc... what can *only*
>> be done with Red Hat Cash? Is there anything that an individual
>> cannot say "I'll pay for that (and/or buy that) for you" ?
>
>
> Absolutely. An individual or organization can say "We'll pay for
> Joe's travel" or "We'll pay for lunch on Saturday" or
"We'll pay for
> the internet connection" or a myriad of other things like that. They
> just need to pay for those things directly -- they can't just hand
> Fedora a pile of cash.
>
Does Fedora exist outside of the US (on the books)? Surely there must be a
way to dissociate Redhat US sponsorship to an international non-profit that
represents Fedora?
I believe there were efforts to create a Fedora Foundation in the
European Union a while ago. Those efforts failed. I honestly don't
remember why, but it wasn't because people just weren't interested.
josh
3:04 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, Apr 4, 2012 at 3:54 PM, Brendan Jones
<brendan.jones.it(a)gmail.com> wrote:
Does Fedora exist outside of the US (on the books)? Surely there must
be a
way to dissociate Redhat US sponsorship to an international non-profit that
represents Fedora?
Been there, tried that... still have the scars. I'm happy to share
details if people really want to go down this road, but we're pretty
far off-topic at this point. I think it's sufficient to say that if
there was a simple answer to this situation, we would have tried it
already.
--
Jared Smith
1:56 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On Wed, 04 Apr 2012 11:29:06 -0700
Jesse Keating <jkeating(a)j2solutions.net> wrote:
On 4/4/12 11:28 AM, DJ Delorie wrote:
> Ok, giving money won't work, and the tax stuff is a mess. Let's
> ignore that for a second.
>
> What about equipment?
>
> Consider: if a box showed up at PHX, which contained hardware that
> met the technology requirements of PHX, with a note that said "here,
> yours, no strings attached" - what would happen? Would it be
> returned, or used?
Used. There is a process for donating hardware in place, and it's
been used before.
Just to add/clarify here:
Please don't send random stuff to us without checking first. ;)
At a minimum:
- There must be some tangible benefit to Fedora from the hardware.
(no, we don't want to host your personal fileserver)
- The hardware MUST be rack mountable/enterprise quality.
- The hardware MUST have a warentee from a major vendor with 24x7
response time. (No joe's discount computers or 9 to 5 when we get to
it, etc).
Your best bet if you want to send us something is to open a
Infrastructure ticket or post to the Infrastructure list or mail
admin(a)fedoraproject.org and we can discuss things.
Further note that we also accept co-location/server donations in other
sites (in particular places we don't have good coverage already).
I'd like to also thank our existing sponsors:
http://fedoraproject.org/sponsors.html
kevin
1:49 p.m.
New subject: Feedback on secondary architecture promotion requirements draft
On 4 April 2012 12:28, DJ Delorie <dj(a)redhat.com> wrote:
Ok, giving money won't work, and the tax stuff is a mess. Let's
ignore that for a second.
What about equipment?
Consider: if a box showed up at PHX, which contained hardware that met
the technology requirements of PHX, with a note that said "here,
yours, no strings attached" - what would happen? Would it be
returned, or used?
In the past it was used. Currently we would probably send it back
unless a set of parameters were met:
1) We didn't own it. [Welcome to most nations tax laws.. computer
equipment are assets and taxable. Items at a conference are not.. ] If
we own it, we have a way to buy it for some amount and deal with the
taxes on its real versus "declared" value.
2) The owners have a warranty on the system and a way for us to return
it to them when it is done. The warranty is because a lot of that
equipment we used to get donated to us did not have any and we ended
up paying more to fix them than we would have if Red Hat had bought
them.
Now we do have a lot of systems that are colocated and their hardware
is donated to us from various peering companies. We also have rules in
place on what we will accept here.. mainly because we were getting a
lot of 256MB Pentium II boxes being "given for our use" which were not
useful for our needs. We are very thankful to those facilities which
have been able to deal with our "needs" (internetx, bodhost, peer1,
telia, and I have forgotten one or two others)
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
2:06 p.m.
On Tue, Apr 3, 2012 at 2:58 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 04/03/2012 09:07 AM, Josh Boyer wrote:
>
> From a koji perspective, there really isn't much benefit to step 2.
> What needs to happen is the RPMs from the secondary hub need to be
> copied to the primary in the correct NVR directories in the hub's
> storage. That can happen in the background for quite a bit, but at
> some point the hub would need to be taken offline to sync up the last
> few builds, and then switch the builders over.
>
> Having a staging hub just means you have to copy and move the builders
> twice. This is mostly due to how koji builders can only talk to one
> hub at a time and one hub only.
Where do you envision the builders being in this scenario? I see the steps
being something like this:
1. SA builders and/or hub are located outside PHX.
2 option a. Builders come up in PHX, hub stays in original location.
2 option b. Staging hub comes up in PHX, builders stay in original location.
3. Both staging hub and builders come up in PHX
4. When appropriate move from staging hub to primary hub.
I hope when you refer to "staging hub" you mean "the hub being used
as the SA hub.
Having everything take place in PHX prior to the switchover has
numerous
benefits. These 3 come to mind immediately:
1. Fast local network will represent true build times (vs transfering rpms
across the external network).
Yes. Which is why you ship the SA hub to PHX.
I'm not saying this is a _requirement_, but it is the most expedient
option. Otherwise you have a hell of a lot of data to get to PHX
anyway.
2. Realistic load assessment. If, hypothetically primary koji and
staging
koji are both virtual machines on the same underlying hardware you'll know
if the hardware can handle the load. Also network, disk, etc.
3. Comparable infrastructure reliability.
Switching koji hubs twice does incur a bit more work, but it may also
provide better results.
I don't see how. The hub characteristics are the least of the worries
in this entire scenario. The builders are going to dominate the time
spent, and you aren't going to get exactly comparable statistics by
using a "staging" hub on identical hardware/VM config because that
staging hub isn't going to be building both PA and the soon-to-be PA
SA.
Really, staging hubs seem like a waste of time to me.
josh
1:45 p.m.
On 04/03/2012 04:58 AM, Josh Boyer wrote:
On Apr 2, 2012 11:10 PM, "Brendan Conoboy"
<blc(a)redhat.com
<mailto:blc@redhat.com>> wrote:
> All builds must occur on Fedora-maintained build servers.
>
> FYI, this will require an additional koji-hub for each architecture
trying to move to PA. Generally agree, though.
No. The additional hub is only needed while an arch is secondary.
Once it is PA it is driven from the single koji hub.
Exactly. And if there were two unrelated arches in transition it would
mean 2 hubs would be needed. The point here is that a piece of hardware
is needed so SA's making the transition will need to ensure this
hardware is available.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
2:02 p.m.
On Tue, Apr 3, 2012 at 2:45 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 04/03/2012 04:58 AM, Josh Boyer wrote:
>
> On Apr 2, 2012 11:10 PM, "Brendan Conoboy" <blc(a)redhat.com
> <mailto:blc@redhat.com>> wrote:
>
> > All builds must occur on Fedora-maintained build servers.
> >
> > FYI, this will require an additional koji-hub for each architecture
> trying to move to PA. Generally agree, though.
>
> No. The additional hub is only needed while an arch is secondary.
> Once it is PA it is driven from the single koji hub.
Exactly. And if there were two unrelated arches in transition it would mean
2 hubs would be needed. The point here is that a piece of hardware is
needed so SA's making the transition will need to ensure this hardware is
available.
Erm... you already have this. So will any SA making a transition. I
don't see a problem.
josh
2:10 p.m.
On Tue, Apr 3, 2012 at 3:04 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 04/03/2012 12:02 PM, Josh Boyer wrote:
>
> Erm... you already have this. So will any SA making a transition. I
> don't see a problem.
Outside PHX, yes. Inside, no.
If an SA wants to go off and do a staging hub instead of just planning
on shipping their hub they've built with from inception to PHX that's
fine. It seeems like a waste of time to purchase/create a new hub
instance that will basically be thrown away once it migrates to a PA
but if the SA team wants to do that then I doubt anyone will complain.
josh
2:10 p.m.
On Tue, 03 Apr 2012 12:04:07 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
On 04/03/2012 12:02 PM, Josh Boyer wrote:
> Erm... you already have this. So will any SA making a transition.
> I don't see a problem.
Outside PHX, yes. Inside, no.
I'll note again that the ppc and s390 secondary arch hubs are in fact
in phx2. ;)
kevin
2:38 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 03 Apr 2012 11:45:09 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
On 04/03/2012 04:58 AM, Josh Boyer wrote:
> On Apr 2, 2012 11:10 PM, "Brendan Conoboy" <blc(a)redhat.com
> <mailto:blc@redhat.com>> wrote:
>
> > All builds must occur on Fedora-maintained build servers.
> >
> > FYI, this will require an additional koji-hub for each
> > architecture
> trying to move to PA. Generally agree, though.
>
> No. The additional hub is only needed while an arch is secondary.
> Once it is PA it is driven from the single koji hub.
Exactly. And if there were two unrelated arches in transition it
would mean 2 hubs would be needed. The point here is that a piece of
hardware is needed so SA's making the transition will need to ensure
this hardware is available.
there should be no transition of hubs from one location to another.
that is really just silly and wasteful. any transition from secondary
to primary would only ever occur in rawhide only. the existing hub will
need to remain up and working for at least the life of currently
released stable releases. we would add builders into phx, we could add
them to the existing staging koji to do soem testing if desired. there
would eb a flag day that is a cutover from the arch being secondary to
primary, but that transition would only be adding the new arches to
rawhide only. we would only be importing the most recent rawhide builds
for the secondary arch, or alternatively we would add the secondary
arch as a external repo and do a mass rebuild to add the secondary
arch. but it would only be a transition for rawhide.
if an arch was to become primary for f18 it would need to complete the
transition before we branch rawhide to f18, if it misses that date it
could only be considered for f19. once we branch we start looking at
alpha, the new arch would debut with Alpha.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk97UcwACgkQkSxm47BaWfcq0ACfbJn0W2GtdBy+YOEgWYv0VCrw
p1EAnijZyWFNPWfQqUkrO5REoHXHRkcp
=W2R8
-----END PGP SIGNATURE-----
8:24 a.m.
On Tue, Apr 3, 2012 at 5:10 AM, Brendan Conoboy <blc(a)redhat.com> wrote:
> as such there are various expectations that the overall Fedora
> experience will be consistent over all primary architectures.
Can we quantify what the overall experience is that must be consistent? I
understand Anaconda installations is considered a part of this... except
when it's not for EC2 images. What I'm looking for is "These 10 things are
partof the Fedora experience- any PA needs to provide at least 7 of them" or
something like that.
All architectures are built from the same SRPMs, so the overall
experience is sort of consistent by default. 7/10 is certainly not
enough, I'd assume >98% - only a few named exceptions, and the ARM
team probably knows what these are better than I do :)
This could be construed to mean "the secondary architecture will have
a comparable 3D support to the primary so that gnome-shell performs
comparably", but that's way out of scope I think. In any case, the
true requirements start with the bullet list.
> There must be adequate representation for the architecture on
the
> Fedora infrastructure and release engineering teams.
This makes sense, but what is adequate?
I think this is left to be decided by the infrastructure and rel-eng teams.
> The architecture must meet appropriate formal release criteria
As long as the release criteria are applicable to the architecture.
I actually think this requirement is too strict most of the time - the
primary architectures need weeks of bug fixing to meet the release
criteria :) I'm not sure about a better way to word it, though.
Perhaps this just means that the PA promotion decision would have take
place at the same time that the next beta release meets release
criteria.
> This list is not intended to be exhaustive - promotion to
primary
> architecture status will require agreement from the Fedora
> infrastructure, release engineering, kernel and installer teams and
> is subject to overall approval by the Fedora Engineering Steering
> Committee, and additional criteria may be imposed if felt to be
> necessary.
Let's make the list exhaustive; there needs to be a path to sure success.
This means establishing a complete procedure where when an SA formally
applies to become PA, acceptance means there is a definitive set of steps
needed to get there. This is one of the major reasons for developing these
criteria. Put another way:
FESCo and affected groups should have the ability to review whether or not
the SA has in-fact fulfilled the requirements for PA, as agreed to by all
parties at the time of application. If those requirements are deemed to
have been met, promotion is automatic.
AFAICT there is a clear FESCo consensus that the list can not be exhaustive.
Essentially, asking for a promise to promote automatically if a
checklist is met is equivalent to asking for permission to promote
even if the software is known to be broken and/or unfixable.
There _are_ unknowns and risks in this process. We can only shift the
place where they manifest, and asking for an exhaustive list
essentially shifts the risks to Fedora users and other Fedora
maintainers. And again, the current discussions didn't suggest that
there is any communication breakdown between FESCo and the ARM team,
or that FESCo knows much more about ARM than the ARM team. I don't at
all expect a situation in which the ARM team thinks everything is
working fine and FESCo doesn't.
Mirek
9:26 a.m.
2012/4/3 Miloslav Trmač <mitr(a)volny.cz>:
On Tue, Apr 3, 2012 at 5:10 AM, Brendan Conoboy
<blc(a)redhat.com> wrote:
>> as such there are various expectations that the overall Fedora
>> experience will be consistent over all primary architectures.
>
> Can we quantify what the overall experience is that must be consistent? I
> understand Anaconda installations is considered a part of this... except
> when it's not for EC2 images. What I'm looking for is "These 10 things
are
> partof the Fedora experience- any PA needs to provide at least 7 of them" or
> something like that.
All architectures are built from the same SRPMs, so the overall
experience is sort of consistent by default. 7/10 is certainly not
enough, I'd assume >98% - only a few named exceptions, and the ARM
team probably knows what these are better than I do :)
This could be construed to mean "the secondary architecture will have
a comparable 3D support to the primary so that gnome-shell performs
comparably", but that's way out of scope I think. In any case, the
true requirements start with the bullet list.
It's already been stated that 3D isn't a blocker for PA, but that the
needs to be reasonable GUI support similar to that of the mainline
project.
>> There must be adequate representation for the architecture on
the
>> Fedora infrastructure and release engineering teams.
>
> This makes sense, but what is adequate?
I think this is left to be decided by the infrastructure and rel-eng teams.
Yes.
>> The architecture must meet appropriate formal release
criteria
>
> As long as the release criteria are applicable to the architecture.
I actually think this requirement is too strict most of the time - the
primary architectures need weeks of bug fixing to meet the release
criteria :) I'm not sure about a better way to word it, though.
Perhaps this just means that the PA promotion decision would have take
place at the same time that the next beta release meets release
criteria.
As long as it's reasonable, if it's too strict on primary at the
moment that is a completely separate discussion and not really related
to this one and is likely very much a matter of opinion :)
>> This list is not intended to be exhaustive - promotion to
primary
>> architecture status will require agreement from the Fedora
>> infrastructure, release engineering, kernel and installer teams and
>> is subject to overall approval by the Fedora Engineering Steering
>> Committee, and additional criteria may be imposed if felt to be
>> necessary.
>
> Let's make the list exhaustive; there needs to be a path to sure success.
> This means establishing a complete procedure where when an SA formally
> applies to become PA, acceptance means there is a definitive set of steps
> needed to get there. This is one of the major reasons for developing these
> criteria. Put another way:
>
> FESCo and affected groups should have the ability to review whether or not
> the SA has in-fact fulfilled the requirements for PA, as agreed to by all
> parties at the time of application. If those requirements are deemed to
> have been met, promotion is automatic.
AFAICT there is a clear FESCo consensus that the list can not be exhaustive.
I agree it's hard to make it exhaustive but ultimately it can't be a
moving target with extra items added and the goal posts moved every
time it's reached.
Essentially, asking for a promise to promote automatically if a
checklist is met is equivalent to asking for permission to promote
even if the software is known to be broken and/or unfixable.
We're not asking for that what so ever. What we're asking for is a pre
decided and agreed point we need to reach that doesn't keep on moving.
Ultimately there's a lot of packages that are broken on x86 mainline
at the moment (just look at the list of FTBFS that still exist from
the gcc 4.7 mass rebuild) so we're not asking for instant promotion if
stuff is known to be broken, it's never been bought up so I'm not sure
where you get that idea from.
There _are_ unknowns and risks in this process. We can only shift
the
place where they manifest, and asking for an exhaustive list
essentially shifts the risks to Fedora users and other Fedora
maintainers. And again, the current discussions didn't suggest that
there is any communication breakdown between FESCo and the ARM team,
or that FESCo knows much more about ARM than the ARM team. I don't at
all expect a situation in which the ARM team thinks everything is
working fine and FESCo doesn't.
Of course there are unknown risks, there's also unknown risks every
time a core package is bumped, or each time infra/rel-eng change
something, but there's benefits to those changes as well. Just like
that there are unknown risks and possible issues with promotion of a
new architecture but there are also known benefits which is ultimately
why we've asked FESCo to create these criteria, different people put
different benefits to the criteria but ultimately personally I believe
it will be a net gain for Fedora.
Peter
5:09 a.m.
Peter Robinson wrote:
It's already been stated that 3D isn't a blocker for PA, but
that the
needs to be reasonable GUI support similar to that of the mainline
project.
"reasonable GUI support" already includes 3D in GNOME, and with the
developments in Qt 5, chances are the same will become true in KDE Plasma
too in a few months.
Now the "reasonable 3D" criterion can in principle be met by llvmpipe, but
CPU power is not what ARM is strong at.
I think sweeping that issue under the carpet is not going to help. I don't
think ARM is ready for primary architecture status as long as the upstream
status of Free OpenGL drivers is what it is now.
I agree it's hard to make it exhaustive but ultimately it
can't be a
moving target with extra items added and the goal posts moved every
time it's reached.
Why not, if new issues are discovered which nobody thought of before? Would
you rather sweep them under the carpet just so that you can stick that
"primary" label on your work? The overall goal should be to do what's best
for the Fedora project as a whole, not to promote your architecture as the
goal in itself.
Of course there are unknown risks, there's also unknown risks
every
time a core package is bumped, or each time infra/rel-eng change
something, but there's benefits to those changes as well. Just like
that there are unknown risks and possible issues with promotion of a
new architecture but there are also known benefits which is ultimately
why we've asked FESCo to create these criteria, different people put
different benefits to the criteria but ultimately personally I believe
it will be a net gain for Fedora.
But the important question to ask is always: Do the benefits outweigh the
risks (and the known drawbacks)? If new risks are discovered, they can
outweigh the benefits.
Kevin Kofler
5:25 a.m.
On Wed, Apr 4, 2012 at 11:09 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Peter Robinson wrote:
> It's already been stated that 3D isn't a blocker for PA, but that the
> needs to be reasonable GUI support similar to that of the mainline
> project.
"reasonable GUI support" already includes 3D in GNOME, and with the
developments in Qt 5, chances are the same will become true in KDE Plasma
too in a few months.
Now the "reasonable 3D" criterion can in principle be met by llvmpipe, but
CPU power is not what ARM is strong at.
I think sweeping that issue under the carpet is not going to help. I don't
think ARM is ready for primary architecture status as long as the upstream
status of Free OpenGL drivers is what it is now.
I'm not and have never suggested sweeping anything under the carpet, I
and noting what others have said elsewhere in the various threads.
It's clear you don't want ARM as a primary arch and I'm sure you'll
dig out any random package and add it as a blocker to ensure that is a
case. It's up to FESCo to define what they wish, once that has
happened we will work towards ensure we meet that.
> I agree it's hard to make it exhaustive but ultimately it
can't be a
> moving target with extra items added and the goal posts moved every
> time it's reached.
Why not, if new issues are discovered which nobody thought of before? Would
you rather sweep them under the carpet just so that you can stick that
"primary" label on your work? The overall goal should be to do what's best
for the Fedora project as a whole, not to promote your architecture as the
goal in itself.
Nope, never said that. I am, as are the rest of the ARM SIG, sure
there will things that will come up as things move along, this isn't
something that as ever happened before. Our, as in the ARM team, goal
has always been to do what is the best for the Fedora Project as a
whole, the architecture is a dependency of that goal, the goal being
getting Fedora to a wider audience.
> Of course there are unknown risks, there's also unknown risks
every
> time a core package is bumped, or each time infra/rel-eng change
> something, but there's benefits to those changes as well. Just like
> that there are unknown risks and possible issues with promotion of a
> new architecture but there are also known benefits which is ultimately
> why we've asked FESCo to create these criteria, different people put
> different benefits to the criteria but ultimately personally I believe
> it will be a net gain for Fedora.
But the important question to ask is always: Do the benefits outweigh the
risks (and the known drawbacks)? If new risks are discovered, they can
outweigh the benefits.
Absolutely, and that's why it's an open discussion and every
contributor will have different opinions on benefits and risks and
that is why we're a dynamic project and why one particular group in
the project can't dictate what goes on. That is exactly why there are
multiple web servers, mail server and desktops such as KDE rather than
one of each :-)
Peter
7:48 a.m.
Peter Robinson wrote:
It's clear you don't want ARM as a primary arch and I'm
sure you'll
dig out any random package and add it as a blocker to ensure that is a
case. It's up to FESCo to define what they wish, once that has
happened we will work towards ensure we meet that.
All the issues I'm pointing out are real. I'm not inventing them. You're
shooting the messenger!
Now it's true that the issue I personally care about the most is build speed
(which I don't see being addressed in any even remotely satisfactory way any
time soon, FWIW), but that doesn't mean the other issues don't exist or
should be ignored.
And as a Free Software advocate who has always refused to use proprietary
drivers, seeing an architecure getting promoted to primary with only
proprietary OpenGL drivers, at a time where we FINALLY got the x86 graphics
issues sorted out with radeon and nouveau, genuinely DOES make me sad, too
(even though it won't affect me as much as the build speed issue).
Kevin Kofler
5 a.m.
Miloslav Trmač wrote:
AFAICT there is a clear FESCo consensus that the list can not be
exhaustive.
That's good news.
Essentially, asking for a promise to promote automatically if a
checklist is met is equivalent to asking for permission to promote
even if the software is known to be broken and/or unfixable.
+1
Promotion MUST be a case by case decision!
Kevin Kofler
8:54 a.m.
On Mon, Apr 2, 2012 at 10:10 PM, Brendan Conoboy <blc(a)redhat.com> wrote:
This is feedback vs the current version of the following web page:
http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requiremen...
FESCo and affected groups should have the ability to review whether
or not
the SA has in-fact fulfilled the requirements for PA, as agreed to by all
parties at the time of application. If those requirements are deemed to
have been met, promotion is automatic.
I think a lot of the above boils down to providing goals for the SA
team while leaving discretion in FESCO's hands. And in that light, I
think once requirements are met, promotion should be approved, but
certainly not automatic.
There could be a deadline on application acceptance: EG, 12 months
from
acceptance of application to fulfillment of criteria. This protects against
criteria becoming stale.
I like this idea, modulo the exact time value. If you apply and are
approved for F18, and aren't ready until F25, I think all would agree
that reassessment is sorely needed.
-J
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
in your fear, seek only peace
in your fear, seek only love
-d. bowie
10:21 a.m.
On 04/02/2012 11:10 PM, Brendan Conoboy wrote:
This is feedback vs the current version of the following web page:
http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requiremen...
It would be nice if the bullet points were numbers so they could be
referenced numerically.
Done (but btw it is a wiki - you could easily have done this.)
> Promoting an architecture to primary architecture status is a
> significant responsibility. It implies that the port is sufficiently
> mature that little in the way of further architecture-specific
> changes or rebuilds will be required, and also that it has enough
> development effort to avoid it delaying the development of other
> primary architectures.
What is "...enough development effort to avoid..."? Perhaps this
could be restated for clarity as a development effort is not a unit
of measurement.
> as such there are various expectations that the overall Fedora
> experience will be consistent over all primary architectures.
Can we quantify what the overall experience is that must be
consistent? I understand Anaconda installations is considered a part
of this... except when it's not for EC2 images. What I'm looking for
is "These 10 things are partof the Fedora experience- any PA needs to
provide at least 7 of them" or something like that.
I think this whole process is going to work a whole lot better if we *don't*
focus on having very precise and all encompassing criteria. General criteria
will suit us much better.
The process for each of the items needs to be more like:
SA Maintainer: Here's what we plan to do to satisfy #3. Comments or concerns?
FESCo: Well, tweak $THIS and $THAT, and it's looking pretty good
SAM: Okay, well that's a little problematic because $ARCH has a feature that
makes $THAT weird.
FESCo: Okay, just tweak $THIS then.
We're trying to make a general process; being two precise won't help for a
couple of reasons. First, it leads to doing something you think is right
because of an error in the process document where we didn't consider something.
There's no way we're going to get this right thinking about it in abstract,
and also no way that everything we come up with while thinking of ARM is
necessarily going to apply when the next architecture comes along. So we know
we're going to be wrong about some things, and there will be some accidental
omissions. That has to be part of the process, and the process has to be built
around knowing that. Which leads me to the other reason - it discourages you
from talking to us along the way, and encourages you to go away, do something
and come back. While that's good in some situations, it's really *not* for
this, because it will lead to even more cases where a SAM implements something
because of following rules closely instead of what should happen. We need to
make the whole process one with continuous feedback, or it's never going to
work.
So I'd expect that we don't want to specify anything all that precisely -
I'd rather you come up with an implementation plan to satisfy each point,
and then we (SA Maintainer and FESCo) decide together if it's satisfactory,
and later decide that it has or hasn't yet been met, and if not what remedial
steps should be taken.
--
Peter
3:41 p.m.
On 04/03/2012 08:21 AM, Peter Jones wrote:
[snip]
We need to
make the whole process one with continuous feedback, or it's never going to
work.
So I'd expect that we don't want to specify anything all that precisely -
I'd rather you come up with an implementation plan to satisfy each point,
and then we (SA Maintainer and FESCo) decide together if it's satisfactory,
and later decide that it has or hasn't yet been met, and if not what remedial
steps should be taken.
Communication is really the piece which needs development in the
proposed guidelines. SA's tend to work quite independently so the
proposal needs to spell out a few things that get everybody
communicating at the right times and the right ways. It's probably
perfectly clear in many people's minds folks how these things should be
handled, but if we could formalize them a tiny bit it would do wonders
for filling in what's missing in the secondary promotion draft.
1. What does the SA2PA proposal need to cover? MJG's 10 criteria give a
general scope of what needs to be covered, so this is more or less done.
If I'm reading Peter's comments above correctly the guidelines should
indicate that the SA2PA proposal must be generated by the SA team (as
opposed to FESCo) and should address all 10 points.
2. How should an SA team propose to FESCo and the community that their
SA is ready to be evaluated for PA track? Is submitting a feature page
the right way to start, or a discussion on f-d-l? Whatever the right
way is I'd like to see that information added to the proposed guidelines.
3. When should the SA team make their first proposal? There is great
potential for wasted effort bringing the topic up too early or too late
in the SA's development, not to mention when in the primary release
cycle such topics should be brought up.
4. How to keep FESCo and the community informed during the process.
Presumably after #2 there will be feedback along the lines of "you need
to do more on points x, y, and z". If the answer is "FESCo will say how
to keep everybody informed" then let's have the proposal state that.
Basically, I think the guidelines MJG has put together are good
principles; they just need some procedural blanks filled in so SA teams
know how to apply them and communicate with the greater Fedora community.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
4:20 p.m.
On Mon, Apr 16, 2012 at 01:41:58PM -0700, Brendan Conoboy wrote:
Basically, I think the guidelines MJG has put together are good
principles; they just need some procedural blanks filled in so SA
teams know how to apply them and communicate with the greater Fedora
community.
I think a better way to think about this might be lie the packaging
guidelines - they provide a set of technical constraints, but they don't
tell you how to be part of the packaging community. I see SAs in the
same kind of way. Secondary architecture maintainers should be active
members of the greater Fedora community. You should be talking about
what you're doing, providing regular status updates on devel@, actively
involving yourself in other technical discussions to make sure that
decisions aren't made without consideration of your constraints.
Basically, behave as if you're a primary architecture.
If you manage that then I think most of the problems you're worried
about go away. It'll be obvious to everyone whether or not you're ready
to be a primary architecture at any given point. Don't worry about the
details. Just be part of Fedora.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
7:34 p.m.
On 04/16/2012 02:20 PM, Matthew Garrett wrote:
I think a better way to think about this might be lie the packaging
guidelines - they provide a set of technical constraints, but they don't
tell you how to be part of the packaging community. I see SAs in the
same kind of way. Secondary architecture maintainers should be active
members of the greater Fedora community. You should be talking about
what you're doing, providing regular status updates on devel@, actively
involving yourself in other technical discussions to make sure that
decisions aren't made without consideration of your constraints.
Basically, behave as if you're a primary architecture.
If you manage that then I think most of the problems you're worried
about go away. It'll be obvious to everyone whether or not you're ready
to be a primary architecture at any given point. Don't worry about the
details. Just be part of Fedora.
That almost sounds like an argument for scrapping the promotion
requirements document entirely. Is that what you meant? I understand
where you're coming from philosophically, but we're talking about
something more concrete. Many people who are interested in SA2PA
promotion requirements are working on Fedora 24/7 and they want guidance
too. As documents go I'm all for having a philosophical section on what
the mindset is, but it should be matched with applied examples.
I think what you're trying to say above is "For a secondary architecture
to become primary architecture, its team should have a demonstrable
history of communicating with the greater Fedora community about what
it's doing and how the greater Fedora community's activities are
affecting it." If that is indeed what you mean, please put it in the
document and include some examples. The word "communicate" doesn't
exist in the current document.
I'm open to providing what I think are reasonable examples if they may
ultimately make it into the end document.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
5:26 p.m.
On Mon, Apr 02, 2012 at 08:10:12PM -0700, Brendan Conoboy wrote:
> as such there are various expectations that the overall Fedora
> experience will be consistent over all primary architectures.
Can we quantify what the overall experience is that must be
consistent? I understand Anaconda installations is considered a
part of this... except when it's not for EC2 images. What I'm
looking for is "These 10 things are partof the Fedora experience-
any PA needs to provide at least 7 of them" or something like that.
The only differences between the Fedora experience on ARM and x86 should
be those dictated by hardware.
> There must be adequate representation for the architecture on
the
> Fedora infrastructure and release engineering teams.
This makes sense, but what is adequate? Perhaps 1 distinct person
in each group saying "I will be responsible for $ARCH?" What if
only 1 person wants to be the secondary representative in both
groups?
That's something that would have to be discussed with the infrastructure
and release engineering teams.
> Where technically possible, all supported hardware targets must
be
> supported via Anaconda. Exceptions are limited to highly resource
> constrained devices or hardware which provides no means for
> simultaneous support of install and target media.
This is overloading "support" so I'm having a little trouble
understanding the intention. Let's try a thought experiment that's
a little more generic than the above. I propose any given
architecture falls into at least 1 and possibly all 4 of the
following categories:
1. Specs not suited to Fedora at all (too little RAM, no MMU, etc)
2. Can run Fedora, but Anaconda installation doesn't make sense for
technical reasons.
3. Can run Fedora, would even benefit by Anaconda installation, but
requires changes to Anaconda and/or other packages to work.
4. Can run Fedora and Anaconda supports it fine.
I think what you're trying to express is that either 2 or 4 must be
true and that if 3 is true, 4 must also be true. Is that right?
Yes, I think that's accurate.
> All supported platforms must have kernels built from the Fedora
> kernel SRPM and enabled by default in the spec file. Each kernel must
> be built in a timely manner for every SRPM upload.
What exactly is timely? What margin is acceptable? Is this only
for kernel or does this apply to any package with a
much-longer-than-average build time? What would constitute being in
that class? Or should the class be critical-path packages?
Something else?
The kernel's kind of a special case due to the relatively frequent
security updates. The exact nature of what kind of speed is required
would probably need to be discussed with the kernel team.
> Sufficient developer resources must be available to fix any
> architecture-specific issues in such a way that they do not delay
> overall Fedora development.
Can you quantify this and also describe how this measurement is to
be assessed? Are we saying there must be X many engineers available
at any given time to handle an architecture-specific build issue? I
don't believe there is a pool of x86 engineers hanging about waiting
for inline assembler issues to come in so some discussion of the
mechanics of what's envisioned here would be helpful. I think the
notion is that there must be a critical-mass of talent competent to
help out, but how do you define that?
If architecture-specific issues get fixed in a timely way then the
developer resources are sufficient. I don't think it's something that
can be explicitly quantified.
> It must be possible for maintainers of critical-path hardware
> dependent packages to have direct access to supported hardware in
> order to rectify any release-blocking issues. For example, X
> maintainers must have direct access to any hardware with graphics
> capabilities.
Is simulated hardware acceptable? Remote-X or VNC access? Physical
hardware? What happens when a new generation of hardware comes out?
What about architectures where there is no video at all? What about
architectures where some systems have video, others don't, but the
primary use case is systems without video?
Whatever level of access is required to fix the bugs. The aim here is to
deal with architecture-specific but otherwise generic issues - if X
fails to work on a specific model then that's just a bug and it's not
the end of the world, but if X fails to work on ARM at all then that's
something that needs to be fixed. My experience of dealing with these
things is that it's pretty difficult to fix most of these bugs remotely,
so I'd probably expect that hardware be physically available to the
people who need to fix the bugs.
> The port must not rely on sourceless binaries unless they fall
under
> the generic firmware exemption. Where source and toolchain are
> available, the binaries must be built in the Fedora build
> infrastructure.
Yes, assuming the source is compatible with Fedora packaging
guidelines. I'm not sure there's a case where source would be
incompatible but binaries wouldn't be, but thought I'd mentioned it.
If the source isn't compatible with Fedora packaging guidelines then we
shouldn't be shipping the binaries unless they fall under the generic
firmware exemption.
> Excludearch may be used only to disable packages that are
> fundamentally architecture specific.
Assuming we mean the package has architecture specific components
that either can not, or have not, been ported, agree.
I'm not enthusiastic about excludearch being used simply because a
component hasn't been ported, but I think that's probably a stronger
position than we've traditionally had so I'm probably ok with it being
used for that.
> This list is not intended to be exhaustive - promotion to
primary
> architecture status will require agreement from the Fedora
> infrastructure, release engineering, kernel and installer teams and
> is subject to overall approval by the Fedora Engineering Steering
> Committee, and additional criteria may be imposed if felt to be
> necessary.
Let's make the list exhaustive; there needs to be a path to sure
success. This means establishing a complete procedure where when an
SA formally applies to become PA, acceptance means there is a
definitive set of steps needed to get there. This is one of the
major reasons for developing these criteria. Put another way:
There is no path to sure success. That's not how this works.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:01 p.m.
On Wed, Apr 4, 2012 at 11:26 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Mon, Apr 02, 2012 at 08:10:12PM -0700, Brendan Conoboy wrote:
> > as such there are various expectations that the overall Fedora
> > experience will be consistent over all primary architectures.
>
> Can we quantify what the overall experience is that must be
> consistent? I understand Anaconda installations is considered a
> part of this... except when it's not for EC2 images. What I'm
> looking for is "These 10 things are partof the Fedora experience-
> any PA needs to provide at least 7 of them" or something like that.
The only differences between the Fedora experience on ARM and x86 should
be those dictated by hardware.
> > There must be adequate representation for the architecture on the
> > Fedora infrastructure and release engineering teams.
>
> This makes sense, but what is adequate? Perhaps 1 distinct person
> in each group saying "I will be responsible for $ARCH?" What if
> only 1 person wants to be the secondary representative in both
> groups?
That's something that would have to be discussed with the infrastructure
and release engineering teams.
There needs to be some resilience IMO, but then there's quite a bit of
stuff that is general cross knowledge so I'm not sure it's a problem.
> > Where technically possible, all supported hardware targets
must be
> > supported via Anaconda. Exceptions are limited to highly resource
> > constrained devices or hardware which provides no means for
> > simultaneous support of install and target media.
>
> This is overloading "support" so I'm having a little trouble
> understanding the intention. Let's try a thought experiment that's
> a little more generic than the above. I propose any given
> architecture falls into at least 1 and possibly all 4 of the
> following categories:
>
> 1. Specs not suited to Fedora at all (too little RAM, no MMU, etc)
> 2. Can run Fedora, but Anaconda installation doesn't make sense for
> technical reasons.
> 3. Can run Fedora, would even benefit by Anaconda installation, but
> requires changes to Anaconda and/or other packages to work.
> 4. Can run Fedora and Anaconda supports it fine.
>
> I think what you're trying to express is that either 2 or 4 must be
> true and that if 3 is true, 4 must also be true. Is that right?
Yes, I think that's accurate.
> > All supported platforms must have kernels built from the Fedora
> > kernel SRPM and enabled by default in the spec file. Each kernel must
> > be built in a timely manner for every SRPM upload.
>
> What exactly is timely? What margin is acceptable? Is this only
> for kernel or does this apply to any package with a
> much-longer-than-average build time? What would constitute being in
> that class? Or should the class be critical-path packages?
> Something else?
The kernel's kind of a special case due to the relatively frequent
security updates. The exact nature of what kind of speed is required
would probably need to be discussed with the kernel team.
> > Sufficient developer resources must be available to fix any
> > architecture-specific issues in such a way that they do not delay
> > overall Fedora development.
>
> Can you quantify this and also describe how this measurement is to
> be assessed? Are we saying there must be X many engineers available
> at any given time to handle an architecture-specific build issue? I
> don't believe there is a pool of x86 engineers hanging about waiting
> for inline assembler issues to come in so some discussion of the
> mechanics of what's envisioned here would be helpful. I think the
> notion is that there must be a critical-mass of talent competent to
> help out, but how do you define that?
If architecture-specific issues get fixed in a timely way then the
developer resources are sufficient. I don't think it's something that
can be explicitly quantified.
> > It must be possible for maintainers of critical-path hardware
> > dependent packages to have direct access to supported hardware in
> > order to rectify any release-blocking issues. For example, X
> > maintainers must have direct access to any hardware with graphics
> > capabilities.
>
> Is simulated hardware acceptable? Remote-X or VNC access? Physical
> hardware? What happens when a new generation of hardware comes out?
> What about architectures where there is no video at all? What about
> architectures where some systems have video, others don't, but the
> primary use case is systems without video?
Whatever level of access is required to fix the bugs. The aim here is to
deal with architecture-specific but otherwise generic issues - if X
fails to work on a specific model then that's just a bug and it's not
the end of the world, but if X fails to work on ARM at all then that's
something that needs to be fixed. My experience of dealing with these
things is that it's pretty difficult to fix most of these bugs remotely,
so I'd probably expect that hardware be physically available to the
people who need to fix the bugs.
There's relatively cheap hardware available and a number of HW vendors
that will provide ARM HW as well so I think this should be achievable
for general HW specific things, for general arch bits the ARM qemu
support is quite good and we plan to build images that are easy to
import into virt-manager so we have a number of reasonable options
here.
> > The port must not rely on sourceless binaries unless they
fall under
> > the generic firmware exemption. Where source and toolchain are
> > available, the binaries must be built in the Fedora build
> > infrastructure.
>
> Yes, assuming the source is compatible with Fedora packaging
> guidelines. I'm not sure there's a case where source would be
> incompatible but binaries wouldn't be, but thought I'd mentioned it.
If the source isn't compatible with Fedora packaging guidelines then we
shouldn't be shipping the binaries unless they fall under the generic
firmware exemption.
That is what we plan, I don't see any reasons for other exceptions.
> > Excludearch may be used only to disable packages that are
> > fundamentally architecture specific.
>
> Assuming we mean the package has architecture specific components
> that either can not, or have not, been ported, agree.
I'm not enthusiastic about excludearch being used simply because a
component hasn't been ported, but I think that's probably a stronger
position than we've traditionally had so I'm probably ok with it being
used for that.
Being the person that has handled the coordination and tracking of
building F-17 as of where we stand at the moment there isn't any major
exclusions from the architecture now. Of the entire 11500 odd packages
of the mainline repository we've built 10,500 of those currently,
about half of the remaining are ftbfs on mainline, and the remainder
we're working to build or are x86 or ppc. There's only a handful of
packages that aren't HW specifc I'm aware of that are currently
building on ARM, in the coming weeks I hope to have this at near to
zero with tracking bugs against those that don't.
> > This list is not intended to be exhaustive - promotion to
primary
> > architecture status will require agreement from the Fedora
> > infrastructure, release engineering, kernel and installer teams and
> > is subject to overall approval by the Fedora Engineering Steering
> > Committee, and additional criteria may be imposed if felt to be
> > necessary.
>
> Let's make the list exhaustive; there needs to be a path to sure
> success. This means establishing a complete procedure where when an
> SA formally applies to become PA, acceptance means there is a
> definitive set of steps needed to get there. This is one of the
> major reasons for developing these criteria. Put another way:
There is no path to sure success. That's not how this works.
On the flip side I don't believe it's unachievable, I hope I'm not wrong.
Peter
Peter
6:28 p.m.
On Thu, Apr 05, 2012 at 12:01:13AM +0100, Peter Robinson wrote:
On Wed, Apr 4, 2012 at 11:26 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> There is no path to sure success. That's not how this works.
On the flip side I don't believe it's unachievable, I hope I'm not wrong.
I'd be surprised if ARM doesn't end up as a primary architecture. I
certainly think it's achievable.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
6:57 a.m.
On Wed, Apr 4, 2012 at 6:26 PM, Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Mon, Apr 02, 2012 at 08:10:12PM -0700, Brendan Conoboy wrote:
> > All supported platforms must have kernels built from the Fedora
> > kernel SRPM and enabled by default in the spec file. Each kernel must
> > be built in a timely manner for every SRPM upload.
>
> What exactly is timely? What margin is acceptable? Is this only
> for kernel or does this apply to any package with a
> much-longer-than-average build time? What would constitute being in
> that class? Or should the class be critical-path packages?
> Something else?
The kernel's kind of a special case due to the relatively frequent
security updates. The exact nature of what kind of speed is required
would probably need to be discussed with the kernel team.
It was, on the kernel list:
https://lists.fedoraproject.org/pipermail/kernel/2012-March/003702.html
(Max build time for the kernel: 4 hours).
josh
7:40 a.m.
On Thu, Apr 5, 2012 at 12:57 PM, Josh Boyer <jwboyer(a)gmail.com> wrote:
On Wed, Apr 4, 2012 at 6:26 PM, Matthew Garrett
<mjg59(a)srcf.ucam.org> wrote:
> On Mon, Apr 02, 2012 at 08:10:12PM -0700, Brendan Conoboy wrote:
>> > All supported platforms must have kernels built from the Fedora
>> > kernel SRPM and enabled by default in the spec file. Each kernel must
>> > be built in a timely manner for every SRPM upload.
>>
>> What exactly is timely? What margin is acceptable? Is this only
>> for kernel or does this apply to any package with a
>> much-longer-than-average build time? What would constitute being in
>> that class? Or should the class be critical-path packages?
>> Something else?
>
> The kernel's kind of a special case due to the relatively frequent
> security updates. The exact nature of what kind of speed is required
> would probably need to be discussed with the kernel team.
It was, on the kernel list:
https://lists.fedoraproject.org/pipermail/kernel/2012-March/003702.html
(Max build time for the kernel: 4 hours).
With luck, and I use the term tongue in cheek, we should be able able
to use DeviceTree in the F-18+ time frame and reduce the number of
kernels we have and hence the build time greatly but only time will
tell.
Peter
8:04 a.m.
Josh Boyer wrote:
(Max build time for the kernel: 4 hours).
Wow, if they can achieve that, I'll be impressed, though I'm worried it'll
probably be achieved through a kernel-specific cheat (like building only a
monolithic kernel for QEMU with no modules at all, and using custom kernels
built separately for actual hardware as they currently do), which won't help
all the other packages with similar build time requirements (qt, kdelibs,
kde-workspace, xulrunner, firefox, libreoffice etc. Yes, all those DO get
security updates!).
Kevin Kofler
8:18 p.m.
On 04/04/2012 03:26 PM, Matthew Garrett wrote:
> Can we quantify what the overall experience is that must be
> consistent? I understand Anaconda installations is considered a
> part of this... except when it's not for EC2 images. What I'm
> looking for is "These 10 things are partof the Fedora experience-
> any PA needs to provide at least 7 of them" or something like that.
The only differences between the Fedora experience on ARM and x86 should
be those dictated by hardware.
Just hardware, or hardware and software? Or hardware, software, and
community? If hardware is capable of providing a desktop experience,
but only with proprietary drivers, does that mean the arch isn't
acceptable as PA? What if some forms of the hardware are desktop
capable, others are not, but the community only has an interest in
supporting headless installations? I think we're all going to be
rational about this, but my rational and yours might not match up.
> This makes sense, but what is adequate? Perhaps 1 distinct
person
> in each group saying "I will be responsible for $ARCH?" What if
> only 1 person wants to be the secondary representative in both
> groups?
That's something that would have to be discussed with the infrastructure
and release engineering teams.
If that's the case please spell it out:
SA must secure from the Fedora Infrastructure and Release Engineering
teams a statement that they are prepared to support the SA as PA. It us
up to these teams how to form that consensus and provide an answer. The
question should be formally posed to their respective mailing lists
unless they have an otherwise stated policy.
Or something like that.
> This is overloading "support" so I'm having a
little trouble
> understanding the intention. Let's try a thought experiment that's
> a little more generic than the above. I propose any given
> architecture falls into at least 1 and possibly all 4 of the
> following categories:
>
> 1. Specs not suited to Fedora at all (too little RAM, no MMU, etc)
> 2. Can run Fedora, but Anaconda installation doesn't make sense for
> technical reasons.
> 3. Can run Fedora, would even benefit by Anaconda installation, but
> requires changes to Anaconda and/or other packages to work.
> 4. Can run Fedora and Anaconda supports it fine.
>
> I think what you're trying to express is that either 2 or 4 must be
> true and that if 3 is true, 4 must also be true. Is that right?
Yes, I think that's accurate.
Okay- would you put that in the document?
>> All supported platforms must have kernels built from the
Fedora
>> kernel SRPM and enabled by default in the spec file. Each kernel must
>> be built in a timely manner for every SRPM upload.
>
> What exactly is timely? What margin is acceptable? Is this only
> for kernel or does this apply to any package with a
> much-longer-than-average build time? What would constitute being in
> that class? Or should the class be critical-path packages?
> Something else?
The kernel's kind of a special case due to the relatively frequent
security updates. The exact nature of what kind of speed is required
would probably need to be discussed with the kernel team.
I believe a subsequent discussion on the matter has yielded the value of
4 hours. Can the guidelines include this, perhaps with the caveat of
"At the time this draft was approved, the agreed maximum build time for
a kernel was 4 hours."
If architecture-specific issues get fixed in a timely way then the
developer resources are sufficient. I don't think it's something that
can be explicitly quantified.
Okay, you're clearly writing that with a do everything to be PA while
SA, then you'll have proved yourself mindset. That's fine, but it would
help to spell this out. You might just as well say all
architecture-specific issues are fixed before promotion may be granted.
I'm not sure that's an achievable goal, frankly, but that does seem to
be what you're saying.
> Is simulated hardware acceptable? Remote-X or VNC access?
Physical
> hardware? What happens when a new generation of hardware comes out?
> What about architectures where there is no video at all? What about
> architectures where some systems have video, others don't, but the
> primary use case is systems without video?
Whatever level of access is required to fix the bugs. The aim here is to
deal with architecture-specific but otherwise generic issues - if X
fails to work on a specific model then that's just a bug and it's not
the end of the world, but if X fails to work on ARM at all then that's
something that needs to be fixed. My experience of dealing with these
things is that it's pretty difficult to fix most of these bugs remotely,
so I'd probably expect that hardware be physically available to the
people who need to fix the bugs.
Would like to see clarification on whether using a simulator (with X
support) would meet this requirement. If not then the requirement is
essentially: Most packagers on the critical path must own one of these
SA-supported systems before it can be primary.
>> Excludearch may be used only to disable packages that are
>> fundamentally architecture specific.
>
> Assuming we mean the package has architecture specific components
> that either can not, or have not, been ported, agree.
I'm not enthusiastic about excludearch being used simply because a
component hasn't been ported, but I think that's probably a stronger
position than we've traditionally had so I'm probably ok with it being
used for that.
Okay, please clarify in the document.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
8:42 p.m.
On Wed, Apr 18, 2012 at 06:18:34PM -0700, Brendan Conoboy wrote:
On 04/04/2012 03:26 PM, Matthew Garrett wrote:
>>Can we quantify what the overall experience is that must be
>>consistent? I understand Anaconda installations is considered a
>>part of this... except when it's not for EC2 images. What I'm
>>looking for is "These 10 things are partof the Fedora experience-
>>any PA needs to provide at least 7 of them" or something like that.
>
>The only differences between the Fedora experience on ARM and x86 should
>be those dictated by hardware.
Just hardware, or hardware and software?
Just hardware. The software should be equivalent between both.
Or hardware, software, and community? If hardware is capable of
providing a desktop experience, but only with proprietary drivers,
does that mean the arch isn't acceptable as PA?
We still support unaccelerated video hardware.
What if some forms of the hardware are desktop capable, others are
not, but the community only has an interest in supporting headless
installations?
Then it's not fit to be a primary architecture.
>>This makes sense, but what is adequate? Perhaps 1 distinct
person
>>in each group saying "I will be responsible for $ARCH?" What if
>>only 1 person wants to be the secondary representative in both
>>groups?
>
>That's something that would have to be discussed with the infrastructure
>and release engineering teams.
If that's the case please spell it out:
SA must secure from the Fedora Infrastructure and Release
Engineering teams a statement that they are prepared to support the
SA as PA. It us up to these teams how to form that consensus and
provide an answer. The question should be formally posed to their
respective mailing lists unless they have an otherwise stated
policy.
Or something like that.
Seems reasonable.
>>This is overloading "support" so I'm having a
little trouble
>>understanding the intention. Let's try a thought experiment that's
>>a little more generic than the above. I propose any given
>>architecture falls into at least 1 and possibly all 4 of the
>>following categories:
>>
>>1. Specs not suited to Fedora at all (too little RAM, no MMU, etc)
>>2. Can run Fedora, but Anaconda installation doesn't make sense for
>>technical reasons.
>>3. Can run Fedora, would even benefit by Anaconda installation, but
>>requires changes to Anaconda and/or other packages to work.
>>4. Can run Fedora and Anaconda supports it fine.
>>
>>I think what you're trying to express is that either 2 or 4 must be
>>true and that if 3 is true, 4 must also be true. Is that right?
>
>Yes, I think that's accurate.
Okay- would you put that in the document?
That's... what it already says? I'll attempt to clarify it.
>>>All supported platforms must have kernels built from the
Fedora
>>>kernel SRPM and enabled by default in the spec file. Each kernel must
>>>be built in a timely manner for every SRPM upload.
>>
>>What exactly is timely? What margin is acceptable? Is this only
>>for kernel or does this apply to any package with a
>>much-longer-than-average build time? What would constitute being in
>>that class? Or should the class be critical-path packages?
>>Something else?
>
>The kernel's kind of a special case due to the relatively frequent
>security updates. The exact nature of what kind of speed is required
>would probably need to be discussed with the kernel team.
I believe a subsequent discussion on the matter has yielded the
value of 4 hours. Can the guidelines include this, perhaps with the
caveat of "At the time this draft was approved, the agreed maximum
build time for a kernel was 4 hours."
No, because it's the kind of thing that's going to be influenced by
multiple factors. Each architecture seeking PA status should have this
discussion with the kernel team.
>If architecture-specific issues get fixed in a timely way then
the
>developer resources are sufficient. I don't think it's something that
>can be explicitly quantified.
Okay, you're clearly writing that with a do everything to be PA
while SA, then you'll have proved yourself mindset. That's fine,
but it would help to spell this out. You might just as well say all
architecture-specific issues are fixed before promotion may be
granted. I'm not sure that's an achievable goal, frankly, but that
does seem to be what you're saying.
Becoming a PA won't magically produce extra maintainers. It's still
going to be up to the architecture maintainers to deal with ARM-specific
bugs in packages, if the package maintainer isn't able to deal with
them. So, yes, I think in this respect it's important for the SA to
demonstrate that it's not going to hold up development once it becomes
primary.
>>Is simulated hardware acceptable? Remote-X or VNC access?
Physical
>>hardware? What happens when a new generation of hardware comes out?
>>What about architectures where there is no video at all? What about
>>architectures where some systems have video, others don't, but the
>>primary use case is systems without video?
>
>Whatever level of access is required to fix the bugs. The aim here is to
>deal with architecture-specific but otherwise generic issues - if X
>fails to work on a specific model then that's just a bug and it's not
>the end of the world, but if X fails to work on ARM at all then that's
>something that needs to be fixed. My experience of dealing with these
>things is that it's pretty difficult to fix most of these bugs remotely,
>so I'd probably expect that hardware be physically available to the
>people who need to fix the bugs.
Would like to see clarification on whether using a simulator (with X
support) would meet this requirement. If not then the requirement
is essentially: Most packagers on the critical path must own one of
these SA-supported systems before it can be primary.
A simulator might be sufficient in some circumstances - I'd really need
to defer to people who do more work on graphics for that. Most crit-path
packages could be handled fine in qemu, which is why the criterion
mentions hardware-dependence. There's not a huge amount of userspace
code that falls into that category.
>>>Excludearch may be used only to disable packages that
are
>>>fundamentally architecture specific.
>>
>>Assuming we mean the package has architecture specific components
>>that either can not, or have not, been ported, agree.
>
>I'm not enthusiastic about excludearch being used simply because a
>component hasn't been ported, but I think that's probably a stronger
>position than we've traditionally had so I'm probably ok with it being
>used for that.
Okay, please clarify in the document.
Ok.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:04 p.m.
On 04/18/2012 06:42 PM, Matthew Garrett wrote:
[snip]
> What if some forms of the hardware are desktop capable, others
are
> not, but the community only has an interest in supporting headless
> installations?
Then it's not fit to be a primary architecture.
Okay, please add examples like this wherever possible.
> I believe a subsequent discussion on the matter has yielded the
> value of 4 hours. Can the guidelines include this, perhaps with the
> caveat of "At the time this draft was approved, the agreed maximum
> build time for a kernel was 4 hours."
No, because it's the kind of thing that's going to be influenced by
multiple factors. Each architecture seeking PA status should have this
discussion with the kernel team.
Huh? The whole point of this item is that it's architecture neutral-
the kernel team for security reasons believes it important that all
kernel builds take less than 4 hours from start to finish. Why would a
new architecture change that number? There's a caveat in the suggested
wording above. Don't understand the resistance.
> Okay, you're clearly writing that with a do everything to be
PA
> while SA, then you'll have proved yourself mindset. That's fine,
> but it would help to spell this out. You might just as well say all
> architecture-specific issues are fixed before promotion may be
> granted. I'm not sure that's an achievable goal, frankly, but that
> does seem to be what you're saying.
Becoming a PA won't magically produce extra maintainers. It's still
going to be up to the architecture maintainers to deal with ARM-specific
bugs in packages, if the package maintainer isn't able to deal with
them. So, yes, I think in this respect it's important for the SA to
demonstrate that it's not going to hold up development once it becomes
primary.
I'm nonplussed by the answer, but can't disagree with it either. This
seems to make #5 and #8 the same thing. You just need to merge them by
adding the changes you'd already agreed with below, and including
something like "All packages that are architecture neutral or have been
ported to ARM must build from the same srpm prior to PA promotion."
[snip]
>> I'm not enthusiastic about excludearch being used simply
because a
>> component hasn't been ported, but I think that's probably a stronger
>> position than we've traditionally had so I'm probably ok with it being
>> used for that.
>
> Okay, please clarify in the document.
Ok.
Thanks!
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
9:13 p.m.
On Wed, Apr 18, 2012 at 07:04:24PM -0700, Brendan Conoboy wrote:
On 04/18/2012 06:42 PM, Matthew Garrett wrote:
[snip]
>>What if some forms of the hardware are desktop capable, others are
>>not, but the community only has an interest in supporting headless
>>installations?
>
>Then it's not fit to be a primary architecture.
Okay, please add examples like this wherever possible.
I'm confused. How would the Fedora experience be consistent across all
primary architectures if an architecture community has no interest in
supporting major parts of Fedora? Basically, I think the text already
says this. I don't think adding examples make it clearer.
>>I believe a subsequent discussion on the matter has yielded
the
>>value of 4 hours. Can the guidelines include this, perhaps with the
>>caveat of "At the time this draft was approved, the agreed maximum
>>build time for a kernel was 4 hours."
>
>No, because it's the kind of thing that's going to be influenced by
>multiple factors. Each architecture seeking PA status should have this
>discussion with the kernel team.
Huh? The whole point of this item is that it's architecture
neutral- the kernel team for security reasons believes it important
that all kernel builds take less than 4 hours from start to finish.
Why would a new architecture change that number? There's a caveat
in the suggested wording above. Don't understand the resistance.
The kernel team may have their view skewed by how likely they think it
is that a given architecture will be likely to force additional
rebuilds. So yes, the point of this document is that it's architecture
neutral, and so it's inappropriate for it to list figures that have been
quoted for a specific architecture.
>Becoming a PA won't magically produce extra maintainers.
It's still
>going to be up to the architecture maintainers to deal with ARM-specific
>bugs in packages, if the package maintainer isn't able to deal with
>them. So, yes, I think in this respect it's important for the SA to
>demonstrate that it's not going to hold up development once it becomes
>primary.
I'm nonplussed by the answer, but can't disagree with it either.
This seems to make #5 and #8 the same thing. You just need to merge
them by adding the changes you'd already agreed with below, and
including something like "All packages that are architecture neutral
or have been ported to ARM must build from the same srpm prior to PA
promotion."
Not really. You could potentially satisfy number 8 without satisfying
number 5, and you could satisfy number 5 without satisfying number 8.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:57 p.m.
On 04/18/2012 07:13 PM, Matthew Garrett wrote:
> Huh? The whole point of this item is that it's architecture
> neutral- the kernel team for security reasons believes it important
> that all kernel builds take less than 4 hours from start to finish.
> Why would a new architecture change that number? There's a caveat
> in the suggested wording above. Don't understand the resistance.
The kernel team may have their view skewed by how likely they think it
is that a given architecture will be likely to force additional
rebuilds. So yes, the point of this document is that it's architecture
neutral, and so it's inappropriate for it to list figures that have been
quoted for a specific architecture.
This is very puzzling. As part of your proposal we had the discussion
with the kernel team and they came back with the answer for this
proposal. Now you don't want it. If you don't want to kernel team's
answer, why mention them at all? If it's a general principle for a
braod spectrum of packages that's entirely sensible and the document
shoudl say so. If we're specifically calling out the kernel and nothing
else it's nonsense to ignore the answer to the question.
Not really. You could potentially satisfy number 8 without
satisfying
number 5, and you could satisfy number 5 without satisfying number 8.
As you like.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
12:12 a.m.
On Wed, Apr 18, 2012 at 09:57:19PM -0700, Brendan Conoboy wrote:
On 04/18/2012 07:13 PM, Matthew Garrett wrote:
>The kernel team may have their view skewed by how likely they think it
>is that a given architecture will be likely to force additional
>rebuilds. So yes, the point of this document is that it's architecture
>neutral, and so it's inappropriate for it to list figures that have been
>quoted for a specific architecture.
This is very puzzling. As part of your proposal we had the
discussion with the kernel team and they came back with the answer
for this proposal. Now you don't want it. If you don't want to
kernel team's answer, why mention them at all? If it's a general
principle for a braod spectrum of packages that's entirely sensible
and the document shoudl say so. If we're specifically calling out
the kernel and nothing else it's nonsense to ignore the answer to
the question.
They're happy with it being 4 hours for ARM. The number might be
different for some other architecture. Since this is supposed to be a
generic document, it's not appropriate to put the 4 hour figure in it.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:17 a.m.
On 04/18/2012 10:12 PM, Matthew Garrett wrote:
On Wed, Apr 18, 2012 at 09:57:19PM -0700, Brendan Conoboy wrote:
> On 04/18/2012 07:13 PM, Matthew Garrett wrote:
>> The kernel team may have their view skewed by how likely they think it
>> is that a given architecture will be likely to force additional
>> rebuilds. So yes, the point of this document is that it's architecture
>> neutral, and so it's inappropriate for it to list figures that have been
>> quoted for a specific architecture.
>
> This is very puzzling. As part of your proposal we had the
> discussion with the kernel team and they came back with the answer
> for this proposal. Now you don't want it. If you don't want to
> kernel team's answer, why mention them at all? If it's a general
> principle for a braod spectrum of packages that's entirely sensible
> and the document shoudl say so. If we're specifically calling out
> the kernel and nothing else it's nonsense to ignore the answer to
> the question.
They're happy with it being 4 hours for ARM. The number might be
different for some other architecture. Since this is supposed to be a
generic document, it's not appropriate to put the 4 hour figure in it.
Still not following you. Everything in PA builds at once- 4 hours is
the lowest common denominator that the kernel team will accept. The
builds all start at the same time and have to end within 4 hours,
regardless of arch. This is a silly thing to be quibbling over so I'll
leave it there.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
11:29 a.m.
On Thu, 2012-04-19 at 02:42 +0100, Matthew Garrett wrote:
> >>Is simulated hardware acceptable? Remote-X or VNC
access? Physical
> >>hardware? What happens when a new generation of hardware comes out?
> >>What about architectures where there is no video at all? What about
> >>architectures where some systems have video, others don't, but the
> >>primary use case is systems without video?
> >
> >Whatever level of access is required to fix the bugs. The aim here is to
> >deal with architecture-specific but otherwise generic issues - if X
> >fails to work on a specific model then that's just a bug and it's not
> >the end of the world, but if X fails to work on ARM at all then that's
> >something that needs to be fixed. My experience of dealing with these
> >things is that it's pretty difficult to fix most of these bugs remotely,
> >so I'd probably expect that hardware be physically available to the
> >people who need to fix the bugs.
>
> Would like to see clarification on whether using a simulator (with X
> support) would meet this requirement. If not then the requirement
> is essentially: Most packagers on the critical path must own one of
> these SA-supported systems before it can be primary.
A simulator might be sufficient in some circumstances - I'd really need
to defer to people who do more work on graphics for that. Most crit-path
packages could be handled fine in qemu, which is why the criterion
mentions hardware-dependence. There's not a huge amount of userspace
code that falls into that category.
If the hardware never has a real framebuffer, like s390, then I wouldn't
demand a simulator with a framebuffer.
arm isn't like that, but arm's also weird in often not having PCI. I'd
_prefer_ to have a simulator that had a GPU that resembles something
people actually have, but even qemu-on-x86 fails that test (ha ha ha
cirrus). I'd at least want something that presents a firmware interface
that matches what you'd expect on real hardware (efifb or vesa on x86,
offb on ppc, etc). It needn't attempt acceleration like vbox or qxl,
since that's going to be per-device anyway.
I'd obviously love to be more of a hardass about this, but I'm not going
to make more demands of new arches than I'm making of the existing.
- ajax
8:54 p.m.
On Wed, Apr 18, 2012 at 05:34:11PM -0700, Brendan Conoboy wrote:
On 04/16/2012 02:20 PM, Matthew Garrett wrote:
>If you manage that then I think most of the problems you're worried
>about go away. It'll be obvious to everyone whether or not you're ready
>to be a primary architecture at any given point. Don't worry about the
>details. Just be part of Fedora.
That almost sounds like an argument for scrapping the promotion
requirements document entirely. Is that what you meant? I
understand where you're coming from philosophically, but we're
talking about something more concrete. Many people who are
interested in SA2PA promotion requirements are working on Fedora
24/7 and they want guidance too. As documents go I'm all for having
a philosophical section on what the mindset is, but it should be
matched with applied examples.
Not really. The proposed criteria provide strong guidance. If you meet
them all then you're probably fine. But the point isn't to be slaves to
these criteria. It's to be active particpants in the Fedora development
community.
Right now I don't think ARM's doing a great job of that. Your meetings
happen on the phone and aren't minuted. I've got no insight at all into
how your development process is progressing. At minimum you should be
meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd
be Cc:ing them to devel@. If you're doing everything transparently then
people are more likely to object to things at the time, whereas if you
turn up at the beginning of F19 and say "Look, we've ticked all your
boxes" you're liable to find people who haven't been actively following
you and have only just realised that you're done something wrong.
I think what you're trying to say above is "For a secondary
architecture to become primary architecture, its team should have a
demonstrable history of communicating with the greater Fedora
community about what it's doing and how the greater Fedora
community's activities are affecting it." If that is indeed what
you mean, please put it in the document and include some examples.
The word "communicate" doesn't exist in the current document.
I'm open to providing what I think are reasonable examples if they
may ultimately make it into the end document.
This document isn't supposed to be a discussion of how to be good
members of the Fedora community. A secondary architecture should be led
by people who already know how to do that.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:42 p.m.
Hi Matthew,
On 04/18/2012 09:54 PM, Matthew Garrett wrote:
Right now I don't think ARM's doing a great job of that
[being part of
the Fedora community]. Your meetings happen on the phone and aren't
minuted.
I am sorry that you feel that way. I think it is important to add some
context to the point about meetings (I'm not sure how one generalizes
that into a broader statement). We have meetings that are on the phone,
and on IRC, on #fedora-arm, which you are welcome to join (though I
understand that this is unusual to have a phone call and the timing
might not be convenient to everyone's schedule - the current time was
collaboratively chosen by everyone involved in Fedora ARM). We use the
standard meeting bot, and we have an intention to move to
#fedora-meeting in due course. For now we're still using #fedora-arm,
but if it's important that we move meetings from now on, we can do that.
We are aware of the need to do a better job in getting things written
down (on IRC) as they are discussed. In the meeting we had today (prior
to your email), we specifically discussed whether we want to continue to
use the phone, and it was decided that this was generally preferred for
the time being. Not everyone prefers the phone, of course, but the
consensus appeared to be that we will continue the dual phone/IRC
approach for now, and revisit this topic semi-regularly for review.
I've got no insight at all into
how your development process is progressing.
I'm glad to see that you care deeply about the topic. You're welcome to
join #fedora-arm, participate in the discussions, join the mailing list,
and reply to any of the discussions there. You're also welcome to start
new conversations, or raise issues on IRC any time you like. It might
also be relatively easy for us to arrange to get you some hardware that
you can run the ARM port on if you would like to help?
At minimum you should be
meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd
be Cc:ing them to devel@.
Feel free to add that to the list of requirements for SA promotion.
If you're doing everything transparently
We are doing everything transparently. Some times it might happen on the
"wrong" channel, and we might screw up with regard to certain
expectations, but there is no attempt to be non-transparent.
Thanks,
Jon.
12:22 a.m.
On Thu, Apr 19, 2012 at 12:42:58AM -0400, Jon Masters wrote:
Hi Matthew,
On 04/18/2012 09:54 PM, Matthew Garrett wrote:
> Right now I don't think ARM's doing a great job of that [being part of
> the Fedora community]. Your meetings happen on the phone and aren't
minuted.
I am sorry that you feel that way. I think it is important to add some
context to the point about meetings (I'm not sure how one generalizes
that into a broader statement). We have meetings that are on the phone,
and on IRC, on #fedora-arm, which you are welcome to join (though I
understand that this is unusual to have a phone call and the timing
might not be convenient to everyone's schedule - the current time was
collaboratively chosen by everyone involved in Fedora ARM). We use the
standard meeting bot, and we have an intention to move to
#fedora-meeting in due course. For now we're still using #fedora-arm,
but if it's important that we move meetings from now on, we can do that.
#fedora-meeting is a given, but really, other parts of the project are
able to function by having meetings on IRC - It's important to have a
written record of not only what decisions were made, but also why they
were made.
> I've got no insight at all into
> how your development process is progressing.
I'm glad to see that you care deeply about the topic. You're welcome to
join #fedora-arm, participate in the discussions, join the mailing list,
and reply to any of the discussions there. You're also welcome to start
new conversations, or raise issues on IRC any time you like. It might
also be relatively easy for us to arrange to get you some hardware that
you can run the ARM port on if you would like to help?
I don't have the time or the inclination to be involved in the ARM port
at the moment. What I *do* want is to have some visibility into what
you're doing in order to reduce the probability of decisions being made
that are incompatible with some other aspect of the distribution. The
onus is on you to make sure that people are aware of relevant decisions
you've made.
> At minimum you should be
> meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd
> be Cc:ing them to devel@.
Feel free to add that to the list of requirements for SA promotion.
No, because it's not a requirement. In theory an SA could be perfectly
suited for PA promotion without any real involvement with the Fedora
community. It'd just be massively more difficult.
> If you're doing everything transparently
We are doing everything transparently. Some times it might happen on the
"wrong" channel, and we might screw up with regard to certain
expectations, but there is no attempt to be non-transparent.
I appreciate that there's no deliberate attempt to avoid scrutiny, but
that's not enough. You need to take the initiative in being more active
in communicating with the rest of the project.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:34 a.m.
On 04/19/2012 01:22 AM, Matthew Garrett wrote:
On Thu, Apr 19, 2012 at 12:42:58AM -0400, Jon Masters wrote:
> Hi Matthew,
>
> On 04/18/2012 09:54 PM, Matthew Garrett wrote:
>
>> Right now I don't think ARM's doing a great job of that [being part of
>> the Fedora community]. Your meetings happen on the phone and aren't
> minuted.
>
> I am sorry that you feel that way. I think it is important to add some
> context to the point about meetings (I'm not sure how one generalizes
> that into a broader statement). We have meetings that are on the phone,
> and on IRC, on #fedora-arm, which you are welcome to join (though I
> understand that this is unusual to have a phone call and the timing
> might not be convenient to everyone's schedule - the current time was
> collaboratively chosen by everyone involved in Fedora ARM). We use the
> standard meeting bot, and we have an intention to move to
> #fedora-meeting in due course. For now we're still using #fedora-arm,
> but if it's important that we move meetings from now on, we can do that.
#fedora-meeting is a given, but really, other parts of the project are
able to function by having meetings on IRC - It's important to have a
written record of not only what decisions were made, but also why they
were made.
Thanks for making this point very clear. I'm sure we'll take it on
board. I'm all for doing what makes sense - moving IRC channel is hardly
difficult, and dropping the phone can be done (note that we are not the
only part of the Fedora project that uses the phone though).
>> I've got no insight at all into
>> how your development process is progressing.
>
> I'm glad to see that you care deeply about the topic. You're welcome to
> join #fedora-arm, participate in the discussions, join the mailing list,
> and reply to any of the discussions there. You're also welcome to start
> new conversations, or raise issues on IRC any time you like. It might
> also be relatively easy for us to arrange to get you some hardware that
> you can run the ARM port on if you would like to help?
I don't have the time or the inclination to be involved in the ARM port
at the moment.
That's fine. Not a problem. Do note though that we're very willing to
work with anyone who does want to get involved. You're most welcome.
What I *do* want is to have some visibility into what
you're doing in order to reduce the probability of decisions being made
that are incompatible with some other aspect of the distribution.
It's certainly a good idea to make sure everyone is aware of important
decisions. We certainly don't need the personal approval of any one
person, but we hope that in general we make sane choices, and we can
benefit by making sure that everyone is aware of our sane choices :) I
think the team will need to do what makes sense. We're busily trying to
make progress, and we need to make some decisions. For example, you're
not running the build system, but Chris and the Seneca team are. They're
doing a great job. It would probably be inappropriate to expect your
approval for decisions we would need to make around the build system,
but it would certainly be beneficial to share what we are deciding so
that there is due opportunity for any course correction. So, we'll take
your input on board and we'll try to increase the level of informational
flow and general comfort of those observing our effort.
The
onus is on you to make sure that people are aware of relevant decisions
you've made.
Of course, that's good input. I think we can always do a better job :)
>> At minimum you should be
>> meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd
>> be Cc:ing them to devel@.
>
> Feel free to add that to the list of requirements for SA promotion.
No, because it's not a requirement. In theory an SA could be perfectly
suited for PA promotion without any real involvement with the Fedora
community. It'd just be massively more difficult.
I think there's a missunderstanding here. I don't recall suggesting that
you need to add anything about "real involvement" to the list, just that
if you feel certain specifics are required around meeting format,
etiquette, and so forth, that would be useful to note down.
>> If you're doing everything transparently
>
> We are doing everything transparently. Some times it might happen on the
> "wrong" channel, and we might screw up with regard to certain
> expectations, but there is no attempt to be non-transparent.
I appreciate that there's no deliberate attempt to avoid scrutiny, but
that's not enough. You need to take the initiative in being more active
in communicating with the rest of the project.
Absolutely. We are a small team, and we are trying. Like you, the reason
Brendan and myself are replying this late into the evening is that we
are working around to clock to advance this project. We agree that the
Fedora ARM team can do a better job at engagement and we will try to
dedicate a good chunk of time to improving overall cohesion.
Thanks,
Jon.
12:43 a.m.
On Thu, Apr 19, 2012 at 01:34:00AM -0400, Jon Masters wrote:
On 04/19/2012 01:22 AM, Matthew Garrett wrote:
> No, because it's not a requirement. In theory an SA could be perfectly
> suited for PA promotion without any real involvement with the Fedora
> community. It'd just be massively more difficult.
I think there's a missunderstanding here. I don't recall suggesting that
you need to add anything about "real involvement" to the list, just that
if you feel certain specifics are required around meeting format,
etiquette, and so forth, that would be useful to note down.
I don't think they're required. I'm not in any position to veto
decisions you've made. The relevant point here is that having public
meetings makes it more likely that you'll get useful feedback from
others regarding decisions you've made, and that makes it less likely
that anyone will have objections when you propose ARM as a primary
architecture. If you choose to do that without making it easy for other
people to offer you advice then you're free to. I just think it'd be a
mistake.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
11:46 p.m.
On 04/18/2012 06:54 PM, Matthew Garrett wrote:
Not really. The proposed criteria provide strong guidance. If you
meet
them all then you're probably fine. But the point isn't to be slaves to
these criteria. It's to be active particpants in the Fedora development
community.
It's a big if for any secondary to meet such criteria.
Right now I don't think ARM's doing a great job of that. Your
meetings
happen on the phone and aren't minuted. I've got no insight at all into
how your development process is progressing. At minimum you should be
meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd
be Cc:ing them to devel@. If you're doing everything transparently then
people are more likely to object to things at the time, whereas if you
turn up at the beginning of F19 and say "Look, we've ticked all your
boxes" you're liable to find people who haven't been actively following
you and have only just realised that you're done something wrong.
While I'm glad you've taken the time to watch the ARM team and form
these opinions I'm also sad you've waited until now to share them. Why
haven't you troubled yourself to mail fedora-arm about this matter
instead of bringing it up at an inappropriate time? We're talking about
secondary architectures in general here, not ARM.
This document isn't supposed to be a discussion of how to be
good
members of the Fedora community. A secondary architecture should be led
by people who already know how to do that.
Volunteers welcome.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
12:38 a.m.
On Wed, Apr 18, 2012 at 09:46:16PM -0700, Brendan Conoboy wrote:
On 04/18/2012 06:54 PM, Matthew Garrett wrote:
>Not really. The proposed criteria provide strong guidance. If you meet
>them all then you're probably fine. But the point isn't to be slaves to
>these criteria. It's to be active particpants in the Fedora development
>community.
It's a big if for any secondary to meet such criteria.
It's a big job to commit to supporting an architecture as part of the
project.
>Right now I don't think ARM's doing a great job of that.
Your meetings
>happen on the phone and aren't minuted. I've got no insight at all into
>how your development process is progressing. At minimum you should be
>meeting in #fedora-meeting and posting minutes to arm@ - ideally you'd
>be Cc:ing them to devel@. If you're doing everything transparently then
>people are more likely to object to things at the time, whereas if you
>turn up at the beginning of F19 and say "Look, we've ticked all your
>boxes" you're liable to find people who haven't been actively following
>you and have only just realised that you're done something wrong.
While I'm glad you've taken the time to watch the ARM team and form
these opinions I'm also sad you've waited until now to share them.
Why haven't you troubled yourself to mail fedora-arm about this
matter instead of bringing it up at an inappropriate time? We're
talking about secondary architectures in general here, not ARM.
It's really not my problem. It should be obvious to anyone promoting a
secondary architecture that there's a large number of skilled people
already working on Fedora. It's sensible to make use of them, but you
can't expect them to all want to be actively involved. So it's up to you
to let them know about decisions you've made, giving them an opportunity
to offer advice before you've committed to them.
Of course, nobody can force you to do this. You're free to do it all on
your own. It'll just make your job significantly harder.
>This document isn't supposed to be a discussion of how to be
good
>members of the Fedora community. A secondary architecture should be led
>by people who already know how to do that.
Volunteers welcome.
Jon's been active in Fedora for longer than I have, so I'd expect him to
have useful insight here.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
12:50 a.m.
Hey guys,
Cutting this sub-thread off at the pass :)
I think it's obvious that we in the ARM project can do a better job at
engagement, cohesion, and we can learn and improve in many ways. I would
like to suggest that we steer this thread back toward the more abstract
question at hand: that of secondary promotion criteria. With that in
mind, I've a few thoughts specific to the existing draft, some of which
have been touched on already, but let me just offer my $0.02:
* Not really sure how to word this, but something about the website,
wiki, and documentation? After all, it's all very x86-ish right now.
* I'm trying to figure out what "adequate representation" means in the
context of infrastructure and release engineering. For example, Dennis
Gilmore is very involved in a number of secondary efforts and I would
/think/ that would be sufficient? But are you putting specific head
count requirements in terms of dedicated resources in here?
* We agree on the need for Fedora maintained servers. Absolutely. We'll
drop the notion of interim solutions (for any architecture).
* I would like clarification of "developer resources". For example, does
this mean head count, hardware, both? And to what level? In terms of
access to hardware, we're working on solutions for this. For those who
work for Red Hat, I can get certain hardware made available internally
(for e.g. ARM), and in the broader community, a certain amount of
hardware is already being given out. But clearly, we can't give everyone
one of every system. So having some numbers here - however vague they
need to be - will help to clarify things. In the case of ARM, we'll
endeavor to have certain hardware available in a central fashion that
can be provisioned by individual developers (there are some technical
challenges there, but that is being thought through).
* Is the release criteria malleable when it comes to the influence of
new architectures in general, in terms of what that might allow the
distribution to do that it can't do on the existing architectures?
Thanks for reading. Meanwhile, we genuinely will take the earlier
comments on board about a need to improve our level of engagement.
Jon.
9:39 a.m.
On Thu, Apr 19, 2012 at 01:50:20AM -0400, Jon Masters wrote:
* Not really sure how to word this, but something about the website,
wiki, and documentation? After all, it's all very x86-ish right now.
You mean making sure that an architecture is covered by the
documentation before promotion?
* I'm trying to figure out what "adequate
representation" means in the
context of infrastructure and release engineering. For example, Dennis
Gilmore is very involved in a number of secondary efforts and I would
/think/ that would be sufficient? But are you putting specific head
count requirements in terms of dedicated resources in here?
If the teams are happy with the level of coverage they have, that's
going to be fine. This should just be a sanity check.
* I would like clarification of "developer resources". For
example, does
this mean head count, hardware, both? And to what level? In terms of
access to hardware, we're working on solutions for this. For those who
work for Red Hat, I can get certain hardware made available internally
(for e.g. ARM), and in the broader community, a certain amount of
hardware is already being given out. But clearly, we can't give everyone
one of every system. So having some numbers here - however vague they
need to be - will help to clarify things. In the case of ARM, we'll
endeavor to have certain hardware available in a central fashion that
can be provisioned by individual developers (there are some technical
challenges there, but that is being thought through).
If ARM regularly holds things up then the developer resources are
inadequate. I don't think this is really something that can be
quantified. Once you've aligned yourself with the primary architectures
it ought to be pretty obvious whether promotion would cause problems -
if you're getting packages fixed and built in a timely manner then we're
good, if we're not then there's a problem.
* Is the release criteria malleable when it comes to the influence
of
new architectures in general, in terms of what that might allow the
distribution to do that it can't do on the existing architectures?
I'd guess there could be exceptions for sufficiently compelling cases.
I'm not inclined to feel that ARM offers anything special enough to do
so, but people could probably be convinced.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
9:49 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 02 Apr 2012 20:10:12 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
This is feedback vs the current version of the following web page:
http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requiremen...
<snip>
> There must be adequate representation for the architecture on
the
> Fedora infrastructure and release engineering teams.
This makes sense, but what is adequate? Perhaps 1 distinct person in
each group saying "I will be responsible for $ARCH?" What if only 1
person wants to be the secondary representative in both groups?
- From a releng perspective the only grounds that I could object on are
that the tooling to do composes is not acceptable. since a secondary
arch should be using the same tooling as primary I cant make that
objection. If the community wants something it happens. I wont speak
for Kevin but the only grounds I know of for objection from
Infrastructure are lack of rackspace/power/cooling or a lack of
sufficient disk space for /mnt/koji otherwise if its what the community
wants it happens. so really that should be reworded to something like
Release engineering find the tooling and methods of composing to be
acceptable to be integrated into the fedora release process,
Infrastructure is able to provide adequate power, cooling and rack
space, additionally there is enough storage to accommodate the
additional architecture.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk+QJgMACgkQkSxm47BaWfcyfwCcCrBPRGZtKy9Ye4tfQ5FcEv4v
JIcAoKOKLgFly/+0IOph74fA7z0WHbJB
=ZVKo
-----END PGP SIGNATURE-----
10:04 a.m.
On Thu, Apr 19, 2012 at 09:49:34AM -0500, Dennis Gilmore wrote:
Release engineering find the tooling and methods of composing to be
acceptable to be integrated into the fedora release process,
Ok, so there's no expectation that release engineering have experience
with the architecture?
Infrastructure is able to provide adequate power, cooling and rack
space, additionally there is enough storage to accommodate the
additional architecture.
Ditto here.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
4 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 19 Apr 2012 16:04:57 +0100
Matthew Garrett <mjg59(a)srcf.ucam.org> wrote:
On Thu, Apr 19, 2012 at 09:49:34AM -0500, Dennis Gilmore wrote:
> Release engineering find the tooling and methods of composing to be
> acceptable to be integrated into the fedora release process,
Ok, so there's no expectation that release engineering have
experience with the architecture?
No, We get asked to do stuff if we say no, we get asked why, if its a
tooling issue the tooling gets fixed if its that we dont want to do it
we get told thats not ok, as long as its supportable and there is
people to lean on when needed then it will happen. in the end it comes
down to what the community wants. when we hit issues we work with the
teams with the knowledge to get the issue resolved.
> Infrastructure is able to provide adequate power, cooling and
rack
> space, additionally there is enough storage to accommodate the
> additional architecture.
Ditto here.
Much the same reasons. Infrastructure is full of very smart people. we
hit weird issues with the harware we have and make it work.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk+QfQMACgkQkSxm47BaWfeupwCgkzFtKgAMZlbGXoFNYqvcazan
X40AniSaIiEYl2xUwd3DzogbRFWlPQZl
=/tsh
-----END PGP SIGNATURE-----
4:36 p.m.
Ok, I'll modify that section. Thanks for the feedback!
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:22 p.m.
On 04/19/2012 05:36 PM, Matthew Garrett wrote:
Ok, I'll modify that section. Thanks for the feedback!
Matthew,
Could you add comments addressing the need for documentation and website
content around a promoted arch? And any of the other comments I made in
my previous reply that you would like to add in? E.g. clarifying what
"sufficient developer resources" means, etc.
Thanks,
Jon.
3:30 p.m.
On Fri, Apr 20, 2012 at 04:22:38PM -0400, Jon Masters wrote:
On 04/19/2012 05:36 PM, Matthew Garrett wrote:
> Ok, I'll modify that section. Thanks for the feedback!
Matthew,
Could you add comments addressing the need for documentation and website
content around a promoted arch? And any of the other comments I made in
my previous reply that you would like to add in? E.g. clarifying what
"sufficient developer resources" means, etc.
I think we'll want to discuss the documentation and website scenario
first - I have no idea how well PPC was documented when it was a primary
architecture, and we don't necessarily want to hold new ones to a higher
standard when it comes to that. But yes, I'll tidy up the rest before
the fesco meeting.
--
Matthew Garrett | mjg59(a)srcf.ucam.org
3:37 p.m.
On 04/20/2012 04:30 PM, Matthew Garrett wrote:
On Fri, Apr 20, 2012 at 04:22:38PM -0400, Jon Masters wrote:
> On 04/19/2012 05:36 PM, Matthew Garrett wrote:
>> Ok, I'll modify that section. Thanks for the feedback!
>
> Matthew,
>
> Could you add comments addressing the need for documentation and website
> content around a promoted arch? And any of the other comments I made in
> my previous reply that you would like to add in? E.g. clarifying what
> "sufficient developer resources" means, etc.
I think we'll want to discuss the documentation and website scenario
first - I have no idea how well PPC was documented when it was a primary
architecture, and we don't necessarily want to hold new ones to a higher
standard when it comes to that. But yes, I'll tidy up the rest before
the fesco meeting.
Excellent. Thanks. See you in #fedora-meeting ;)
Jon.
4389
days inactive
4406
days old
98 comments
20 participants
participants (20)
-
Adam Jackson -
Brendan Conoboy -
Brendan Jones -
Dennis Gilmore -
DJ Delorie -
Jared K. Smith -
Jesse Keating -
Jon Ciesla -
Jon Masters -
Josh Boyer -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kevin Kofler -
Matthew Garrett -
Matthew Garrett -
Miloslav Trmač -
Peter Jones -
Peter Robinson -
Przemek Klosowski -
Stephen John Smoogen