| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod | |
|---|---|---|
| Hi everybody; who's around? | ||
| * nirik is here. | ||
| j-rod | here | |
| jwb | here | |
| * rwmjones here | ||
| rwmjones | dan'll be around in a minute | |
| dwmw2_PDX | yay | |
| * notting is here | ||
| bpepple | ok, let's get started... | |
| --- bpepple has changed the topic to: FESCo-Meeting -- MinGW - all | ||
| rwmjones | ready when you are | |
| bpepple | Alright, where do we want to start on this? | |
| packaging guidelines have gone to the packaging committee, right? | ||
| rwmjones | FPC approved the guidelines but wanted mingw to be changed to mingw32 throughout (eg. package names etc) | |
| I have done that change to the guidelines | ||
| and I'm rebuilding the packages themselves | ||
| links: | ||
| http://fedoraproject.org/wiki/PackagingDrafts/MinGW | ||
| http://hg.et.redhat.com/misc/fedora-mingw--devel/ | ||
| dwmw2_PDX | ew, hg. | |
| rwmjones | almost through rebuilding the packages with the new names, at which point I'll upload them to a repo for people to try out | |
| jwb | ok, i have two questions | |
| 1) does anyone think the Board's suggestion of a separate repo is a huge deal and is a show stopper? | ||
| dwmw2_PDX | we're not expecting users in general to interact with hg, are we? That's just a detail for you folks internally? | |
| * jds2001 here sorry | ||
| dwmw2_PDX | no, the separate repo is a fine plan | |
| rwmjones | dwmw2_PDX, no no, Hg is just our development repo until we get packages into cvs | |
| dwmw2_PDX | ok, cool. | |
| nirik | I don't understand the seperate repo, but I don't think its a blocker if others are happy with it. | |
| rwmjones | well, hang about, the separate repo is extra burden for no real benefit | |
| dwmw2_PDX | is it really much extra burden? | |
| * nirik nods at rwmjones | ||
| rwmjones | have a look at the list of files (before renaming): http://www.annexia.org/tmp/mingw/00-files.txt | |
| that's an x86-64 build, but it takes 211MB | ||
| most packages are noarch | ||
| dwmw2_PDX | I like putting the compilers themselves (the .arch packages) into Fedora properly | |
| and the Win32 binarys/dlls into the separate repo | ||
| notting | rwmjones: i asked this a few weeks ago... have we verified that the packages build correctly no matter which fedora arch the noarch build gets shuffled off to? | |
| spoleeba | dwmw2_PDX, for clarification that was the board mandate in a nutshull | |
| dwmw2_PDX | the win32 environment is completely separate from, and independent of, the Fedora environment. | |
| rwmjones | notting, I've only got i386 & x86-64, and I'm building for both right now, so I can tell you later | |
| No5251, however they really ought to, otherwise there's a problem in the cross-compiler itself | ||
| jwb | spoleeba, we have been told it was not a mandate from the board | |
| spoleeba, by other board members. | ||
| spoleeba | jwb, the seperate repo? | |
| rwmjones | dwmw2_PDX, it's not really separate because we need them for further package builds | |
| * nirik is confused by the board minutes. | ||
| jwb | spoleeba, correct | |
| spoleeba | jwb, they havent told me that | |
| jwb | spoleeba, we were told it was a suggestion | |
| bpepple | spoleeba: correct, spot said it was only a suggestion. | |
| notting | rwmjones: also, are you intending to support x86_64-pc-mingw64 (i.e., win64)? | |
| spoleeba | bpepple, i asked for clarification....on the board list...i got crickets | |
| bpepple, the minutes have the mandate | ||
| nirik | http://fedoraproject.org/wiki/Board/Meetings/2008-07-15 "Leave technical details and implementation to FESCo" and "Board supports such an effort as long as it is self contained and separated from the main package respository " | |
| jds2001 | it has been made clear that there is no mandate. | |
| spot | as the person who suggested it, it is simply a suggestion. | |
| jds2001 | the details are up to FESCo. | |
| rwmjones | notting, if we could do it, but our advice has been that the upstream mingw64 project (which is separate from mingw) isn't very functional ... HOWEVER I've not tried it | |
| dwmw2_PDX | rwmjones: so you want all these identical noarch packages to be available in all current versions of Fedora, on all architectures? | |
| (and likewise, by extension, we'd do that kind of thing for other cross-targets?) | ||
| rwmjones | dwmw2_PDX, not sure I understand the question ... they are noarch packages because they have no (build) architecture | |
| however they do have a specific host/target architecture, which is i686-pc-mingw32 | ||
| spoleeba | spot, the minutes as worded..are stronger than a suggestion | |
| rwmjones | as you might gather, rpm doesn't really understand x-compilation | |
| spot | spoleeba: yes, but as the person who made the suggestion and was present at the meeting, the minutes do not do it justice. | |
| dwmw2_PDX | if you want to put them in the "Fedora" repository, you end up putting them in about 6 repositories right now. F8/i386 F8/ppc F8/x86_64 F9/i386 F9/ppc F9/x86_64 | |
| spoleeba | spot, did you ack the minutes? | |
| spot | i intended it as a suggestion, FESCo is the responsible party for working out the details | |
| rwmjones | dwmw2_PDX, ok .. I thought that noarch packages would be shared | |
| dwmw2_PDX | all identical packages, because they have no arch dependency or even Fedora-version dependency | |
| spoleeba | spot, did you reply back to my board-list post asking for clarification? | |
| jwb | dwmw2_PDX, if they are identical, then hardlinks will suffice.. | |
| spot | spoleeba: i replied to the FESCo trac ticket | |
| dwmw2_PDX | well, they can be -- but it seems to make more sense to have their own repo. | |
| you could even install the .repo file when you install the toolchain package. | ||
| jds2001 | spoleeba: none of that makes a difference right now. Take the bickering elsewhere. Spot has made himself abundantly clear. | |
| rwmjones | dwmw2_PDX, so what's the benefit to doing that? | |
| dwmw2_PDX | and it lets you have a 'mingw32 development repo' where you update all your win32 libraries, decoupled from the Fedora version | |
| nirik | dwmw2_PDX: they would need to have repos for all the releases they support right? | |
| spoleeba | spot, i dont like being set up a spokesman for what i take to be the board's consensus opinion on the matter..then told after the fact by another board member that the minutes are wrong and my own personal efforts at getting clarification from other board members go unanswered | |
| dwmw2_PDX | nirik: no, that's the point. | |
| they're the _same_ for all the releases. | ||
| jwb | dwmw2_PDX, erm... no? | |
| nirik | dwmw2_PDX: so, this saves space? why not do something like this for all fedora noarch packages? | |
| spot | spoleeba: i dont think you were set up to be anything. if anything, you volunteered. apologies if i stopped reading your email after the 3rd page. | |
| spoleeba | jds2001, are you saying that spot's opinion should be taken for the board's concensus? | |
| rwmjones | dwmw2_PDX, ok so I misunderstood you ... the noarch packages are only the same within a Fedora release | |
| dwmw2_PDX, we aim to follow 'native' package versions in each release | ||
| dwmw2_PDX | rwmjones: so F8 builds different win32 binaries to F9? | |
| rwmjones | dwmw2_PDX, and have indeed written a tool to do this | |
| dwmw2_PDX, well, they'd be different versions, assuming the native F8 & F9 packages were different | ||
| dwmw2_PDX | ah, I see. | |
| notting | rwmjones: given the package guideline about stripping, that implies you can't build native and mingw in the same package | |
| jwb | right | |
| rwmjones | sorry for the confusion there | |
| dwmw2_PDX | mea culpa. I think I did know that before. | |
| jds2001 | spoleeba: should I take yours as the Board's consensus? Not trying to be argumenative here, and I'd suggest we really just drop this until later. | |
| rwmjones | notting, it would seem so ... if you set __strip for one, it might not work for the other | |
| dwmw2_PDX | it also matches what we'll want to do with cross-building for Fedora. | |
| jwb | dwmw2_PDX, yes | |
| i've said that a lot :) | ||
| dwmw2_PDX | so let's not think about this as a one-off for mingw32 -- let's think about what we want to do in the general case | |
| * jwb sighs | ||
| jwb | do you not read the lists? | |
| nirik | rwmjones: I have some questions as well... 1) does this build/work on ppc? whats the target there? ppc windows(does it even exist?), 2) what .exe's are in the fedora packages? could there be a guideline to limit those/eliminate them? | |
| dwmw2_PDX | do we want our F9/i386 repo to include F9-version packages for _all_ architectures, including windows? | |
| or do we want the various targets to each be in their own repo? | ||
| rwmjones | nirik, (1) I don't know, but it certainly ought to (very big bug if not) (2) there are some .exe's ... let me find you a link to explain that | |
| notting | rwmjones: is your plan to do day-by-day tracking of your dependent packages, week-by-week, or occasional-and-one-final-build-before-freeze? | |
| jds2001 | ppc windows doesnt exist :) | |
| spoleeba | jds2001, i think you should read the minutes | |
| jwb | jds2001, it did at one point | |
| spoleeba | jds2001, and if there are questions you should aks for clarification in fab | |
| dwmw2_PDX | in all cases (including x86_64), it would target Win32/i386. | |
| jds2001 | jwb: i thought that was Alpha | |
| dwmw2_PDX | jds2001: there was ppc too. | |
| ppcle, iirc. | ||
| jwb | there was a ppc laptop at some point that ran windows i thought | |
| it sucked | ||
| rwmjones | the target in this case would always be win32 on i686, at least until upstream get somewhere with win64 | |
| nirik | rwmjones: and on x86_64 also win32? | |
| rwmjones | nirik, https://fedorahosted.org/fesco/ticket/7#comment:12 | |
| rwmjones | nirik, yes absolutely | |
| nirik, the host compiler shouldn't make any difference, since it's a cross-compiler | ||
| dwmw2_PDX | I think it makes sense for all the _output_ of cross-toolchains to be in separate repositories per _target_ architecture, rather than all bundled in with the Fedora repo. | |
| jwb | dwmw2_PDX, that does make some sense | |
| which is why i'm not opposed to a separate repo | ||
| nirik | rwmjones: right. I think we need some kind of guideline about that... but I don't know how to word it. Ban all non native exes from being in the fedora packages? that would affect the debug case you have... how can we say 'no end user exe's' ? | |
| dwmw2_PDX | I don't think the separate repo should be problematic in any way. | |
| rwmjones | dwmw2_PDX, I'd still be wondering what the purpose of this is .. the space requirements are not that big, like one big openoffice binary | |
| nirik, yes that needs to be said | ||
| nirik, but wording has also escaped me | ||
| dwmw2_PDX | rwmjones: a clean separation. A repository which stands alone and can be used one its own. | |
| spoleeba | nirik, can you draw a line on how an exe is to be used? | |
| nirik | spoleeba: yeah, but that gets into murky intent... ;( | |
| rwmjones | nirik, "libraries and development tools" is a key phrase in the mission | |
| spoleeba | nirik, that's pretty precedent setting...we make no effort now with submission to guage intent | |
| nirik | spoleeba: right, which is why I don't like it/don't think it would ever fly. | |
| spoleeba | nirik, if i thought we could defend that sort of policy and say this exe is good and that one is not...id have suggested it | |
| * dgilmore shows up | ||
| dwmw2_PDX | if it's in a separate repository, do we still really need to ban executables? | |
| rwmjones | nirik, actually https://fedorahosted.org/fesco/ticket/7#comment:13 is the comment i meant | |
| nirik | so perhaps we could say no exes ? sorry for debugging, but someone could compile their own? | |
| rwmjones | nirik, no that's a really bad idea - see the comment above | |
| nirik | rwmjones: yeah, read down. ;) | |
| rwmjones | it'll cause developers to have to rebuild the RPMs | |
| nirik | dwmw2_PDX: ok, so then you could have anything in that seperate repo? firefox.exe ? | |
| dwmw2_PDX | do we have any specific reason to forbid that? | |
| jwb | hell yes | |
| rwmjones | there's just no point building it | |
| spoleeba | dwmw2_PDX, 'need'? we'd feel less pressure to restrict the payloads in any way | |
| rwmjones | it's not of any use to Fedora developers | |
| and Windows users can get it from mozilla.org | ||
| not that they would know what to do with an rpm anyway | ||
| nirik | dwmw2_PDX: I would guess the support burden? re-building all these apps and supporting them running on windows? | |
| dwmw2_PDX | of course there's plenty of stuff that doesn't make sense to include | |
| the question is whether we actually need to _ban_ them | ||
| spoleeba | nirik, support burden would work itself out..without policy restrictions | |
| jwb | you could phrase it as "FESCo approved binaries" | |
| rwmjones | but virsh.exe is necessary for fedora developers ... they need to give it to the windows users as a debug tool | |
| nirik | dwmw2_PDX: so what is your argument for seperate repo again? space savings? seperation of a functional area of packages? | |
| spoleeba | nirik, but to construct a ban of any sort...presupposes the value of the executable | |
| dwmw2_PDX | nirik: a clean separation of a functional area of packages. This repository stands alone -- it doesn't depend on anything else in Fedora (except maybe a toolchain), and nothing in Fedora really depends on it. | |
| dgilmore | rwmjones: but virsh.exe will be you building and distributing via libvirt.org | |
| dwmw2_PDX | if I want to be running F9, but working on the rawhide mingw stuff, I can just point my _mingw_ yum repo at rawhide and all is well | |
| nirik | dwmw2_PDX: so what makes this different than any other package grouping? less dependencies on the rest of the collection? | |
| dgilmore | rwmjones: everything needed to build that on fedora though should be ok for fedora inclusion | |
| rwmjones | dgilmore, but it's stupid for us (loyal Fedora developers) to have to rebuild these packages. That defeats the point and need for them being in Fedora in the first place for us (as libvirt devs) | |
| dwmw2_PDX | nirik: Think about where we're going with this, ideally, in the long run. We will be building _every_ package in Fedora, for _every_ architecture supported by Fedora. And then some more. | |
| this is jsut the start | ||
| dgilmore | rwmjones: your not getting me | |
| rwmjones | dwmw2_PDX, we will not be building every package in Fedora for mingw ... for a start it's completely impossible to do that | |
| dwmw2_PDX | I don't think we want _all_ that explosion of packages in the core repo. I think we want a separate repo for each target | |
| rwmjones | the amount of work is astronomical | |
| it's taken us weeks to build just 20 packages, because they have to be individually ported by hand | ||
| nirik | dwmw2_PDX: so would this replace secondary arches is what you are saying? | |
| dwmw2_PDX | rwmjones: when we do cross-builds for other linux architectures, we're likely to build at lot more than you do for mingw32 | |
| dgilmore | rwmjones: the tools and DLL's to build what your going to ship is ok for inclusion in fedora | |
| dwmw2_PDX | nirik: no, that's a separate thing | |
| notting | nirik: i don't know that it will, but i don't necessarily think this is the right way for someone to do, say, an arm port | |
| dgilmore | rwmjones: but final products that windows end users will use have no place in fedora | |
| rwmjones | dgilmore, but we'll still end up rebuilding libvirt RPM | |
| dgilmore | rwmjones: when i asked you the other week you clearly said that the product you give to windows users will not be built in fedora | |
| nirik | right, it's same arch, different os tools in fedora. The question is can it be just the fedora packages needed to do the development (as the mingw people clearly want) or is it all packages for that os eventually? | |
| rwmjones | dgilmore, that argument can apply to the whole of mingw though | |
| jds2001 | dgilmore: I think that we're on the same page, sorry to have been silent in this discussion - I am in a $DAYJOB meeting at the same time :) | |
| dgilmore | rwmjones: any .exe really has no place in fedora. | |
| rwmjones | dgilmore, I meant that we won't be giving them RPMs, because obviously they'll be no use ... also we will build some end-user applications (specifically virt-manager) | |
| nirik | if it's just the development tools, I think a seperate repo isn't needed. If it's going to be everything in the world, it probibly should be. | |
| dwmw2_PDX | dgilmore: you could make the same argument about .DLL. And I'd still disagree. | |
| spoleeba | nirik, i really have to apologize for making such heavy use of the 2ndary arch comparison meme | |
| dgilmore | rwmjones: yes. im happy to have the tools to do taht in fedora | |
| jds2001 | rwmjones: this is different than what I understood then. | |
| spoleeba | nirik, its colored everyone's thinking too much | |
| jds2001 | I'm happy to have tools to rebuild virt-manager, but not the virt-manager binary itself. | |
| nirik | spoleeba: perhaps. It does add confusion... oh well, such is life. ;) | |
| dgilmore | rwmjones: but building of .exe files for windows users consumption is up to you to build and distribute on your | |
| own | ||
| rwmjones | let's step back here ... we want to help fedora developers build without needing Windows ... if they have to rebuild the whole toolchain to get virsh.exe, then we haven't done that | |
| we've put some stupid barrier in the way because of some tiny executable | ||
| jds2001 | is virsh.exe not part of virt-manager proper? | |
| * jds2001 may be misinformed here. | ||
| rwmjones | jds2001, no it's part of libvirt | |
| nirik | why would they need to rebuild the toolchain? don't we provide the toolchain for them to do this? | |
| dwmw2_PDX | can't you just rename it to virsh.dll and it'll run anyway? :) | |
| dgilmore | rwmjones: when i asked you previously if you intended to build end user windows apps in fedora you said that no you did not. just the supporting infrastucture | |
| rwmjones | dgilmore, virsh.exe is a debug tool, it's not an application | |
| virsh = libvirt shell | ||
| dwmw2_PDX | virsh.scr | |
| rwmjones | it's 255K | |
| dgilmore | rwmjones: yes and thats for you to build on your own | |
| rwmjones: i dont care how big or small it is | ||
| nirik | rwmjones: so why does that need to be in a fedora package? how would a windows user install it from rpm? | |
| spoleeba | how do we distinguish an application exe from a tool exe? | |
| rwmjones | but we're failing because let's take gnutls ... CERTTOOL.EXE is a debug tool, small, etc. Now the Fedora developer wants to ship this, he's got to rebuild the gnutls RPM which was already built in Fedora. | |
| * jds2001 thinks that if I as a Fedora user can make usefulness of it, then it belongs in Fedora. | ||
| rwmjones | so we've failed him | |
| jds2001 | if I can't execute it, it doesn't. | |
| dwmw2_PDX | spoleeba: better question: why would we, FESCo, _want_ to distinguish between them rather than leaving it to the folks working on mingw32 to do what they feel is appropriate? | |
| rwmjones | you can execute it fine under wine | |
| nirik | either: a) we ban all .exe files b) seperate repo, and we don't care about exe files... | |
| rwmjones | all of these programs run from the command line if you have wine installed | |
| dwmw2_PDX | separate repo, and don't care about exe files, really. | |
| rwmjones | you don't even need to type 'wine ...', the kernel finds the right interpreter for them | |
| dgilmore | rwmjones: building libjpeg dlls thats an ok use. cross compilers, thats ok. building something intended for end user consumtion thats not fedora. thats where you are on your own to build and distribute. | |
| dwmw2_PDX | for mostly separate reasons, but still. | |
| spoleeba | dwmw2_PDX, i can think of many reasons as to why fesco would want to try...but ive gone way past my comfort level in making suggestions :-> | |
| rwmjones | are we helping fedora developers here or not? | |
| jwb | dgilmore, you mean like the livecd creator tool that lmacken worked on? | |
| * nirik is still wondering how someone on win32 would deal with a rpm download? | ||
| nirik | jwb: is that available as an rpm in fedora? | |
| rwmjones | nirik, there is no issue there ... no one is talking about building Fedora RPMs for the sole purpose of giving them to Windows users | |
| dgilmore | jwb: i say thats something that should not be built in koji as a rpm. but can be built on the developers workstation. | |
| dwmw2_PDX | What's the actual question being put to FESCo? Whether, and how, we allow this project to move forward? | |
| dgilmore | jwb: but the tools and dll's needed to build it are ok | |
| spoleeba | nirik, well... if you had a fedora run data server...exporting a filesystem via samba.... | |
| jwb | nirik, it was an illustration on how windows only binaries _could_ be beneficial for Fedora. not everything is black and white | |
| dwmw2_PDX | I propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora. | |
| rwmjones | jwb, the full NSIS binary is only available as a windows binary running under wine ... although with a lot of effort on monday I ported most of Debian's work on building a native NSIS | |
| jwb | i'm +1 to dwmw2_PDX's proposal | |
| sort of | ||
| :) | ||
| rwmjones | I'm ok with dwmw2_PDX's proposal, but have no vote so ... | |
| spoleeba | jwb, im pretty confident there are more tools out there like the livecd creator that we could brand as Fedora but would run on windows, we just havent thought of them yet | |
| jds2001 | +1 to dwmw2_PDX | |
| bpepple | +1 to dwmw2_PDX proposal. | |
| j-rod | +1 here too | |
| jwb | dwmw2_PDX, can we assume you're a +1 to your own proposal? | |
| spoleeba | dwmw2_PDX, how tight of a definition are you applying to toolchain? | |
| dgilmore | dwmw2_PDX: to implement that cleanly we would need to add new tags/targets to koji, a new series of cvs branches. new bodhi update streams. new branches on the mirrors. an update to fedora-release to have the new repo(is it enabled or disabled by default) | |
| * notting is wary of the effect that 'take this subset of koji built packages and put them somewhere else' is going to have on the releng tools | ||
| dgilmore | dwmw2_PDX: i.e. alot of work by people not involved in this discussion | |
| dwmw2_PDX | spoleeba: yeah. I haven't been drinking yet | |
| jwb | dgilmore, why a new series of cvs branches? | |
| dwmw2_PDX | spoleeba: I was thinking "the packages which aren't noarch" when I said toolchain | |
| spoleeba | dwmw2_PDX, you might need to be okay with the toolchain including a few dlls and exes | |
| dgilmore | -1 to dwmw2_PDX's propposal. it has alot of variables that need looking at before we can say yeah or nope to it | |
| dwmw2_PDX | spoleeba: like my i686-linux-gnu-gcc package already does, you mean ? | |
| dgilmore | jwb: because maintaining lists of this goes here and that goes there leads to fail | |
| jwb | um, no | |
| spoleeba | dwmw2_PDX, maybe..ive given up trying to understand what I mean | |
| dwmw2_PDX | :) | |
| spoleeba | dwmw2_PDX, your proposal is an implied limit of some kind as to what goes into the main repository | |
| dwmw2_PDX, just be sure YOU know what you mean to limit :-> | ||
| dwmw2_PDX | dgilmore: we don't need a fedora-release update. The toolchain package itself could contain the repo file. | |
| spoleeba | dwmw2_PDX, so you dont have to come back and argue over it..after the fact | |
| * rwmjones still wonders, why a separate repo for a few hundred MB? | ||
| jwb | dwmw2_PDX, except we have guidelines against that | |
| dgilmore | dwmw2_PDX: we dont allow other packages to ship repo definitions | |
| rwmjones | why not a separate repo for perl packages? | |
| dwmw2_PDX | do we? | |
| jwb | rwmjones, it's not a minGW specific thing | |
| rwmjones, think of it this way: today MinGW. tomorrow: cross-toolchains for ppc, sparc, arm, mips, etc | ||
| rwmjones | jwb, those are secondary architectures, nothing like mingw at all | |
| jwb | rwmjones, few hundred MiB today, few GiB tomorrow | |
| dgilmore | dwmw2_PDX: we banned it because someone got there package in shipped a .repo file and then updated the package elsewhere | |
| jwb | rwmjones, horsepoo. they are not | |
| dwmw2_PDX | spoleeba: I don't mean it as a limit -- I mean it as a clean separation. And it's "stuff which doesn't run on the host, but is packaged as noarch because it's just fodder for a cross-compiler" | |
| spoleeba | jwb, my understanding..talking to others..is that the arm stuff is even more complicated..since its a family of targets | |
| dwmw2_PDX, just trying to make sure you are clear | ||
| rwmjones | jwb, you're talking about embedded sparc systems or something? | |
| dwmw2_PDX | dgilmore: that kind of behaviour is bad. Fixing the wording of the guidelines to say "no repo files pointing at things other than official fedora repos" would be reasonable though, right? | |
| jwb | rwmjones, you can build cross toolchains _just like_ MinGW is that target different architectures | |
| rwmjones, sure "embedded" if you want to call it that | ||
| notting | rwmjones: i don't really buy that argument. they're all cross-compilers. mingw is cross-arch+host, the others are just cross-arch | |
| rwmjones | jwb, you mean Windows on sparc? | |
| dgilmore | rwmjones: there are non-fedora embededed use cases for mips, arm, ppc | |
| dwmw2_PDX | rwmjones: no, Linux on sparc,i386,arm,ppc,etc. | |
| jwb | rwmjones, no i mean cross compiling. has nothing to do with windows or target arch | |
| rwmjones | jwb, this is not just a matter of recompiling .. each package is patched and ported individually ... seriously hard work | |
| dwmw2_PDX | all with their _own_ set of hundreds of .noarch. packages, for each of the packages in Fedora. | |
| rwmjones | jwb, for example I spent 3 days porting gcalctool (and still haven't finished) | |
| jwb | rwmjones, i do it all day long. it's what i'm paid to do. i know that | |
| spoleeba | gcalctool..isnt that an end user app? | |
| rwmjones | dwmw2_PDX, this is a misconception (as far as mingw is concerned anyway) ... there's just no way you could do that | |
| gcalctool was ported because I wanted to blog about how to do ti | ||
| it | ||
| jwb | rwmjones, you are NOT getting it | |
| dwmw2_PDX | rwmjones: it's just harder for Windows. | |
| rwmjones | nothing to do with fedora | |
| dwmw2_PDX | rwmjones: but the principle is the same | |
| jwb | rwmjones, everything you are proposing for MinGW is applicable to _any_ cross compiling toolchain | |
| dwmw2_PDX | rwmjones: we do not want to set a precedent for how we handle cross-compiler output/libraries based on the limitations of Windows | |
| jwb | as dwmw2_PDX says, the principle is the same | |
| rwmjones | dwmw2_PDX, no, it really is totally different .. you have to port POSIX code to work against the Win32 native API for a start | |
| dwmw2_PDX | we want to get it right for _all_ cross-toolchain stuff. | |
| jwb | rwmjones, no, it's not different | |
| dwmw2_PDX | rwmjones: that's an implementation detail which isn't particularly relevant here | |
| rwmjones | it's not a recompile | |
| dgilmore | rwmjones: your not getting the point we are trying to make | |
| dwmw2_PDX | it's "How do we package and ship" this stuff | |
| not "how much does the developers brain hurt when they work on it" | ||
| dgilmore | rwmjones: we want to setup a framework for any combination of cross compiling | |
| rwmjones | but what are these other platforms ... ok, there's some embedded platforms (the arm guys). What else? | |
| dwmw2_PDX | dgilmore: will you change your -1 if we modify the proposal to be dependent on rel-eng feedback? If rel-eng run away screaming we'll revisit it? | |
| dgilmore | rwmjones: the possibilities are endless | |
| dwmw2_PDX | I don't _think_ it should actually be that hard to do, but let's ask for a coherent response from someone who actually knows? | |
| dgilmore | dwmw2_PDX: it needs infrastructure input as well as releng | |
| dwmw2_PDX | I think that's what I meant | |
| rwmjones | what does that even mean? mingw targets a specific platform with its own completely different API | |
| jwb | rwmjones, damnit man. listen. this has nothing to do with mingw | |
| dwmw2_PDX | rwmjones: these other platforms are Fedora on _all_ CPU architecutres | |
| for example, on my shinybook I want to build for i386 Fedora | ||
| jwb | mingw is a subset, an example, of cross compling | |
| jwb | FESCo needs to get it right for cross compiling as a whole | |
| jds2001 | jwb: +1 | |
| bpepple | ok, I think the vote for dwmw2_PDX proposal was five '+1', and two '-1'. I think dwmw2_PDX suggestion to get rel-eng & infrastructure teams feedback on the feasibility of it makes sense. | |
| * nirik999 lost network there for a bit. ;( | ||
| jds2001 | absolutely. | |
| spoleeba | dwmw2_PDX, i poked infrastructure a bit... i was told koji isnt a problem | |
| * nirik999 wishes he knew what the proposal was. oh well. | ||
| dwmw2_PDX | in practice that was going to be the case anyway -- if we decide something and the folks who have to implement it say "fuck off", then that's a fairly effective veto :) | |
| jds2001 | if they run the other way, we can revisit. | |
| spoleeba | dwmw2_PDX, im not sure if rel_eng would have a problem | |
| dgilmore | spoleeba: i want you to stay out of this from now on please. | |
| dwmw2_PDX | but I'm happy with adding that wording to the proposal :) | |
| jds2001 | 18:37 < dwmw2_PDX> I propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora. | |
| 18:37 < dwmw2_PDX> I propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora. | ||
| 18:37 < dwmw2_PDX> I propose that we don't make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora. | ||
| gack | ||
| dgilmore | jds2001: we get it | |
| spoleeba | dgilmore, i was just informing dwmw2_PDX as to what ive been told | |
| jds2001 | sorry, there's the proposal three times nirik999 :) | |
| dgilmore: sorry, stupid terminal. | ||
| nirik999 | ok, sounds sane... except how can you tell the target stuff from the toolchain? | |
| dgilmore | add to that that we need to check with releng and infrastructure. and ill give it a +1 | |
| nirik999: different tags/targets in koji different cvs branches | ||
| dwmw2_PDX | Proposal #2: Let them apply common sense on .exe files, and please don't ship end-user binaries. Ask infrastructure team to report on our plan to put the target (noarch) stuff into a separate repository. Unless that's prohibitively hard, that's what we want. | |
| bpepple | +1 | |
| dwmw2_PDX | nirik: toolchain is the .arch.rpm packages, of which there are probably only one or two (binutils and gcc). | |
| dgilmore | dwmw2_PDX: thet target noarch stuff really needs to be kept in its own playhouse | |
| rwmjones | so can we get infrastructure to do something to https://fedorahosted.org/fedora-infrastructure/ticket/807 and https://fedorahosted.org/fedora-infrastructure/ticket/689 | |
| dwmw2_PDX | nirik: the rest is the rest. The .noarch packages. | |
| dgilmore: 'own playhouse' != 'separate repository' ? | ||
| nirik999 | ok, I will +1 that... | |
| * jds2001 read 'own playhouse | ||
| jds2001 | == separate repo | |
| dgilmore | dwmw2_PDX: own playhouse == seperate repo, cvs branches, build targets, bodhi stream, | |
| notting | well, if they're its own koji build target, that makes some of the releng side easier (i.e., don't need to deal with mash/pungi bits to pull it out of the release trees) | |
| dwmw2_PDX | well, I only really care about the separate repo part; for the rest you're probably right but I'm happy with whatever's easiest with our infrastructure | |
| dgilmore | notting: that would lead to madness if its not kept completely seperate | |
| nirik999 | so would the mingw32-release package be in fedora? or only in the sperate repo | |
| dwmw2_PDX | separate like secondary arches? How much can we re-use the stuff that builds for secondary arches? Or don't we want to go there? | |
| rwmjones | is that end of mingw topic? I kind of need to go soon ... | |
| rwmjones | nirik, we'd very much like it to be available immediately for developers | |
| dwmw2_PDX | nirik: I think we should relax the no-new-repo-files guideline to say 'no new repo files except for official Fedora repos' | |
| nirik | dwmw2_PDX: yeah, or fesco approved or something, thats fine. | |
| dwmw2_PDX | yeah | |
| that was kind of the point in it in the first place anyway, right? | ||
| jwb | mostly | |
| dgilmore | nirik: its contents would need to be in fedora-release to comply with our guidelines | |
| jwb | rwmjones, we realize it's a bit unfair to MinGW to try and make generic cross compiling decisions. but you're blazing a path here, and you've done a damn good job so far :) | |
| rwmjones | if the repo goes in fedora-release then there's no way we could "sabotage" it, or any concerns like that | |
| dwmw2_PDX | dgilmore: I am proposing that we fix the guidelines. | |
| nirik | dgilmore: ok, that should be fine too to me... whatever we can work out. | |
| dwmw2_PDX | rwmjones: I don't think we need to worry about sabotage. We know where you live. | |
| rwmjones | dwmw2_PDX, indeed you do | |
| dgilmore | dwmw2_PDX: id rather see it in fedora-release and disabled | |
| dwmw2_PDX | dgilmore: ok, I suppose. | |
| is there any way for a separate package to _enable_ it? | ||
| rwmjones | but why disabled? | |
| notting | dwmw2_PDX: not sanely, no | |
| nirik | in any case shall we move on for the last 2 minutes of our meeting slot? ;) | |
| rwmjones | that just hinders us for no reason | |
| dgilmore | rwmjones: because most fedora users wont care for it | |
| dwmw2_PDX | rwmjones: because we don't want 'yum update' to go fetch all the headers for _all_ cross-architectures every time. | |
| again, thinking of the precedent we're setting for the general case. | ||
| jds2001 | dgilmore: most fedora users dont care for my icelandic-fonts, either :) | |
| rwmjones | any windows developers wanting to give up windows, or any fedora devs asked to build windows programs (a frequent request) will be | |
| bpepple | nirik: actually our time slot has been changed to 2 hours, since we were constantly going over our time. ;) | |
| dgilmore | rwmjones: its easy to enable a repo | |
| dwmw2_PDX | dgilmore: it's a good point though; I would prefer to find some way that installing the mingw32-compiler package would automatically enable the ming32-target repo. | |
| rwmjones | dgilmore, it's an extra step ... another thing to explain ... it means that 'yum search' won't show this wonderful new capability etc | |
| dwmw2_PDX | either shipping the repo file with that package and relaxing our guidelines, or some way to make it _enabled_ | |
| nirik | dwmw2_PDX: propose some guidelines change to the packaging folks? | |
| dgilmore | dwmw2_PDX: you could do some sed magic in %post i guess | |
| rwmjones | this is a valuable way to enable fedora developers to stay on fedora | |
| dwmw2_PDX | dgilmore: that might work, but how does it work with fedora-release upgrades? | |
| as long as it works sanely, that could be done. | ||
| dgilmore | dwmw2_PDX: they are marked as config files | |
| though there has been instances where we have forced new configs in | ||
| dwmw2_PDX | I think the sed thing in %post is a good start. | |
| dwmw2_PDX | we can argue about the 'no repos' guideline later. | |
| nirik | I think it might be easier to get the guideline changed and have a mingw32-release, then it can be pulled in/installed however you like. | |
| dwmw2_PDX | true | |
| rwmjones | nirik, there is already a mingw32-filesystem package | |
| which does the base stuff | ||
| dwmw2_PDX | since that way we don't have to modify fedora-release. | |
| what are the disadvantages of just fixing the guideline? | ||
| rwmjones | might be timely to look at: http://fedoraproject.org/wiki/PackagingDrafts/MinGW | |
| dgilmore | dwmw2_PDX: more people asking for exceptions | |
| dwmw2_PDX | dgilmore: depends how we phrase it. | |
| dwmw2_PDX | no exceptions, just a guideline of "no repository files except pointing to official Fedora repositories" | |
| jwb | move on? | |
| dwmw2_PDX | do we want to make that guideline change a proposal and vote on it? | |
| or wait for the infra team to respond before we settle that detail? | ||
| bpepple | dwmw2_PDX: how about we wait for the infra team to respond. | |
| jwb | shouldn't we wait to see if we have to destroy the proposal that is causing the new proposal to surface? | |
| dwmw2_PDX | ok | |
| bpepple | ok, if there's nothing else lets move on to a couple of feature items. | |
| --- bpepple has changed the topic to: FESCO-Meeting - FEATURES - all | ||
| rwmjones | ok I have to leave now, but if anyone has any questions please don't hesitate to mail rjones/redhat_dot_com | |
| bpepple | rwmjones: thanks for all your work on this. | |
| alright, poelcat wanted us to look at a couple of features that haven't had any response. | ||
| https://fedoraproject.org/wiki/Features/EFI | ||
| poelcat | bpepple: i'm told an update is "coming" | |
| bpepple | ah, so let's hold off then. | |
| poelcat | that is all I know | |
| bpepple | poelcat: is the haskell feature also being updated? | |
| poelcat | nothing | |
| well no response | ||
| bpepple | ok, so this is our policy for dropping features: https://fedoraproject.org/wiki/Features/Policy/Dropping | |
| jwb | sounds like a candidate for the latter | |
| wwoods | loupgaroublond: ping - isn't haskell yours? | |
| jwb | .fas Yaakov | |
| zodbot | jwb: ynemoy 'Yaakov Meir Nemoy' <loupgaroublond@gmail.com> | |
| jwb | seems so | |
| bpepple | jwb: yeah, based on the feature page, this looks like a feature we should drop based on the information available. | |
| * nirik nods. | ||
| bpepple | does anyone disagree with that? | |
| * bpepple listens to the crickets. | ||
| jwb | it's bumped | |
| bpepple | ok, the next features we need to determine if they are in a testable state. | |
| https://fedoraproject.org/wiki/Features/HDTVEnhancements | ||
| nirik | ajax: ? | |
| ajax | getting there. | |
| ajax | i have the mailing list set up now, which is fortunate | |
| and i have a working parser, it's just not in the server quite yet. | ||
| it'll probably miss the beta compose though | ||
| jwb | sounds like not testable | |
| ajax | that's a fair assessment, yeah | |
| * jwb sheds a tear | ||
| dgilmore | ajax: so F11 now | |
| ajax | well, or just unannounced in f10 | |
| i mean, i'm still going to do it, it just might not be something to advertise | ||
| jwb | yeah | |
| dgilmore | ajax: ok, so we punt and yell about it for F11 | |
| ajax | wfm | |
| dgilmore | it just might happen to be there and working before hand | |
| bpepple | ok, the next feature is: https://fedoraproject.org/wiki/Features/KernelModesetting | |
| jwb | this one seems testable | |
| nirik | just the intel part is fail, right? | |
| dgilmore | ajax: is this you also? | |
| ajax | well, my team, but sure. | |
| notting | certainly appears testable | |
| jwb | is intel still fail? | |
| ajax | intel kms is known to be quite broken, and is shipping disabled for the beta | |
| and will probably continue to be in final, but might be stable enough for users to turn on by hand by then | ||
| dgilmore | how would i go about testing ati? | |
| ajax | boot. | |
| jwb | so, really, it's only on for ATI. and only for x86 at that | |
| ajax | if you see a shiny splash, yay, it works. | |
| if you see something else, it's broken. | ||
| dgilmore | ok | |
| i get the bar going across the screen | ||
| ajax | r300 through r600 only | |
| j-rod | works on one of my boxes, ship it! | |
| ajax | excuse me: through r500 | |
| jwb | dgilmore, the bar? | |
| ajax | jwb: he means the text progress bar | |
| jwb | if you mean the cylon looking thing, i think you need to update plymouth | |
| ajax | this: | |
| bpepple | alright, so this feature is testable, though with a caveat in regard to intel. anything else in regard to this feature? or should we move on? | |
| ajax | http://ajax.fedorapeople.org/text-boot-hotness.ogg | |
| dgilmore | ATI Technologies Inc Mobilitiy Radeon HD 3600 Series | |
| ajax | dgilmore: is an r600. too new, sorry. | |
| dgilmore | thats in my desktop | |
| ajax | working on it though. | |
| dgilmore | not sure its actuallya mobility card | |
| ajax: :) | ||
| ajax | bpepple: if "testable" is the metric, i think we're done here. | |
| bpepple | ajax: agreed. | |
| jwb | i will note that krh fixed r400 yesterday | |
| bpepple | Ok, the next feature is: https://fedoraproject.org/wiki/Features/Sugar | |
| jwb | so there is progress even | |
| bpepple | I know there has been some progress on this, but I'm not sure it's testable yet. | |
| dgilmore | jeremy: ping | |
| jeremy | dgilmore: pong | |
| dgilmore | jeremy: suagr feature | |
| it should be testable right | ||
| bpepple | is it in a testable state for the beta? | |
| wwoods | It's testable. You can install sugar-desktop at installtime, it starts like a normal desktop session | |
| dgilmore | you can yum install and log into sugar | |
| dwmw2_PDX | cool | |
| wwoods | there are no packaged activities, AFAIK | |
| so you can't actually *do* anything | ||
| but the framework is there | ||
| dwmw2_PDX | the page says an initial set of activities is packaged | |
| dgilmore | wwoods: there is journal and a bunch in review i think | |
| dwmw2_PDX | but waiting for pyxpcom -- is there progress on that? | |
| dgilmore | dwmw2_PDX: last i poked at that it was blocking on caillon working out if we could even ship it | |
| jeremy | there are packaged activities now | |
| they'll be in rawhide as soon as we unfreeze | ||
| dwmw2_PDX | cool | |
| jeremy | which, since they're not on any of the media other than everything, means they're essentially "in the beta" :-) | |
| bpepple | jeremy: works for me. | |
| jeremy | pyxpcom will be in the post-security-update xulrunner build according to what caillon told me this afternoon | |
| (and then all the bits for browse will get packaged up pretty quickly) | ||
| dwmw2_PDX | ok | |
| bpepple | ok, anything else in regard to Sugar? Otherwise let's move on. | |
| dgilmore | jeremy: :) | |
| bpepple | Feature: https://fedoraproject.org/wiki/Features/LXDE | |
| dgilmore | jeremy: so its likely to land in time for F-10? | |
| wwoods | out of curiosity, does sugar have its own way of installing new activities? or should testers fire up a terminal (or other session) to do so? | |
| dgilmore | wwoods: you can install via journal and browse | |
| jeremy | dgilmore: yep, it will | |
| nirik | for lxde, sadly 2 packages are still in review... so I think it needs to go to 11 (ha ha). | |
| dgilmore | though it puts them ins ~/Activities | |
| jeremy | wwoods: you can install them through the journal. but the Fedora Way (tm) will be via 'yum install'. just as the Fedora Way (tm) of installing perl modules isn't perl -MCPAN | |
| dgilmore | so not testable | |
| bpepple | nirik: do we know what's holding up those 2 reviews? | |
| nirik | unless those packages aren't critical for testing, but I think they are. | |
| wwoods | (for the record, I've been slowly attempting to test features: https://fedoraproject.org/wiki/QA/TestResults/Fedora10Features/Beta) | |
| nirik | bpepple: I glanced at them and there was a lot of discussion about what should be a subpackage, etc. | |
| wwoods | none of the LXDE packages are even built, AFAICT | |
| nirik | wwoods: some are, but thats because they were already in... like openbox is the windowmanager. | |
| notting | well, if they try and add the comps group now, they'll be breaking the string freeze | |
| nirik | yeah, so I think this should move back to next release... if they get it sooner great, we can trumpet it in 11 | |
| bpepple | nirik: +1 | |
| notting | +1 | |
| bpepple | anyone disagree with pushing LXDE, otherwise we can move on. | |
| ok, I had a question whether this was testable or not: https://fedoraproject.org/wiki/Features/GStreamer_dependencies_in_RPM | ||
| Did the packagekit piece get written yet? | ||
| nirik | well, it could be tested via yum too, right? | |
| wwoods | the PK bits are built but not in Beta | |
| so they are technically testable right now | ||
| notting | any reason not? | |
| bpepple | wwoods: cool. that's what I was wondering. thanks. | |
| notting | (in beta) | |
| wwoods | notting: already late, don't want to risk futher destabilization, will be available at day-0 | |
| bpepple | ok, is there anything else in features folks want to discuss, otherwise we can start to wrap up for today. | |
| stickster | bpepple: I have one issue -- meeting time. | |
| bpepple | stickster: floors yours. | |
| jwb | stickster, what about it? | |
| --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| stickster | The point of using #fedora-meeting is that it's centrally located and well-attended. | |
| dgilmore | bpepple: election | |
| stickster | People know to go there, and can log other meetings. | |
| * jwb waits... | ||
| stickster | Speaking as a Fedora mgr type -- Originally Docs moved out to another room during a week when things were running late here (as they do) | |
| dgilmore | stickster: you would like fesco to change its meeting time? | |
| stickster | Would it be troublesome for FESCo to shift an hour earlier, and do a two-hour meeting? | |
| * dwmw2_PDX has only just got used to this one. Almost. At least I get the day right now | ||
| dwmw2_PDX | an hour earlier I could handle. Two hours less so. | |
| stickster | heh | |
| jwb | hour earlier is probably fine | |
| with me anyway | ||
| dwmw2_PDX | when I'm at home, an hour earlier would actually be good | |
| stickster | Just consider it. That's all | |
| dgilmore | an hour earlier should work for me | |
| bpepple | stickster: I think Kick & j-rod weren't about to attend earlier. | |
| s/about/able/ | ||
| * stickster & | ||
| dwmw2_PDX | we went through this before, didn't we? | |
| is there any reason things should have changed? | ||
| dgilmore | perhaps we should move to #fedora-meeting2 | |
| j-rod | I'm fine with Wednesdays an hour earlier, my big issue is Tues/Thurs being no good | |
| notting | well, i can't really speak for Kick and j-rod in their absence. take it to e-mail? | |
| bpepple | dgilmore: I'm fine with moving to #fedora-meeting2, though I though quaid told me the doc team was moving there. | |
| * j-rod just wandered back, sorry... | ||
| dgilmore | bpepple: it sounds like they would prefer to be here | |
| dwmw2_PDX | notting: yeah, let's ask | |
| dgilmore | bpepple: im willing to accomodate them on that | |
| bpepple | how about we discuss this on the mailing list, and see if we can work on a solution? | |
| stickster | +1, no need to spin wheels here, just wanted to put it in for consideration. | |
| quaid | here's the problem, there is no critical mass in meeting-1 | |
| (not using -2 etc. yet) | ||
| there are ~100 ppl here, and ~9 there | ||
| until we can get everyone here to also lurk there, it makes the secondary mtg room nonviable | ||
| I'm happy for Docs to move | ||
| but we need that room to be useful, at least as many lurkers as there are in #fedora-docs :D | ||
| bpepple | Maybe if we move to meeting-2, that will get more folks to hang out there. | |
| quaid | sure, gravity draw rule | |
| it worked for this channel | ||
| dwmw2_PDX | am I missing the point? Why do we need lurkers? | |
| the channels are logged, right? | ||
| dgilmore | quaid: i think im in meeting 2 never knew 1 existed | |
| quaid | dwmw2_PDX: that is the point of a common meeting channel | |
| jwb | dwmw2_PDX, no? | |
| quaid | dwmw2_PDX: one can watch as many meetings without lurking in multiple sub-channels | |
| dgilmore: hmm | ||
| dgilmore: we set something on the meeting channel wiki page | ||
| bpepple | anyway, let's discuss this on the mailing list and work out a solution. | |
| * quaid back to his meeting on #fedora-docs | ||
| dgilmore | bpepple: election | |
| dgilmore | we should get cracking on it | |
| bpepple | yeah. | |
| One question is whether we should have our election at the same time as the board, since with the release delay we've got a small window to run it before the holidays. | ||
| dgilmore | bpepple: im +1 for that | |
| bpepple | I'm +1 for that also. | |
| dgilmore | bpepple: i think it could help turn out if both are at once | |
| abadger1999 | That was always my hope. Now that G has written election software that can handle that I'm all for it :-) | |
| jwb | how do you handle people that are running for both, but will drop from one if they are elected to the other? | |
| bpepple | The only downside if for the folks that one to be on the board or FESCo but not both. | |
| * bpepple see jwb beat him to it. | ||
| notting | have them state their preference? | |
| bpepple | notting: that's what G and I discussed last night. | |
| jwb | can you be a bit more verbose on that? | |
| dgilmore | bpepple: i would say they pick what they really want and run for it | |
| jwb | sorry, no | |
| dgilmore | FESCo or the board should not been seen as consolation prizes | |
| dgilmore | if you run for both you shuld be prepared to do both | |
| bpepple | dgilmore: I tend to think the same thing. | |
| jwb | that's a fairly silly statement, considering we've never held the elections at the same time before | |
| so there was always a choice | ||
| jwb | you could run for the Board, and if that didn't work, you could still run for FESCo to try and make an impact | |
| jwb | it's not a consolation prize | |
| dgilmore | that was a side effect of the old elections app | |
| jwb | that doesn't make it any less valid | |
| dgilmore | where we could only run one election at a time | |
| dgilmore | jwb: you can still have an effect without being on FESCo or the board | |
| dgilmore | I know at leats oncein the past we wanted to run them at the same time but couldnt | |
| jwb | this is sort of a waste of time to discuss. people that want to do one or the other will just run for both and drop whichever they like least if they are elected to both | |
| (paraphrasing) | ||
| dgilmore | I propose that we say yes we want to have the FESCo election at teh same time as the fedora board election | |
| jwb | 0 | |
| bpepple | +1 | |
| jds2001 | sorry i stepped away for quite some time for a meeting :/ | |
| +1 | ||
| dwmw2_PDX | -1 | |
| dgilmore | jwb: there is nothing we can do to stop people declining a position if they are elected. and we can accept that | |
| dwmw2_PDX: whats your objection? | ||
| dwmw2_PDX | the same as jwb's | |
| jwb | dgilmore, you need at least 9 people in FESCo to make it a valid body. if you only have 9 candidates to start with, and one drops, you have to figure something out | |
| dwmw2_PDX | it's not about being a consolation prize | |
| notting | dgilmore: +1 | |
| dgilmore | jwb: well this election of for 4 people | |
| * bpepple notes we've got a hard stop in 3 minutes, so we might need to take this to the mailing list, since we don't need to decide this today. | ||
| dgilmore | jwb: the next is for 5 | |
| jds2001 | jwb: we have procedures for that, though. | |
| nirik | +1 on proposal | |
| dwmw2_PDX | it's about wanting to help out and/or be involved -- and I don't think people will want to do _both_ (even if we want them to) | |
| dgilmore | if 4 people nominate then we dont have elections they are all accepted | |
| bpepple | alright, I see five '+1' and one '-1', and one '0'. | |
| dwmw2_PDX | I suppose if people drop out within days of the election we can just pick the next person on the list, who just missed out. | |
| so it doens't have to be _so_ much of an issue for it. | ||
| j-rod | 0 here too | |
| dwmw2_PDX | I can revise to 0 too. | |
| jds2001 | our procedure actually calls for that, dwmw2_PDX | |
| dgilmore | dwmw2_PDX: its happened like that in the past | |
| dwmw2_PDX | ok then | |
| I'm ambivalent then | ||
| jwb | jds2001, our procedure does not account for having exactly the number needed, and then having one drop | |
| but whatever | ||
| bpepple | ok, so that give use five '+1', and three '0'. we've decided to hold the election at the same time as the board. | |
| dwmw2_PDX | jwb: if we have more candidates than positions, it's OK | |
| jwb | dwmw2_PDX, right | |
| bpepple | ok, we're out of time, so we have to call an end to the meeting. | |
| dgilmore | jwb: if we have the exact number there is no election. | |
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!