Re: Feedback on secondary architecute promotion requirements draft
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 02 Apr 2012 20:10:12 -0700 Brendan Conoboy b...@redhat.com wrote: This is feedback vs the current version of the following web page: http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 19 Apr 2012 16:04:57 +0100 Matthew Garrett mj...@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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
Ok, I'll modify that section. Thanks for the feedback! -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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,
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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.4000...@redhat.com from yesterday. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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
Re: Feedback on secondary architecute promotion requirements draft
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
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Wed, Apr 4, 2012 at 6:26 PM, Matthew Garrett mj...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Thu, Apr 5, 2012 at 12:57 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Apr 4, 2012 at 6:26 PM, Matthew Garrett mj...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Wed, Apr 4, 2012 at 11:09 AM, Kevin Kofler kevin.kof...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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
Re: Feedback on secondary architecute promotion requirements draft
On Wed, Apr 4, 2012 at 11:26 PM, Matthew Garrett mj...@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
Re: Feedback on secondary architecute promotion requirements draft
On Thu, Apr 05, 2012 at 12:01:13AM +0100, Peter Robinson wrote: On Wed, Apr 4, 2012 at 11:26 PM, Matthew Garrett mj...@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 | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 5:10 AM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Mon, Apr 2, 2012 at 10:10 PM, Brendan Conoboy b...@redhat.com wrote: This is feedback vs the current version of the following web page: http://fedoraproject.org/wiki/Secondary_Architecture_Promotion_Requirements_%28Draft%29 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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
2012/4/3 Miloslav Trmač m...@volny.cz: On Tue, Apr 3, 2012 at 5:10 AM, Brendan Conoboy b...@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
Re: Feedback on secondary architecute promotion requirements draft
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_Requirements_%28Draft%29 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 10:16 AM, Peter Robinson wrote: On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 4:31 PM, Peter Jones pjo...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 11:35 AM, Peter Jones pjo...@redhat.com wrote: On 04/03/2012 10:16 AM, Peter Robinson wrote: On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 12:07 PM, Josh Boyer wrote: On Tue, Apr 3, 2012 at 11:35 AM, Peter Jones pjo...@redhat.com wrote: On 04/03/2012 10:16 AM, Peter Robinson wrote: On Tue, Apr 3, 2012 at 12:58 PM, Josh Boyer jwbo...@gmail.com wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 04:58 AM, Josh Boyer wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com mailto:b...@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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 2:45 PM, Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 04:58 AM, Josh Boyer wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com mailto:b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
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. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Apr 2012 11:58:11 -0700 Brendan Conoboy b...@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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 2:58 PM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 3:04 PM, Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, 03 Apr 2012 12:04:07 -0700 Brendan Conoboy b...@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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On 04/03/2012 12:10 PM, Kevin Fenzi wrote: I'll note again that the ppc and s390 secondary arch hubs are in fact in phx2. ;) You're already one step ahead of ARM ;-) -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
On Tue, Apr 3, 2012 at 3:05 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Apr 2012 11:58:11 -0700 Brendan Conoboy b...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Feedback on secondary architecute promotion requirements draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Apr 2012 11:45:09 -0700 Brendan Conoboy b...@redhat.com wrote: On 04/03/2012 04:58 AM, Josh Boyer wrote: On Apr 2, 2012 11:10 PM, Brendan Conoboy b...@redhat.com mailto:b...@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- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
