--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
* tibbs here
nirik is here.
bpeppleHi, everyone.
* jeremy is here
warren here
abadger1999 here
f13 here
bpeppleLet'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
abadger1999So I sent out an email and got no responses.
bpeppleProposal is to use the same voting method as FPB election is using.
abadger1999I think it's pretty noncontroversial to change to approval voting to be just like the Board Election.
bpeppleabadger1999: +1
tibbsI honestly don't know the difference and have no opinion.
* spot is indifferent, +1
nirikabadger1999: +1, should be consistant.
tibbsI know we changed it originally because there were issues with the last FESCo election.
tibbsAs long as the new method also fixes those issues then I can't complain.
bpeppleAlright, 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
bpeppleok, 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
bpeppleEveryone get a chance to read poelcat's revision of the Feature Policy Draft?
f13I 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
nottingfuture and/or current?
tibbsI 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?
poelcattibbs: FESCo reviews and votes on each feature
f13notting: yes.
* poelcat would like to move forward with something... and tweak as we run into problems
f13tibbs: FESCo would still have to approve the feature.
spotone item which is not clear: can someone propose a feature but not own it?
poelcatevery feature needs to have an owner/accountable party
i suppose they could be different
nottingspot: presumably, if the person who *is* accountable/owns it agrees to it
f13spot: you thinking of blindsiding somebody?
spoti wonder if it is worthwhile to put up a place for "community suggested features"
f13or rather, somebody getting blindsided with a feature?
c4chrishi all, sorry to be late
nottingspot: i think a wishlist is great, but not really covered here
spotfor folks who want features, but are not capable of implementing them
f13spot: oh that noise.
who do we assign /that/ fun task to?
spote.g. partitioning overhaul in anaconda
bpeppleI'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.
nirikthe feature manager? who would try and find anyone who could do the wishlist tasks?
f13nirik: I'm afraid that the noise level on such thing would get pretty high
nirikcould be.
jeremyspot: 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...
nottingnirik: not sure the feature manager wants to be in the business of begging for resources. poelcat?
nirikjust look at the wishlist mailing list or forum threads...
spotsure, 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
f13RFE bugs against distribution!  oh wait, I'm on that component :(
spotalso, so developers could look it over quickly and pick up items they wish to work on
poelcatnotting: wishlist could be interesting; i'd propose starting with just managing features with owners for starters
f13Can we seperate that out as a different topic?
bpepplef13: +1
spoti just dont want to leave the community out of our feature proposals.
spotand right now, they are.
f13as they always have been
we're not regressing them
poelcatare there other viewpoints on the concerns raised here: http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft#head-fec0ab608fd2bde6177db2adff67bc47f17dcf20
f13we're just not helping either.
spoti'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
poelcatspot: wikipage?
spotone could argue that this is where ubuntu is stronger than fedora wrt community involvement
f13I see no reason not to add a TODO item.
* warren is uncomfortable with this idea of Wishlist
abadger1999poelcat: 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.
nottingyeah, but i don't see us getting to the point of actually implementing a lot of wishlist items real soon
spotnotting: perhaps this is a failure in the project.
nottinghow so?
warrenEven 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.
spotif 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!
c4chrisI think we see wishes in the devel mailing list
jeremyabadger1999: 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
nirikunless there is a rating/voting system it's hard to tell how much push is behind a feature... isn't it?
spotnirik: yes, which i think is important
abadger1999There'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.
jeremynirik: just because there's voting for a feature doesn't actually mean it's a good idea....
spotjeremy: its a process
nottingabadger1999: that's a bigger win, i think. how to help those willing to provide ponies as opposed to just demanding them
f13I 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.
warrenWishlist system is on the wishlist? =)
jeremybpepple: agreed
c4chrisyea, let's concentrate on the trackable features
spotand ignore the untrackable ones.
c4chrislater we can track wishes
* bpepple wonders were we are at in this discussion.
c4chrisI think we need to approve poelcat's proposal
nottingdo we need to call a vote on the feature proposal?
f13a vote on taking poelcat's draft as policy
bpeppleyeah, I think we need to vote on it.
spot0 (i cannot support in good conscience a policy which ignores the community when we are supposed to be a community driven project)
poelcatwhat about http://fedoraproject.org/wiki/JohnPoelstra/FeaturePolicyDraft#head-fec0ab608fd2bde6177db2adff67bc47f17dcf20
* poelcat would like to close this section out in a fair way
wwoodsspot, "ignore" and "exclude" are very different terms
nottingspot: so, the community is now defined as 'those who are unable to do work?'
abadger1999Note -- by community you're referencing "user community" whereas "community driven" could equally be "contributor community"
wwoodsthe draft doesn't directly address The Community, but that does not exclude them
tibbsI'm happy with the policy as long as its understood that it's incomplete.
spotwwoods: it requires that features have owners
wwoodsyes - for work to be done, someone must do it
spoti cannot put up a feature for improvement without owning it
wwoodsyou can certainly find someone who can own it
spoti might be able to do it, but there is no proper mechanism for doing this
wwoodsbut there's no sense in tracking a feature that nobody will actually implement
f13we just don't have an "approved" framework for that.
spotand without that framework, we're kidding ourselves if we think anyone else will do it
f13poelcat: perhaps incorporate abadger1999's suggestions for "what would not be approved"
poelcatspot: you can propose anything you want
spoti think it is vital to trap that data from users, even if we don't act on these owner-less features
f13and I don't know what to do about the time vs feature question.
warrenSuch a process must only track features that have someone accountable to it.
abadger1999spot: I do agree with that portion of your argument.
poelcatspot: 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
spotrather, simply that the process include a way for users to submit features
wwoodsthe 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
spotand for that list of features (owned and unowned) be available
bpepplewwoods: +1.
spotso that it can be reviewed for relevance and picked up by interested parties
wwoodsfailure to set up a magical system for divining wishlists doesn't invalidate the process for tracking actual features
c4chrisspot: IIUC, you'd like to have unowned features, that will not be tracked as milestones for a release ?
wwoodsI agree that we should have some way of tracking wishes and helping people find devs who can turn wishes into actual feature implementations
poelcatsince 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
wwoodsbut that's outside the scope of this discussion
f13spot: 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?
spotf13: that would be a good start
poelcati agree that is a good distinction
f13poelcat: can you incorporate that in clearer english?
poelcatf13: yes
c4chrisso we have "draft features", "approved features", and "rejected features"
spoti 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.
poelcatwhy not combine "proposed" and "wip" and add "approved" ?
poelcatwip = work in progress
spoti see a process loosely like this
A) idea
B) idea prereqs met
C) fesco approves idea
D) idea gets tracked for release
f13A == Draft, B == Proposed, C == Approved
C == D
spoti think its important to have that distinction
warrena single system could track these from A to D
spotright now, the draft reads more like B->C->D
poelcatspot: good point
c4chriscan spot and poelcat hack the proposal to shape?
f13I still think we should +1 it as it stands for getting features proposed/approved/tracked, and let spot/ poelcat work in the drafted part.
nirikin 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
bpepplef13: +1, In general I'm fine with the proposal, it just need a few tweaks.
jeremynotting/f13: +1
c4chriswell, 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?
warrensorry, lost my connection
abadger1999notting: +1
* spot abstains from voting, not a -1, just abstain
f13notting: I agree.  I don't want to hold up the show for those that already have proposed features.
bpeppleOk, I see five '+1', and one '0'.  anyone else?
nirikI guess +1 for now, with the idea that it will be reworked.
abadger1999I 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.
c4chrisabadger1999: exactly
bpeppleAlright, 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.
f13I 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
nottingpoelcat: want to drive the feature approval process?
poelcatnotting: yes
f13(with the expectation that they will add the missing sections in due course)
poelcatwe need to reorganize namepspaces for the pages and then I'll round up a list
bpeppleOk, we should probably move on then, since we still have to discuss the perl-devel issue.
nottingpoelcat: oof. care to start sending them to the list for approval?
unless someone thinks that's a bad place to handle it
bpepplenotting: which list?
nottingbpepple: fesco-list? the approval process is fesco-voting based.
bpepplenotting: that's fine with me.
poelcat: anything else you need before we move on?
spotpoelcat: let me know when you write up the final policy, please. :)
bpeppleok, moving on.......
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- decide whether perl-devel can be removed from the default buildroot - f13
bpepplef13: you want to lead this one?
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.
tibbsWho doesn't want this?
warrentibbs, some of the fedora perl leaders don't want it
f13tibbs: 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
nirikI think people who maintain a ton of perl packages don't want it... lots of work for them.
bpeppledo we have the number of packages that will be effected by this?
f13lots of.. one time work for them.
nirikFYI, there are 741 perl- packages in owners.list.
tibbsIf the issue is "lots of work", the solution isn't "let's never do it".
warrenI 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.
bpepplenirik: thanks.
tibbsThe solution is "let's get folks together and fix the packages".
nirikor could we have an automated mass fixing script? or is that too complicated to script?
f13warren: I'm not sure the 'we haven't gained anything in doing this' is accurate.
spotits not more complex. its a natural extension of the old perl policy of "don't require perl-foo, require perl(foo)"
warrenWe should have grandfathered in the non-split.  This has not gained us anything of substance.
tibbsnirik: It's a bit difficult due to optional modules needed for test coverage.
c4christibbs: BR perl-devel is not enough?
abadger1999f13: 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
f13warren: many of our policies haven't gained us anything of "substance" yet we do them anyway and force them upon our existing packages.
tibbsI see BR: perl-devel as a significantly inferior bandaid to just fixing the packages to require that they need.
f13abadger1999: they could, but that's against perl packaging conventions/policy
nirikI 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?
f13rnorwood: perl!
spotrnorwood: run!
rnorwoodf13: just use python, dude.
wwoodsso instead they should require things like perl(ExtUtils::MakeMaker)?
f13rnorwood: 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
f13wwoods: yes.  That's what rpm does itself for autodep generation.
spotthe split allows for finer grained installs, easier replacing of modules
rnorwoodAnd for building systems that don't have the 'development/module building' bits of perl
abadger1999So... 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.
warrenspot, rnorwood: how does jpo feel about this?
spotwarren: you know how jpo feels. he thinks that all the perl components from the upstream perl tarball should be in  the default buildroot
abadger1999What'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?
rnorwoodwarren: jpo hates the idea, obviously.
bpeppleDo we realistically have enough time to fix all those perl packages?  Especially since we only have 3 months or so to complete this.
warrenIf all the components in the upstream perl are in the same tarball, is it *really* necessary to split that up?
f13surprisingly ralf seems Ok with the split now, and is very much in favor of making perl packages properly BuildRequire perl(foo::bar)
spotbpepple: in most cases, its a one line fix.
spotusually, all that is missing is perl(Test::More)
rnorwoodabadger1999: yes, that's pretty much it - the argument is that 'upstream packages it as one unsplittable distribution, and we shouldn't split it.'
f13which is bogus
lennertthen we shouldn't split glibc and glibc-devel either
rnorwoodspot: and ExtUtils::MakeMaker, no?
f13warren: most of our packages ship in a single tarball yet we split them out into foo and foo-devel
bpepplespot: If that's the case, I'm fine with dropping it from the buildroot.
rnorwoodlennert: yes, that's the counter-counter argument, which I agree with.
warrenWe are adding a lot of complexity, losing key contributors, due to misguided pedantry.
spotwarren: you keep saying its a lot of complexity.
f13warren: lets throw some more drama in there.
spotin the worst case, its "three" BR.
warrenI'm stating it like it is.
spotthats really complex.
warrenWe didn't gain anything by doing this.
f13no, 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.
abadger1999What's the packaging convention that prevents BR: perl-devel?
lennertso 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
warrenIs 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
spoti'd prefer they did it right, but still.
lennertin general, let the work be done by those who care about getting it done, not by those who couldn't care less about it
warrendoes perl-devel pull in all of the former components that were split from perl?
rnorwoodwarren: no, it doesn't.
spotwarren: except perl-CPAN
warrenall except for perl-CPAN?
spotand nothing needs perl-CPAN to build (or it would fail in mock)
rnorwoodspot: warren: No, it doesn't pull any of them in -
spot: unless you changed it back recently?
spoteach subpackage requires: perl-devel
wait, nm.
i have it backwards.
rnorwoodspot: but not the other way
spotthe perl-core subpackage
it does pull everything back in
rnorwoodspot: right, that's the one you added.
* c4chris is fine to remove perl-devel from the build root
spoti added that to ease the pain.
rnorwoodspot: Hasn't worked so far. ;-)
warrenDo you object if people BuildRequires: perl-core then?
they just don't want to deal with this crap
spotrnorwood: 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
spotwarren: nope.
as soon as a perl is rebuilt with perl-core
rnorwoodspot: yeah, I meant it hasn't eased *my* pain.
warrenHow much sense is it that you would want BR: perl-core but not BR: perl-devel?
bpeppleAre we ready to vote on removing perl-devel from the buildroot now?
f13is perl-core just a bandaid?  Seemed that "core" was not really well defined.
spotwarren: i don't want BR: perl-core
warrenperl-core is nonsensical
spotbut i dont want to argue with lazy packagers.
tibbsI wonder if it's reasonable to think that base Perl might eject some of the currently bundled modules in the future.
spottibbs: they have in the past.
tibbsIf so, then requiring what you need to build is merely future-proofing your package.
spottibbs: this is the logic behind the "br the perl(foo), not perl-foo)
rnorwoodf13: 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
spotthis change doesn't bug me, because i'm making valid corrections
tibbsBottom 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.
warrenWill jpo still quit?
* spot is also willing to fix perl modules
* bpepple is willing to help out also.
c4christibbs: +1
tibbsHe wants to quit?  Over this?
warrentibbs, yes.
rnorwoodwarren: have to ask him.  I think we should accomodate him, but I think we should pick the right technical solution.
tibbsThen I don't feel comfortable with him maintaining that many packages.
rnorwoodtibbs: yes, threatened to many times.
warrenHere's a related question...
perl module specs that build on F8...
nirikhe's top of the list by number. ;)
rnorwoodand of course I'll sign up for fixing packages too.
warrendo the older distros have provides or virtual provides to handle those specs without modifications?
tibbsFrankly 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.
rnorwoodif we drop the BR, and offer to fix all of his packages....
nottingdoes any other distro do this?
warrenolder distros that are still alive that is... FC6, RHEL4, RHEL5
f13warren: if they BR "perl-devel" it will not.
warren: if they br the module correctly they'll just work.
nirikBR with perl() whatever should work all those places... but yeah, perl-devel will not
f13which is another reason why perl() is the preferred method.
warrenIf we respin perl in errata for those distros, we should add it.
OK, another clarification
f13or we should just not allow the use of 'perl-devel' as a BR
warrenwhat exactly is the purpose of perl-devel?
not allow the use of BR: perl-devel might work.
c4chriswarren: band-aid for the build root ?
f13or at least warn loudly that this is not backwards compatible.
warrenperl-devel in F8 would be a virtual package that does nothing but pull in perl-upstream-tarball except perl-CPAN?
spotwarren: perl-devel has devel files
its not a metapackage
they are files that are only useful for developing perl (headers, dev tools)
warrenThen how about this...
Discourage BuildRequires: perl-devel
the spec can then continue to work on RHEL4+ without issues
rnorwoodwarren: BR: perl-devel isn't much use anyway.
warrenrnorwood, why?
spotperl-devel doesn't exist in RHEL4/5
rnorwoodwarren: BR: perl-core (the metapackage) does save you from doing the other BR's though.
spotneither does perl-core
warrenperl-core doesn't exist on RHEL4/5
spotthe only way to have one spec work on all branches is to do the BR correctly
abadger1999spot: %if 0%{fedora} ......
spotok, without conditionalization. :)
abadger1999The same as for python.
spotwhich 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
spotmake this point moot
f13we can quickly vote
* c4chris wishes the force be with spot :)
bpepple+1 to removing perl-devel from buildroot.
f13Proposal:  remove perl-devel from default buildroot.  Assist others with proper spec fixups.  Alert time of removal is 1 week.
f13+1 (with one week's notice)
bpepple+1 to f13's proposal.
c4chrisf13: +1
abadger1999Clarification: Is there any guideline preventing people from BR: perl-core?
spotnot that i can find.
abadger1999Then +1.
warrenGuideline should discourage BR: perl-core and perl-devel (unless otherwise truly needed)
spotwarren: thats for the FPC
notting+1, as long as it stops the discussion about it. *ducks*
warrennotting, +1
bpeppleOk, I see more than seven '+1'.
bpeppleso f13's proposal is approved.
f13warren: we can mention that in the warning email too
bpepplealright, it's pretty late.  anything pressing that we *have* to discuss before calling it quits for this week?
f13rnorwood: 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) ) ?
rnorwoodf13: oh, goodie.
f13: sure.
* spot needs to go into the office now, thanks all
c4chrisbpepple: 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!