| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| rwmjones | FESCO people: Dan Berrange is going to be 10-15 mins late so requests that you discuss non-MinGW stuff first | |
|---|---|---|
| bpepple | rwmjones: that was the plan anyhow, since we've got a couple of topics that need to be decided today. | |
| FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, kick_, jds2001, j-rod | ||
| Hi everybody; who's around? | ||
| * notting is here | ||
| * jwb is here | ||
| nirik is here. | ||
| dgilmore | ||
| bpepple | ok, while we're waiting for more people to show up, let's get started with the first topic. | |
| * jds2001 semi-here - $DAYJOB scheduled a con-call on top of this | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- Why was CVS force tag changed w/o FESCo, rel-eng approval? - jwb | ||
| jwb | ok | |
| jwb | first, is there anyone in FESCo (or otherwise i guess) that thinks the change itself is the wrong thing to do? | |
| dgilmore | i removed it because it should never been added | |
| * jds2001 agrees with dgilmore | ||
| notting | jwb: given the easy workaround, i'm not sure what good removing it does | |
| nirik | I think removing it should also remove TAG_OPTS and such. | |
| * nirik thinks it should be removed, but we should come up with a way to remove it totally... | ||
| dgilmore | notting: it makes it not blatant and easy to do | |
| jwb | nirik, hold on that | |
| so i don't hear anyone that's saying the removal was really wrong | ||
| spoleeba | dgilmore, was that the underlying motivation... i know ive been stumping for this for a while..but i never got consensus developed to do it | |
| dgilmore | notting: but its still trivial. so at the least the developer has put some thought into it | |
| nirik | not much. TAG_OPTS=-F is in the Makefile.common, on several wiki pages about updating packages, etc. | |
| spoleeba | dgilmore, mmcgrath mentioned legal issues in the discussion thread as a motivation | |
| bpepple | spoleeba: right, gpl compliance. | |
| jwb | that's a bit of a red herring | |
| spoleeba | bpepple, lets be clear....afaict..this one action doesnt actually solve the problem | |
| jwb | correct | |
| dgilmore | spoleeba: while there may be some legitimate uses to force a tag. if it was done after a build was completed and shipped we could not reproduce the srpm if we needed to. at least not easily | |
| jwb | nor does additionally removing TAG_OPTS | |
| spoleeba | bpepple, matt and I looked at this specifically...and we never got concensus to do anything about it | |
| dgilmore | spoleeba: so my motivation was to not make it completely trivial and simple | |
| spoleeba | dgilmore, right.. the compliance issues mmcgrath mentioned were not part of the motivation afaik? | |
| jwb | dgilmore, and that's a valid motivation. i think one that most can even get behind. which brings me to the main point for this topic... | |
| jwb | in the future, changes that impact users really need to be discussed first so that we have some semblance of FESCo actually being a functional elected body that represents said users | |
| dgilmore | spoleeba: compliance issues are why i dont want it to be simple to do | |
| bpepple | jwb: +1 | |
| * nirik nods | ||
| dgilmore | jwb: every change to Makefile.common effects users in some way | |
| jds2001 | how often does it functionally change? | |
| jwb | that's hyperbole. comments don't | |
| spoleeba | dgilmore, this doesnt actually meet the bar for compliance needs. I just want to make sure people dont walk away from this action thinking that we've met that burden with regard to being able to rely on cvs tags | |
| dgilmore | jwb: and ive never run those changes by FESCo in tha past. they have always been run by the buildsys list | |
| * nirik would suggest that if something impacts the maintainer workflow significantly, it should be run by fesco. | ||
| dgilmore | jwb: the change that added force-tag and test-srpm was not run by anyone anywhere | |
| jwb | dgilmore, two wrongs does not make a right | |
| dgilmore | it was quietly added because someone inside RH complained that Red Hats and Fedora's were different | |
| jwb | i don't really care for the purposes of this discussion | |
| dgilmore | jwb: sure. | |
| jwb | so | |
| we've had vocal feedback on this | ||
| i think a simple vote is in order | ||
| dgilmore | your saying you want FESCo to control Makefile.common | |
| jwb | i'm saying FESCo was elected to represent our developer and user communities, and changes that impact them should at least be run past FESCo | |
| bpepple | dgilmore: maybe when functionality is being removed. | |
| nirik | when the impact is 'significant' ? | |
| * jds2001 wonders if had this run past FESCo, would the results have been any different? | ||
| jwb | jds2001, why does that matter? | |
| spoleeba | nirik, hard to know for sure..until you remove the functionality :-> | |
| dgilmore | jds2001: doubtful | |
| jwb: whats your proposal? | ||
| nirik | spoleeba: I think everyone would agree this was significant and would change some people's workflow... | |
| jwb | all in favor of removing force-tag and TAG_OPTS=-F? | |
| spoleeba | nirik, a significant number of people? | |
| dgilmore | nirik: i honestly figured it would have never been used. | |
| jwb | spoleeba, what does that matter | |
| ok, going to call a vote here | ||
| spoleeba | jwb, just saying that 'significant' is non-obvious judgement and should be avoided as a test condition which latches oversight | |
| dgilmore | notting: we we make cvs send emails on tag creation? | |
| nirik | number shouldn't matter I wouldn't think... I would just say minor changes that don't impact the maintainer workflow are fine, but if there are changes in it, we should get fesco to look/approve. | |
| dgilmore | jwb: +1 | |
| notting | dgilmore: that sounds bad... | |
| jwb | Proposal: remove force-tag and TAG_OPTS=-F | |
| dgilmore | notting: i meant can we? | |
| nirik | jwb: of course you can still manually do it with cvs... that doesn't solve the problem. | |
| notting | dgilmore: not sure | |
| dgilmore | notting: it would give an idea how often its actually done? | |
| jwb | nirik, yes i know. would you like me to put up the counter-proposal for voting instead? | |
| dgilmore | i know ive forced a tag when ive forgoten a patch | |
| * jwb sighs | ||
| dgilmore | but ive done it by calling cvs tag -F | |
| nirik | jwb: just noting that. | |
| dgilmore | jwb: +! to your proposal | |
| +1 | ||
| bpepple | +1 | |
| jds2001 | +1 to the proposal of removing force-tag and TAG_OPTS=-F | |
| nirik | +1 | |
| jwb | dwmw2_gone, notting | |
| notting | 0 | |
| jwb | Kick_, j-rod? | |
| * j-rod straggles in | ||
| bpepple | jwb: I see four "+1" not including you. | |
| dgilmore | j-rod: 13:14 < jwb> Proposal: remove force-tag and TAG_OPTS=-F | |
| jwb | j-rod, we're voting on removing force-tag and TAG_OPTS=-F from Makefile.common | |
| jwb | bpepple, i haven't voted yet | |
| j-rod | now me, I was actually happy to see that added, because I occasionally screw the pooch and forget to cvs add a patch or something... | |
| j-rod | what's the argument against it? | |
| jwb | j-rod, can still use 'cvs tag -f' | |
| j-rod | yeah, I know, but m | |
| nirik | but you shouldn't. ;) | |
| j-rod | ...but 'make force-tag' is just so nice and easy | |
| jwb | argument against it is that it makes it easier to mess with tags for builds that are already done | |
| abadger1999 | spoleeba: We can definitely make all tagging operations immutable. Making just some immutable would need some planning but could be done as well. | |
| spoleeba | abadger1999, for a later discussion | |
| abadger1999 | s/tagging operations/tags/ | |
| nirik | abadger1999: that would be great if it was easy to do. | |
| j-rod | I'm inclined to think that if someone wants to screw with already tagged bits, they're not going to be deterred by no 'make force-tag' if they can still 'cvs tag -F' manually | |
| dgilmore | I do want to get to a paoint where make tag checks that patches and source are commited. its just not going to be easy to implement | |
| abadger1999 | I'll make sure to run it by FESCo first :-) | |
| jds2001 | +1 to immutable tags if it's easy | |
| abadger1999: :) | ||
| jwb | jds2001, wait on that | |
| abadger1999, thanks | ||
| * jds2001 waits :) | ||
| jwb | j-rod, so are you +1 for removing it or -1? | |
| j-rod | I think I'm -1 | |
| * bpepple notes we've already spent 20 minutes on this and there is still a lot on the schedule. | ||
| jwb | as am i. -1 | |
| jwb | bpepple, i think that's all the votes you are going to get today | |
| bpepple | ok, so that give us four '+1', and two '-1', and one abstaining. | |
| dgilmore | 4 +1, 2 -1 and a 0 | |
| j-rod | I'd rather see tags that have been successfully built made immutable | |
| jwb | j-rod, me too | |
| anyway, that's a different day | ||
| jwb | bpepple, i think that constitutes a removal is passed | |
| bpepple | jwb: agreed. | |
| anyone have anything else to add? | ||
| * j-rod wonders idly why evo forgot to remind him about the meeting today... | ||
| bpepple | or should we move on? | |
| moving on then.... | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- FTBFS pending deletion - https://bugzilla.redhat.com/showdependencytree.cgi?id=440169 - all | ||
| bpepple | mdomsh wanted me to mention this. | |
| spoleeba | crap bugzilla is down | |
| jwb | he has it down to 70 packages now | |
| bpepple | I believe they are planned on being removed shortly after the beta. | |
| jwb | i asked about a package dep tree for those 70 and i never saw it | |
| * nirik wonders if we are telling dgilmore to revert the force-tag change, or leave it as it is now? | ||
| bpepple | I glanced at the list and didn't see anything that popped out as a major problem. | |
| jwb | nirik, leave it and remove TAG_OPTS=-F | |
| jds2001 | jwb: a script was provided | |
| jwb | jds2001, yes but mdomsch said he had the results of that script | |
| nirik | jwb: no, the vote didn't pass, so what does that mean? nothing? revert back to before? | |
| jwb | nirik, the vote _did_ pass | |
| nirik | oh... sorry, I got confused by newer smaller fesco. Ok. don't mind me... moving on. | |
| jwb | :) | |
| it just barely passed | ||
| notting | i'd like to see the results of said script as well | |
| nirik | I'm fine with nuking those 68 packages... unless a serious dep chain happens... perhaps we block them in koji now, then in a week or something go and dead.package them (to allow someone to easily pick up one that causes them pain) | |
| jwb | that sounds like a good plan | |
| notting | +1 | |
| bpepple | nirik: sounds good. | |
| ok, anyone have any more questions about the FTBFS deletions, or should we move on? | ||
| --- bpepple has changed the topic to: FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Presto | ||
| jds2001 | +1 | |
| to the FTBFS, that is :) | ||
| bpepple | jds2001: thanks for the clarification. ;) | |
| jwb | lmacken, around/ | |
| * dgilmore is working to get his fixed | ||
| dgilmore | his FTBFS that is. I did get it building with gcc-4.3.0 but it fails with 4.3.1 and 4.3.2 | |
| jwb | so i have a question on Presto | |
| says it's going to be done in Bodhi now instead... | ||
| nirik | is this the last meeting for features? isn't freeze tomorrow? | |
| bpepple | nirik: yes. | |
| jwb | which is all well and good, but doesn't account for rawhide... | |
| nor can it be tested in rawhide as a result... | ||
| nirik | good point. | |
| j-rod | what if its deployed only for updates-testing first? | |
| happy medium between no rawhide testing and going straight into use for updates | ||
| dgilmore | problem with Presto is that aFAIK know one has done any work to integrate it into koji and bodhi | |
| notting | that doesn't help the 'how do you test it before release'? | |
| jwb | dgilmore, it says it's 90% done and it's going into bodhi | |
| dgilmore | lmacken: ^^^ | |
| nirik | I guess mash needs to do it for rawhide? | |
| jwb | nirik, yeah likely | |
| notting, how feasible is that? | ||
| nirik | (but thats going to be a different path, so testing that isn't going to entirely test all the bits for stable releases) | |
| notting | jwb: ... by feature freeze? not. | |
| bpepple | so, it sounds like this feature is a non-starter at the moment based on the info we currently got. | |
| jwb | so yeah... i have no idea where to go on this one. i would hate to kill it (again), but the testing thing seems pretty important... | |
| that sucks | ||
| notting | there's not really any detail as to *how* it's going to fit into the bodhi push process | |
| dgilmore | i cant give it a go ahead. | |
| lmacken | sorry guys, I'm back | |
| bpepple | ok, I think we're at a point to vote on this. Can I get a quick show of hands? | |
| d'oh! spoke to soon. | ||
| jwb | lmacken, how exactly is bodhi going to accommodate deltarpms, and how are we supposed to get test coverage before the release happens? | |
| dgilmore | I would maybe say we punt this to F-11 but have part of its plan getting deltra RPMS generated for F-10 so it can be tested for a release | |
| jwb | lmacken, have really good answers because it's not looking good for the feature as it stands right now... | |
| lmacken | jwb: so we have a few different places we can throw them. Last night I wrote some code in bodhi to spit them out. However, it was quite obvious that the presto code was not very well tested, so I may hit some issues down the line | |
| jwb | not inspiring confidence... | |
| :) | ||
| lmacken | the most I can do is try and get it working so people can test.... | |
| what else do you need ? | ||
| jwb | how can they test it? | |
| without actually deploying it to bodhi... | ||
| lmacken | we'll have to throw the deltas somewhere else then ? | |
| dgilmore | lmacken: thoughts on making deltas for F-10 updates. but not having it enabled by default. It would give us a release for propper testing | |
| lmacken | why not deploy them to bodhi though? they will live fine alongside the existing data | |
| nirik | lmacken: how does rawhide do deltas? | |
| dgilmore | nirik: i honestly dont think it can | |
| lmacken | notting: but yes, valid point. We could just add this churn to the end of the push process, or we can try it do it async somehow. The former would be the easiest at the moment | |
| nirik: it doesn't | ||
| dgilmore | i guess you could do them to yesterdays | |
| nirik | yeah, it would need to be figured... how many to keep and against what. | |
| yesterday and last alpha/beta/test1 | ||
| lmacken | so getting it to the point where we can test this is crucial... so how do we go about doing that? slip the DRPMS our to our master mirror only? | |
| dgilmore | all eats disk and bandwidth | |
| lmacken | also, what deltas do we want to generate ? | |
| last update->new update? gold->first update? gold->recent update ? | ||
| * nirik is pretty nervous of this, given feature freeze is... tomorrow. | ||
| dgilmore | im thinking we could offer it as a Tech Preview for F-10 | |
| jwb | wtf is a Tech Preview? all of Fedora is a Tech Preview | |
| dgilmore | give it 4 months of better real world testing | |
| jwb: advertise its there this is how you enable it. but it might be broken at times | ||
| dgilmore | not enable it by default | |
| but help it get ready for F-11 | ||
| jwb | if we can do that without causing bodhi to crash in a horrible flaming pile of rpm bits, i might be ok with that | |
| spoleeba | dgilmore, you could even put the repo definition in a seperate package not in the main release package to further isolate it from..uninformed use | |
| jds2001 | dgilmore: that sounds like a happy medium. What are the infrastructure requirements? | |
| jwb | guarantees on that happening? | |
| lmacken | dgilmore: sounds sane to me | |
| jwb | lmacken, how much longer does this make the push process? | |
| bpepple | dgilmore: yeah, I think that is about the only way we can get any type of decent testing done. | |
| lmacken | jwb: I don't know for sure. I need to touch base with jdieter, who seems to have already written a multithreaded xmlrpc-based delta generator.... | |
| he says it's about 2 hours to generate deltas for rawhide | ||
| jwb | push is already long... | |
| lmacken | I've only tested my code at a small scale. i was planning doing a lot more testing and hacking today | |
| yeah | ||
| dgilmore | jds2001: bodhi would need to learn to create delta rpms and deltarpm repos. other than that disk on the primary mirrors. which is precious | |
| bpepple | ok, so we're going to push this feature back to F11, but enable testing during F10. | |
| lmacken | dgilmore: it already knows how to do that. now we just need to figure out which deltas we want, and where we want to store them | |
| dgilmore | bpepple: i would propose that | |
| dgilmore | lmacken: :) | |
| lmacken | but yeah, it's obvious that a lot of this presto code is untested, so I would feel comfortable not rushing to get this stuff out the door, and doing it the Right Way. | |
| dgilmore | so voting on punting to F11 but enabling better testing in F10, advertisng with caveats. | |
| bpepple | +1 | |
| dgilmore | +1 from me | |
| notting | +1 to dgilmore | |
| nirik | +1 | |
| jds2001 | +1 from me | |
| j-rod | +1 | |
| jwb | +1 | |
| spoleeba | lmacken, for testing... can you delta only specific packages instead of the full update collection to conserve space? | |
| lmacken | spoleeba: that's what I've been doing for my own testing | |
| bpepple | ok, that seven '+1' to dgilmore's proposal. | |
| spoleeba | lmacken, it would make it easier to make a resource commitment now...while we figure out what to do about a resource commitment for F11 | |
| bpepple | anyone have anything to add? Otherwise we should move on. | |
| ok, moving on...... | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- Appliance Tools Feature questions - https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00841.html - f13 | ||
| bpepple | f13 brought up some good questions regarding this that we missed. | |
| bryan_kearney | f13: did you see email to rel-eng on this topic? | |
| f13 | bryan_kearney: I saw it go by, haven't read it in depth yet, other fires this morning :/ | |
| bryan_kearney | bryan_kearney: understood | |
| bryan_kearney | f13: may I summarize it here? | |
| f13 | sure | |
| bryan_kearney | the feature does discuss an image be hosted on the spin page | |
| The hope was to use the appliance-tools which are tested as part of F10 | ||
| the path would be similar to the kickstart -> livecd -> iso path | ||
| with the following exceptions: | ||
| different tool (appliance-tool) which is basd off of livecd-tools | ||
| output format is (tar instead of iso) | ||
| The former (we assumed) was low risk because appliance-tools is dereived from livecd-tools | ||
| the latter we assumed low risk becuase the spins page already hosts tarballs | ||
| but to your point, it was not discusssed in last meeting | ||
| notting | the spins page already hosts tarballs? | |
| jwb | no... | |
| nirik | so what is the approval/vetting/testing process for the appliance images? | |
| bryan_kearney | videos, cclive content | |
| jds2001 | What FESCo approved at that meeting was touting that appliance-tools was available in Fedora, and that you could create appliances from it. I don't believe that we discussed anything that could happen with those appliances. | |
| nirik | same as for spins? something else? | |
| * nirik nods at jds2001. Thats what I saw in the feature page as well. | ||
| bryan_kearney | jds2001: we did not, but it was in the doc at that time.. hence discussing it here | |
| f13 | # Requires hosting an AOS kickstart file in the kickstart pool | |
| # Requires hosting a binary image on http://spins.fedoraproject.org/ | ||
| f13 | # May require tooling changes to build/host an appliance image rather than a livecd iso? (appliance image = tar.gz which contains a binary disk image and meta-date used to launch the image.) | |
| bryan_kearney | nirik: the content went through the spins sig | |
| quaid | ! | |
| Fedora Docs is meeting in #fedora-meeting-1 in five minutes | ||
| this is a permanent move | ||
| jwb | DOOM | |
| bryan_kearney | nirik: content is derived from the kickstart file there in same way that the iso is derived from the ks | |
| quaid | FESCo should expand to take the whole two hours | |
| quaid | <eof> | |
| jwb | oh, un-doom | |
| bpepple | quaid: thanks. | |
| quaid | yeah! | |
| carry on ... | ||
| dgilmore | f13: i see no problem with hosting the specs for different appliances. and the tools | |
| nirik | +1 dgilmore | |
| jds2001 | +1 dgilmore | |
| dgilmore | I dont want to go hosting and QA'ing 100 different appliances | |
| jwb | i'd like someone to QA my fscking dishwasher | |
| bryan_kearney | dgilmore: please note, this was a request for a single appliance only | |
| jwb | oh wait... | |
| nirik | I would even be ok with that, but it has to have a process. You can't just say "thincrust" ok, it's all done forever. | |
| bryan_kearney | dgilmore: I would assume any new appliance would follow the same process as a spin does tday | |
| dgilmore | bryan_kearney: t me an appliance image would be a very specialised thing. | |
| bryan_kearney | nirik: we followed the spin process | |
| dgilmore | bryan_kearney: say an IDS appliance | |
| nirik | bryan_kearney: ok, cool. Thats what I wanted to hear. | |
| dgilmore | already to go. | |
| bryan_kearney | dgilmore: understand that this could lead to rpolifieration, but I would expect anything like an IDS appliance to follow the spin process as it exists at the time | |
| f13 | why wouldn't we turn all of our existing spins into appliances as well? | |
| or why wouldn't we offer our appliances as traditional iso spins? | ||
| notting | what's the purpose of hosting a aos *image* in any case? wouldn't someone who wanted to deploy an appliance never use the stock disk image? | |
| f13 | also, what kind of documentation do we have to provide users as to how to consume the tarball? | |
| nirik | notting: looks like the one they have is generic/test/base/example right now. | |
| zodbot | Announcement from my owner (stickster): Fedora Docs meeting is at UTC 1900 in #fedora-meeting-1 <-- note channel change | |
| bryan_kearney | f13: I think that live images and spins serve slightly different purposes.. but it could be done | |
| notting: to provide a base upon which to build up derivitive appliance | ||
| nirik: it is | ||
| notting | bryan_kearney: right, 'build upon'. which implies using the source files, and not the image itself | |
| dgilmore | notting: :) | |
| bryan_kearney | notting: build upon which includes adding packages | |
| danpb_ltop | notting: yeah, shipping pre-built appliances is more like demo-ware | |
| notting: not something you'd put into production | ||
| notting | danpb_ltop: and with the base one... is there anything really to demo? (look, it boots) | |
| danpb_ltop | notting: having a library of appliance recipes (eg, the kickstart file) is probably the most interesting thing | |
| dgilmore | danpb_ltop: which is what i honestly thought was all we are touting. and im ok with that | |
| danpb_ltop | notting: well i expect that projects building stuff off fedora would end up being the ones actuall shipping useful appliances | |
| bryan_kearney | this provides an easy(er) path to loading the appliance into the virt-tools | |
| f13 | basically I got a little concerned when I noticed yesterday that releng was expected to produce something we've never seen before | |
| f13 | and since we're going to do the featured spins at beta time, that gives us very little time to get familiar with the software and process | |
| bryan_kearney | f13: that was my mistake, i assumed I needed TM approval before approaching rel-eng | |
| f13 | and it seemed FESCo overlooked that | |
| dgilmore | f13: i think we all missed that part | |
| f13 | nod | |
| bryan_kearney | f13: FWIW the tools went through a fedora test day already | |
| f13 | that is good to know | |
| * jlaska gives a thumbs up for appliance-creator | ||
| f13 | I expect the tools work, I hope you can understand my concern though. | |
| dgilmore | bryan_kearney: could we change it to just hosting kickstarts. and advertising that you can and how to create appliances using fedora | |
| f13 | 11th hour surprises are !fun | |
| bryan_kearney | f13: I do | |
| dgilmore: I would prefer to attempt to keep the current scope, and back off if there are issues | ||
| jwb | when using language, the bitwise not might be more appropriate as opposed to the logical not. | |
| * jwb stfu | ||
| bryan_kearney | we (the thincrust team) will be happy to pitch in to mitigate the issues which f13 brought up | |
| f13 | bryan_kearney: do you have any documents prepared for end users who would be consuming the tarball, and for QA who would be expected somewhat to validate them? | |
| dgilmore | ill defer to f13 here. but id rather nota dd to rel-eng's workload | |
| f13 | how many other spins have been approved for f10? | |
| bryan_kearney | f13: only what was done for the test day, but they would have to be modified for this | |
| jds2001 | f13: we relegated them to teh spins SIG...we're not doing "spins as features" | |
| bryan_kearney | f13: We could put them together today | |
| f13 | jds2001: *strangle* | |
| jds2001 | :/ | |
| f13 | jds2001: they are still features, and they still require coordination and communication. | |
| jds2001 | right | |
| f13 | and releng needs to know what's expected of us to produce, just like QA needs to know, docs needs to know, our users need to know... | |
| jds2001 | I guess maybe we need to revisit that process if it's broken. | |
| f13 | I'm getting really tired of the "pass the job around" game. | |
| nirik | the spins process is confusing. ;( | |
| spoleeba | nirik, my fault | |
| bryan_kearney | spoleeba: OT.. but I can write down what I think it is, having gone through it | |
| f13 | poelcat: ping; perhaps you can help out here. Do you have a list of approved spins at this point? | |
| spoleeba | bryan_kearney, i certainly expected to see feedback at some point | |
| bpepple | f13: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080730#Spins | |
| jds2001 | FEL comes to mind. | |
| poelcat | f13: funny you should ask... i was debating yesterday how to classify them | |
| f13 | poelcat: if you ask me, they're freaking features. | |
| they smell like features, they look like features, they talk like features, why are we calling them something else? | ||
| * poelcat is trying to track a concall... not able to discuss now, but glad to in the future | ||
| f13 | poelcat: roger. | |
| nirik | part of the issue is that they have to get board approval and rel-eng... and it's unclear to me in the process when those happen... | |
| f13 | so at this point, I'm not even sure what spins RELENg is supposed to either look at or produce. | |
| and we're on the hook to produce them... next week. | ||
| nirik: I honestly think they can be done in parallel, as checkboxes | ||
| f13 | because releng/board/fesco are all looking at different aspects of it | |
| nirik | ok, the process could be clarified then on that. | |
| dgilmore | f13: ill help create spins as needed | |
| spoleeba | nirik, releng is the most restrictive approval... you can get trademark approval but not be part of a "release" | |
| * nirik isn't sure what to say on the Xfce spin testing plan... | ||
| bryan_kearney | f13: The steps for rel_eng would be very similar to https://fedoraproject.org/wiki/Features/ApplianceTools#Test_Plan | |
| f13: We would need to augment and add steps for the user. | ||
| f13 | bryan_kearney: to be fair, that's a larger issue for spins in general. We (releng) don't do much but drop the output into a torrent set. We sort of rely on the spin owner to do any sort of advertising/messaging/etc... It's a bigger problem to solve | |
| bryan_kearney: something I'd expect the spins sig to work on | ||
| releng sort of draws the line at "we'll produce the bits and make them available" | ||
| spoleeba | nirik, and the original spin policy was delibrately left pretty open in terms of what releng decides to do as a process to choose what is release-worthy | |
| nirik | if thats the case, then does rel-eng need to approve spins? if they are just making the bits and making them available? | |
| in any case, we are drifting here... | ||
| f13 | nirik: sorry, thats on the production side. On the approval side, we're just sanity checking the contents of the configs | |
| f13 | nirik: and trying to make sure we don't overload ourselves with work by trying to do too many spins, although that may fall under FESCo | |
| spoleeba | f13, im okay with releng making a firm statement as to how many spins they are willing to deal with each release cycle | |
| f13 | right now (if I understand it correctly) the board sees releng as the technical protectors of the Fedora trademark | |
| until we get different trademark guidelines that's likely not going to change | ||
| rwmjones | are we going to get on to mingw? | |
| bpepple | rwmjones: that's the next topic on the schedule. | |
| f13 | I think FESCo needs to decide whether they want to see an appliance image as part of the AOS feature or not | |
| f13 | rel-eng is not opposed necessarily to doing it, but I still want to get a grasp on how many other spins we'll be doing | |
| bryan_kearney | as one of the feature owners, I would like to see this as part of the feature | |
| notting | stepping back ... do we actually have a list of spins at this point? | |
| bpepple | notting: I'm aware of three. Math, Games, Xfce. | |
| http://fedoraproject.org/wiki/Features/EducationMathSpin | ||
| http://fedoraproject.org/wiki/Features/GamesSpin | ||
| http://fedoraproject.org/wiki/Features/XfceSpin | ||
| f13 | no FEL, Developer this time around? | |
| bpepple | f13: I can't find any feature pages for those. | |
| f13 | k | |
| adding AOS would I think be the limit as far as releng resources are concerned | ||
| abadger1999 | FEL was active... I remember they had to keep moving the Feature Page around to make it match up with something wiki-wise | |
| spoleeba | f13, we'll need to get a good feel for what the releng manpower limit and communicated for F11 runup. So that the Spin SIG can prioritize which test plans they tackle | |
| bpepple | ah, I missed one other spin: http://fedoraproject.org/wiki/Features/BrOffice.orgSpin | |
| f13 | spoleeba: releng manpower isn't the only resource. There is QA, there is disk space, there is bandwidth, there is time needed for machines to produce the output, etc... | |
| oof. | ||
| so 5 traditional spins, plus one newcomer. | ||
| how much space is this all going to take? | ||
| spoleeba | f13, the policy process as drafted had a resource limit statement from infrastructure if we didnt get that earlier then we'll need to figure out how to make sure we get it early in F11 | |
| f13 | so fesco needs to vote, so that it can move on (: | |
| bpepple | f13: agreed. | |
| spoleeba | f13, ill follow up on this post release day | |
| bryan_kearney | f13: AOS is about 150 MB compressed | |
| bpepple | alright, can I get a quick show of hands for on the appliance image as part of the AOS feature or not. | |
| bpepple | Ok, since people seem shy. | |
| jds2001 | +1, pending that releng is comfortable with the toolset used to produce it | |
| bpepple | +1 to appliance image. | |
| notting | 0. not sure i see the point of the image itself | |
| nirik | sorry, got pulled away for a few. | |
| jwb | +1 | |
| nirik | +1 I guess... as long as rel-eng is willing. | |
| bpepple | dgilmore, dwmw2_HIO, j-rod: ? | |
| j-rod | +1, I suppose | |
| dgilmore | 0 | |
| dwmw2_HIO | don't see why not | |
| +1 | ||
| bpepple | ok, I see six '+1', and two '0'. So we approved the appliance image part of this feature. | |
| bryan_kearney | thanks! | |
| f13 | bryan_kearney: for the sake of Beta, I think selinux=permissive is likely OK | |
| bryan_kearney: we may debate it more, but we'll at least get the image rolling for beta | ||
| bryan_kearney: I'll probably contact you later as I try to work out the tools | ||
| bpepple | we need to still clear up the spin feature process since there has clearly been some mis-communication, but we can look at that next week (or on that mailing list). | |
| bryan_kearney | f13.. ok..that is committed | |
| bryan_kearney | f13: do you want rel-eng steps on the feature page, or email? | |
| f13 | bryan_kearney: whatever you prefer | |
| bpepple | anything else, or should we finally move on to mingw? | |
| ok, moving on..... | ||
| --- bpepple has changed the topic to: FESCo-Meeting -- MinGW - https://fedoraproject.org/wiki/User:Jspaleta/Draft - all | ||
| rwmjones | that URL is really nothing to do with the mingw SIG | |
| notting | do we think we can cover this in a reasonable amount of time? | |
| * nirik suspects not at all. | ||
| spoleeba | sorry dropped out for a second | |
| nirik | rwmjones: so whats the high level here? what is the goal of all this? | |
| jwb | rwmjones, you've pointed that out. but your SIG doesn't address policy | |
| bpepple | notting: I doubt it, but we could at least start the discussion. | |
| rwmjones | nirik, to build a cross-development environment targetting windows as a crazy embedded system | |
| nirik | rwmjones: so, providing only development tools/libs so development can be done on windows? | |
| dgilmore | rwmjones: thats pretty vague | |
| rwmjones | these are the packaging drafts, not quite finished yet, but could be usefully discussed: https://fedoraproject.org/wiki/PackagingDrafts/MinGW | |
| nirik, no | ||
| nirik, providing a fedora environment where you can sit and generate windows binaries | ||
| * nirik is confused as to the point here... | ||
| jwb | rwmjones, you're putting the cart before the horse a bit i think | |
| nirik | ah, so they are fedora packages that allow you to develop windows binaries? | |
| jwb | nirik, yes | |
| spoleeba | nirik, essentially yes | |
| dgilmore | rwmjones: is all you want is the tools to be able to build windows binaries on fedora boxes using mingw? | |
| danpb_ltop | nirik: the goal is that we want to be able to build windows binaries without using windows | |
| rwmjones | yes, you never need to leave Fedora, even though your users demand windows programs | |
| spoleeba | dgilmore, define..tools | |
| rwmjones | here is a list of the packages we have so far: (217 MB) http://annexia.org/tmp/mingw/00-files.txt | |
| nirik | so why the big fuss? shouldn't that be like any other package? we don't tell our users what they can do with the tools we provide... thats up to them? | |
| jds2001 | compilers, linkers, etc | |
| dgilmore | is it just having the tool chain available? or is it something more | |
| danpb_ltop | we specifically do *not* want to ship windows applications with fedora - just the toolchain libraries to enable people to build applications | |
| spoleeba | nirik, the are compiled binary payloads...in the form of no arch packages... | |
| nirik, which do not actually operate in the context of our distribution | ||
| dgilmore | danpb_ltop: thats something im perfectly comfortable with | |
| rwmjones | nirik, you need to supply some compiled libraries too, for linking purposes | |
| danpb_ltop | dgilmore: so as a concrete example, we (the libvirt community) want to ship a windows installer containing virt-manager | |
| spoleeba | rwmjones, you desire | |
| jds2001 | spoleeba: did danpb_ltop not just say we need not host anything? | |
| rwmjones | same as if you want to link to libc.so then you need to have libc.so around | |
| spoleeba | rwmjones, there is no explicit need to provide the libraries | |
| abadger1999 | danpb_ltop: And the applications that make development possible (cross compilers, etc) | |
| dgilmore | rwmjones: but you dont want to build windows .exe files in koji and have fedora host them right | |
| nirik | ok, so you need an exception to packaging binaries? | |
| dwmw2_HIO | how feasible is it to have a separate repository for the libraries? | |
| spoleeba | jds2001, who is going to decide which libraries are okay? | |
| rwmjones | dgilmore, DLLs primarily | |
| abadger1999 | but those aren't windows binaries so that's a tangent. sorry. | |
| danpb_ltop | so what this means for Fedora, is that we'd want the mingw toolchain (binutils, gcc, runtime) + libraries (libvirt, gtk, etc), but not virt-manager itself | |
| spoleeba | jds2001, is kde libs okay? | |
| dwmw2_HIO | it should be independent of the host distro, surely? | |
| rwmjones | dwmw2_HIO, the packages are noarch | |
| see http://annexia.org/tmp/mingw/00-files.txt | ||
| dwmw2_HIO | I'm looking | |
| dgilmore | danpb_ltop: and to be clear on that you want the tools to build that windows installer. but you will build it yourselves? | |
| spoleeba | dwmw2_HIO, my draft specificly covers having a seperate repo | |
| jwb | danpb_ltop, why do the libraries need to be in Fedora? | |
| dgilmore | rwmjones: as long as its not binary blobs thats ok | |
| rwmjones | this is our development repo: http://hg.et.redhat.com/misc/fedora-mingw--devel/ | |
| spoleeba | dgilmore, not just the tools.. we are talking about compiles of dlls | |
| rwmjones | dgilmore, not sure what you mean by 'binary blobs' ... everything is open source and builds from source | |
| dgilmore | spoleeba: stop confusing things | |
| spoleeba | dgilmore, to be packageed as noarch packages.. | |
| danpb_ltop | jwb: if they not, then everyone who wants to do this has to build all the dlls & toolchain from scratch themselves | |
| notting | this would be the equivalent of packaging the output of say, an arm crosscompiler as well? | |
| spoleeba | dgilmore, im not confusing things... define "tools" | |
| notting | (as opposed to an arm arch, buildhost, etc.) | |
| spoleeba | dgilmore, how far up the library stack do you consider a tool? | |
| jwb | notting, exactly. and we don't | |
| dgilmore | spoleeba: please be quiet right now and let rwmjones and danpb_ltop answer the questions | |
| spoleeba | dgilmore, i need you to define the word tools | |
| dwmw2_HIO | notting: true. But do we want to make these people wait until we've got a viable solution for that? | |
| notting | jwb: ...? but that's what the proposal is | |
| dgilmore | spoleeba: im going to ignore you for now | |
| danpb_ltop | which is a seriously tedious job - by having the libraries & toolchain in Fedora, people can focus on the bits which are relevant to them - ie packaging their application & buiding its installer | |
| jwb | danpb_ltop, i cross build for a living essentially. i'm aware of the pain | |
| dwmw2_HIO | especially since the solution is likely to be different for cross-packaging Linux stuff. | |
| rwmjones | there's quite a lot of work involved in cross-compiling each library, and that work is contained in the spec file | |
| danpb_ltop | and not have to constantly re-invent work to build DLLs of common libraries like libxml, libvirt, gtk | |
| nirik | so, none of this has gone thru packaging? | |
| dgilmore | rwmjones: so we ship an arm binutils and glibc as noarch to build against. and arch specific cross compilers | |
| jwb | nirik, we're addressing the 1000ft view | |
| dgilmore | rwmjones: your asking for the same thing right? | |
| danpb_ltop | nirik: none of it is in CVS yet - we're still refining the packaging guidelines & testing ideas to ease maintainence burden | |
| jwb | dgilmore, plus output from it | |
| dgilmore, they want to ship libraries built with said toolchain as packages as well | ||
| nirik | danpb_ltop: no, I meant the packaging guidelines from the package comittee. | |
| dgilmore | rwmjones: by no binary blobs i mean everything you need to get into fedora builds from source on fedora | |
| rwmjones | dgilmore, it's more than that because we want to supply common libraries cross-compiled too | |
| dgilmore, absolutely yes | ||
| danpb_ltop | nirik: no, we've not submitted the Mingw packaging guidelines for review yet | |
| rwmjones | dgilmore, for example: http://hg.et.redhat.com/misc/fedora-mingw--devel/?cmd=manifest;manifest=dcf0f981bfac6635f0e35b6b0fb13ea9cfd2d69c;path=/jasper/ | |
| 3 patches plus some stuff in the spec file, but it all builds strictly from source | ||
| dgilmore | rwmjones: i think thats ok | |
| rwmjones | there are some .exe files in that specific package that probably shouldn't be packaged up ... in general we wouldn't want to package exe's | |
| danpb_ltop | we're still working to cut down the number of mingw specific guidelines which are required - we're getting pretty close to workable guidelines which can be presented for review | |
| dgilmore | rwmjones: the thing that scared me was that it sounded like you wanted to build your .exe in koji and have fedora host it. | |
| rwmjones | no no no | |
| jwb | danpb_ltop, so such guidelines could be used by other cross-compilers? | |
| notting | random technical note: does building windows on any fedora arch really produce the same binaries each time? | |
| jwb | danpb_ltop, to package, say, libc for ARM? | |
| rwmjones | notting, good question. In theory it should. | |
| danpb_ltop | jwb: yes, i'd like to thing they're nicely applicable to any cross-compile | |
| rwmjones | but not actually done a bit-for-bit compare | |
| jwb | danpb_ltop, interesting | |
| danpb_ltop | notting: something worth validating... | |
| dgilmore | rwmjones: but asl long as whats goes into fedora meets fedora's licencing and packaging guidelines i think its ok | |
| notting | rwmjones: otherwise you might run into some interesting failures later | |
| rwmjones | as I'm working on the packages I'm uploading them here: http://annexia.org/tmp/mingw/ | |
| there are lots of spec files in there too | ||
| danpb_ltop | jwb: the mingw layout/guidelines are more or less encoded in the 'mingw-filesystem' RPM, which defines the cross compiler filesystem hierarchy, and provides all the convenient RPM macros | |
| dgilmore | rwmjones: it would be good to have it tested on a big endian arch | |
| nirik | instead of another arch, this is another os, right? so could we do the same here with herd/qnx/something else? | |
| jwb | nirik, yes. it opens all kinds of interesting possibilities | |
| danpb_ltop | nirik: its not really another OS | |
| nirik | windows isn't another os? | |
| danpb_ltop | nirik: because we're not including the base OS environemnt (ie windows) | |
| notting | nirik: ... in theory. it's one particular host triplet. | |
| nirik | right, build on fedora for foo. | |
| danpb_ltop | but you can actually test the stuff you produce using wine (already in fedora) | |
| nirik | so you can build foo binaries | |
| rwmjones | you can cross-compile the packages, but they're not self-contained. You need Wine or Windows to actually run any executables you make. | |
| jwb | danpb_ltop, but you could technically use this as a template for building binaries for hurd/qnx/sometthing else | |
| * nirik nods at jwb. Thats what I am asking. | ||
| dgilmore | jwb: i would think so | |
| fedora solaris | ||
| danpb_ltop | jwb: yes, i see what nirik is getting at | |
| notting | right. some crazy person could do something that stuff stuff in ia64-hp-hpux11 | |
| jwb | or AIX | |
| nirik | and with that in mind, we should try and come up with a way to do this that scales and is setup for that? | |
| jwb | nirik, i think these guys are doing a pretty good job so far | |
| what i don't get is what they object to in spoleeba's draft | ||
| danpb_ltop | nirik: the biggest burden will ultimately be keeping the patches in sync with 'native' fedora equivalents | |
| jwb | or, why it can't be used as the template for _policy_ | |
| rwmjones | jwb, I don't see how 217 MB means we need another repo, even if you account for large future uptake | |
| spoleeba | This does not indicate to me that the eventual library package set is of small bounded size https://fedorahosted.org/fedora-infrastructure/ticket/807#comment:7 | |
| danpb_ltop | nirik: eg, if libpng maintainer adds a patch, we need to pull that into mingw-libpng too | |
| spoleeba | there will absolutely be pressure for the packaged crosscompiled libraries..to grow | |
| jwb | rwmjones, you said in email that the separate repo thing wasn't a show stopper | |
| is that still correct? | ||
| rwmjones | I don't see it as a huge problem, but it is make-work | |
| jwb | anything else you overtly object to in that proposal? | |
| danpb_ltop | jwb: its not a show-stopper, just a annoyance / extra work - in fact most of the extra work is on the rel-eng folks to set it all up | |
| nirik | how does a seperate repo help again? | |
| rwmjones | jwb, yes two things I covered here: | |
| * jwb is digging for the email, sorry | ||
| rwmjones | https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00898.html | |
| the thread is here: https://www.redhat.com/archives/fedora-devel-list/2008-September/thread.html#00865 | ||
| we need a Windows installer (currently we are packaging NSIS) | ||
| notting | if you don't do a separate repo, is the idea that each cross-compiled library grows some mingw-related stanzas? | |
| jwb | nirik, easier to filter out on mirrors? | |
| * bpepple notes we only have 5 minutes left, so we need to wrap this up. | ||
| spoleeba | nirik, multiple arches.... | |
| nirik | jwb: true I guess... if it grows really big that could be an issue. | |
| spoleeba: ? | ||
| danpb_ltop | jwb: even if the mingw repo multiplies by x10 over our current 200 MB, that's still line noise compared to a single openoffice RPM set | |
| dgilmore | bpepple: i think we are an hour over already | |
| jwb | i'm confused as to what "repository" means here | |
| rwmjones | notting, I did do some work in that direction earlier, but there's a problem that existing maintainer might not want to maintain the -mingw subpackage | |
| jwb | package repo, or source repo? | |
| spoleeba | jwb, seperate cvs modules.. seperate desigination in the fedora-release package..seperate mirror manager url | |
| notting | rwmjones: or additional -n810, -solaris, -whatever (talking in theory, here) | |
| bpepple | dgilmore: yeah, but there's a meeting at 4:00 I believe, and I don't want to bump another groups time. ;) | |
| abadger1999 | notting: as in the feodra package grows a mingw subpackage or something else? | |
| notting | abadger1999: yes | |
| danpb_ltop | spoleeba: multiple archs doesn't explode the size, because they're all noarch apart from the compiler toolchain | |
| abadger1999 | notting: FPC would be against doing that. | |
| rwmjones | notting, http://hg.et.redhat.com/misc/fedora-mingw--devel/?cs=dadbf9d0ba46 shows a proposed gnutls subpackage | |
| jwb | so basically, this is OLPC but for mingw | |
| danpb_ltop | abadger1999: i tend to agree with you - i wanted sub-RPMs originally, but i think on balance the separate RPM spec is cleaner to understand | |
| spoleeba | danpb_ltop, indeed | |
| rwmjones | notting, just so you can see what it involves | |
| abadger1999 | danpb_ltop: <nod>. Totally agreed. | |
| danpb_ltop | and i think effort would be better spent on support tools to track patches & changes between the two specs | |
| spoleeba | jwb, except under FESCo's perview | |
| spoleeba | jwb, i dont think OLPC has to conform to our packaging guidance | |
| danpb_ltop | (such things would already be useful for people trying to maintain the same spec across f8/f9/rawhide/epel5) | |
| jwb | true | |
| ok, i think it basically comes down to the 'natively available on Fedora' part | ||
| dgilmore | spoleeba: yes they do | |
| danpb_ltop | spoleeba: our goal is that the core packaging guidelines should all be applicable to mingw, with just a few minor tweaks/addons (eg %mingw_configure instead of %configure) | |
| spoleeba | dgilmore, oh they do? | |
| jwb | because the separate repo makes sense and isn't a show stopper, and the enablment in fedora-release is minor | |
| danpb_ltop | and %_mingw_bindir instead of %_bindir in the %files section listing | |
| dgilmore | spoleeba: if its in fedora-cvs and built in koji it must meet packaging guidelines. and go through review | |
| spoleeba | dgilmore, no custom kernel in the olpc tree? | |
| notting | jwb: 'enablement in fedora-release'? why not build a 'mingw-build-for-windows' package that contains the repo file? | |
| dgilmore | spoleeba: its built outside of fedora | |
| spoleeba | dgilmore, ah | |
| dgilmore, okay | ||
| rwmjones | dgilmore, we want it to go through package review! and conform to guidelines | |
| jwb | notting, i'm just commenting on spoleeba's proposal as it is | |
| danpb_ltop | and we don't want to carry custom feature related patches in the RPMs either | |
| jwb | trying to get to the meat of why there is disagreement and what needs to be settled | |
| dgilmore | i dont see why this should be in its own tree | |
| danpb_ltop | the only patches should be those already in the native fedora packages, or mingw build system related | |
| spoleeba | dgilmore, potential space consumption | |
| nirik | dgilmore: I also am wondering that | |
| notting | i'm not sure how you build it without putting it there | |
| rwmjones | 217 MB at the moment, with this list of packages: http://annexia.org/tmp/mingw/00-files.txt | |
| danpb_ltop | spoleeba: should all the game -data RPM be a separate repo too then ? | |
| spoleeba: we've got GB of game datafiles in fedora repos already | ||
| abadger1999 | spoleeba: That holds for the mirrored download repo... but not sure I see that for cvs. | |
| notting | oof. bpepple: are we at time? | |
| danpb_ltop | which dwarf what's proposed for mingw RPMs | |
| nirik | can't it be moved to another repo if space becomes an issue? | |
| jwb | notting, yes... | |
| spoleeba | danpb_ltop, we have to make choices | |
| bpepple | notting: yeah, we are. | |
| jwb | bpepple, i think the thing FESCo needs to focus on for this is the 'natively available on Fedora' part | |
| dgilmore | spoleeba: even if its 500Mb or 1GB i think its ok | |
| danpb_ltop | spoleeba: i'm just saying that if you want to cut size of fedora repos, there's much bigger things to worry about than mingw | |
| jwb | the rest just doesn't matter | |
| bpepple | jwb: I agree. | |
| spoleeba | danpb_ltop, i do not want to cut the size.. i want to set things up in a way that lets new people with new interests..add to resources | |
| jwb | or is already looking really good (in the case of the guidelines) | |
| spoleeba | danpb_ltop, this is a distinctly new interest | |
| rwmjones | there's been loads of interest in having this as a feature, and people already do this for Fedora eg. http://www.haxxed.com/rpms/ | |
| we're just making it so people don't have to reinvent this wheel again | ||
| spoleeba | dgilmore, and if it gets bigger than that because its popular? | |
| dgilmore | lets wrap up for today. we are over 1hr over schedule | |
| dgilmore | spoleeba: then people want it iand its useful | |
| notting | 'wrap it up'? you mean 'reconvene on this topic next week'? | |
| rwmjones | popular is good surely? means more people are remaining in Fedora | |
| jwb | notting, i think so | |
| dgilmore | notting: if we cant come to a resolution in the next couple of minutes yes | |
| spoleeba | rwmjones, if they bring resources to sustain the effort...yes | |
| bpepple | notting: yeah, I think that's for the best, unless we can come to a quick resolution. | |
| rwmjones | the same argument can be made for game data ... do game players bring resources to fedora? | |
| jwb | well... considering that we're wanking about repos and not talking about things that we actually need to make a decision on, i think we have to revisit next week | |
| spoleeba | rwmjones, yes we have to make choices | |
| bpepple | jwb: +1 | |
| danpb_ltop | spoleeba: none of these things you're mentioning are specific to mingw - AFAICT they're all just general scalability questions wrt to package mainataince & distro infrastructure support | |
| jwb | danpb_ltop, exactly | |
| spoleeba | danpb_ltop, yes...general scalability questions.... we have to make choices | |
| jwb | spoleeba, infrastructure can do that. FESCo doesn't need to | |
| spoleeba | danpb_ltop, if FESCo wants to throw out game data to make room for you...fine | |
| jwb | call it a meeting bpepple | |
| spoleeba | jwb, actually infrastructure cant do it | |
| danpb_ltop | spoleeba: so you're basically asking FESCO to say whether Mingw is part of fedora or not | |
| spoleeba | jwb, infrastructure tells us what we have... governanace must choose | |
| danpb_ltop, no | ||
| bpepple | alright, let's end this discussion for today. | |
| jwb | spoleeba, or delegates | |
| bpepple | we can pick it up next week. | |
| spoleeba | danpb_ltop, i am asking FESCo to setup a new construct inside Fedora..that can grow seperately from the main repository | |
| jwb | which the board does so well | |
| danpb_ltop | bpepple: works for me - same time next week | |
| bpepple | danpb_ltop: yup. | |
| * bpepple will end the meeting in 60 | ||
| spoleeba | danpb_ltop, based on the communities commitment to that specific new idea | |
| rwmjones | yeah I've got to go now, it's 9pm here | |
| jwb | danpb_ltop, an hour earlier hopefully | |
| * bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| danpb_ltop | jwb: that would be very helpful - i'm in UK timezone... | |
| jwb | at least from today's discussion start time :) | |
| spoleeba | danpb_ltop, we ask secondary arches to commit resources | |
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!