| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren | |
|---|---|---|
| * tibbs here | ||
| nirik is here. | ||
| spot | here | |
| bpepple | Hi, everyone. | |
| * jeremy is here | ||
| warren here | ||
| abadger1999 here | ||
| f13 here | ||
| bpepple | Let's start off with something fairly non-controversial to begin with while people are still showing up. | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- FESCo election voting method - https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02822.html - abadger1999 | ||
| abadger1999 | So I sent out an email and got no responses. | |
| bpepple | Proposal is to use the same voting method as FPB election is using. | |
| abadger1999 | I think it's pretty noncontroversial to change to approval voting to be just like the Board Election. | |
| bpepple | abadger1999: +1 | |
| tibbs | I honestly don't know the difference and have no opinion. | |
| * spot is indifferent, +1 | ||
| f13 | +1 | |
| nirik | abadger1999: +1, should be consistant. | |
| tibbs | I know we changed it originally because there were issues with the last FESCo election. | |
| warren | +1 | |
| tibbs | As long as the new method also fixes those issues then I can't complain. | |
| bpepple | Alright, I don't see any '-1', and there were no complaints on the mailing list, so I think we can consider this approved. | |
| jeremy | +1 from me | |
| bpepple | ok, if there is nothing else on this, let's move on. | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Feature Policy Draft - http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft | ||
| bpepple | Everyone get a chance to read poelcat's revision of the Feature Policy Draft? | |
| f13 | I like it in principle and general, and I'd like to give poelcat the ability to fine tune it over time with the feedback he's getting. | |
| but I think we should make it official sooner rather than later so that we can drive future features through it | ||
| notting | future and/or current? | |
| tibbs | I like it, but I've a question. | |
| In the past, some features have been handed down as dictates from the board. | ||
| How does this alter that process? | ||
| poelcat | tibbs: FESCo reviews and votes on each feature | |
| f13 | notting: yes. | |
| * poelcat would like to move forward with something... and tweak as we run into problems | ||
| f13 | tibbs: FESCo would still have to approve the feature. | |
| spot | one item which is not clear: can someone propose a feature but not own it? | |
| poelcat | every feature needs to have an owner/accountable party | |
| i suppose they could be different | ||
| notting | spot: presumably, if the person who *is* accountable/owns it agrees to it | |
| f13 | spot: you thinking of blindsiding somebody? | |
| spot | i wonder if it is worthwhile to put up a place for "community suggested features" | |
| f13 | or rather, somebody getting blindsided with a feature? | |
| c4chris | hi all, sorry to be late | |
| notting | spot: i think a wishlist is great, but not really covered here | |
| spot | for folks who want features, but are not capable of implementing them | |
| f13 | spot: oh that noise. | |
| who do we assign /that/ fun task to? | ||
| spot | e.g. partitioning overhaul in anaconda | |
| bpepple | I'm pretty much in agreement with f13. I like what poelcat has so far, and I'm with giving poelcat the ability to tweak it over time. | |
| nirik | the feature manager? who would try and find anyone who could do the wishlist tasks? | |
| f13 | nirik: I'm afraid that the noise level on such thing would get pretty high | |
| nirik | could be. | |
| jeremy | spot: they're welcome to try to find someone to step up and do things. but ultimately, features get done based on people doing the work... | |
| notting | nirik: not sure the feature manager wants to be in the business of begging for resources. poelcat? | |
| nirik | just look at the wishlist mailing list or forum threads... | |
| spot | sure, but i think that it might also be nice to have some sort of tracking facility for "wishlist" items | |
| maybe tied into the fedora acct system | ||
| so folks could +1 items they support | ||
| f13 | RFE bugs against distribution! oh wait, I'm on that component :( | |
| spot | also, so developers could look it over quickly and pick up items they wish to work on | |
| poelcat | notting: wishlist could be interesting; i'd propose starting with just managing features with owners for starters | |
| f13 | Can we seperate that out as a different topic? | |
| bpepple | f13: +1 | |
| spot | i just dont want to leave the community out of our feature proposals. | |
| f13 | nod | |
| spot | and right now, they are. | |
| f13 | as they always have been | |
| we're not regressing them | ||
| poelcat | are there other viewpoints on the concerns raised here: http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft#head-fec0ab608fd2bde6177db2adff67bc47f17dcf20 | |
| f13 | we're just not helping either. | |
| spot | i'm merely saying that if we're making changes now, we should take the community into consideration | |
| even if it is a "TODO: Wishlist" item in the draft | ||
| poelcat | spot: wikipage? | |
| spot | one could argue that this is where ubuntu is stronger than fedora wrt community involvement | |
| f13 | I see no reason not to add a TODO item. | |
| * warren is uncomfortable with this idea of Wishlist | ||
| abadger1999 | poelcat: I think mclasen's second point has validity but I'm unsure if it belongs in this policy or broken out to a related but separate document. | |
| notting | yeah, but i don't see us getting to the point of actually implementing a lot of wishlist items real soon | |
| spot | notting: perhaps this is a failure in the project. | |
| notting | how so? | |
| warren | Even if the "community" wants something and (possibly) votes to make it a priority, ultimately what happens is what someone actually works on. Wishes alone are shallow. | |
| spot | if fedora is not meeting the demands of the userbase | |
| if we are ignoring popular requests for "easy" requests | ||
| notting | ... then the userbase has an avenue to meet those demands! | |
| c4chris | I think we see wishes in the devel mailing list | |
| jeremy | abadger1999: it's no different than the gnome roadmap stuff or any one else who does time based releases and yet still tries to have an idea of what's coming in the next $timeframe | |
| nirik | unless there is a rating/voting system it's hard to tell how much push is behind a feature... isn't it? | |
| spot | nirik: yes, which i think is important | |
| abadger1999 | There's another level -- wishlists are shallow but we need to find ways for someone who wants to work on a wishlist feature to gain traction with the developers. | |
| jeremy | nirik: just because there's voting for a feature doesn't actually mean it's a good idea.... | |
| nirik | agreed. | |
| spot | jeremy: its a process | |
| notting | abadger1999: that's a bigger win, i think. how to help those willing to provide ponies as opposed to just demanding them | |
| f13 | I think capturing these wishes and tracking them somehow is better than leaving them unanswered in emails and untracked, but I really don't want to be the person who has to deal with the incomings on this. | |
| * bpepple really thinks were getting off-topic with the wishlist. Thinks we should add it as a TODO. | ||
| warren | Wishlist system is on the wishlist? =) | |
| jeremy | bpepple: agreed | |
| c4chris | yea, let's concentrate on the trackable features | |
| spot | and ignore the untrackable ones. | |
| c4chris | later we can track wishes | |
| * bpepple wonders were we are at in this discussion. | ||
| c4chris | I think we need to approve poelcat's proposal | |
| notting | do we need to call a vote on the feature proposal? | |
| f13 | a vote on taking poelcat's draft as policy | |
| bpepple | yeah, I think we need to vote on it. | |
| spot | 0 (i cannot support in good conscience a policy which ignores the community when we are supposed to be a community driven project) | |
| poelcat | what about http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft#head-fec0ab608fd2bde6177db2adff67bc47f17dcf20 | |
| * poelcat would like to close this section out in a fair way | ||
| wwoods | spot, "ignore" and "exclude" are very different terms | |
| notting | spot: so, the community is now defined as 'those who are unable to do work?' | |
| abadger1999 | Note -- by community you're referencing "user community" whereas "community driven" could equally be "contributor community" | |
| wwoods | the draft doesn't directly address The Community, but that does not exclude them | |
| tibbs | I'm happy with the policy as long as its understood that it's incomplete. | |
| spot | wwoods: it requires that features have owners | |
| wwoods | yes - for work to be done, someone must do it | |
| spot | i cannot put up a feature for improvement without owning it | |
| wwoods | you can certainly find someone who can own it | |
| spot | i might be able to do it, but there is no proper mechanism for doing this | |
| wwoods | but there's no sense in tracking a feature that nobody will actually implement | |
| f13 | we just don't have an "approved" framework for that. | |
| spot | and without that framework, we're kidding ourselves if we think anyone else will do it | |
| f13 | poelcat: perhaps incorporate abadger1999's suggestions for "what would not be approved" | |
| poelcat | spot: you can propose anything you want | |
| spot | i think it is vital to trap that data from users, even if we don't act on these owner-less features | |
| f13 | and I don't know what to do about the time vs feature question. | |
| warren | Such a process must only track features that have someone accountable to it. | |
| abadger1999 | spot: I do agree with that portion of your argument. | |
| poelcat | spot: or it could be proposed in draft form and deferred fro taking to FESCo for approval | |
| * spot is not advocating that all wishlist items be magically done | ||
| spot | rather, simply that the process include a way for users to submit features | |
| wwoods | the definition we've got here suggests that a wish is not a "feature" until someone is actually going to do the work to create it | |
| spot | and for that list of features (owned and unowned) be available | |
| bpepple | wwoods: +1. | |
| spot | so that it can be reviewed for relevance and picked up by interested parties | |
| wwoods | failure to set up a magical system for divining wishlists doesn't invalidate the process for tracking actual features | |
| c4chris | spot: IIUC, you'd like to have unowned features, that will not be tracked as milestones for a release ? | |
| wwoods | I agree that we should have some way of tracking wishes and helping people find devs who can turn wishes into actual feature implementations | |
| poelcat | since the idea of a feature being approved was put forth it is feasible that a feature could be proposed and sit there until brought to FESCo for approval | |
| wwoods | but that's outside the scope of this discussion | |
| f13 | spot: would it be enough to add wording that a feature draft can be started before all required things are in place so long as they are in place before being proposed as a feature for approval? | |
| spot | f13: that would be a good start | |
| poelcat | i agree that is a good distinction | |
| f13 | poelcat: can you incorporate that in clearer english? | |
| poelcat | f13: yes | |
| c4chris | so we have "draft features", "approved features", and "rejected features" | |
| spot | i would argue that the distinction is closer to "proposed feature" and "feature in progress" | |
| as there will likely be features with willing developers that we don't want. | ||
| poelcat | why not combine "proposed" and "wip" and add "approved" ? | |
| poelcat | wip = work in progress | |
| spot | i see a process loosely like this | |
| A) idea | ||
| B) idea prereqs met | ||
| C) fesco approves idea | ||
| D) idea gets tracked for release | ||
| f13 | A == Draft, B == Proposed, C == Approved | |
| C == D | ||
| spot | i think its important to have that distinction | |
| warren | a single system could track these from A to D | |
| spot | right now, the draft reads more like B->C->D | |
| poelcat | spot: good point | |
| c4chris | can spot and poelcat hack the proposal to shape? | |
| f13 | I still think we should +1 it as it stands for getting features proposed/approved/tracked, and let spot/ poelcat work in the drafted part. | |
| nirik | in particular the rsyslog folks are eager to get their feature approved and into devel so it can be tested, etc... | |
| * notting +1s. and suggests we immediately start approving/etc the current lists | ||
| spot is willing to work on the draft, but not willing to vote on it until then | ||
| bpepple | f13: +1, In general I'm fine with the proposal, it just need a few tweaks. | |
| jeremy | notting/f13: +1 | |
| c4chris | well, the approval part is not in issue, so we can approve the current list and let spot and poelcat complete the draft at ease, no? | |
| warren | sorry, lost my connection | |
| abadger1999 | notting: +1 | |
| * spot abstains from voting, not a -1, just abstain | ||
| f13 | notting: I agree. I don't want to hold up the show for those that already have proposed features. | |
| bpepple | Ok, I see five '+1', and one '0'. anyone else? | |
| tibbs | +1 | |
| nirik | I guess +1 for now, with the idea that it will be reworked. | |
| c4chris | +1 | |
| abadger1999 | I think we can start doing useful work with the draft as it stands. It doesn't appear that it will contradict what spot and poelcat come up with for step A) -- it's just incomplete in terms of that step. | |
| c4chris | abadger1999: exactly | |
| bpepple | Alright, I think that's seven '+1', and one '0'. So this proposal has been approved. | |
| with the knowledge that it will be slightly modified for spot's suggestions. | ||
| f13 | I think it's worth noting that probably most the existing Feature pages are missing a couple sections, such as rollback plan and end user impact | |
| however I'm ok with "grandfathering" them in since they were drafted before we had a guideline | ||
| notting | poelcat: want to drive the feature approval process? | |
| poelcat | notting: yes | |
| f13 | (with the expectation that they will add the missing sections in due course) | |
| poelcat | we need to reorganize namepspaces for the pages and then I'll round up a list | |
| bpepple | Ok, we should probably move on then, since we still have to discuss the perl-devel issue. | |
| notting | poelcat: oof. care to start sending them to the list for approval? | |
| unless someone thinks that's a bad place to handle it | ||
| bpepple | notting: which list? | |
| notting | bpepple: fesco-list? the approval process is fesco-voting based. | |
| bpepple | notting: that's fine with me. | |
| poelcat: anything else you need before we move on? | ||
| spot | poelcat: let me know when you write up the final policy, please. :) | |
| bpepple | ok, moving on....... | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- decide whether perl-devel can be removed from the default buildroot - f13 | ||
| bpepple | f13: you want to lead this one? | |
| f13 | sure! | |
| brief history | ||
| perl used to be a singular package. It had lots of stuff in it. | ||
| then came the perl-devel split out, where things that were more development in nature are being split out to perl-devel | ||
| however when this happened, it was too late for the churn of fixing lots of packages, so 'perl-devel' was added to the default buildroot package list | ||
| was to be removed early in F8 development to give time for packagers to fix their packages. | ||
| so here we are, early(ish) into F8 development and I'd like to remove 'perl-devel' leaving just 'perl' again. | ||
| tibbs | Who doesn't want this? | |
| warren | tibbs, some of the fedora perl leaders don't want it | |
| f13 | tibbs: not sure, there seems to be some voices on the perl list and -devel list that more specifically aren't happy with the split, nor with taking away the crutch | |
| nirik | I think people who maintain a ton of perl packages don't want it... lots of work for them. | |
| bpepple | do we have the number of packages that will be effected by this? | |
| f13 | lots of.. one time work for them. | |
| nirik | FYI, there are 741 perl- packages in owners.list. | |
| tibbs | If the issue is "lots of work", the solution isn't "let's never do it". | |
| warren | I personally believe we shouldn't have opened this can of worms. We haven't gained anything in doing this, and it is suddenly more complex and painful. | |
| bpepple | nirik: thanks. | |
| tibbs | The solution is "let's get folks together and fix the packages". | |
| nirik | or could we have an automated mass fixing script? or is that too complicated to script? | |
| f13 | warren: I'm not sure the 'we haven't gained anything in doing this' is accurate. | |
| spot | its not more complex. its a natural extension of the old perl policy of "don't require perl-foo, require perl(foo)" | |
| warren | We should have grandfathered in the non-split. This has not gained us anything of substance. | |
| tibbs | nirik: It's a bit difficult due to optional modules needed for test coverage. | |
| c4chris | tibbs: BR perl-devel is not enough? | |
| abadger1999 | f13: Is the perl-devel package going to remain, though? Can those people just ad BuildRequires: perl-devel to their packages? | |
| * spot has no plans to remove perl-devel | ||
| f13 | warren: many of our policies haven't gained us anything of "substance" yet we do them anyway and force them upon our existing packages. | |
| tibbs | I see BR: perl-devel as a significantly inferior bandaid to just fixing the packages to require that they need. | |
| f13 | abadger1999: they could, but that's against perl packaging conventions/policy | |
| abadger1999 | Ah | |
| nirik | I guess the next best thing to a mass script would be a mass rebuild to at least identify the packages that would be affected/need fixing? | |
| f13 | rnorwood: perl! | |
| spot | rnorwood: run! | |
| rnorwood | f13: just use python, dude. | |
| wwoods | so instead they should require things like perl(ExtUtils::MakeMaker)? | |
| f13 | rnorwood: can you (and/or spot) give us a brief rundown of A) why the split was made, and B) why this is good for us? | |
| * rnorwood points at spot | ||
| f13 | wwoods: yes. That's what rpm does itself for autodep generation. | |
| spot | the split allows for finer grained installs, easier replacing of modules | |
| rnorwood | And for building systems that don't have the 'development/module building' bits of perl | |
| abadger1999 | So... the Pro side is: Having perl-devel in the minimal buildroot is hiding other BuildRequire problems that wouldn't normally be allowed; get rid of it. | |
| warren | spot, rnorwood: how does jpo feel about this? | |
| spot | warren: you know how jpo feels. he thinks that all the perl components from the upstream perl tarball should be in the default buildroot | |
| abadger1999 | What's the Con side? That perl provides things in its standard library, therefore we should be able to depend on one perl-X that brings in all of perl's standard library? | |
| rnorwood | warren: jpo hates the idea, obviously. | |
| bpepple | Do we realistically have enough time to fix all those perl packages? Especially since we only have 3 months or so to complete this. | |
| warren | If all the components in the upstream perl are in the same tarball, is it *really* necessary to split that up? | |
| f13 | surprisingly ralf seems Ok with the split now, and is very much in favor of making perl packages properly BuildRequire perl(foo::bar) | |
| spot | bpepple: in most cases, its a one line fix. | |
| spot | usually, all that is missing is perl(Test::More) | |
| rnorwood | abadger1999: yes, that's pretty much it - the argument is that 'upstream packages it as one unsplittable distribution, and we shouldn't split it.' | |
| f13 | which is bogus | |
| lennert | then we shouldn't split glibc and glibc-devel either | |
| rnorwood | spot: and ExtUtils::MakeMaker, no? | |
| f13 | warren: most of our packages ship in a single tarball yet we split them out into foo and foo-devel | |
| bpepple | spot: If that's the case, I'm fine with dropping it from the buildroot. | |
| rnorwood | lennert: yes, that's the counter-counter argument, which I agree with. | |
| warren | We are adding a lot of complexity, losing key contributors, due to misguided pedantry. | |
| spot | warren: you keep saying its a lot of complexity. | |
| f13 | warren: lets throw some more drama in there. | |
| spot | in the worst case, its "three" BR. | |
| warren | I'm stating it like it is. | |
| spot | thats really complex. | |
| warren | We didn't gain anything by doing this. | |
| f13 | no, you're stating it like you /see/ things, with hopefully enough dramatic sounding words so that people will be scared into your side of things. | |
| abadger1999 | What's the packaging convention that prevents BR: perl-devel? | |
| lennert | so what's wrong with just making all modules BR perl-devel and then having the people who care about it change those BRs to the proper BRs? | |
| i.e. not forcing the package maintainer to do it | ||
| warren | Is it really so bad to allow BR: perl-devel? (I don't like this either, but it is a reasonable compromise.) | |
| * spot isn't going to complain if anyone does BR: perl-devel | ||
| spot | i'd prefer they did it right, but still. | |
| lennert | in general, let the work be done by those who care about getting it done, not by those who couldn't care less about it | |
| warren | does perl-devel pull in all of the former components that were split from perl? | |
| rnorwood | warren: no, it doesn't. | |
| spot | warren: except perl-CPAN | |
| warren | all except for perl-CPAN? | |
| spot | and nothing needs perl-CPAN to build (or it would fail in mock) | |
| rnorwood | spot: warren: No, it doesn't pull any of them in - | |
| spot: unless you changed it back recently? | ||
| spot | each subpackage requires: perl-devel | |
| wait, nm. | ||
| i have it backwards. | ||
| rnorwood | spot: but not the other way | |
| spot | the perl-core subpackage | |
| it does pull everything back in | ||
| rnorwood | spot: right, that's the one you added. | |
| * c4chris is fine to remove perl-devel from the build root | ||
| spot | i added that to ease the pain. | |
| rnorwood | spot: Hasn't worked so far. ;-) | |
| warren | Do you object if people BuildRequires: perl-core then? | |
| they just don't want to deal with this crap | ||
| spot | rnorwood: well, to be fair, perl hasn't build due to koji/mock bug | |
| * c4chris is ready to script a few stuff to auto-rebuild some stuff if needed | ||
| spot | warren: nope. | |
| as soon as a perl is rebuilt with perl-core | ||
| rnorwood | spot: yeah, I meant it hasn't eased *my* pain. | |
| warren | How much sense is it that you would want BR: perl-core but not BR: perl-devel? | |
| bpepple | Are we ready to vote on removing perl-devel from the buildroot now? | |
| f13 | is perl-core just a bandaid? Seemed that "core" was not really well defined. | |
| spot | warren: i don't want BR: perl-core | |
| warren | perl-core is nonsensical | |
| spot | but i dont want to argue with lazy packagers. | |
| tibbs | I wonder if it's reasonable to think that base Perl might eject some of the currently bundled modules in the future. | |
| spot | tibbs: they have in the past. | |
| tibbs | If so, then requiring what you need to build is merely future-proofing your package. | |
| spot | tibbs: this is the logic behind the "br the perl(foo), not perl-foo) | |
| rnorwood | f13: perl-core is really well defined 'what comes in the upstream tarball' | |
| * spot notes that he is either #2 or #3 in the perl packagers list | ||
| spot | this change doesn't bug me, because i'm making valid corrections | |
| tibbs | Bottom line for me is that I think perl-devel should not be in the default buildroot, and that I'm willing to assist in fixing modules that fail to build due to this. | |
| warren | Will jpo still quit? | |
| * spot is also willing to fix perl modules | ||
| * bpepple is willing to help out also. | ||
| c4chris | tibbs: +1 | |
| tibbs | He wants to quit? Over this? | |
| warren | tibbs, yes. | |
| rnorwood | warren: have to ask him. I think we should accomodate him, but I think we should pick the right technical solution. | |
| tibbs | Then I don't feel comfortable with him maintaining that many packages. | |
| rnorwood | tibbs: yes, threatened to many times. | |
| warren | Here's a related question... | |
| perl module specs that build on F8... | ||
| nirik | he's top of the list by number. ;) | |
| rnorwood | and of course I'll sign up for fixing packages too. | |
| warren | do the older distros have provides or virtual provides to handle those specs without modifications? | |
| tibbs | Frankly if someone's willing to quit over something this minor then we need to work out a plan to deal with his leaving for whatever minor thing comes up next. | |
| rnorwood | if we drop the BR, and offer to fix all of his packages.... | |
| notting | does any other distro do this? | |
| warren | older distros that are still alive that is... FC6, RHEL4, RHEL5 | |
| f13 | warren: if they BR "perl-devel" it will not. | |
| warren: if they br the module correctly they'll just work. | ||
| nirik | BR with perl() whatever should work all those places... but yeah, perl-devel will not | |
| f13 | which is another reason why perl() is the preferred method. | |
| warren | If we respin perl in errata for those distros, we should add it. | |
| OK, another clarification | ||
| f13 | or we should just not allow the use of 'perl-devel' as a BR | |
| warren | what exactly is the purpose of perl-devel? | |
| not allow the use of BR: perl-devel might work. | ||
| c4chris | warren: band-aid for the build root ? | |
| f13 | or at least warn loudly that this is not backwards compatible. | |
| warren | perl-devel in F8 would be a virtual package that does nothing but pull in perl-upstream-tarball except perl-CPAN? | |
| spot | warren: perl-devel has devel files | |
| its not a metapackage | ||
| they are files that are only useful for developing perl (headers, dev tools) | ||
| warren | Then how about this... | |
| Discourage BuildRequires: perl-devel | ||
| the spec can then continue to work on RHEL4+ without issues | ||
| rnorwood | warren: BR: perl-devel isn't much use anyway. | |
| warren | rnorwood, why? | |
| spot | perl-devel doesn't exist in RHEL4/5 | |
| rnorwood | warren: BR: perl-core (the metapackage) does save you from doing the other BR's though. | |
| spot | neither does perl-core | |
| warren | perl-core doesn't exist on RHEL4/5 | |
| spot | the only way to have one spec work on all branches is to do the BR correctly | |
| perl(foo::bar) | ||
| abadger1999 | spot: %if 0%{fedora} ...... | |
| spot | ok, without conditionalization. :) | |
| abadger1999 | The same as for python. | |
| spot | which i would argue is more complex than actually using the right BR | |
| * bpepple thinks we may need to take this to the mailing list, since it's getting fairly late. | ||
| * spot is tempted to just fix all the perl packages | ||
| spot | make this point moot | |
| f13 | we can quickly vote | |
| * c4chris wishes the force be with spot :) | ||
| bpepple | +1 to removing perl-devel from buildroot. | |
| spot | +1 | |
| tibbs | +1 | |
| c4chris | +1 | |
| f13 | Proposal: remove perl-devel from default buildroot. Assist others with proper spec fixups. Alert time of removal is 1 week. | |
| jeremy | +1 | |
| f13 | +1 (with one week's notice) | |
| bpepple | +1 to f13's proposal. | |
| c4chris | f13: +1 | |
| abadger1999 | Clarification: Is there any guideline preventing people from BR: perl-core? | |
| (currently) | ||
| spot | not that i can find. | |
| abadger1999 | Then +1. | |
| nirik | +1 | |
| warren | Guideline should discourage BR: perl-core and perl-devel (unless otherwise truly needed) | |
| spot | warren: thats for the FPC | |
| notting | +1, as long as it stops the discussion about it. *ducks* | |
| warren | notting, +1 | |
| bpepple | Ok, I see more than seven '+1'. | |
| bpepple | so f13's proposal is approved. | |
| f13 | warren: we can mention that in the warning email too | |
| bpepple | alright, it's pretty late. anything pressing that we *have* to discuss before calling it quits for this week? | |
| f13 | rnorwood: since you sent the last one, care to send another one, this time with feeling? (and point out that the only backward compatible and approved BR method is perl(foo::bar) ) ? | |
| rnorwood | f13: oh, goodie. | |
| f13: sure. | ||
| * spot needs to go into the office now, thanks all | ||
| c4chris | bpepple: adjourn++ | |
| * bpepple will end the meeting in 60 | ||
| bpepple will end the meeting in 30 | ||
| bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!