FESCo meeting summary for 20090729
by Jon Stanley
Sorry for the delay in getting this out, I was distracted right at the
end of the meeting by a coworker hovering over my desk :).
Summary: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-29/fedora-meeting...
Log: http://meetbot.fedoraproject.org/fedora-meeting/2009-07-29/fedora-meeting...
Note that the vote on VirtTCK was not unanimous, somehow that didn't
make it into the summary but was something that we wanted to call out.
----
17:01:20 <jds2001> #startmeeting FESCo special meeting - 2009-07-29
17:01:24 <jds2001> #chair dgilmore jwb notting nirik sharkcz jds2001
j-rod skvidal Kevin_Kofler
17:01:28 * onekopaka will be here.
17:01:41 * skvidal is here
17:01:44 * cwickert is also here as Christoph Wickert
17:01:44 * notting is here
17:01:47 * nirik is here.
17:01:49 <Kevin_Kofler> Present.
17:01:54 * sharkcz is here
17:01:56 <Kevin_Kofler> onekopaka: Yeah, but you can't vote. ^^
17:01:58 * jds2001 brings up the list
17:02:02 <onekopaka> Jeff_S: I know!
17:02:07 <onekopaka> err
17:02:10 <onekopaka> Kevin_Kofler: I know!
17:02:10 <Gerd> Gerd is also here as Gerd Pokorra
17:02:22 * Jeff_S can't vote either
17:02:24 * onekopaka will be here for the fun of it.
17:02:31 * dgilmore is here
17:02:39 <dgilmore> but im in another meeting also
17:02:42 <onekopaka> because it's fun to watch these meetings.
17:02:45 <onekopaka> FUN.
17:02:50 <jds2001> anyhow
17:02:51 <jds2001> ;et
17:02:54 <jds2001> let
17:02:59 <jds2001> 's get started
17:03:05 <jds2001> i cant type today
17:03:13 <jds2001> #topic Raduko perl 6
17:03:16 * skvidal gives jds2001 a new 300 baud acoustic coupler to use
17:03:18 <jds2001> .fesco 218
17:03:29 <cwickert> can I say something about this?
17:03:31 <onekopaka> perl 6?
17:03:35 <jds2001> sure
17:03:43 <cwickert> first of all I feel like people who voted were not
really informed
17:03:50 <dgilmore> -1
17:03:53 <cwickert> somebody claimed we were still waiting for something.
17:03:57 <Kevin_Kofler> +1, seems they can get it in, and if not it
can always be punted later.
17:03:58 <cwickert> this is not correct. the 'something" was released
three days before.
17:04:06 <cwickert> we have a building package now
17:04:07 <dgilmore> this feature is 33% done and feature freeze is past
17:04:10 <jds2001> right, we didnt think you had a working interpreter at all.
17:04:17 <jds2001> but now you do :)
17:04:23 <skvidal> cwickert: fortunately we don't have to be informed
to vote - it's just like the american electorate :)
17:04:26 <Kevin_Kofler> I think we should approve this.
17:04:31 <cwickert> skvidal: ;)
17:04:32 <Kevin_Kofler> It's a new package, it can't break anything.
17:04:52 <cwickert> dgilmore: the feature does not need to be at 100%
for feature freeze
17:04:56 <Kevin_Kofler> So even if it gets completed a few days late
due to upstream scheduling, that won't affect Fedora in any negative
way.
17:05:12 <cwickert> we did it in a couple of days, so please let us try
17:05:22 <Kevin_Kofler> And if it really fails, we can always postpone
it to F13 later.
17:05:44 <cwickert> Kevin_Kofler: we are in contact with upstream, at
least Gerd works with them closely
17:05:45 * jds2001 says to let them try
17:05:58 * onekopaka would say +1.
17:05:59 <nirik> is someone planning on reviewing that package? it's
still in new. ;)
17:06:03 <dgilmore> cwickert: it should be very close
17:06:12 <skvidal> so I'm confused
17:06:19 <Kevin_Kofler> dgilmore: It's a new package, it can't break anything.
17:06:20 <cwickert> nirik: I will and I think lubomir will too
17:06:21 <Kevin_Kofler> It can go in late.
17:06:37 <skvidal> cwickert: if we don't approve this as a feature -
how does it stop you from working on it?
17:06:38 <dgilmore> Kevin_Kofler: doesnt matter
17:06:41 <Kevin_Kofler> I'm sure rel-eng can let it in.
17:06:56 <cwickert> skvidal: nothing, but Fedora won't benefit then
17:06:56 <dgilmore> skvidal: it doesnt
17:06:58 <nirik> skvidal: it doesn't, it just doesn't get advertised.
17:07:05 <nirik> (or as much)
17:07:07 <Kevin_Kofler> dgilmore: Freeze exemptions have been granted
for new packages in several cases.
17:07:10 <skvidal> cwickert: fedora benefits from it how?
17:07:15 <Kevin_Kofler> The rationale is: it can't hurt.
17:07:32 <Kevin_Kofler> skvidal: It supports a new language which is
going to be the next big thing in the Perl community.
17:07:38 <cwickert> if we have a working perl6 binary, fedora can be
used by teachers to show their students the future of perl
17:07:46 <Kevin_Kofler> Maybe KDE 5 or even some later 4.x will even require it.
17:07:48 <cwickert> we could hae it in the devel spin as well
17:08:04 <Kevin_Kofler> (Current KDE requires Perl 5 for some things,
e.g. kconf_update and some build-time scripts.)
17:08:08 <cwickert> Fedora will be a better platform for developers
17:08:13 * nirik looks at the feature freeze page.
17:08:14 <skvidal> cwickert: again
17:08:18 <skvidal> nothing says it can't get it
17:08:21 <skvidal> just that it is not a feature
17:08:26 <skvidal> see what I mean?
17:08:30 <Kevin_Kofler> skvidal: Why is it not a feature?
17:08:37 <skvidal> if we don't approve it
17:08:38 <Kevin_Kofler> Just because it gets in a few days late?
17:08:41 <Kevin_Kofler> That's ridiculous.
17:08:42 <cwickert> skvidal: yes I d, but I think I lined all this out
on the featrure page
17:08:44 <notting> the issue i have is not that it's not 100% done;
it's not even testable at all
17:08:48 <nirik> "All features must be complete in a testable state"
17:09:05 <Kevin_Kofler> notting: I'm sure it can be snuck into the alpha.
17:09:11 <cwickert> nirik: good catch
17:09:14 <jds2001> they've demonstrated that it's testable, they have
a perl6 working
17:09:17 <Kevin_Kofler> The extra time between the freeze and the
alpha is just to avoid anything which breaks spins.
17:09:22 <jds2001> it can say hello world right now
17:09:26 <Kevin_Kofler> A new package can't break anything.
17:09:32 <dgilmore> jds2001: its not testable packages are not in fedora
17:09:33 <skvidal> Kevin_Kofler: yes, it really can
17:09:33 <nirik> Kevin_Kofler: not entirely true
17:09:53 <Kevin_Kofler> Yeah, of course if it Obsoletes: glibc, it can
break something. ^^
17:09:53 <notting> jds2001: if testable means 'testable by the QA
group', i don't want that to involve 'build it yourself'
17:09:55 <cwickert> is fedora Studio testable? no, they donÄt have a spin
17:09:58 <Kevin_Kofler> But in practice, it can't break anything.
17:10:10 <jds2001> notting: correct, i thought it was already in rawhide
17:10:22 <nirik> jds2001: it's not past review yet
17:10:22 <jds2001> if not, then this needs to be deferred.
17:10:30 <cwickert> or is moblin testable? this requires much more
reviews, but it's approved
17:10:30 <jds2001> ok, i was mistaken.
17:10:57 <Kevin_Kofler> Can't we give them a few more days (assuming
rel-eng buyin)?
17:11:11 <jds2001> unfortuantely not
17:11:18 <notting> cwickert: then it will likely get yanked. the
earlier the feature comes in, the more lenient we can be in getting
time to get it finished
17:11:24 <Kevin_Kofler> The upstream release of parrot they needed was
only a few days before the freeze.
17:11:28 <dgilmore> cwickert: if its not testable it will be on the
table to be dropped
17:11:31 <Kevin_Kofler> jds2001: And why not? Because you say so?
17:11:54 <jds2001> we've been soft in the past, and it's bitten us
17:11:57 <nirik> yeah, I suspect moblin won't make it... :(
17:12:04 <notting> there still isn't a link in the review page to a
package that actually builds. (last update as of monday)
17:12:11 <Kevin_Kofler> +1 to the feature and -1 to pointless pedantic
bureaucracy which will just hurt our PR.
17:12:13 <cwickert> dgilmore: ok, then please drop all other features
that are not testable today, and please don't forget to explain this
to their owners, who have put much work into it.
17:12:23 <Kevin_Kofler> Because it means the package will end up in
F12 anyway, but not be eligible as a feature.
17:12:36 <Kevin_Kofler> Either it'll get advertised as a "F13 feature"
when it's really a F12 one.
17:12:45 <Kevin_Kofler> Or it'll get rejected outright and we lose.
17:13:17 <cwickert> ok, time to vore I guess. or does anybody have
something he wants to add?
17:13:37 <nirik> should we just not have deadlines at all is what you
are saying?
17:13:48 <Kevin_Kofler> We should have flexible deadlines.
17:14:20 <Kevin_Kofler> What really counts is that the feature is
ready when the last RC (the one which gets the "gold approval" and
becomes the GA) is cut.
17:14:38 <Kevin_Kofler> Everything else is just a means to get there
and should be flexible.
17:14:38 <cwickert> nirik: sure we should have dealines, but for me
the deadline is alpha freeze. if the package does not make it into
alpha, let's drop the feature
17:14:44 <jds2001> if that's what you want propose that for the F13 schedule.
17:15:04 <Kevin_Kofler> It's just common sense, really.
17:15:20 <skvidal> Kevin_Kofler: I've found common sense is almost
always neither
17:15:23 <f13> We moved the feature freeze back from the alpha freeze
17:15:40 <f13> because I was really fucking tired of people crash
landing shit at the alpha freeze, and me having to clean it up before
we could do a clean compose
17:15:44 <dgilmore> cwickert: that is not correct
17:15:49 <jds2001> f13: the proposal now is to make feature freeze GA!
17:15:51 <f13> freezes should happen when we're ready, not so that we
can spend time to get ready
17:16:01 <f13> jds2001: hell no
17:16:04 <Kevin_Kofler> The proposal is to be flexible.
17:16:11 <jds2001> f13: you and I are together on this :)
17:16:15 <cwickert> dgilmore: elaborate please!
17:16:27 <Kevin_Kofler> We should have a feature freeze, but should we
allow exceptions if they're doable on time.
17:16:38 <dgilmore> cwickert: you dont have until alpha to land it you
have until feature freeze
17:16:42 <jds2001> on time == freature freeze.
17:17:04 <jds2001> we have that for a reason.
17:17:08 <Kevin_Kofler> f13: For example, in this case, how is that
new package going to screw up your composes if it lands in the time
between feature freeze and alpha freeze?
17:17:10 <cwickert> dgilmore: the feature freeze is for the feature
itself, not the package IMO
17:17:12 <jds2001> and it's not our health.
17:17:29 <Kevin_Kofler> It's not going to touch any existing package
(except possible parrot - cwickert: did that go in already?).
17:17:34 * nirik thinks the deadlines make sense, but in this case
it's worth considering an exception... it's unclear if it's really
that close to being ready though.
17:17:44 <cwickert> Kevin_Kofler: of course
17:17:57 <cwickert> Gerd did the package in less than a week, so I
think we can do it. trust us
17:17:57 <nirik> cwickert: when do you see this package as being
approved and imported?
17:18:01 <Kevin_Kofler> OK, so it's not going to touch any existing
package, just a new one.
17:18:10 <f13> and what's this package?
17:18:11 <cwickert> nirik: depends on the review process
17:18:17 <Kevin_Kofler> f13: rakudo
17:18:18 <cwickert> f13: pardon?
17:18:20 <Kevin_Kofler> An implementation of Perl 6.
17:18:29 <nirik> (noting that there is no buildable link in the review
bug and it's in NEW. ;)
17:18:36 <dgilmore> cwickert: but your wrong the featurefreeze is to
land things. its when features need to be testable in Fedora itself
17:18:42 <cwickert> f13: did you just say you have no idea what we are
talking about? ;)
17:18:44 <f13> and it doesn't introduce any scary Provides/Requires
that may screw up package ordering, size on media, etc...?
17:18:49 <cwickert> no
17:18:58 <f13> cwickert: yes, I noticed the tab due to talk about punting to F13
17:19:01 <cwickert> it's not suppsed to be n the media
17:19:16 <f13> and then saw suggestionst hat we move feature freeze to GA
17:19:34 <cwickert> it just buildrequires parrot, which is in Fedora >= 10
17:19:38 <cwickert> nothing more
17:20:00 <dgilmore> f13: i do think we need to move feature submission
freeze a month before feature freeze
17:20:03 <nirik> right, so it's a somewhat min change.
17:20:21 <f13> cwickert: and you can't manage to get a pre-release built today?
17:20:22 <Kevin_Kofler> dgilmore: FWIW, that's how KDE works.
17:20:26 <jds2001> dgilmore: that makes sense
17:20:35 <Kevin_Kofler> They have a "soft feature freeze" which is
what you call "feature submission freeze".
17:20:38 <cwickert> f13: ask Gerd please
17:20:41 <notting> f13: there is no working buildable package in the
review ticket
17:20:44 <Kevin_Kofler> And a "hard feature freeze" which is what you
call "feature freeze".
17:20:45 <cwickert> Gerd: ?
17:21:10 <Kevin_Kofler> I'm not sure I like that idea though. The
experience I got from KDE is that it encourages overpromising.
17:21:22 <cwickert> dgilmore: repeating myself. I undestand your point
of view, but I think it's wrong
17:21:30 <cwickert> please drop all other features that are not
testable today, and please don't forget to explain this to their
owners, who have put much work into it.
17:21:31 <Kevin_Kofler> You don't know yet whether you can get a
feature done, so you declare it just in case and have them punt it
later.
17:21:45 <cwickert> drop Gnome 2.28, itÄs not released, so not testable
17:22:04 <jds2001> but it is testable
17:22:14 <jds2001> we have pre-release built all the time
17:22:24 * nirik thinks we are getting sidetracked...
17:22:27 <dgilmore> what jds2001 said
17:22:32 <dgilmore> notting: i agree
17:22:36 * cwickert agrees to nirik
17:22:39 <notting> cwickert: don't be ridiculous
17:22:47 <Kevin_Kofler> (It's even tougher in KDE though because they
don't allow features in after the soft freeze which aren't declared in
the feature list. In Fedora, you can get away with doing a lot of
stuff as long as you don't declare it as a Feature.)
17:22:51 <cwickert> so lets just vote please, gentleman
17:23:00 <dgilmore> i stand by my -1 vote. i dont think that this can
be a F-12 feature.
17:23:24 <notting> Kevin_Kofler: that 'don't know yet' is what you're
suggesting we do now *AFTER* feature freeze.
17:23:52 <skvidal> before we take a vote
17:23:55 <skvidal> I'd like to say something
17:24:01 <nirik> cwickert: what timezone is Gerd in?
17:24:01 <skvidal> for EVERYONE here
17:24:13 <skvidal> 1. please stop the snarky and snide responses
17:24:16 <cwickert> nirik: UTC+2, just like me
17:24:25 <Kevin_Kofler> notting: I'm pretty sure this package can pass
review quickly (they have 2+ people, so one submitter, one reviewer,
my experience is that reviews get done fast in those cases).
17:24:33 <cwickert> nirik: so he is no longer in the office I think
17:24:35 <skvidal> 2. please stop using complying with the rules we
have as a threat
17:24:42 <notting> nirik: he said he was here at the meeting's beginning
17:24:43 <skvidal> 3. please stop acting like asses to each other.
17:24:44 <Kevin_Kofler> And then getting the feature in is just as
simple as building the package in Rawhide.
17:24:52 <cwickert> skvidal: +1
17:24:53 <f13> skvidal: thank you!
17:25:05 <nirik> skvidal: totally agreed.
17:25:07 <Kevin_Kofler> (or worst case with a freeze override)
17:25:12 <skvidal> cwickert: number 2 was addressed to you in particular
17:25:32 <f13> my suggestion would be to vote it as not a feature now,
since it isn't ready.
17:25:44 <f13> if it becomes ready in the next few days, re-visit the
issue once there is a built and testable package on hand.
17:25:56 <cwickert> skvidal: understood. but it seems like the rules
are different for different features
17:25:57 * jds2001 is +1, if the package doesn't make it by alpha, we
can punt to F13.
17:26:17 <f13> cwickert: you make that claim, but where is the evidence?
17:26:25 <jds2001> f13: I'm of the same opinion, but default accept
UNLESS there's not a built and testable package on hand.
17:26:27 <cwickert> f13: http://fedoraproject.org/wiki/Releases/12/FeatureList
17:26:32 <nirik> I am +1 if it lands very very soon. It needs reviewed
and added asap. If it's not, punt to next release.
17:26:34 <skvidal> cwickert: I think the rules are bent with the
relative importance of the feature, no doubt
17:26:56 <skvidal> cwickert: and I don't think that should be
otherwise - flexibility has its benefits - but we cannot ALWAYS be
flexible
17:26:58 <f13> cwickert: please be a bit more specific.
17:27:04 <skvidal> f13: let's not do this here, okay?
17:27:08 <sharkcz> +1, same opinion as nirik
17:27:11 <f13> sure.
17:27:18 <cwickert> skvidal: but the feature is not important, it
can't break anythink, so no need to apply the rules so strictly
17:27:30 <skvidal> cwickert: that's why we vote
17:27:45 <Kevin_Kofler> I stand by my +1.
17:27:50 * f13 wonders if it's not important, why is it a Feature?
17:27:56 <notting> *cough* if it's not important, it shouldn't be a
Feature. i'm assuming that's not what you meant.
17:28:06 * dgilmore says -1
17:28:17 <cwickert> f13: there are features in the page and that are
behind us, that are not testable ether, but that are appoved
17:28:18 <jds2001> this is getting really old really fast.
17:28:28 <jds2001> we have 3 +1, 2 -1 thus far
17:28:51 <Kevin_Kofler> I think the point is that it is important to
advertise, but not critical for the distro.
17:28:58 <notting> jds2001: i saw 4 +1, 1 -1
17:29:05 <cwickert> thanks
17:29:30 <cwickert> f13: who say's it's not important? it's not
important do you as rel-eng, but it's important for others
17:29:47 <jds2001> notting: youre right, im on some good stuff apparently :)
17:29:51 <skvidal> cwickert: you said it wasn't important
17:30:06 <skvidal> "[13:25] <cwickert> skvidal: but the feature is not
important, it can't break anythink,"
17:30:08 <cwickert> skvidal: important depends on the pov.
17:30:22 <cwickert> not important for distro composition etc
17:30:45 <cwickert> anyway, thanks everybody for the time discussing this
17:30:52 <f13> cwickert: any brand new rushed package can have
disastrous impact upon composing.
17:30:58 <Kevin_Kofler> Grrr, we already spent 30 minutes on debating
this one feature and we still don't have an outcome.
17:31:11 <Kevin_Kofler> Anybody who dares giving the 5th +1 vote? :-)
17:31:20 <f13> there is a reason why I strongly push to have things
land a week before we freeze so that we can catch the gotchas before
they turn into a release slip
17:31:40 <f13> people don't like long freezes, so we have to land
things before we freeze so that we can get /out/ of the freeze ASAP
17:31:42 <cwickert> f13: how would this cause a slip?
17:31:42 <Gerd> +1
17:31:55 <Kevin_Kofler> Gerd: :-) Too bad your +1 does not count...
17:31:56 <nirik> Gerd: nice try. :)
17:32:02 <cwickert> Gerd: we are not allowed to vote ;)
17:32:05 <f13> cwickert: an overlooked provides clash
17:32:11 * nirik wonders where the rest of fesco is... please vote so
we can move on?
17:32:18 <skvidal> f13: or an auto-provides :(
17:32:23 <f13> yep
17:32:33 <f13> both have caused major issues in the past
17:32:37 <cwickert> skvidal: this should be catched in alpha and beta
17:32:38 <jds2001> we've spent 30 minutes on this feature.....
17:32:43 <Kevin_Kofler> Hmmm, I do see the risk there, especially
clashes with Perl 5.
17:32:56 <f13> cwickert: it should be caught /before/ we freeze for Alpha
17:33:03 <f13> so that it doesn't cause alpha to slip
17:33:13 <skvidal> -1 - I do not think this needs to be a feature in
order to be advertised to a specific subset of our users who will use
perl. I think it should come in as a package and be tested normally,
though.
17:33:27 <cwickert> 4:2 then
17:33:43 <Kevin_Kofler> 3 FESCo members have not voted yet.
17:33:48 <notting> does the vote have to be +1/-1? i am ok with a "+1,
should land by friday", as i don't want it to land right at the
package freeze
17:34:14 <skvidal> notting: I think a provisional +1 is reasonable
17:34:18 <cwickert> notting: you mean in the repo by Friday?
17:34:18 <jds2001> notting: the vote can be that
17:34:23 <jds2001> cwickert: yep
17:34:30 <cwickert> this is hard..
17:34:58 <notting> cwickert: 'reviewed by'
17:35:03 <cwickert> ok
17:35:20 <f13> (this is why I recommended defaulting to voting it not
a feature, and re-convening should the package make it in time to
discuss reversing that vote)
17:35:53 <jds2001> we can punt this to friday and see if anything changes.
17:35:58 <jds2001> im fine with that.
17:36:10 <cwickert> where are the 3 fesco members who haven't voted?
17:36:11 <jds2001> all in favor?
17:36:20 <jds2001> cwickert: un-here :)
17:36:31 <nirik> well, with nottings provisional +1, it's approved right?
17:36:44 <Gerd> I will try to hold the timetable by Friday
17:36:54 <jds2001> yeah, i'd still like to revisit on Friday
17:37:00 <Kevin_Kofler> Let's do that.
17:37:12 <nirik> Gerd: you have a buildable package, right? you should
update the review bug with a link asap. ;)
17:37:29 <cwickert> Gerd: this is addressed to you
17:37:36 <jds2001> #agreed Raduko Perl 6 feature is approved,
providing the pakcage review is approved by Friday 7/31/09
17:37:53 <jds2001> #topic System crypto database
17:37:53 <dgilmore> jds2001: thats fine
17:38:00 <jds2001> .fesco 219
17:38:56 <notting> -1 . this doesn't look done yet, and it's an API
other packages would have to buy into
17:39:00 <dgilmore> -1
17:39:13 <notting> (it's a fine idea)
17:39:22 <dgilmore> looks like the work to get it testable is still a ways off
17:39:25 <nirik> -1 here as well... it doesn't seem testable, and will
require coordination with other packages.
17:39:35 <dgilmore> notting: i agree and f13 will love it
17:39:48 <jds2001> -1 for that reason too, actually
17:39:53 <sharkcz> -1, but the idea is right
17:39:57 <Kevin_Kofler> Hmmm, I'd +1 this in principle, but if no apps
are actually using it, it doesn't look that great.
17:39:57 <skvidal> -1 as well, worried how badly this could break a
lot of things
17:39:58 * jds2001 thought it was a fine idea as well.
17:40:15 <jds2001> that's why i was +1 in email :)
17:40:44 <jds2001> im not sure how badly it could break things, though
- it looks like the API is new
17:40:57 <notting> jds2001: advertising an API nothing is using isn't
particularly useful
17:41:00 <jds2001> or does it change the behavior of existing API's
17:41:08 <jds2001> notting: agreed :)
17:41:30 <Kevin_Kofler> Same here.
17:41:31 <jds2001> anyhow
17:42:04 <Kevin_Kofler> That said, weren't the SystemTap improvements
the same - new APIs, but no apps using them yet?
17:42:13 <Kevin_Kofler> That said, SystemTap is a developer tool, it's
kinda different.
17:42:14 <jds2001> #agreed System Crypto Database is declined for F12
due to nothing using the new API's.
17:42:23 <Kevin_Kofler> This here is an end user library, but no users yet.
17:42:25 <jds2001> Kevin_Kofler: it is a developer tool, you use the
API's yourself :)
17:42:34 <Kevin_Kofler> Yeah. :-)
17:42:47 <notting> Kevin_Kofler: systemtap APIs were also done, as i recall
17:42:49 <Kevin_Kofler> So -1, this needs to be implemented
distro-wide kinda like FeatureDictionary was.
17:43:02 <jds2001> #topic Virt TCK
17:43:37 <Kevin_Kofler> Same as last week: -1, not a feature, just an
internal process improvement.
17:43:42 <jds2001> so has anyone's opinions on this changed, or are we
in for another deadlock?
17:44:04 <notting> if nothing has changed with the page, feature
itself, can we table it until the end?
17:44:35 <jds2001> sure
17:44:37 <Kevin_Kofler> I propose we just ask the people who didn't
vote last Friday to express their vote.
17:44:49 <Kevin_Kofler> At least dgilmore is here now, I forgot who
was the other non-voter.
17:45:32 <jds2001> #topic media repo
17:45:38 <jds2001> .fesco 226
17:45:47 <jds2001> I se this as both good and bad.
17:46:20 <nirik> does this have buy in from the various maintainers?
is it testable now? (seeing 50%) there
17:46:32 <jds2001> there are screenshots there.
17:46:53 <Kevin_Kofler> This appears to be implemented even in
KPackageKit, that's nice for a change!
17:47:01 <Kevin_Kofler> Finally somebody who cares about KDE.
17:47:18 <Kevin_Kofler> +1 to this feature, it's useful and it's being
implemented in gnome-packagekit, KPackageKit and even Yumex!
17:47:59 <dgilmore> -1 its not testable, and its not clear whats done
or left to be done. I think the idea is good.
17:48:19 <dgilmore> without enough data to know if its really actually
close i cant give it a +1
17:48:24 <nirik> I would be ok with it, but it's unclear to me if it's
already in or not.
17:48:33 <notting> it doesn't appear testable - there's no link to the
patches/packages. also, it brings in a hal dependency where there
wasn't one before
17:48:35 <nirik> and has buyin from the maintainers, etc.
17:48:42 <notting> so, -1 from me
17:49:21 <skvidal> can we defer this one until friday? I ask b/c
Alsadi has updated all his patches and I've seen the posts to the
upstreams
17:49:30 <nirik> yeah, -1 here, but the idea is good. Persure for next
cycle and/or ask for a late vote if it's really already in and
testable and the page doesn't let us know that.
17:49:33 <skvidal> I'd lik to make sure he's updated the page
17:49:35 <skvidal> however
17:49:41 <skvidal> if not - then I'm fine w/it not being a feature
17:49:51 <dgilmore> skvidal: that seems fine
17:50:01 <nirik> yeah, seems fine to me.
17:50:12 <Kevin_Kofler> The usefulness is limited due to how the
packages from the media are very often outdated in Fedora land.
17:50:16 <jds2001> seems fine
17:50:19 <dgilmore> skvidal: though the page was last edited yesterday
17:50:21 <Kevin_Kofler> But still, it can save bandwidth.
17:50:26 <jds2001> Kevin_Kofler: that was my thing on the ML
17:50:42 <nirik> in some places it would be very handy...
17:50:43 <skvidal> Kevin_Kofler: and nothing is stopping it from landing anyway
17:50:51 <jds2001> i think it's use should be discouraged, but it's handy
17:50:51 <skvidal> and if/when it does land
17:50:53 * f13 wonders what the point of a feature freeze is if we
keep punting things to 3 days after the feature freeze
17:50:56 <skvidal> then popping the disk is will just work
17:51:09 <skvidal> f13: it seems like we have enough -1's to say 'no' to it
17:51:14 <skvidal> so nevermind
17:51:45 <jds2001> #agreed media repo feature is declined for F12
17:51:46 <f13> sorry, I'm being snarky :/
17:52:19 <jds2001> f13: no worries
17:52:38 <jds2001> #topic Split Softokn off from NSS
17:52:48 <jds2001> .fesco 227
17:52:55 <jds2001> so im not sure what this is.
17:52:57 <Kevin_Kofler> Uh, I see only 3 -1 votes for Media Repo.
17:53:10 <jds2001> Kevin_Kofler: out of six here
17:53:38 <jds2001> 6-3 = 3, 5 needed to pass.
17:53:39 <nirik> so is this feature a feature?
17:53:45 <jds2001> thus passage is impossible.
17:53:50 <jds2001> nirik: i dont think so
17:54:05 <nirik> it seems like a reorg of packages that most people
won't care about...
17:54:15 <notting> yeah, -1, not a feature. go ahead, though.
17:54:23 <jds2001> -1, this doesnt seem like a feature.
17:54:34 <sharkcz> -1
17:54:41 <nirik> yeah, -1. I suspect no fedora user cares about FIPS either. ;)
17:54:45 <Kevin_Kofler> Yeah, -1, the one sentence should go into the
Release Notes, but that's not a feature at all.
17:54:46 <skvidal> -1 not a feature
17:55:17 <jds2001> #agreed Split Softokn off from NSS is not a
feature, just a package reorg.
17:55:19 <Kevin_Kofler> If I filed a feature each time we split a
subpackage from a KDE package, KDE would have more features than
virtualization. ^^
17:55:35 <jds2001> #topic stap eclipse gui
17:55:40 <jds2001> Kevin_Kofler: :D
17:55:48 <jds2001> .fesco 228
17:56:14 <jds2001> oops, we lost notting
17:57:19 <Kevin_Kofler> +1 to this in principle, but I have some questions:
17:57:33 <Kevin_Kofler> "Users will need to be part of the stapdev
group on their machine in order to fully take advantage of SystemTap's
offerings." - do we really want to still rely on groups for these
things these days?
17:57:44 <Kevin_Kofler> This sounds like the lamest method for access control.
17:58:06 <Kevin_Kofler> Plus, why is there no documentation yet and
when will it be written?
17:58:27 <jds2001> Kevin_Kofler: this is how stap today works
17:58:29 <jds2001> i think
17:58:44 <jds2001> at least last time i used it, which was awhile ago.
17:58:59 <Kevin_Kofler> Yeah, I guess it's out of the scope of this
feature. But this also means that the Release Notes section needs to
be more relevant to the actual feature. ;-)
17:59:21 <dgilmore> +1, though there is very little information in
the feature page. at 90% done it should be testable
17:59:31 <jds2001> +1
17:59:37 <nirik> +1 here, but yes, needs docs/update
17:59:48 <notting> +1
17:59:52 <sharkcz> +1
17:59:57 <skvidal> looks like it passes
18:00:11 <jds2001> #agreed SystemTap eclipse gui feature is approved
for F12, please update docs
18:00:32 <jds2001> #topic thusnelda
18:00:41 <jds2001> .fesco 229
18:00:45 <Kevin_Kofler> +1, this is great.
18:00:49 <nirik> +1 here on this.
18:01:11 <sharkcz> +1
18:01:17 <jds2001> +1
18:01:32 <notting> +1
18:01:34 <jds2001> #agreed Thusnelda feature is approved
18:01:50 <jds2001> #topic volume control continued
18:01:57 <jds2001> .fesco 230
18:02:07 <Kevin_Kofler> +1, makes the GNOME volume control suck less
(but still suck ;-) ).
18:02:14 <Kevin_Kofler> But IMHO it should be called
GnomeVolumeControlContinued.
18:02:22 <jds2001> +1
18:02:27 <nirik> +1
18:02:29 <skvidal> Kevin_Kofler: what did I say about being snarky and an ass?
18:02:29 <sharkcz> +1
18:02:33 <skvidal> Kevin_Kofler: knock it off
18:02:44 <notting> +1, it's better, and it's testable (even on f11, with effort)
18:02:50 <skvidal> +1 to the feature
18:03:05 <dgilmore> +1
18:03:07 <jds2001> #agreed Volume Control Continued feature is accepted
18:03:15 <jds2001> #topic Harfbuzz
18:03:21 <jds2001> .fesco 231
18:03:32 <Kevin_Kofler> As long as gnome-volume-control will not talk
directly to ALSA for advanced settings and as long as PA will continue
to hide settings like CD (the direct cable) or PC Speaker, it will
never be able to fulfill all usecases.
18:03:58 <jds2001> Kevin_Kofler: i dont think it's intended to
18:04:06 <jds2001> but that's outside of the scope here :)
18:04:25 <nirik> this sounds good. Is it already in?
18:04:25 <Kevin_Kofler> +1 to HarfBuzz - finally! Qt 4 has used this
for ages. I hope this will improve consistency of font rendering.
18:04:27 <skvidal> it's unclear to me that harfbuzz is testable now?
18:05:03 <dgilmore> skvidal: indeed im leaning towards -1 based on
the feature page it alls eems to be in an upstream git repo
18:05:06 <Kevin_Kofler> skvidal: Use any Qt 4 app and you're testing
HarfBuzz. ;-)
18:05:12 <skvidal> Kevin_Kofler: in pango?
18:06:19 <nirik> I'd be ok with it if it's testable, but it's unclear
if it is. Can we ask for clarification and punt to friday/
18:06:25 <Kevin_Kofler> Let me check if Pango in devel is using HarfBuzz yet...
18:06:54 <Kevin_Kofler> Doesn't look like it.
18:06:58 <jds2001> :(
18:07:05 <Kevin_Kofler> It seems it's vanilla 1.24.5 at the moment. :-(
18:07:08 <skvidal> If it is not testable then -1
18:07:18 <jds2001> -1, not testable.
18:07:21 <sharkcz> -1
18:07:30 <nirik> ok, -1 then if it's not in.
18:07:34 <notting> yeah, -1 as it doesn't look testable yet
18:07:39 <Kevin_Kofler> IMHO it should go in.
18:07:51 <dgilmore> -1
18:07:54 <jds2001> #agreed Harfbuzz feature is declined, as it is not testable.
18:08:03 <Kevin_Kofler> We're having several problems on the KDE spin
with GTK+ apps looking different from Qt/KDE ones.
18:08:10 <Kevin_Kofler> A HarfBuzz Pango is likely to fix that.
18:08:18 <Kevin_Kofler> So I think it should be able to go into F12 even late.
18:08:20 <jds2001> Kevin_Kofler: it may still yet land.
18:08:38 <skvidal> Kevin_Kofler: please remember - this is only
declaring if these are features
18:08:41 <jds2001> but anyhow
18:09:08 <Kevin_Kofler> Land, but not be documented as such? This is
really ridiculous and IMHO the worst failure of our feature process.
18:09:14 <jds2001> shall we move to virt tck?
18:09:20 <skvidal> jds2001: sure
18:09:30 <jds2001> #topic VirtTCK
18:09:31 <skvidal> jds2001: can you provide the link to it, again
18:09:34 <Kevin_Kofler> We should also allow late features when we
allow freeze overrides.
18:09:40 <jds2001> sure
18:09:40 * nirik notes the mediarepo feature owner is in devel if we
want to ask them to join and answer questions on that.
18:09:59 <jds2001> .fesco 223
18:10:11 <jds2001> nirik: that would be awesome, that way we dont defer it :)
18:10:14 <Kevin_Kofler> So Virt TCK was +4 -3 last week, with dgilmore
and jwb absent.
18:10:26 <jwb> one sec
18:10:29 <jds2001> jwb is absent now as well
18:10:32 <jds2001> or not :)
18:10:39 <jwb> i had a conflict at 1
18:10:45 <jds2001> oh, np
18:10:52 <jwb> give me one sec to catch up
18:11:11 <dgilmore> +1
18:11:20 <jds2001> +1, as last week
18:11:45 <dgilmore> its testable and seems generally useful
18:12:04 <jwb> out of curiosity, what were the -1 vote based on?
18:12:16 <Kevin_Kofler> Not a feature, just an internal process improvement.
18:12:26 <notting> not a feature - having a test suite is not a feature.
18:12:44 <jds2001> and we believe it's a feature useful to enterprises and such.
18:12:47 <Kevin_Kofler> Yeah, myself, nirik and notting voted -1 on Friday.
18:12:49 <sharkcz> +1 as last week
18:13:11 <jds2001> we == everyone who didn't vote -1 :)
18:13:13 <jwb> jds2001, if you mean "as a selling point for enterprise
distros", sure
18:13:32 <jwb> i'm going to have to go with a -1 as well. i was
thinking the same already
18:13:54 <jwb> test suites are good, we'd like more of them, but they
aren't Features
18:14:18 <skvidal> -1, not a feature - and difficult to explain to others.
18:14:37 <Kevin_Kofler> j-rod, skvidal, jds2001 and sharkcz voted +1
last time. Looks like skvidal is changing to -1?
18:14:47 <skvidal> yes
18:14:58 <skvidal> swayed to understand it is not a feature
18:15:41 <Kevin_Kofler> OK, so we now have -1 votes from me, jwb and
skvidal. nirik, notting: ping? Are you confirming your -1 votes from
last week?
18:15:50 <notting> yes.
18:16:24 <jds2001> #agreed VirtTCK does not meet the definition of a feature.
18:16:54 * jds2001 does not personally agree with that assessment, but
that's why we have a voting system :)
18:16:56 <jwb> jds2001, we should note it was not unanimous
18:17:08 <jwb> nirik, does meetbot do that?
18:17:22 <onekopaka> jwb: yep.
18:17:32 <Kevin_Kofler> Uh, not really.
18:17:37 <Kevin_Kofler> Meetbot logs the whole discussion.
18:17:39 <onekopaka> #noted Decision on VirtTCK was not unanimous.
18:17:43 <jds2001> #note the previous vote was not unamious
18:17:49 <jwb> onekopaka, thanks!
18:17:51 <nirik> yeah, just via that.
18:17:57 <Kevin_Kofler> But it doesn't log scores until you note it explicitly.
18:18:02 <nirik> can we move on?
18:18:06 <jds2001> sure
18:18:14 <jds2001> is the media repo owner still around?
18:18:35 <nirik> let me check
18:18:46 <nirik> or skvidal can check.
18:19:34 <jds2001> :)
18:19:50 <nirik> in any case he has patches that work, but they use hal.
18:20:10 <notting> have the patches been okayed by their respective upstream?
18:20:14 <nirik> He needs to port them to using GIO. The packagekit
maintainer is receptive to adding them, but they don't exist yet.
18:20:30 <nirik> (at least thats how I understand it)
18:20:50 <jds2001> hmmm
18:20:59 <skvidal> notting: the upstream has said no b/c of the hal use aiui
18:21:05 <Kevin_Kofler> Ugh, GIO? :-/
18:21:14 <nirik> I don't know on yum. Perhaps we could find the yum
maintainer and ask. ;)
18:21:20 <Kevin_Kofler> Isn't the core of PackageKit supposed to be
independent of glib?
18:21:24 <skvidal> nirik: they are not patches to yum
18:21:37 <skvidal> nirik: none of this gets down to the yum layer -
only yumex and PK
18:21:43 <nirik> well, the feature also lists yum as being a target I thought.
18:22:01 <jds2001> an optional one iirc
18:22:06 <Kevin_Kofler> Hmmm, upstream for PK is also our PK maintainer.
18:22:09 <nirik> Yum (if we want this feature in yum-cli)
18:22:17 <Kevin_Kofler> So if he doesn't want the patches, they're not
likely to go in for F12.
18:22:19 <skvidal> nirik: yum-cli is not going to have mediahandling
18:22:41 <Kevin_Kofler> I don't see why using HAL is that big an
issue. There's plenty of stuff still using it.
18:22:47 <nirik> well, in any case I don't know that it's testable
now. (a out of tree hal patch is, but thats not going to be what goes
in)
18:22:59 <jds2001> well surely everyone agrees that new stuff shouldntr
18:23:13 <nirik> Kevin_Kofler: PackageKit doesn't depend on hal
anymore... they don't want to readd it just for this feature.
18:23:56 <nirik> oh well, I guess he's not around... punt to friday?
18:24:56 <skvidal> nirik: or just go with no
18:25:22 <nirik> that works for me too.
18:25:32 <notting> given that the patches aren't in (ergo, not
testable) and upstream is not planning to accept the patches as-is...
i'd vote -1.
18:26:06 <nirik> yeah, based on the current info I have, -1 here too.
18:26:06 <notting> Kevin_Kofler: current PK daemon already is at least
linked against glib and gio
18:26:19 <nirik> keep trying and get it in next time.
18:26:20 <sharkcz> -1, it's not ready
18:26:20 <Kevin_Kofler> Well, then GIO looks like the way to go.
18:26:25 <Kevin_Kofler> But yeah, it's not there yet.
18:26:42 <dgilmore> -1
18:26:49 <jds2001> -1
18:26:51 <Kevin_Kofler> So I'll change my +1 to -1 too, the feature is
not even written (in a way which will be accepted) yet!
18:27:28 <jds2001> #agreed media repo feature is declined for F12
18:27:31 <jds2001> we done?
18:27:45 <Kevin_Kofler> The PK maintainer is also PK upstream, if he
doesn't like the patch, he sure won't commit it in Fedora unless we
force him to (and I don't think we should).
18:27:57 <jds2001> anyhow, we
18:28:03 <jds2001> are done here :)
18:28:15 <jds2001> #endmeeting
14 years, 8 months
Audacious 2.1 coming - SONAME change
by Michael Schwendt
Audacious 2.1 is going to land in Rawhide soon.
src.rpm updates have been comitted to Fedora package cvs/devel already.
Compared with 1.5.1 this new final release changes the SONAME version
of essential libraries within the audacious-libs package. Dependencies
will need to be rebuilt. Plugins may need a minor update to sync with
modified plugin API structures.
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
14 years, 8 months
Lower Process Capabilities
by Steve Grubb
Hello,
I wanted to send an email to give everyone a heads up about a project I'm
working on. You can find the write-up here:
https://fedoraproject.org/wiki/Features/LowerProcessCapabilities
The basic idea goes something like this: We would like to do something to
prevent priv escalation for processes running as root. For this example, lets
take cupsd to be a good case in point. If the attacker can find a vuln with
cupsd, then they can have root privs and all that goes with it. (SE Linux may
prevent total compromise, but some people turn it off.)
What can be done is that we program the application to drop some of the
capabilities so that its not all powerful. There's just one flaw in this plan.
The directory for /bin is 0755 root root. So, even if we drop all
capabilities, the root acct can still trojan a system.
If we change the bin directory to 005, then root cannot write to that
directory unless it has the CAP_DAC_OVERRIDE capability. The idea with this
project is to not allow network facing or daemons have CAP_DAC_OVERRIDE, but
to only allow it from logins or su/sudo.
This will fundamentally change the permissions you see when doing ls -l, but
it will work as it always did for admins. If you wanted to test this out for
yourselves, you can setup a VM and run the following commands:
echo "Hardening files..."
find / -type f -perm /00700 -a -uid 0 -exec chmod u-wrx {} \; 2>/dev/null
find / -type f -perm /00070 -a -gid 0 -exec chmod g-wrx {} \; 2>/dev/null
echo "Hardening directories..."
find / -type d -perm /00200 -a -uid 0 -exec chmod u-w {} \; 2>/dev/null
find / -type d -perm /00020 -a -gid 0 -exec chmod g-w {} \; 2>/dev/null
echo "Correcting a couple things..."
find /sbin -type f -perm /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
find /usr/sbin -type f -perm /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
This project also plans to set the permissions for /etc/shadow and
/etc/gshadow to 0000 so that daemons running as root, but without DAC_OVERRIDE
cannot read the shadow file. Login, [gkx]dm, and sshd will still have
DAC_OVERRIDE or this wouldn't work.
Does a system running like this still work? Yes it does. But there is still
one rough spot. That is the /etc/resolve.conf file. The problem is that if we
follow the new theory of only allowing system updates with DAC_OVERRIDE, then
root daemons cannot update dynamically created files. The solution to this is
to move those into a directory owned by an account other than root and have
the daemon running under that account to write the file.
This would mean that anything that writes to /etc/resolve.conf, would need to
run under this new acct. And /etc/resolve.conf would need to be moved to
something like /etc/resolve/resolve.conf. And then that is symlinked back to
/etc/resolve.conf for the transition.
The last phase of the project is to play whack-a-mole and fix permission
problems in packages that specify file permissions explicitly. The plan is to
cover @core files first as I would like to make the minimal install work first
and then branch out to other use cases.
Asbestos underwear is firmly in place. Let me know if any one has concerns.
Also please try out the script above on a VM before posting so that you can
assure yourself that everything still works. :)
Thanks,
-Steve
14 years, 8 months
Changing the default 32-bit x86 arch for Fedora 12 (#2)
by Bill Nottingham
Given the loud feedback, I've updated the proposal at:
https://fedoraproject.org/wiki/Features/F12X86Support
The revised proposal:
- Build all packages for i686 (this requires cmov)
- Optimize for Atom
Why?
- We don't really support i586 in any meaningful matter
- OLPC still works with base i686
- We are likely doing a mass rebuild for F-12 anyways, might as well switch
while we're doing it
- Atom is the only currently produced 32-bit x86 chip of note; optimize
for what's currently available
If you want numbers, I did some benchmarking of code [1] with various
build options on a variety of processors, with the F-11 gcc code. All
of these results are relative to a F-11 baseline of "-march=i586
-mtune=generic".
P4 2.4Ghz Athlon 3400+ Core2Duo E6850 Atom N270
march=i686/ -1.1% +2.0% +0.9% +0.6%
mtune=generic
march=i586/ +0.3% -0.3% -0.2% +1.3%
mtune=atom
march=i686/ -1.5% +1.2% +0.5% +1.7%
mtune=atom
Bill
[1] gzip, bzip2, math simulation, mp3 encode/decode, ogg encode/decode
14 years, 8 months
[ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
by Lennart Poettering
Heya!
I'd like to draw your attention to the new mixer handling logic in PA
0.9.16/F12. It includes a number of improvements:
- We now support input and output "ports". i.e. switching between
Mic/Line-In resp. Speaker/Headphones. Only one of those ports can be
active per sink at a time.
- we merge a number of low-level mixer controls into a single
slider. This has various advantages: we become less dependant on
correct mixer initialization done by "alsactl init"; we get a better
hardware volume granularity and range; we can make use of ALSA's
surround volume controls ("Front", "Rear", yadda yadda).
- We support semi-pro/pro sound cards much better and can wrap more
than just one channel of them (Currently done for two Native
Instruments Audio4DJ cards)
- The supported profiles and what to do with the alsa controls are no
longer hard coded in PA, but can be changed without recompiling via
the config files in /usr/share/pulseaudio/alsa-mixer/
In the F11 cycle there has been some criticism on how g-v-c was
presenting a new minimal volume control interface. Most issues raised
back then should now be fixed, except for a few which we consider
strictly out of focus for us.
I'd like to ask everyone to test this new volume logic. If you don't
raise your voice now that some output port is not properly detected or
audio is too faint then later on you won't have any right to complain.
You should particularly pay attention to the new "Hardware" tab in
g-v-c, where you can now choose the hardware profile (i.e. stereo
vs. 5.1, and so on) which you want to use. And then on the
Input/Output tab you may or may not find an additional dropdown menu
for selecting the port you want to use (only shown if you have more
than one).
When you test this, please make sure to run version 0.9.16-4.test3 of
PA and 2.27.5 of gnome-media at least. Both are still stuck in Koji,
aren't in Rawhide yet.
Please note that it is our intention not to wrap obsolete mixer
controls such as "CD", "PC Speaker", "MIDI" and so on. If you file a
bug asking for those to be wrapped we will disappoint you and
close the bug WONTFIX.
gst-mixer is not longer listed as default in comps now.
Without too much effort it is now possible to change the way PA sees
the alsa mixer, for an explanation how to do that, consider reading this:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html
That mail also goes a bit into detail on the technical background of
these changes, might be an interesting read for everyone.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
14 years, 8 months
midi seq interface vs. fc11: #505421
by Fernando Lopez-Lezcano
Hi... anyone out there could help with the bugzilla bug 505421?? Filed
on 2009-06-11, no answers of substance yet and no workaround suggested.
Should be easy, a module is not being loaded on demand, it was before.
I keep getting questions about this on the Planet CCRMA list, it makes
midi unusable for a normal user, anyone installing fc11 for audio _will_
stumble into this problem. It was working, it is broken, please fix it!
-- Fernando
14 years, 8 months
orphaning nopaste // ruby help wanted for broken package
by Simon Wesp
Dear List,
short version:
I'm going to orphan nopaste since rafb.net/paste, which was used by
this package, is discontinued (bug #504108).
I tried to contact upstream four times and asked if they were planning
to switch to another provider, but no avail
If someone with ruby skills is able to rewrite nopaste for another
pastebin, he/she is welcome to take over the package.
long version:
I'm the maintainer (not a good one) of "nopaste". I was wondering
myself that the pasteservice of rafb.net/paste closed on my birthday.
I contacted the upstream of nopaste on the same day
(25th May), 3 days later, a week later, and yesterday. I wrote him the
situation and my problem (i believe the same problem is in gentoo,
too, because they have nopsate, too[didn't find a solution @ gentoo])
and I hint at the urgency.
Nothing happened. :-(
Yesterday I got the bug #504108. I can't ruby, so I can't fix it. I took
over the review from Phillip Baum, who discarded the idea to
become a Fedora packager.
My most important question is:
Can anybody wrote the script to fpaste.org or an other pastebin, to
continue the life of this package in fedora?
I will hand over the package to the guy(s) who can fix this, of course.
I'm really awfully sorry, for orphaning this package with an open
bug. :-(
--
Mit freundlichen Grüßen aus dem schönen Hainzell
Simon Wesp
The G in GNU stands for GNU
http://fedoraproject.org/wiki/SimonWesp
14 years, 8 months
Critical Path Packages - Enforcement?
by Kevin Kofler
Hi,
I have a few questions for the folks involved with the Critical Path
Packages proposal, as I'm still confused about the implementation details:
1. How will the policy be enforced? Will Bodhi withhold submitted updates
for packages in the depsolving hull of @critical-path until they get
approval from QA and/or rel-eng, like it currently does for security updates
until security team approval?
Assuming the answer to 1. is "Yes":
2. Will critical-path-gnome also get the same enforcement?
3. Will critical-path-kde also get the same enforcement?
4. Will critical-path-* for spins.fp.o spins also get the same enforcement?
If the answer to any of the above (1. to 4.) is "No", what kind of
enforcement will there be? When we discussed critical-path-kde today at KDE
SIG, we were very much confused about what exactly the practical
implications will be. I think it won't be of much use to define critical
path packages if that definition doesn't lead to some actual enforcement.
What we basically agreed on in KDE SIG (see also our meeting log [1]) was:
* The KDE spin being one of the primary spins, critical-path-kde should get
the same kind of enforcement as critical-path-gnome. (We have no official
opinion about stuff like critical-path-xfce as that's out of the scope of
our SIG.)
* It doesn't make much sense for us to define critical path packages if it
won't have any actual practical implications. (We already know what's
critical to what extent, so a purely-informative critical-path-kde won't be
of much use to us.)
But we need the clarification I requested above to make any further
decisions.
Another open question is who is going to QA critical-path-kde, as we still
don't have a dedicated tester in KDE SIG. Anybody volunteering to be a
tester for KDE SIG is requested to talk to us on the #fedora-kde IRC chan
and/or the fedora-kde mailing list. Being a tester has a much lower barrier
to entry than most other forms of contribution, you just need some HD space
to install test systems to (ideally, you'd have Rawhide, Fn and Fn-1 on at
least one machine each, but even just testing one release is helpful) and
some spare time. No programming, drawing, technical writing etc. skills
required. I will post a call for help to the fedora-test-list as well. (Note
that we do have a KDE SIG member in rel-eng (rdieter), so that part is
covered.)
Kevin Kofler
[1] http://urlx.eu/_Mzk4MQ
14 years, 8 months
