4:57 p.m.
A new version of bodhi has just hit production. This release contains
a number of bugfixes and improvements, along with some important process
changes.
https://admin.fedoraproject.org/updates
ChangeLog
=========
- Package update acceptance criteria compliance
https://fedoraproject.org/wiki/Package_update_acceptance_criteria
- Disable direct-to-stable pushes
(https://fedorahosted.org/bodhi/ticket/434)
- Minimum time-in-testing requirements
- Every day bodhi will look for updates that have been
in testing for N days (fedora: N=7, epel: N=14), and will
add a comment notifying the maintainer that the update is
now able to be pushed to stable.
- When someone tries to push an update to stable, bodhi will
look to see if it has the appropriate karma, or if it has
been in testing for more than N days.
- Critical path update changes
- Hide obsolete updates in our critpath view
(https://fedorahosted.org/bodhi/ticket/447)
- Disabled strict critical path procedures for EPEL
- EPEL is back to the same process that it has always had
- Add a new nagmail message for unapproved critical path updates
- RSS feed & grid of unapproved critical path updates
https://admin.fedoraproject.org/updates/rss/rss2.0?critpath=True&rele...
https://admin.fedoraproject.org/updates/critpath?unapproved=True&rele...
- RSS feed & grid of user-specific comments
(https://fedorahosted.org/bodhi/ticket/445)
https://admin.fedoraproject.org/updates/comments?user=lmacken
https://admin.fedoraproject.org/updates/rss/rss2.0?comments=True&user...
- Package-specific RSS feeds of updates
(https://fedorahosted.org/bodhi/ticket/339)
https://admin.fedoraproject.org/updates/rss/rss2.0?package=kernel
- Add more links to the package-specific page
https://admin.fedoraproject.org/updates/TurboGears2
- Show 7 days worth of entries in our RSS feeds, as opposed to 20
entries (https://fedorahosted.org/bodhi/ticket/339)
- Bodhi command-line client fixes
- Output now goes to stdout, instead of stderr
(https://fedorahosted.org/bodhi/ticket/449)
(Thanks to Till Maas)
- Duplicate logging issue resolved
(https://bugzilla.redhat.com/show_bug.cgi?id=613533)
- Support using --critpath and --type with --testable
- Link to the submitter and release on the home page & testing
list (Thanks to Till Maas)
- Made the suggest_reboot flag actually configurable
(https://fedorahosted.org/bodhi/ticket/352)
- Notify the security team when an update is edited and turned into
a security update (https://fedorahosted.org/bodhi/ticket/403)
- Only verify the autokarma thresholds if it is enabled (Thanks to
Till Maas)
- Only touch bugs under the Fedora/EPEL Bugzilla products
(https://fedorahosted.org/bodhi/ticket/448)
- Prevent the masher from pushing obsolete updates
- Prevent obsolete updates from getting auto-promoted to stable
- Obsolete updates upon deletion, as opposed to destroying them.
- Added more unit tests (up to 122)
- Link up bug numbers and other URLs in the text of comments
- Document the `newpackage` update type in the bodhi-client commands
(https://bugzilla.redhat.com/show_bug.cgi?id=621828)
- Set bugs to MODIFIED upon submission
(https://fedorahosted.org/bodhi/ticket/343)
- Added a `bodhi --push-request={stable,testing}` command to
improve our releng updates push workflow
- A new /updates/releases JSON API and python-fedora
BodhiClient.get_releases() method for AutoQA
- Have the build auto-completion widget query candidate builds
from koji, as opposed to looking in /mnt/koji/packages
(https://fedorahosted.org/bodhi/ticket/173)
Bugs & RFEs
===========
Please file and bug reports or enhancement requests here:
https://fedorahosted.org/bodhi/newticket
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
6:12 p.m.
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
- Minimum time-in-testing requirements
- Every day bodhi will look for updates that have been
in testing for N days (fedora: N=7, epel: N=14), and will
add a comment notifying the maintainer that the update is
now able to be pushed to stable.
Suppose I submit a package to testing and it gets pushed. Six days
later, I find a terrible bug in the package (or a user reports this to
me). I fix the package and edit the update, request the fixed package
to be pushed to testing again and it gets pushed the next day.
Now without any further testing the package can be pushed to stable,
which contradicts the purpose of this whole change in bodhi.
I think, for packages that are modified during the testing period,
this N should be calculated from the day the last push was made to
testing.
Orcan
6:15 p.m.
Orcan Ogetbil wrote:
Now without any further testing the package can be pushed to stable,
which contradicts the purpose of this whole change in bodhi.
Sssh, why can't you keep quiet about this?!
I think, for packages that are modified during the testing period,
this N should be calculated from the day the last push was made to
testing.
NO! I really don't want any small fix to my update to restart the whole
testing cycle from scratch! Imagine I want to edit something in the update
notes, e.g. add a Bugzilla reference, I have to edit the update for that,
but does this warrant new testing? No!
Kevin Kofler
6:25 p.m.
On 08/12/2010 07:15 PM, Kevin Kofler wrote:
Orcan Ogetbil wrote:
> Now without any further testing the package can be pushed to stable,
> which contradicts the purpose of this whole change in bodhi.
Sssh, why can't you keep quiet about this?!
> I think, for packages that are modified during the testing period,
> this N should be calculated from the day the last push was made to
> testing.
NO! I really don't want any small fix to my update to restart the whole
testing cycle from scratch! Imagine I want to edit something in the update
notes, e.g. add a Bugzilla reference, I have to edit the update for that,
but does this warrant new testing? No!
Ok, so the problem here is that bodhi unpushes updates when you edit
*anything* in it. If it only unpushed an updated when you add/remove
builds from it, then this scenario would be sane.
I'm going to tackle this issue next, to ensure that you can add
bugs/notes to a testing update without having it reset the time-in-testing.
luke
7:02 p.m.
Luke Macken wrote:
Ok, so the problem here is that bodhi unpushes updates when you edit
*anything* in it. If it only unpushed an updated when you add/remove
builds from it, then this scenario would be sane.
There's still the "We've been testing a new KDE release for 2-3 weeks, now
we need to edit in a one-line regression fix to one package of the huge
group before pushing this to stable." scenario. This has been the case quite
often. With your "fix", we'd have the choice between pushing the update with
a known regression (yuck!!!) or waiting another full week (also quite a bad
option).
Kevin Kofler
7:19 p.m.
On Fri, Aug 13, 2010 at 3:02 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Luke Macken wrote:
> Ok, so the problem here is that bodhi unpushes updates when you edit
> *anything* in it. If it only unpushed an updated when you add/remove
> builds from it, then this scenario would be sane.
There's still the "We've been testing a new KDE release for 2-3 weeks, now
we need to edit in a one-line regression fix to one package of the huge
group before pushing this to stable." scenario. This has been the case quite
often. With your "fix", we'd have the choice between pushing the update
with
a known regression (yuck!!!) or waiting another full week (also quite a bad
option).
If you have been *testing* it for 2-3 weeks surely you have no problem
to find two
testers to confirm the small fix?
I know you never run kde from updates-testing yourself, so I understand why you
think nobody would want to test it. But the reality is that even if
you don't want to
test your work yourself, there are people who can verify the fix so
that the update
can go out sooner if need be.
M.T.
7:45 p.m.
List Troll wrote:
If you have been *testing* it for 2-3 weeks surely you have no
problem
to find two testers to confirm the small fix?
This argument has been brought up all the time. The thing is, it takes time
to find people to +1 updates. It takes even longer if the people actually
test the updates before +1ing them (as they're expected to). This excessive
and useless QA adds delays over delays.
Kevin Kofler
7:50 p.m.
I wrote:
This argument has been brought up all the time. The thing is, it
takes
time to find people to +1 updates. It takes even longer if the people
actually test the updates before +1ing them (as they're expected to). This
excessive and useless QA adds delays over delays.
But FWIW, when it comes to KDE in particular, the whole thing is moot or
soon to be moot anyway because parts of KDE are now being redefined as
"critical path", resulting in even more annoying update policies, even
though there was clear consensus in KDE SIG that such policies are neither
necessary for nor of any benefit to KDE. FESCo just asked us to come up with
a list of critical KDE packages and shut up. So we did. (My proposal to
submit an empty list was voted down in KDE SIG on the grounds of being
against the spirit of what FESCo asked of us, even though it did get some
support due to our objections to the critical path process as a whole.) We
(KDE SIG) have been more or less forced to participate in a process most of
us (and me in particular) do not agree with and consider outright harmful.
Kevin Kofler
8:10 p.m.
I wrote:
But FWIW, when it comes to KDE in particular, the whole thing is moot
or
soon to be moot anyway because parts of KDE are now being redefined as
"critical path", resulting in even more annoying update policies, even
though there was clear consensus in KDE SIG that such policies are neither
necessary for nor of any benefit to KDE. FESCo just asked us to come up
with a list of critical KDE packages and shut up. So we did. (My proposal
to submit an empty list was voted down in KDE SIG on the grounds of being
against the spirit of what FESCo asked of us, even though it did get some
support due to our objections to the critical path process as a whole.) We
(KDE SIG) have been more or less forced to participate in a process most
of us (and me in particular) do not agree with and consider outright
harmful.
PS:
1. The critical path update rules (and thus also the clause in the general
update rules which references them) were initially defined as requiring only
1 proventester to approve. (This was left somewhat vague in the actual
policy, but 1 proventester was what was mentioned in all the discussion
inside FESCo.) This was modified to 1 proventester + 1 other tester to match
existing practice for freezes (the Critical Path Policy implemented as part
of No Frozen Rawhide). FESCo never actually voted to approve that change, it
was single-handedly made in the wiki by one person. This makes this policy
much more of a PITA than it could have been. It also shows that we aren't
even trusting PROVEN testers to reliably test a package! This is really
ridiculous!
2. FESCo also rejected an amendment I suggested to make sure that the
proventesters group should include at least one member of each of the main 4
desktops' SIGs. And in fact, no KDE SIG member was included in the initial
proventesters seed, despite Rex Dieter:
(i) having applied WEEKS before the proventesters group was seeded and
(ii) having YEARS of experience with approving freeze overrides, as he had
been processing freeze override requests all over the years in the old rel-
eng-Trac-ticket-based process.
This really hurts the abilities of SIGs to self-organize, instead promoting
a kind of centralized power distribution which just does not scale to our
evergrowing distribution. If you want KDE to be considered critical path,
you also have to allow KDE people to approve critical path packages. (In
fact, I think we actually need much more than one KDE proventester in the
long run.) And likewise for XFCE and LXDE.
IMHO, FESCo should be abolished, Fedora needs to be ruled by the SIGs!
Kevin Kofler
8:26 p.m.
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
IMHO, FESCo should be abolished, Fedora needs to be ruled by the
SIGs!
Why are you here? All you do is shout about how everything that is done
is done wrong, and how you wanted to do it different but were out-voted.
Why don't you go start your own distribution? If you are right, then
you should have no trouble getting a large group of developers,
producing an awesome OS, and then you can prove FESCo wrong.
Otherwise, give it a rest. I think everybody knows how you feel, please
stop reminding us. There's nothing productive about this.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:33 p.m.
Chris Adams wrote:
Why are you here? All you do is shout about how everything that is
done
is done wrong, and how you wanted to do it different but were out-voted.
Why don't you go start your own distribution? If you are right, then
you should have no trouble getting a large group of developers,
producing an awesome OS, and then you can prove FESCo wrong.
Are you providing the infrastructure?
A distribution needs a lot of infrastructure, not just manpower. (And
getting existing contributors to move to a new distribution is also not
going to happen overnight, even if it's clearly better. But that's moot in
the absence of infrastructure anyway.)
Kevin Kofler
12:11 a.m.
On Fri, 2010-08-13 at 03:33 +0200, Kevin Kofler wrote:
Chris Adams wrote:
> Why are you here? All you do is shout about how everything that is done
> is done wrong, and how you wanted to do it different but were out-voted.
> Why don't you go start your own distribution? If you are right, then
> you should have no trouble getting a large group of developers,
> producing an awesome OS, and then you can prove FESCo wrong.
Are you providing the infrastructure?
A distribution needs a lot of infrastructure, not just manpower. (And
getting existing contributors to move to a new distribution is also not
going to happen overnight, even if it's clearly better. [...])
Let's try that again. Fedora has no obligation to you; nothing entitles
you (or anyone for that matter) to push updates or even to post to this
list. It is the prerogative of the board or others acting on their
behalf to set the direction of the project and block you from
participating in ways they believe are harmful. Period.
Chris was suggesting that you might consider starting your own project
(which is always one's ultimate remedy in the F/OSS world), and that may
be difficult, but none of that changes the foregoing.
--
Matt
3:11 a.m.
On Friday, August 13, 2010 03:26:11 am Chris Adams wrote:
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
> IMHO, FESCo should be abolished, Fedora needs to be ruled by the SIGs!
Why are you here?
To work? Not to play politics games? Kevin is really one of the top Fedora
contributors.
All you do is shout about how everything that is done
is done wrong, and how you wanted to do it different but were out-voted.
Why don't you go start your own distribution? If you are right, then
you should have no trouble getting a large group of developers,
producing an awesome OS, and then you can prove FESCo wrong.
It would hurt all sides - it would hurt Fedora, the new distribution, our work
in Red Hat, users and so on. And I don't understand why we can't work under one
roof - to make Fedora the best OS. Maybe more autonomy for SIGs could help as
Kevin proposed?
Jaroslav
Otherwise, give it a rest. I think everybody knows how you feel,
please
stop reminding us. There's nothing productive about this.
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
10:08 a.m.
Jaroslav Reznik wrote:
It would hurt all sides - it would hurt Fedora, the new distribution,
our
work in Red Hat, users and so on. And I don't understand why we can't work
under one roof - to make Fedora the best OS. Maybe more autonomy for SIGs
could help as Kevin proposed?
Yeah, the SIGs are the ones who do the actual work, FESCo and the Board are
just political bureaucrats. Proper meritocracy means the SIGs get to decide.
Kevin Kofler
10:45 a.m.
On 08/13/2010 09:08 AM, Kevin Kofler wrote:
Jaroslav Reznik wrote:
> It would hurt all sides - it would hurt Fedora, the new distribution, our
> work in Red Hat, users and so on. And I don't understand why we can't work
> under one roof - to make Fedora the best OS. Maybe more autonomy for SIGs
> could help as Kevin proposed?
Yeah, the SIGs are the ones who do the actual work, FESCo and the Board are
just political bureaucrats. Proper meritocracy means the SIGs get to decide.
However you don't want to let other people decide anything. You want
patches FF and kernel in so you get to do it, you want to push updates
without any testing required so you get to. To hell with whatever anyone
else wants, and when there is an organization put in place to dictate
the rules by which we all play. They have the right to dictate these
rules because the group voted them in, and the majority of them decide
one way. It just happens not to be with what you think.
11:47 a.m.
Nathanael D. Noblet wrote:
However you don't want to let other people decide anything. You
want
patches FF and kernel in so you get to do it, you want to push updates
without any testing required so you get to. To hell with whatever anyone
else wants, and when there is an organization put in place to dictate
the rules by which we all play. They have the right to dictate these
rules because the group voted them in, and the majority of them decide
one way. It just happens not to be with what you think.
The people who voted them in were a small minority (most eligible
contributors don't vote), plus they didn't necessarily have the choice of
candidates they'd have liked to have (I know I didn't, to me those
candidates were a choice between the devil and the beelzebub). Our voting
system just doesn't work.
I tried many things, even running for FESCo and getting voted in. As you can
see, it didn't achieve anything either.
Kevin Kofler
12:43 p.m.
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
The people who voted them in were a small minority
As were the people that voted you in. Does that invalidate your FESCo
standing as well?
I tried many things, even running for FESCo and getting voted in. As
you can
see, it didn't achieve anything either.
Is it impossible for you to accept the fact that not everybody agrees
with you on the direction of Fedora, and that maybe (just maybe) you are
in the minority?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:47 p.m.
On Fri, 2010-08-13 at 12:43 -0500, Chris Adams wrote:
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
> I tried many things, even running for FESCo and getting voted in. As you can
> see, it didn't achieve anything either.
Is it impossible for you to accept the fact that not everybody agrees
with you on the direction of Fedora, and that maybe (just maybe) you are
in the minority?
Yes.
- ajax
2:57 a.m.
On Friday, August 13, 2010 03:10:46 am Kevin Kofler wrote:
I wrote:
> But FWIW, when it comes to KDE in particular, the whole thing is moot or
> soon to be moot anyway because parts of KDE are now being redefined as
> "critical path", resulting in even more annoying update policies, even
> though there was clear consensus in KDE SIG that such policies are
> neither necessary for nor of any benefit to KDE. FESCo just asked us to
> come up with a list of critical KDE packages and shut up. So we did. (My
> proposal to submit an empty list was voted down in KDE SIG on the
> grounds of being against the spirit of what FESCo asked of us, even
> though it did get some support due to our objections to the critical
> path process as a whole.) We (KDE SIG) have been more or less forced to
> participate in a process most of us (and me in particular) do not agree
> with and consider outright harmful.
PS:
1. The critical path update rules (and thus also the clause in the general
update rules which references them) were initially defined as requiring
only 1 proventester to approve. (This was left somewhat vague in the
actual policy, but 1 proventester was what was mentioned in all the
discussion inside FESCo.) This was modified to 1 proventester + 1 other
tester to match existing practice for freezes (the Critical Path Policy
implemented as part of No Frozen Rawhide). FESCo never actually voted to
approve that change, it was single-handedly made in the wiki by one
person. This makes this policy much more of a PITA than it could have
been. It also shows that we aren't even trusting PROVEN testers to
reliably test a package! This is really ridiculous!
2. FESCo also rejected an amendment I suggested to make sure that the
proventesters group should include at least one member of each of the main
4 desktops' SIGs. And in fact, no KDE SIG member was included in the
initial proventesters seed, despite Rex Dieter:
(i) having applied WEEKS before the proventesters group was seeded and
(ii) having YEARS of experience with approving freeze overrides, as he had
been processing freeze override requests all over the years in the old rel-
eng-Trac-ticket-based process.
This really hurts the abilities of SIGs to self-organize, instead promoting
a kind of centralized power distribution which just does not scale to our
evergrowing distribution. If you want KDE to be considered critical path,
you also have to allow KDE people to approve critical path packages. (In
fact, I think we actually need much more than one KDE proventester in the
long run.) And likewise for XFCE and LXDE.
Indeed - we need at least two proventesters for our purposes. And if others
don't trust our testing - provide Plasma Desktop testers for us ;-) Or let
exchange proventesters, we can test Desktop spin, you can test Plasma Desktop
spin - for objectivity. But we desperetely need proventesters once we're on the
list. I agreed to provide correct critical path list for Plasma Desktop as I
think it's really good idea but current situation is really very sad :( And as I
remember noone asked if we want to update the list after the policy was set - I
would vote against including Plasma Desktop in this kind implementation of
critical pathset. But I shut down - my fault I missed FESCo elections deadline,
next time ;-)
Jaroslav
IMHO, FESCo should be abolished, Fedora needs to be ruled by the
SIGs!
Kevin Kofler
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
6:23 p.m.
On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
> - Minimum time-in-testing requirements
> - Every day bodhi will look for updates that have been
> in testing for N days (fedora: N=7, epel: N=14), and will
> add a comment notifying the maintainer that the update is
> now able to be pushed to stable.
Suppose I submit a package to testing and it gets pushed. Six days
later, I find a terrible bug in the package (or a user reports this to
me). I fix the package and edit the update, request the fixed package
to be pushed to testing again and it gets pushed the next day.
Now without any further testing the package can be pushed to stable,
which contradicts the purpose of this whole change in bodhi.
I think, for packages that are modified during the testing period,
this N should be calculated from the day the last push was made to
testing.
Yes, this was my initial intention. However, looking at the code a bit
closer, your scenario would currently be allowed, as it currently only
calculates the time-in-testing based on the first push to testing.
Fixed in
https://fedorahosted.org/bodhi/changeset/97b1a9d1f9ceecaaa2128837cc5bbd7f...
luke
6:27 p.m.
Luke Macken wrote:
That "fix" is really unhelpful and makes it a PITA to edit updates! In the
past, KDE SIG has often edited in some trivial fixes into the final stable
push of a KDE grouped update which has been in testing for a long time. Your
"fix" breaks that. Plus, edits can also be only to the description or bug
references, Bodhi doesn't allow me to edit those without editing the whole
update.
Kevin Kofler
3:13 a.m.
On Friday, August 13, 2010 01:27:18 am Kevin Kofler wrote:
Luke Macken wrote:
> Fixed in
> https://fedorahosted.org/bodhi/changeset/97b1a9d1f9ceecaaa2128837cc5bbd7f
> 8e495f36
That "fix" is really unhelpful and makes it a PITA to edit updates! In the
past, KDE SIG has often edited in some trivial fixes into the final stable
push of a KDE grouped update which has been in testing for a long time.
Your "fix" breaks that. Plus, edits can also be only to the description or
bug references, Bodhi doesn't allow me to edit those without editing the
whole update.
Then we have to push broken updates, policy says so and it's ok, so let's do it
:(
Jaroslav
Kevin Kofler
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
10:17 a.m.
On Friday, August 13, 2010 05:09:17 pm Kevin Kofler wrote:
Jaroslav Reznik wrote:
> Then we have to push broken updates, policy says so and it's ok, so let's
> do it
>
> :(
A policy requiring us to push something broken is broken. I'm not going to
push broken shit.
Just irony but it feels like...
Jaroslav
Kevin Kofler
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
12:21 p.m.
On Fri, 2010-08-13 at 17:17 +0200, Jaroslav Reznik wrote:
On Friday, August 13, 2010 05:09:17 pm Kevin Kofler wrote:
> Jaroslav Reznik wrote:
> > Then we have to push broken updates, policy says so and it's ok, so
let's
> > do it
> >
> > :(
>
> A policy requiring us to push something broken is broken. I'm not going to
> push broken shit.
Just irony but it feels like...
I wonder why I get the impression that the only ones who strongly oppose
this change are you folks from KDE SIG... Are you doing things
differently from anyone else in fedora - the rest of us are either more
or less neutral or positive towards this new change?
Basically from both user and maintainer point of view I'm for more
testing and more conservative update policy in general in stable
branches.
Cheers,
Martin
1:14 p.m.
Martin Sourada wrote:
I wonder why I get the impression that the only ones who strongly
oppose
this change are you folks from KDE SIG... Are you doing things
differently from anyone else in fedora - the rest of us are either more
or less neutral or positive towards this new change?
If we really are the only ones true to Fedora's original principles, who
don't want us to become yet another redundant conservative distribution
(like all those bazillion others out there), that's really sad. :-(
Kevin Kofler
(who wants the Fedora he learned to love back!)
1:24 p.m.
On Fri, 2010-08-13 at 20:14 +0200, Kevin Kofler wrote:
Martin Sourada wrote:
> I wonder why I get the impression that the only ones who strongly oppose
> this change are you folks from KDE SIG... Are you doing things
> differently from anyone else in fedora - the rest of us are either more
> or less neutral or positive towards this new change?
If we really are the only ones true to Fedora's original principles, who
don't want us to become yet another redundant conservative distribution
(like all those bazillion others out there), that's really sad. :-(
Kevin Kofler
(who wants the Fedora he learned to love back!)
It is not the fedora you think it is. You can go form your own distro.
Please leave us to work on ours in peace and relative quiet.
I hear Bero could use some help with arklinux.
kthxbai
-sv
1:36 p.m.
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
If we really are the only ones true to Fedora's original
principles
As I recall, "upstream, upstream, upstream" was one of those principles
that you are demanding others now break.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:14 p.m.
On Fri 13 August 2010 11:36:09 Chris Adams wrote:
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
> If we really are the only ones true to Fedora's original principles
As I recall, "upstream, upstream, upstream" was one of those principles
that you are demanding others now break.
And the same policy that YOU (you as in the Board and FESCo, not Chris Adams
in particular) are asking us to break with the updates policy and general
distaste for a fast moving distro.
When it comes down to it, KDE and The Board's Fedora simply don't work
together, and that is basically what Kev is getting so miffed about, as far as
I can tell. Yes, he's loud, yes he's fiery, but damn, at least he cares, and I
don't blame him for caring. He's put a lot of heart and a lot of effort into
Fedora, as has everyone in the KDE SIG, and the entire Project. We could fork,
hell the KDE SIG has talked about it in the past, but it hurts everyone
involved. Everyone.
I've put a lot of thought into simply stepping away from Fedora, at least on
the KDE end of things if these changes go through because, in some ways, the
Board's vision will change things for us, and for me in particular. I joined
Fedora as a distribution whose goals and processes catered towards creating a
KDE environment which simply kicked ass, was always on the edge of what was
available (sometimes in front of it)... Yet even now, we can't keep up with
what (some of) our users want: the latest KDE, on KDE's release day, whether
it's a major release, or a point release. Yes, not every one of our users is
this way, but many are, and many use Fedora for this very reason. How do we
keep everyone happy? If we're a distro pushing the development of open source,
shouldn't we be pushing it towards those types of users? We could make rawhide
usable, but that can stub development of some major features, it's a tough
medium. We could fork Fn+1 even earlier, and make it stabler and have 12
months in Rawhide... There are solutions to our problems, but endless
bickering and "oh you should just leave!"s aren't going to solve anything
and
just leave everyone in a pissy and unproductive mood. Personally, it depresses
the hell out of me.
Btw, everyone seems to be acting really unexcellent to each other... I'm not
calling anyone, but both "sides" of this are really getting out of control...
Please keep the mailing list friendly. We don't "have" hall monitors
anymore,
but reading this mailing list shouldn't effect my blood pressure as much as it
does.
Ryan "just another POV, back to the shadows" Rix
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==
9:29 a.m.
Ryan Rix (ry(a)n.rix.si) said:
available (sometimes in front of it)... Yet even now, we can't
keep up with
what (some of) our users want: the latest KDE, on KDE's release day, whether
it's a major release, or a point release. Yes, not every one of our users is
this way, but many are, and many use Fedora for this very reason. How do we
keep everyone happy?
I think the simplest way is to start with a stable repo, for those that want
that, and then build something on top of that? You can build some
faster-moving feature packages on top of a stable base for those that want
it. You can't do the reverse. (See the 'optional repo for feature updates'
that's
in the propsal... I suspect that people would love help in getting that set up
and running sanely.)
Bill
2:53 p.m.
Bill Nottingham wrote:
You can build some faster-moving feature packages on top of a stable
base
for those that want it.
In theory you can. In practice that turns out to work rather poorly. It's
the model several other distros are using; their "feature updates"
repositories are always underused by maintainers, poorly supported, used by
many users in a selective fashion (which causes dependency issues) etc. It
also means there are effectively 2 incompatible versions of "Fedora n",
unless we ban library upgrades altogether, which makes it impossible to
provide e.g. a current KDE (something which also plagues other distros'
implementations of this idea; often, KDE updates are in yet another separate
repo etc.).
I think the way we've been handling this – upgrade or get lost – is the only
one that works.
That said, of course I prefer having an 'optional repo for feature updates'
than not being allowed to push them on Fedora infrastructure at all. It's
just that I doubt about the viability of the idea.
I also have some concern about the actual implementation: I've read that one
idea that was floated was to shut down updates-features for Fn after the
Fn+1 release. But that means people who use updates-features effectively
have their support cycle cut by half! (It is not feasible to downgrade to
the conservative updates, and the stuff installed from updates-features also
requires security fixes!) (And in fact this kind of second-class support is
exactly one of the problems of having the features relegated to a separate
repo.)
Kevin Kofler
2:53 p.m.
On Fri, 2010-08-13 at 20:14 +0200, Kevin Kofler wrote:
Martin Sourada wrote:
> I wonder why I get the impression that the only ones who strongly oppose
> this change are you folks from KDE SIG... Are you doing things
> differently from anyone else in fedora - the rest of us are either more
> or less neutral or positive towards this new change?
If we really are the only ones true to Fedora's original principles, who
don't want us to become yet another redundant conservative distribution
(like all those bazillion others out there), that's really sad. :-(
Oh, yeah, to that fedora where every third upgrade broke half of desktop
and another had broken deps... (sarcastic exaggeration intended).
There are also bazillion distributions out there who are on the bleeding
edge. Being conservative with our stable releases while innovative in
rawhide is what fedora should strive to be (with the usually friendly
atmosphere among the contributors and "upstream, upstream, upstream").
Kevin Kofler
(who wants the Fedora he learned to love back!)
Martin Sourada
(who wants *stable* releases of Fedora to be stable and not
another rawhide)
3:32 a.m.
Martin Sourada wrote:
There are also bazillion distributions out there who are on the
bleeding
edge.
But none that have the current stuff without blatant breakage as updates to
the stable releases, and ship the exciting but disruptive changes in new
releases every 6 months, while still supporting the previous release for 7
more months from that point.
There's a balance between bleeding edge and conservativeness. Fedora was
exactly where I, and many other people, who chose Fedora exactly for that
reason (just look at some of the user feedback, e.g. Adam Williamson's poll
on the Fedora Forums, some mails to the kde(a)lists.fp.o ML etc., I'm not
inventing that "many other people" part), wanted it to be on that balance
(except for some odd packages like Firefox and OO.o where the maintainers
did their own thing, basically already following what the new unwanted
policy will be). Now new policies are tilting the scale way too far towards
conservativeness, to the point where we don't distinguish us anymore from
other distributions; Rawhide, on the other hand, is way too far on the
bleeding edge end to be usable for daily use, and this is exactly the issue
with other "bleeding edge" distributions as well.
Not all new upstream versions are equal. New versions with major changes,
especially feature regressions, are NOT suitable as updates to a stable work
environment. Version upgrades WITHOUT such breakage ARE suitable, and
actually WANTED as updates. For example, people EXPECT to be able to use the
latest Firefox (and have complained about the Firefox maintainer being too
conservative with his updates), the latest KDE (and have praised KDE SIG for
being so effective at pushing new versions) etc.
Kevin Kofler
6:03 a.m.
On Sat, 2010-08-14 at 10:32 +0200, Kevin Kofler wrote:
Martin Sourada wrote:
> There are also bazillion distributions out there who are on the bleeding
> edge.
But none that have the current stuff without blatant breakage as updates to
the stable releases, and ship the exciting but disruptive changes in new
releases every 6 months, while still supporting the previous release for 7
more months from that point.
There's a balance between bleeding edge and conservativeness. Fedora was
exactly where I, and many other people, who chose Fedora exactly for that
reason (just look at some of the user feedback, e.g. Adam Williamson's poll
on the Fedora Forums, some mails to the kde(a)lists.fp.o ML etc., I'm not
inventing that "many other people" part), wanted it to be on that balance
(except for some odd packages like Firefox and OO.o where the maintainers
did their own thing, basically already following what the new unwanted
policy will be). Now new policies are tilting the scale way too far towards
conservativeness, to the point where we don't distinguish us anymore from
other distributions; Rawhide, on the other hand, is way too far on the
bleeding edge end to be usable for daily use, and this is exactly the issue
with other "bleeding edge" distributions as well.
Not all new upstream versions are equal. New versions with major changes,
especially feature regressions, are NOT suitable as updates to a stable work
environment. Version upgrades WITHOUT such breakage ARE suitable, and
actually WANTED as updates. For example, people EXPECT to be able to use the
latest Firefox (and have complained about the Firefox maintainer being too
conservative with his updates), the latest KDE (and have praised KDE SIG for
being so effective at pushing new versions) etc.
Hehe, I agree here with a lot of what you say, as well as disagree with
a lot of what you say. I generally don't think we should ban enhancement
updates completely, but things like major firefox/kde/gnome/Xorg/kernel
are usually too much. In the past, when I was still using firefox, I
wasn't especially thrilled with it's stability, especially with new
major releases, I still remember the epic fail of having KDE 4.0 in
stable fedora and I now I'm experiencing the trying to push immature
GNOME 3.0 (luckily it was decided in time to push it back another half a
year)...
I like that Fedora is bleeding edge in rawhide, recieves good deal of
testing *before* release and is more or less conservative when it comes
to important stuff after release. That way we can provide our users with
*stable* but sufficiently modern stuff (in many areas even a few months
ahead of other distros). And I think the new policy aligns pretty well
with this.
Martin
12:05 p.m.
Martin Sourada wrote:
I still remember the epic fail of having KDE 4.0 in stable fedora
* I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed all
the showstoppers before F9 was released, and were also quick to ship updates
fixing more annoyances, including updates to later 4.0.x releases. Yes, I
used F9 with 4.0.x myself, one one machine.
* KDE 4.0 wasn't an update at all! It was what was shipped with a NEW
release. We intentionally DID NOT update F8 to KDE 4.x. Not 4.0, not 4.1,
not ever. This kind of changes is exactly what we have releases for and why
rolling release models are not usable for production.
* Version updates, the very ones you complain about, brought that 4.0 up to
4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to F9's
EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually one of the
stablest Fedoras I used. (For example, F10 had issues with my hardware's
ALSA driver affecting PulseAudio, F11 with the graphics driver.)
I like that Fedora is bleeding edge in rawhide, recieves good deal
of
testing *before* release and is more or less conservative when it comes
to important stuff after release. That way we can provide our users with
*stable* but sufficiently modern stuff (in many areas even a few months
ahead of other distros). And I think the new policy aligns pretty well
with this.
KDE 4.0 was a result of "Fedora [being] bleeding edge in rawhide", this was
NOT pushed "after release". And it DID receive a "good deal of testing
*before* release". We were very hard at work fixing showstoppers resp.
getting them fixed upstream, it would have been much worse otherwise! If you
had compared the pre-4.0 prerelease which was initially imported into
Rawhide with the 4.0.3 + patches we shipped in F9, you'd have noticed that
there were worlds of differences in reliability and glitch-freeness! A lot
of the bugs that were fixed were reported by Rawhide or kde-redhat unstable
users, some of them were fixed by Fedora developers.
The NON-conservative updates are what brought 4.1 and 4.2 to the F9 release,
resolving many of the complaints users had about 4.0.
Kevin Kofler
12:57 p.m.
On Sat, 2010-08-14 at 19:05 +0200, Kevin Kofler wrote:
Martin Sourada wrote:
> I still remember the epic fail of having KDE 4.0 in stable fedora
* I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed all
the showstoppers before F9 was released, and were also quick to ship updates
fixing more annoyances, including updates to later 4.0.x releases. Yes, I
used F9 with 4.0.x myself, one one machine.
Well, I believe most people would
disagree with you here. Many of KDE
user switched temporarily to other DEs because of this, or stayed with
F8...
* KDE 4.0 wasn't an update at all! It was what was shipped with a
NEW
release. We intentionally DID NOT update F8 to KDE 4.x. Not 4.0, not 4.1,
not ever. This kind of changes is exactly what we have releases for and why
rolling release models are not usable for production.
KDE 4.0 wasn't feature
complete, I would call it at the very best Beta
of KDE4. And yet you pushed it to *stable* release. Yes, during the
development time, not as an update, but still have done it.
* Version updates, the very ones you complain about, brought that 4.0
up to
4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to F9's
EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually one of the
stablest Fedoras I used. (For example, F10 had issues with my hardware's
ALSA driver affecting PulseAudio, F11 with the graphics driver.)
Well, the problem was that you pushed KDE 4.0 in the first place. Given
the state of things, you had very *strong* reasons to update to KDE 4.1
and 4.2. And yes, pulseaudio was IMHO pushed one release earlier than
would be ideal as well...
> I like that Fedora is bleeding edge in rawhide, recieves good
deal of
> testing *before* release and is more or less conservative when it comes
> to important stuff after release. That way we can provide our users with
> *stable* but sufficiently modern stuff (in many areas even a few months
> ahead of other distros). And I think the new policy aligns pretty well
> with this.
KDE 4.0 was a result of "Fedora [being] bleeding edge in rawhide", this was
NOT pushed "after release". And it DID receive a "good deal of testing
*before* release". We were very hard at work fixing showstoppers resp.
getting them fixed upstream, it would have been much worse otherwise! If you
had compared the pre-4.0 prerelease which was initially imported into
Rawhide with the 4.0.3 + patches we shipped in F9, you'd have noticed that
there were worlds of differences in reliability and glitch-freeness! A lot
of the bugs that were fixed were reported by Rawhide or kde-redhat unstable
users, some of them were fixed by Fedora developers.
Well, KDE 4.0 was an example of what should have been reverted during
the stabilization pre-release phase (similar to what's now happening
with gnome 3.0, although with gnome it's the upstream that is sane
enough to not release it yet). It was not ready for prime time, IMHO.
And as outlined above, I believe that 4.1 and 4.2 were necessary
updates, precisely the type where there are strong reasons to push them
despite the big number of changes (but require *a lot* of testing).
The NON-conservative updates are what brought 4.1 and 4.2 to the F9
release,
resolving many of the complaints users had about 4.0.
No, given the situation, these were semi-conservative. They fixed
zillions of regressions and bugs...
Martin
9:32 a.m.
On Sat, 2010-08-14 at 19:57 +0200, Martin Sourada wrote:
On Sat, 2010-08-14 at 19:05 +0200, Kevin Kofler wrote:
> * Version updates, the very ones you complain about, brought that 4.0 up to
> 4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to F9's
> EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually one of the
> stablest Fedoras I used. (For example, F10 had issues with my hardware's
> ALSA driver affecting PulseAudio, F11 with the graphics driver.)
>
Well, the problem was that you pushed KDE 4.0 in the first place. Given
the state of things, you had very *strong* reasons to update to KDE 4.1
and 4.2. And yes, pulseaudio was IMHO pushed one release earlier than
would be ideal as well...
But note, that nothing in the Fedora update policy changes would prevent
from the same push during the _development_ phase either. So you might
be dissatisfied with the KDE-4.0 in F9 but this can happen with other
packages or package stacks in new Fedora releases regardless of the
update policy changes. So it is completely irrelevant to the debate
here. And actually with the 'conservative update' policy once something
like KDE-4.0 is in the _final_ release of a Fedora, it will have to stay
there till the EOL of the release.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
2:55 p.m.
Tomas Mraz wrote:
But note, that nothing in the Fedora update policy changes would
prevent
from the same push during the _development_ phase either. So you might
be dissatisfied with the KDE-4.0 in F9 but this can happen with other
packages or package stacks in new Fedora releases regardless of the
update policy changes. So it is completely irrelevant to the debate
here. And actually with the 'conservative update' policy once something
like KDE-4.0 is in the _final_ release of a Fedora, it will have to stay
there till the EOL of the release.
Right, that's exactly why that conservative policy is broken.
Kevin Kofler
10:41 a.m.
On Saturday, August 14, 2010 07:57:27 pm Martin Sourada wrote:
On Sat, 2010-08-14 at 19:05 +0200, Kevin Kofler wrote:
> Martin Sourada wrote:
> > I still remember the epic fail of having KDE 4.0 in stable fedora
>
> * I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed
> all the showstoppers before F9 was released, and were also quick to ship
> updates fixing more annoyances, including updates to later 4.0.x
> releases. Yes, I used F9 with 4.0.x myself, one one machine.
Well, I believe most people would disagree with you here. Many of KDE
user switched temporarily to other DEs because of this, or stayed with
F8...
I switch to KDE 4.0 in early beta and from that time, I couldn't use any other
DE ;-) Just a users preference.
> * KDE 4.0 wasn't an update at all! It was what was shipped
with a NEW
> release. We intentionally DID NOT update F8 to KDE 4.x. Not 4.0, not 4.1,
> not ever. This kind of changes is exactly what we have releases for and
> why rolling release models are not usable for production.
KDE 4.0 wasn't feature complete, I would call it at the very best Beta
of KDE4. And yet you pushed it to *stable* release. Yes, during the
development time, not as an update, but still have done it.
KDE 3.x was just EOL. Maybe upstream should wait with 4.0 release but we
wouldn't have very nice and stable KDE 4.5 right now... It's open source, the
way how it works... And as Kevin said - that's why we have two releases in the
wild - one stable (F8), one progressive (F9). Otherwise we don't need more
than one release out there (maintenance overhead).
> * Version updates, the very ones you complain about, brought
that 4.0 up
> to 4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to
> F9's EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually
> one of the stablest Fedoras I used. (For example, F10 had issues with my
> hardware's ALSA driver affecting PulseAudio, F11 with the graphics
> driver.)
Well, the problem was that you pushed KDE 4.0 in the first place. Given
the state of things, you had very *strong* reasons to update to KDE 4.1
and 4.2. And yes, pulseaudio was IMHO pushed one release earlier than
would be ideal as well...
And we did it - now we can slow down - we'd like to go with one major update
for a Fedora release. Not only PA, the whole desktop stack ;-)
> > I like that Fedora is bleeding edge in rawhide, recieves
good deal of
> > testing *before* release and is more or less conservative when it comes
> > to important stuff after release. That way we can provide our users
> > with *stable* but sufficiently modern stuff (in many areas even a few
> > months ahead of other distros). And I think the new policy aligns
> > pretty well with this.
>
> KDE 4.0 was a result of "Fedora [being] bleeding edge in rawhide", this
> was NOT pushed "after release". And it DID receive a "good deal of
> testing *before* release". We were very hard at work fixing showstoppers
> resp. getting them fixed upstream, it would have been much worse
> otherwise! If you had compared the pre-4.0 prerelease which was
> initially imported into Rawhide with the 4.0.3 + patches we shipped in
> F9, you'd have noticed that there were worlds of differences in
> reliability and glitch-freeness! A lot of the bugs that were fixed were
> reported by Rawhide or kde-redhat unstable users, some of them were
> fixed by Fedora developers.
Well, KDE 4.0 was an example of what should have been reverted during
the stabilization pre-release phase (similar to what's now happening
with gnome 3.0, although with gnome it's the upstream that is sane
enough to not release it yet). It was not ready for prime time, IMHO.
And as outlined above, I believe that 4.1 and 4.2 were necessary
updates, precisely the type where there are strong reasons to push them
despite the big number of changes (but require *a lot* of testing).
Yes - upstream decision. KDE upstream decided to go with 4.0... Gnome did not.
We couldn't support old KDE. And I heard - Gnome guys now have big troubles -
everyone is working on 3.0 and no one wants to take care about old one, even
still official and supported one! But it's a decision. I don't want to rule all,
we are not Microsoft :D
Jaroslav
> The NON-conservative updates are what brought 4.1 and 4.2 to the
F9
> release, resolving many of the complaints users had about 4.0.
No, given the situation, these were semi-conservative. They fixed
zillions of regressions and bugs...
Martin
2:09 p.m.
On Sat, Aug 14, 2010 at 8:05 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Martin Sourada wrote:
> I still remember the epic fail of having KDE 4.0 in stable fedora
* I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed all
the showstoppers before F9 was released, and were also quick to ship updates
fixing more annoyances, including updates to later 4.0.x releases. Yes, I
used F9 with 4.0.x myself, one one machine.
Wow, you actually used F9 yourself (on one machine)? What an accomplishment.
* KDE 4.0 wasn't an update at all! It was what was shipped with a
NEW
release. We intentionally DID NOT update F8 to KDE 4.x. Not 4.0, not 4.1,
not ever. This kind of changes is exactly what we have releases for and why
rolling release models are not usable for production.
* Version updates, the very ones you complain about, brought that 4.0 up to
4.1 and later 4.2. I used F9 on my main machine from F8's EOL up to F9's
EOL. F9 with KDE 4.2 (and IMHO even 4.1) was rock solid, actually one of the
stablest Fedoras I used. (For example, F10 had issues with my hardware's
ALSA driver affecting PulseAudio, F11 with the graphics driver.)
Are you seriously trying to say that you updated your own machine to
Fedora 9 (KDE 4) 7 (!) months after it was rolled out? I have no
words.
Good work using everybody else as your test subjects: when they have
ironed out all the bugs, you finally update your own computer.
M.T.
9:12 p.m.
On Sat, Aug 14, 2010 at 13:09, List Troll <mrlisttroll(a)gmail.com> wrote:
On Sat, Aug 14, 2010 at 8:05 PM, Kevin Kofler
<kevin.kofler(a)chello.at> wrote:
> Martin Sourada wrote:
>> I still remember the epic fail of having KDE 4.0 in stable fedora
>
> * I still think the KDE 4.0.3 we shipped in F9 wasn't that bad. We fixed all
> the showstoppers before F9 was released, and were also quick to ship updates
> fixing more annoyances, including updates to later 4.0.x releases. Yes, I
> used F9 with 4.0.x myself, one one machine.
Wow, you actually used F9 yourself (on one machine)? What an accomplishment.
Stop. This is neither useful, being excellent or anything else beyond
throwing ape-cakes to see who else gets caught up in it.
--
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines
1:17 p.m.
Martin Sourada wrote:
I wonder why I get the impression that the only ones who strongly
oppose
this change are you folks from KDE SIG... Are you doing things
differently from anyone else in fedora - the rest of us are either more
or less neutral or positive towards this new change?
Oh, and FYI, Ralf Corsepius is not in KDE SIG. Yet, he also doesn't like
this policy, as you can clearly see from his replies in this thread and
elsewhere. So your impression is wrong.
Kevin Kofler
2:40 p.m.
On Fri, 2010-08-13 at 20:17 +0200, Kevin Kofler wrote:
Martin Sourada wrote:
> I wonder why I get the impression that the only ones who strongly oppose
> this change are you folks from KDE SIG... Are you doing things
> differently from anyone else in fedora - the rest of us are either more
> or less neutral or positive towards this new change?
Oh, and FYI, Ralf Corsepius is not in KDE SIG. Yet, he also doesn't like
this policy, as you can clearly see from his replies in this thread and
elsewhere. So your impression is wrong.
My bad...
Martin
2:39 p.m.
On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
On Fri, 2010-08-13 at 17:17 +0200, Jaroslav Reznik wrote:
> On Friday, August 13, 2010 05:09:17 pm Kevin Kofler wrote:
> > Jaroslav Reznik wrote:
> > > Then we have to push broken updates, policy says so and it's ok, so
let's
> > > do it
> > >
> > > :(
> >
> > A policy requiring us to push something broken is broken. I'm not going to
> > push broken shit.
>
> Just irony but it feels like...
>
I wonder why I get the impression that the only ones who strongly oppose
this change are you folks from KDE SIG... Are you doing things
differently from anyone else in fedora - the rest of us are either more
or less neutral or positive towards this new change?
Basically from both user and maintainer point of view I'm for more
testing and more conservative update policy in general in stable
branches.
I'm negative towards this change and not part of the KDE SIG but don't
really like to clutter up the mailing lists with a bunch of negative energy.
And I don't like the way it makes me feel about Fedora to continually try to
get a compromise solution that accomodates everyone when none of the parties
with the power to change things want to be reasonable. (This is probably an
oversimplification.... I know at least one person who sat on FESCo at the
time of this change being passed feeling the same way I do about needing
a compromise and not being heard when they tried to ask for one.
Ironically, they are right that they were drowned out by the combative
voices on both sides... I don't even remember when they mentioned the
compromise solution there were so many other strident voices.)
So I've kept my voice out of this... and hopefully, now that you know that
it's not just hte KDE SIG, I can go back to doing so again.
-Toshio
5:09 p.m.
On Fri, 13 Aug 2010 15:39:59 -0400
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
I'm negative towards this change and not part of the KDE SIG but
don't
really like to clutter up the mailing lists with a bunch of negative
energy. And I don't like the way it makes me feel about Fedora to
continually try to get a compromise solution that accomodates
everyone when none of the parties with the power to change things
want to be reasonable. (This is probably an oversimplification.... I
know at least one person who sat on FESCo at the time of this change
being passed feeling the same way I do about needing a compromise and
not being heard when they tried to ask for one. Ironically, they are
right that they were drowned out by the combative voices on both
sides... I don't even remember when they mentioned the compromise
solution there were so many other strident voices.)
Yeah. I for one appreciate your collecting ideas and helping to try and
broker a compromise, even though this didn't end up happening. ;(
Sorry you feel negative about the changes.
So I've kept my voice out of this... and hopefully, now that you
know
that it's not just hte KDE SIG, I can go back to doing so again.
I would like folks to keep in mind a few other things:
1. We are changing things to help improve stability of our stable
releases. These changes may fail to help, or may be too far toward the
stable side of things. We can adjust them and revise them, but give
them a chance first?
2. FESCo is working on implementing the Board's "Stable release
vision":
https://fedoraproject.org/wiki/Stable_release_updates_vision
and our implementation containers:
https://fedorahosted.org/fesco/ticket/382
https://fedoraproject.org/wiki/Stable_release_updates_vision_implementati...
Not to pass the buck, but if you have issues with the Stable release
updates vision from the Board, you can talk to them on their list about
it. If you have issues with our implementation of it, feel free to
chime in with constructive ideas above or on this list.
kevin
12:33 p.m.
Toshio Kuratomi (a.badger(a)gmail.com) said:
So I've kept my voice out of this... and hopefully, now that you
know that
it's not just hte KDE SIG, I can go back to doing so again.
... how does that help?
You've mentioned that you don't like 'this change' ... which part of it
are
you referring to? The changes in what critical path entails? The change to
handling of non-critical path? The entire idea of bodhi? etc.
Bill
4:17 p.m.
On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
I wonder why I get the impression that the only ones who strongly
oppose this change are you folks from KDE SIG... Are you doing things
differently from anyone else in fedora - the rest of us are either
more or less neutral or positive towards this new change?
I don't think that this about the KDE SIG at all.
Not everyone is as passionate (or stubborn) as Kevin.
Most fedorians I talk to are watching all the discussions to see if
the fedora that is currently being formed with all the changes that
are happening is still a distribution that they're comfortable
contributing to. And as the only way to get heard is to fuel a
flamewar on fedora-devel they just stay silent.
[...] I'm for more testing and more conservative update policy
in
general in stable branches.
I don't oppose the ongoing changes in general but still - when I read
through fesco meeting logs I am often disappointed by the amount of
politics going on and more than once I wished that FESCO as a whole
would grow a pair.
I for one have decided that I'm going to stop contributing if the
'Stable Update Vision' is going to be implemented as currently
discussed. If the powers that be are going to stop maintainers from
issuing updates that are not security or bugfix updates then fedora will
have turned into a distro that I'm not interested in.
--
sven === jabber/xmpp: sven(a)lankes.net
5:12 p.m.
On Fri, 13 Aug 2010 23:17:39 +0200
Sven Lankes <sven(a)lank.es> wrote:
On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
> I wonder why I get the impression that the only ones who strongly
> oppose this change are you folks from KDE SIG... Are you doing
> things differently from anyone else in fedora - the rest of us are
> either more or less neutral or positive towards this new change?
I don't think that this about the KDE SIG at all.
Not everyone is as passionate (or stubborn) as Kevin.
I agree.
Most fedorians I talk to are watching all the discussions to see if
the fedora that is currently being formed with all the changes that
are happening is still a distribution that they're comfortable
contributing to. And as the only way to get heard is to fuel a
flamewar on fedora-devel they just stay silent.
I think the flamewars are making people think this is a bigger deal
than it really is.
> [...] I'm for more testing and more conservative update
policy in
> general in stable branches.
I don't oppose the ongoing changes in general but still - when I read
through fesco meeting logs I am often disappointed by the amount of
politics going on and more than once I wished that FESCO as a whole
would grow a pair.
Can you expand on that? I'm not sure what you mean...
I for one have decided that I'm going to stop contributing if
the
'Stable Update Vision' is going to be implemented as currently
discussed. If the powers that be are going to stop maintainers from
issuing updates that are not security or bugfix updates then fedora
will have turned into a distro that I'm not interested in.
Bring your concerns to the Board that issued the vision statement?
I personally think the "just security and bugfixes" is too strong.
I am going to try and push for an exceptions process that takes into
account upstreams that don't release in a way thats compatible with
fedora's release cycle.
I hope you won't be hasty and will try and work with whatever framework
we end up with and help us adjust it.
kevin
5:37 p.m.
On Fri, 2010-08-13 at 16:12 -0600, Kevin Fenzi wrote:
On Fri, 13 Aug 2010 23:17:39 +0200
Sven Lankes <sven(a)lank.es> wrote:
> On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
>
> > I wonder why I get the impression that the only ones who strongly
> > oppose this change are you folks from KDE SIG... Are you doing
> > things differently from anyone else in fedora - the rest of us are
> > either more or less neutral or positive towards this new change?
>
> I don't think that this about the KDE SIG at all.
>
> Not everyone is as passionate (or stubborn) as Kevin.
I agree.
> Most fedorians I talk to are watching all the discussions to see if
> the fedora that is currently being formed with all the changes that
> are happening is still a distribution that they're comfortable
> contributing to. And as the only way to get heard is to fuel a
> flamewar on fedora-devel they just stay silent.
I think the flamewars are making people think this is a bigger deal
than it really is.
> > [...] I'm for more testing and more conservative update policy in
> > general in stable branches.
>
> I don't oppose the ongoing changes in general but still - when I read
> through fesco meeting logs I am often disappointed by the amount of
> politics going on and more than once I wished that FESCO as a whole
> would grow a pair.
Can you expand on that? I'm not sure what you mean...
> I for one have decided that I'm going to stop contributing if the
> 'Stable Update Vision' is going to be implemented as currently
> discussed. If the powers that be are going to stop maintainers from
> issuing updates that are not security or bugfix updates then fedora
> will have turned into a distro that I'm not interested in.
Bring your concerns to the Board that issued the vision statement?
I personally think the "just security and bugfixes" is too strong.
I am going to try and push for an exceptions process that takes into
account upstreams that don't release in a way thats compatible with
fedora's release cycle.
I think that a distinction can be made between core packages that many
different components depend upon versus "leaf" packages that do their
own thing and no other component relies on. I do think we should be
conservative when updating core components in released versions of
Fedora; with rawhide much less so. But perhaps "leaf" packages can have
a less conservative policy.
When it comes to package updates, I don't think "one size fits all". I
wrote up some notes on other possible variables that should be
considered back in March here:
http://dmalcolm.livejournal.com/5013.html
My hope is that it ought to be possible to take the variables I mention
in that blog post and come up with some kind of coherent policy that
everyone is happy with, or, at least, not unhappy.
I hope you won't be hasty and will try and work with whatever
framework
we end up with and help us adjust it.
Agreed
Hope this is helpful
Dave
4:07 a.m.
David Malcolm wrote:
I think that a distinction can be made between core packages that
many
different components depend upon versus "leaf" packages that do their
own thing and no other component relies on. I do think we should be
conservative when updating core components in released versions of
Fedora; with rawhide much less so. But perhaps "leaf" packages can have
a less conservative policy.
Well, a backwards-compatible update to a core library isn't normally a
problem. Of course it doesn't make sense to push a soname bump of something
like Boost to a stable release. An update of something guaranteeing
backwards binary compatibility, e.g. Qt or KDE, on the other hand, is quite
safe to push, after adequate testing. And "leaf" also needs to be qualified,
a library that's used by only a small number of applications can be updated
to a binary-incompatible version in a grouped update with the affected
applications: for example, this has often been done to add new hardware
support to libmtp and a few other such libraries, and those updates have
been very nice for the people with the affected hardware and didn't cause
any trouble for anyone else.
Kevin Kofler
5:53 a.m.
On Sat, 2010-08-14 at 11:07 +0200, Kevin Kofler wrote:
David Malcolm wrote:
> I think that a distinction can be made between core packages that many
> different components depend upon versus "leaf" packages that do their
> own thing and no other component relies on. I do think we should be
> conservative when updating core components in released versions of
> Fedora; with rawhide much less so. But perhaps "leaf" packages can have
> a less conservative policy.
Well, a backwards-compatible update to a core library isn't normally a
problem. Of course it doesn't make sense to push a soname bump of something
like Boost to a stable release. An update of something guaranteeing
backwards binary compatibility, e.g. Qt or KDE, on the other hand, is quite
safe to push, after adequate testing. And "leaf" also needs to be qualified,
a library that's used by only a small number of applications can be updated
to a binary-incompatible version in a grouped update with the affected
applications: for example, this has often been done to add new hardware
support to libmtp and a few other such libraries, and those updates have
been very nice for the people with the affected hardware and didn't cause
any trouble for anyone else.
IMHO, labriaries should be updated in stable release only if there's no
backwards-incompatible change or if there's a really strong reason to
update that outweights the problems caused by API/ABI change. We could
probably be much more lenient with end-user apss, but proper testing is
always a must (and yes, more testers would be *very* helpful).
Seeing your mail, you more or less agree with this. So why exactly are
you against the policy explicitly requiring either positive karma or
some minimal time in testing (setting aside some current shrotcommings
of the implementation like resetting the timer on bug update when you
just add/remove fixed bug or edit update comment)?
Martin
12:14 p.m.
Martin Sourada wrote:
Seeing your mail, you more or less agree with this. So why exactly
are
you against the policy explicitly requiring either positive karma or
some minimal time in testing (setting aside some current shrotcommings
of the implementation like resetting the timer on bug update when you
just add/remove fixed bug or edit update comment)?
There are changes needing a lot (2+ weeks) of testing (e.g. upstream minor
feature releases, such as Qt 4.n+1). There are changes needing some (~1
week, at most 2, of) testing (e.g. upstream bugfix releases / point
releases). There are changes needing no testing (e.g. trivial one-line fixes
for a regression in a previous update which need to go out ASAP to fix the
regression). The maintainer is best qualified to know which applies. The
maintainer is also much better at judging the quality of his updates than
some semi-arbitrary number computed out of tester feedback ("karma"). (He
knows what he changed, he has access to feedback from other places, e.g.
Bugzilla, IRC, mailing lists, upstream's bug tracker, other distros' bug
trackers, anonymous Bodhi feedback not counted towards karma etc. – all
places which can confirm a single patch to fix a reported issue –, he has
experience from previous updates, and he is able to make an educated
judgement call based on all that information.) We are very far from software
being more intelligent than people, so we should let people decide, not
software. And the people should be able to decide on a case by case basis,
not some inflexible bureaucratic policy (which is so dumb that it can even
be enforced by software).
Kevin Kofler
12:44 p.m.
On Sat, 2010-08-14 at 19:14 +0200, Kevin Kofler wrote:
Martin Sourada wrote:
> Seeing your mail, you more or less agree with this. So why exactly are
> you against the policy explicitly requiring either positive karma or
> some minimal time in testing (setting aside some current shrotcommings
> of the implementation like resetting the timer on bug update when you
> just add/remove fixed bug or edit update comment)?
There are changes needing a lot (2+ weeks) of testing (e.g. upstream minor
feature releases, such as Qt 4.n+1). There are changes needing some (~1
week, at most 2, of) testing (e.g. upstream bugfix releases / point
releases). There are changes needing no testing (e.g. trivial one-line fixes
for a regression in a previous update which need to go out ASAP to fix the
regression). The maintainer is best qualified to know which applies. The
maintainer is also much better at judging the quality of his updates than
some semi-arbitrary number computed out of tester feedback ("karma"). (He
knows what he changed, he has access to feedback from other places, e.g.
Bugzilla, IRC, mailing lists, upstream's bug tracker, other distros' bug
trackers, anonymous Bodhi feedback not counted towards karma etc. – all
places which can confirm a single patch to fix a reported issue –, he has
experience from previous updates, and he is able to make an educated
judgement call based on all that information.) We are very far from software
being more intelligent than people, so we should let people decide, not
software. And the people should be able to decide on a case by case basis,
not some inflexible bureaucratic policy (which is so dumb that it can even
be enforced by software).
Hrm, I see that software as means to gain feedback for my updates --
noone can be 100% sure his changes are bugfree, otherwise we would have
bugfree software. In the ideal case scenario (which we are far from)
this would be used to catch the regression *before* making that update
stable in the first place. Testers are also giving reasons why they put
-1 karma if they did so. IMHO each change requires at least minimal
testing (and yes, finding at least +1 karma point for one line fix
should not be very hard).
The only thing I don't understand completely (but can accept without
complaining nevertheless) is why this applies to *new* packages as well
-- they didn't existed in repos before and anything is better than
nothing...
Martin
12:57 p.m.
New packages can break existing systems. Leak ram, eat filesystems, leak personal data,
leak root, dos a system, etc...
--
Sent from my Android phone. Please excuse my brevity, lack of trimming, and top posting.
"Martin Sourada" <martin.sourada(a)gmail.com> wrote:
On Sat, 2010-08-14 at 19:14 +0200, Kevin Kofler wrote:
> Martin Sourada wrote:
> > Seeing your mail, you more or less agree with this. So why exactly are
> > you against the policy explicitly requiring either positive karma or
> > some minimal time in testing (setting aside some current shrotcommings
> > of the implementation like resetting the timer on bug update when you
> > just add/remove fixed bug or edit update comment)?
>
> There are changes needing a lot (2+ weeks) of testing (e.g. upstream minor
> feature releases, such as Qt 4.n+1). There are changes needing some (~1
> week, at most 2, of) testing (e.g. upstream bugfix releases / point
> releases). There are changes needing no testing (e.g. trivial one-line fixes
> for a regression in a previous update which need to go out ASAP to fix the
> regression). The maintainer is best qualified to know which applies. The
> maintainer is also much better at judging the quality of his updates than
> some semi-arbitrary number computed out of tester feedback ("karma"). (He
> knows what he changed, he has access to feedback from other places, e.g.
> Bugzilla, IRC, mailing lists, upstream's bug tracker, other distros' bug
> trackers, anonymous Bodhi feedback not counted towards karma etc. – all
> places which can confirm a single patch to fix a reported issue –, he has
> experience from previous updates, and he is able to make an educated
> judgement call based on all that information.) We are very far from software
> being more intelligent than people, so we should let people decide, not
> software. And the people should be able to decide on a case by case basis,
> not some inflexible bureaucratic policy (which is so dumb that it can even
> be enforced by software).
>
Hrm, I see that software as means to gain feedback for my updates --
noone can be 100% sure his changes are bugfree, otherwise we would have
bugfree software. In the ideal case scenario (which we are far from)
this would be used to catch the regression *before* making that update
stable in the first place. Testers are also giving reasons why they put
-1 karma if they did so. IMHO each change requires at least minimal
testing (and yes, finding at least +1 karma point for one line fix
should not be very hard).
The only thing I don't understand completely (but can accept without
complaining nevertheless) is why this applies to *new* packages as well
-- they didn't existed in repos before and anything is better than
nothing...
Martin
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
3:08 p.m.
On Sat, 2010-08-14 at 19:44 +0200, Martin Sourada wrote:
The only thing I don't understand completely (but can accept
without
complaining nevertheless) is why this applies to *new* packages as well
-- they didn't existed in repos before and anything is better than
nothing...
Same objection as 'nothing is worse than a broken package'; it's not
true. They could have bad conflicts / obsoletes, or they could be set to
run on startup after being installed and crash the system...there's
various ways in which an entirely new package could stuff things up.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:27 p.m.
On Sat, Aug 14, 2010 at 4:08 PM, Adam Williamson wrote:
On Sat, 2010-08-14 at 19:44 +0200, Martin Sourada wrote:
> The only thing I don't understand completely (but can accept without
> complaining nevertheless) is why this applies to *new* packages as well
> -- they didn't existed in repos before and anything is better than
> nothing...
Same objection as 'nothing is worse than a broken package'; it's not
true. They could have bad conflicts / obsoletes, or they could be set to
run on startup after being installed and crash the system...there's
various ways in which an entirely new package could stuff things up.
Very true. New packages are black boxes, for which you aren't exactly
sure what you will get until you start using them in production. Our
reviewers are doing a great job, but there have been issues that have
been missed during the review, which is quite normal, especially for
bigger packages.
As an example, I submitted the clementine media player package to
testing on July 25th. We got a crash report on the 26th. This was
fixed and a new update is submitted to testing. Then I realized that
some files got compiled in without the "-g" flag because upstream
overrides compilation flags. Another update was submitted to testing.
Then another crash was reported on August 6th. This was fixed and an
update got pushed to testing yesterday. Now for pushing to stable, I
will wait another two weeks to make sure the application works
reasonably well for people.
As you might see, 7 days isn't even enough in certain cases. I would
have preferred a 14-day testing period. Some people prefer 0.
I criticized FESCo a lot in the past for being biased (especially for
not calling the Gnome spin "The Gnome spin"). However I think FESCo
did a good job this time in finding the middle ground.
Orcan
5 a.m.
W dniu 14.08.2010 00:12, Kevin Fenzi pisze:
On Fri, 13 Aug 2010 23:17:39 +0200
Sven Lankes <sven(a)lank.es> wrote:
> On Fri, Aug 13, 2010 at 07:21:50PM +0200, Martin Sourada wrote:
>
>> I wonder why I get the impression that the only ones who strongly
>> oppose this change are you folks from KDE SIG... Are you doing
>> things differently from anyone else in fedora - the rest of us are
>> either more or less neutral or positive towards this new change?
>
> I don't think that this about the KDE SIG at all.
>
> Not everyone is as passionate (or stubborn) as Kevin.
I agree.
> Most fedorians I talk to are watching all the discussions to see if
> the fedora that is currently being formed with all the changes that
> are happening is still a distribution that they're comfortable
> contributing to. And as the only way to get heard is to fuel a
> flamewar on fedora-devel they just stay silent.
I think the flamewars are making people think this is a bigger deal
than it really is.
>> [...] I'm for more testing and more conservative update policy in
>> general in stable branches.
>
> I don't oppose the ongoing changes in general but still - when I read
> through fesco meeting logs I am often disappointed by the amount of
> politics going on and more than once I wished that FESCO as a whole
> would grow a pair.
Can you expand on that? I'm not sure what you mean...
> I for one have decided that I'm going to stop contributing if the
> 'Stable Update Vision' is going to be implemented as currently
> discussed. If the powers that be are going to stop maintainers from
> issuing updates that are not security or bugfix updates then fedora
> will have turned into a distro that I'm not interested in.
Bring your concerns to the Board that issued the vision statement?
I personally think the "just security and bugfixes" is too strong.
I am going to try and push for an exceptions process that takes into
account upstreams that don't release in a way thats compatible with
fedora's release cycle.
I hope you won't be hasty and will try and work with whatever framework
we end up with and help us adjust it.
kevin
One should also keep in mind that asking maintainers to backport
bugfixes effectively raises the bar for being one.
While some large projects (firefox, gnome) maintain older branches and
issue fixes to them, the vast majority of smaller projects just leave
the old releases out cold, requiring the maintainer to do all the work
which could be simply avoided by tracking upstream. I, for one, have
next to none coding skills and I'm pretty sure I won't be able to
backport bugfixes if the code paths diverge too much.
Why can't we just leave that up to maintainers whether an update can be
introduced smoothly enough to a released fedora? One size fits all will
basically make us rhel with a more frequent release cycle.
Also, how often was a huge breakage introduced by kde sig? They track
upstream closely, and how does that work out?
Julian
3:50 a.m.
Sven Lankes wrote:
I for one have decided that I'm going to stop contributing if
the
'Stable Update Vision' is going to be implemented as currently
discussed. If the powers that be are going to stop maintainers from
issuing updates that are not security or bugfix updates then fedora will
have turned into a distro that I'm not interested in.
I'm also considering this, but I don't really know what distro I could
switch to. The Fedora way was a unique way, there's really no other
distribution working that way. That's why I have such strong feeling, I see
something unique being taken away from under us, in favor of something
that's just a boring clone of Ubuntu. In fact, that vision reads like a
precise description of Ubuntu.
I think that Fedora is going to lose many contributors and users over those
changes. Those that remain will be drawn to third-party repositories
providing updates, just like Ubuntu's PPAs. (They may or may not use the
repos.fedorapeople.org infrastructure for that, depending on how well you
manage to make it not suck. Right now, it offers little to no benefits over
infrastructure people can come up with themselves.) Maintainers will push
their stuff to Rawhide and to a third-party repository for releases and just
not support it in releases at all, closing all the bugs as RAWHIDE. (We
cannot realistically expect maintainers to backport all the bug fixes when
upstream no longer supports the branch that shipped in the given Fedora
release, and in fact most of the proponents of conservative updates don't
even want them to do that, they often want only "critical" bugs fixed, or
only bugs explicitly filed in our Bugzilla (which is already not feasible
for some packages by backports only).)
Kevin Kofler
6:29 a.m.
On Friday, August 13, 2010 07:21:50 pm Martin Sourada wrote:
On Fri, 2010-08-13 at 17:17 +0200, Jaroslav Reznik wrote:
> On Friday, August 13, 2010 05:09:17 pm Kevin Kofler wrote:
> > Jaroslav Reznik wrote:
> > > Then we have to push broken updates, policy says so and it's ok, so
> > > let's do it
> > >
> > > :(
> >
> > A policy requiring us to push something broken is broken. I'm not going
> > to push broken shit.
>
> Just irony but it feels like...
I wonder why I get the impression that the only ones who strongly oppose
this change are you folks from KDE SIG... Are you doing things
differently from anyone else in fedora - the rest of us are either more
or less neutral or positive towards this new change?
Yes, we do it in a completely different way and I would say it's even much more
strict but still very flexible. All bigger and important updates go through
kde-unstable, kde-testing repository for some time, then it usually takes a
few weeks in updates-testing and we collect input from users, testers (and lot
of us test latest bits too). Final push to stable is team decision! We have
bug trackers as blockers etc. And even our own steering committee for hard
decisions ;-) But it's still flexible - if we need quick fix for some minor
issue - it's possible (it's still team decision!).
Most problems in updates are task for Auto QA, not a very strict policy (I
would say it's more strict than RHEL updates :))). And I'm not completely
against it - it's reasonable to try to have best update experience but... As
David Malcolm said in the thread - one size fits all. And we don't have one
size, ten, hundred but thousands... It's open source!!!
Basically from both user and maintainer point of view I'm for
more
testing and more conservative update policy in general in stable
branches.
That's exactly our aim. To try to balance latest upstream bits (with thousands
fixes) with stability in terms of regressions - it's hard task and I admit we
even failed once (4.4 & akonadi) but still it's the only way how to support
Plasma Desktop.
Jaroslav
Cheers,
Martin
4:27 p.m.
On Tue, 2010-08-17 at 13:29 +0200, Jaroslav Reznik wrote:
Most problems in updates are task for Auto QA, not a very strict
policy (I
would say it's more strict than RHEL updates :))). And I'm not completely
This is clearly hyperbole. Really, we've pointed out multiple times that
all you need to do is have someone from KDE team become a proven tester
- anyone can sign up - and +1 your updates as soon as you push them
(and, hopefully, they actually *test* them). That's nothing like as
strict as the RHEL system, where you have to get approval from real paid
QA people (and jump through lots of
bureaucratic^H^H^H^H^H^H^H^H^H^H^H^Himportant hoops about defining the
problem and documenting the update and all that foobar).
As several people have pointed out, there's a fundamental inconsistency
in your position - you can't simultaneously claim that lots of people
are frothing at the mouth for new releases of KDE, but it's really hard
to find anyone to test the updates. If there's so many people who want
KDE updates, it shouldn't be hard to find *two* people (just one of whom
has to be a proven tester) to test the updates before they get pushed.
Really, if you want to have anyone from the KDE team apply to be a
proven tester, I will sponsor their application personally. It's not
intended to be a hard process to use.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:37 p.m.
Adam Williamson wrote:
As several people have pointed out, there's a fundamental
inconsistency
in your position - you can't simultaneously claim that lots of people
are frothing at the mouth for new releases of KDE, but it's really hard
to find anyone to test the updates. If there's so many people who want
KDE updates, it shouldn't be hard to find *two* people (just one of whom
has to be a proven tester) to test the updates before they get pushed.
In theory that may be so. In practice, finding karma is extremely hard.
Users do not give karma on Bodhi. They do not even have a FAS account and
are not interested in signing up for one. It's just how things are.
I've been soliciting for karma for this update:
https://admin.fedoraproject.org/updates/kdevelop-4.0.0-3.fc14
on #fedora-kde. It's a straight rebuild, it doesn't really need ANY testing
at all. It got only karma 2, and one of those was mine (the update was
submitted by somebody else, so it's not a self-vote). The update was
submitted (again: not by me) with a stablekarma of 3. Over 5 days have
passed now. The repeated claims that those karma requirements are a pure
formality are a LIE. In practice this update is unlikely to get to +3 before
the 7 day timeout, and if it does, it'll just be because of this message and
I do not believe that nagging the devel ML for each update is going to
scale! (And in addition, 5 days is already too long. Though in this
particular case the neverending Alpha freeze would have kept it from going
out to stable anyway, but that's just another broken process.) And
thankfully this one is not critical path, so at least there IS a timeout
here! Some stuff, e.g. kdelibs, has been arbitrarily termed "critical path"
(FESCo forced KDE SIG to provide them a list of "critical" packages, even
though our position was clear: we do not see a use for this process for KDE
at all!) and will get stuck in testing even longer, potentially forever.
Really, if you want to have anyone from the KDE team apply to be a
proven tester, I will sponsor their application personally. It's not
intended to be a hard process to use.
Rex Dieter has applied months ago, before the initial seeding even happened.
https://fedorahosted.org/fedora-qa/ticket/75
He is still not in the group.
Kevin Kofler
6:53 p.m.
On Wed, 2010-08-18 at 01:37 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
> As several people have pointed out, there's a fundamental inconsistency
> in your position - you can't simultaneously claim that lots of people
> are frothing at the mouth for new releases of KDE, but it's really hard
> to find anyone to test the updates. If there's so many people who want
> KDE updates, it shouldn't be hard to find *two* people (just one of whom
> has to be a proven tester) to test the updates before they get pushed.
In theory that may be so. In practice, finding karma is extremely hard.
Users do not give karma on Bodhi. They do not even have a FAS account and
are not interested in signing up for one. It's just how things are.
But there's two of you KDE developers posting in this thread. The two of
you together are enough to get any update approved, if one of you takes
ten minutes to go through the proven testers application process:
https://fedoraproject.org/wiki/Proven_tester
(Admittedly, yeah, +1ing an update you did yourself is bad form. But
surely there's more than two people on the KDE team?)
I've been soliciting for karma for this update:
https://admin.fedoraproject.org/updates/kdevelop-4.0.0-3.fc14
on #fedora-kde. It's a straight rebuild, it doesn't really need ANY testing
at all. It got only karma 2, and one of those was mine (the update was
submitted by somebody else, so it's not a self-vote). The update was
submitted (again: not by me) with a stablekarma of 3.
Then advise the KDE team to submit updates with a lower threshold.
Admittedly, the Bodhi defaults here could stand to be improved; I don't
think using the 'auto push' karma threshold as 'approved' makes sense,
I'd like to see non-critpath updates require simple +1 karma to be
'approved'. But that is, again, just a minor bug in the current system,
not any kind of showstopper.
Over 5 days have
passed now. The repeated claims that those karma requirements are a pure
formality are a LIE.
Please don't set up straw men. I've said it is not an onerous system,
that it is not as strict as the RHEL system...I haven't said it's a pure
formality.
In practice this update is unlikely to get to +3 before
the 7 day timeout, and if it does, it'll just be because of this message and
I do not believe that nagging the devel ML for each update is going to
scale!
No, it doesn't, but for important updates that are stuck, you can
certainly nag -test. And, see above. The +3 requirement is nothing set
in stone, you can already change it, and we should probably change the
default. Nothing in my mail said anything about the non-critpath default
but changeable +3 requirement, I talked about the critpath unchangeable
+1/+1 requirement.
(And in addition, 5 days is already too long. Though in this
particular case the neverending Alpha freeze would have kept it from going
out to stable anyway, but that's just another broken process.)
In what way is it broken? The freeze isn't neverending, it lasts as long
as it takes to release the Alpha. We can hardly start shoving packages
into stable until we sign off on the Alpha images, that breaks the whole
point of the freeze.
And
thankfully this one is not critical path, so at least there IS a timeout
here! Some stuff, e.g. kdelibs, has been arbitrarily termed "critical path"
(FESCo forced KDE SIG to provide them a list of "critical" packages, even
though our position was clear: we do not see a use for this process for KDE
at all!) and will get stuck in testing even longer, potentially forever.
> Really, if you want to have anyone from the KDE team apply to be a
> proven tester, I will sponsor their application personally. It's not
> intended to be a hard process to use.
Rex Dieter has applied months ago, before the initial seeding even happened.
https://fedorahosted.org/fedora-qa/ticket/75
He is still not in the group.
I replied to his application on July 7th - the day we started actually
accepting proven tester applicants - asking him for the things we ask of
all applicants (affirm that they've read and will abide by the
guidelines for proven testers). He has not yet replied to that, so I
can't approve him.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:17 p.m.
Adam Williamson wrote:
Admittedly, yeah, +1ing an update you did yourself is bad form.
Actually, FESCo said that Bodhi should not count such self-voted karma at
all. If it still does, that's a feature which is likely to go away very
soon. :-(
Then advise the KDE team to submit updates with a lower threshold.
That particular update was not submitted by us, but by the guy who did all
the Python 2.7 rebuilds.
The annoying thing is, I have a newer KDevelop build (an upgrade to an
upstream point release) I want to push to testing, but as long as this one
is not at least queued for stable, I can't push the new build without
obsoleting this one, which I don't want to do (because I want the Python 2.7
fix to go out ASAP, but the new upstream release to get the testing it
deserves; see, I DON'T want to push everything without testing, I just want
to be able to use my experienced judgement on how much, if any, testing is
needed).
Admittedly, the Bodhi defaults here could stand to be improved; I
don't
think using the 'auto push' karma threshold as 'approved' makes sense,
I'd like to see non-critpath updates require simple +1 karma to be
'approved'. But that is, again, just a minor bug in the current system,
not any kind of showstopper.
It's a major bug. I'd even call it a showstopper. It makes this system a
really big PITA.
Please don't set up straw men. I've said it is not an onerous
system,
that it is not as strict as the RHEL system...I haven't said it's a pure
formality.
You said (and just repeated) that it's "not an onerous system" which is a
ludicrous enough claim, given the facts.
No, it doesn't, but for important updates that are stuck, you
can
certainly nag -test. And, see above. The +3 requirement is nothing set
in stone, you can already change it, and we should probably change the
default. Nothing in my mail said anything about the non-critpath default
but changeable +3 requirement, I talked about the critpath unchangeable
+1/+1 requirement.
The non-critpath packages still have a hard +1 requirement. For critpath
it's actually +2, where 1 must be a proventester (which is really
ridiculous, why isn't a proventester enough?).
In what way is it broken? The freeze isn't neverending, it lasts
as long
as it takes to release the Alpha. We can hardly start shoving packages
into stable until we sign off on the Alpha images, that breaks the whole
point of the freeze.
We could compose the Alpha off a f14-alpha tag in Koji and allow dist-f14 to
go on. Or we could just have allowed stuff into dist-f14 for a couple more
weeks when it was clear that we weren't in a releasable state. Right now
we're stuck with dozens of broken dependencies which have been unfixed for
WEEKS when the fix for several of those has been queued for stable already.
We should at least have gotten the broken dependencies down to a reasonable
number before starting the Alpha RC process. A tree with so many broken
dependencies is not releasable, the fact that we're withholding the fixes
because we're trying to release the broken stuff is particularly silly. In
addition, the RC1 and RC2 live images were entirely untestable. The whole
Alpha RC process should have been postponed instead of staying in freeze for
so long.
I replied to [rdieter's] application on July 7th - the day we
started
actually accepting proven tester applicants - asking him for the things we
ask of all applicants (affirm that they've read and will abide by the
guidelines for proven testers). He has not yet replied to that, so I
can't approve him.
Looks like the communication broke down somewhere, I'll nag him next time I
catch him on IRC.
Kevin Kofler
10:17 p.m.
On Wed, 2010-08-18 at 03:17 +0200, Kevin Kofler wrote:
That particular update was not submitted by us, but by the guy who
did all
the Python 2.7 rebuilds.
The annoying thing is, I have a newer KDevelop build (an upgrade to an
upstream point release) I want to push to testing, but as long as this one
is not at least queued for stable, I can't push the new build without
obsoleting this one, which I don't want to do (because I want the Python 2.7
fix to go out ASAP, but the new upstream release to get the testing it
deserves; see, I DON'T want to push everything without testing, I just want
to be able to use my experienced judgement on how much, if any, testing is
needed).
To me, that reads more like a problem with the update submission system
than anything. I'd like to see far fewer restrictions on it (just like
I'd like for koji), so you could edit the existing update to add your
packages. This same issue exists even without feedback requirements.
> No, it doesn't, but for important updates that are stuck,
you can
> certainly nag -test. And, see above. The +3 requirement is nothing set
> in stone, you can already change it, and we should probably change the
> default. Nothing in my mail said anything about the non-critpath default
> but changeable +3 requirement, I talked about the critpath unchangeable
> +1/+1 requirement.
The non-critpath packages still have a hard +1 requirement.
Indeed, but that's not a difficult standard to meet.
For critpath
it's actually +2,
Yeah, that's what I meant by +1/+1 (+1 proventester, +1 anyone).
where 1 must be a proventester (which is really
ridiculous, why isn't a proventester enough?).
A single tester can often miss an issue, it's good to have at least two
pairs of eyes.
> In what way is it broken? The freeze isn't neverending, it
lasts as long
> as it takes to release the Alpha. We can hardly start shoving packages
> into stable until we sign off on the Alpha images, that breaks the whole
> point of the freeze.
We could compose the Alpha off a f14-alpha tag in Koji and allow dist-f14 to
go on.
This is an almost irrelevant distinction; right now we have the Alpha
composed off the dist-f14 tag and dist-f14-updates-candidate is 'allowed
to go on'. Your proposal really just renames the tags. Well, given how
they'd be used afterwards, it's slightly different - and I'd agree
slightly better - but it's really not a big change.
One thing that has been different for F14 Alpha is that packages
submitted to updates-testing during the freeze weren't pushed very
quickly; this has nothing to do with the proven testers process, though,
it's just because Jesse was away and those covering for him weren't sure
whether they were supposed to keep pushing packages to updates-testing
while we were doing RCs. AFAIK, as long as we keep pushing builds
through to updates-testing while the main repo (which is filled from the
dist-f14 tag) is frozen for RC composes, there isn't really a problem,
as you can keep pushing fixes into updates-testing, build things on top
of other things there, however you like.
Or we could just have allowed stuff into dist-f14 for a couple more
weeks when it was clear that we weren't in a releasable state. Right now
we're stuck with dozens of broken dependencies which have been unfixed for
WEEKS when the fix for several of those has been queued for stable already.
We should at least have gotten the broken dependencies down to a reasonable
number before starting the Alpha RC process. A tree with so many broken
dependencies is not releasable
Actually, it is, because we don't really release a tree for the Alpha,
we release images (I'm not sure if we stick a full tree frozen in Alpha
state up on mirrors, but if we do, it's not something we really *care*
about - we'd expect people to use the rolling main F14 tree along with
the Alpha images). At Alpha stage, we're fine to release as long as
there's no conflicts or dependency issues *within the packages included
on the DVD / split CD images*, which is a rather smaller subset of
'everything'. We have a release criterion and a validation test which
covers this, and there are no such issues on the RC4 images (except that
systemd-sysvinit and upstart-sysvinit conflict, but that's fine as
there's no way you can actually cause upstart-sysvinit to be selected
for installation, it only gets pulled in because mash pulls in
everything that can potentially satisfy dependencies, and they both
provide the 'sysvinit-userspace' dependency).
As I said above, as long as you can fix dependency issues in
updates-testing, the fact that the 'stable' repo is frozen shouldn't
really be an issue, right?
, the fact that we're withholding the fixes
because we're trying to release the broken stuff is particularly silly. In
addition, the RC1 and RC2 live images were entirely untestable.
Yeah, that was unfortunate. In the past we put a very low priority on
live images for pre-releases. There weren't actually live images built
as part of Alpha RC1 / RC2, I just designated a nightly build to match
each, but as you point out, there were bugs that resulted in them not
being usable. It may be worth considering slipping the start of the
Alpha process rather than the end if the same kind of case where we're
fighting against lots of changes in the tree when we try to start the
TC/RC process comes up again, but I'm sure you appreciate the temptation
is always to try and get something workable spun and catch up with the
schedule...
The whole
Alpha RC process should have been postponed instead of staying in freeze for
so long.
whoops, see above. :) Again, though, this seems to be somewhat off the
topic of the proven tester process.
> I replied to [rdieter's] application on July 7th - the day
we started
> actually accepting proven tester applicants - asking him for the things we
> ask of all applicants (affirm that they've read and will abide by the
> guidelines for proven testers). He has not yet replied to that, so I
> can't approve him.
Looks like the communication broke down somewhere, I'll nag him next time I
catch him on IRC.
Thanks, I'll approve him as soon as he follows up.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:49 p.m.
Adam Williamson wrote:
To me, that reads more like a problem with the update submission
system
than anything. I'd like to see far fewer restrictions on it (just like
I'd like for koji), so you could edit the existing update to add your
packages. This same issue exists even without feedback requirements.
Editing isn't what I want though, I want to have a newer update in testing
while keeping the old one not obsolete because it should go out to stable
ASAP. Bodhi only allows this if it's already queued for stable when the new
update is submitted, otherwise it automatically obsoletes the old one.
> The non-critpath packages still have a hard +1 requirement.
Indeed, but that's not a difficult standard to meet.
That's what I dispute. Especially if you expect people to actually meet the
testing criteria for a +1. (It's easy and fast to just "swap +1 votes" or
something like that, but it defeats the purpose of the process.)
> where 1 must be a proventester (which is really
> ridiculous, why isn't a proventester enough?).
A single tester can often miss an issue, it's good to have at least two
pairs of eyes.
Only 2 testers can often miss an issue, it's good to have at least 3 pairs
of eyes.
Only 3 testers can often miss an issue, it's good to have at least 4 pairs
of eyes.
Only 4 testers can often miss an issue, it's good to have at least 5 pairs
of eyes.
… (ad infinitum)
Where do we stop? NO amount of testers will catch ALL issues.
In addition, the maintainer certainly won't submit something he thinks is
broken, so the proventester is already a second pair of eyes.
Each time we decide that one person is not enough (but n are needed), we
multiply the required manpower to do any work by a factor n! This is not
something to be taken lightly. We DO NOT HAVE the manpower for this kind of
QA. It takes VERY LONG to get any kind of positive karma for anything.
(Negative one can sometimes be gotten quite fast, just screw up blatantly
enough. ;-) )
And FWIW, I also dislike the fact that our QA process focuses almost
exclusively on testing (well, there will be AutoQA too soon, but the manual
checks will still be limited to just testing). I have found proofreading
(even self-proofreading, but proofreading by another person can be even more
effective) to be a much more effective form of QA than testing. I have found
many issues when proofreading changes (both mine and other people's, and
both for RPM specfiles and actual code) which would almost certainly never
have been caught through testing (but were still real issues). I always
proofread my changes before I commit them and I also proofread the specfile
changes done by comaintainers. IMHO, that should already be sufficient
ground for validating the resulting update, but according to our process I'm
not supposed to +1 an update I have "only" proofread the changes of and not
also tested. (That also reminds me of Knuth's "Beware of bugs in the above
code; I have only proved it correct, not tried it.". :-) ) It often takes
much less time to proofread the spec changes than to do testing with any
kind of reasonable coverage (especially for something like KDevelop), and it
is much more likely to find issues (because you just can't test everything:
For example, how many testers actually check for unowned directories? A
trained proofreader catches these quite reliably, especially if the change
being proofread is the one making the directory unowned. And do you really
think you can exhaustively test ALL the features of a powerful application?
Proofreading can evidence that you broke one (e.g. by dropping a required
BuildRequires), or that you made only trivial changes extremely unlikely to
break anything at all). Also a FYI: Often it is also useful to have a look
at the build.log in addition to the specfile, that will evidence complaints
by the package's build system (CMake, autoconf-generated configure or
whatever) about missing optional build requirements (and thus missing
features). Those are again issues which testing generally does not catch.
AFAIK, as long as we keep pushing builds through to updates-testing
while
the main repo (which is filled from the dist-f14 tag) is frozen for RC
composes, there isn't really a problem, as you can keep pushing fixes into
updates-testing, build things on top of other things there, however you
like.
Well, now that we basically force everything through testing (though there
can theoretically still be stuff which gets queued for stable before
reaching testing if karma comes really quickly), it is not such a big
problem anymore, but before, we had the paradoxical situation where urgent
fixes queued directly for stable did not become available whereas
unimportant stuff went out to testing just fine. :-/ Banning direct stable
pushes entirely strikes me as the entirely wrong solution for this issue,
basically solving the wrong problem.
except that systemd-sysvinit and upstart-sysvinit conflict, but
that's
fine as there's no way you can actually cause upstart-sysvinit to be
selected for installation, it only gets pulled in because mash pulls in
everything that can potentially satisfy dependencies, and they both
provide the 'sysvinit-userspace' dependency
Why do we even still ship upstart at all? It should get Obsoleted by systemd
and EOLed.
As I said above, as long as you can fix dependency issues in
updates-testing, the fact that the 'stable' repo is frozen shouldn't
really be an issue, right?
Well, it is, because the stable repo is what shows up in the Branched
reports, what people will be using by default etc. Now I know that we've
started enabling updates-testing by default for prereleases with F13, but
that strikes me as an awfully bad idea, because updates-testing is like the
Red Pill: once you're on it, you're stuck with it! We should NEVER enable
updates-testing by default for ANY user. This is again a completely wrong
solution which misses the essence of the problem.
Kevin Kofler
1 a.m.
On Wed, Aug 18, 2010 at 1:53 AM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Wed, 2010-08-18 at 01:37 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > As several people have pointed out, there's a fundamental inconsistency
> > in your position - you can't simultaneously claim that lots of people
> > are frothing at the mouth for new releases of KDE, but it's really hard
> > to find anyone to test the updates. If there's so many people who want
> > KDE updates, it shouldn't be hard to find *two* people (just one of whom
> > has to be a proven tester) to test the updates before they get pushed.
>
> In theory that may be so. In practice, finding karma is extremely hard.
> Users do not give karma on Bodhi. They do not even have a FAS account and
> are not interested in signing up for one. It's just how things are.
But there's two of you KDE developers posting in this thread. The two of
you together are enough to get any update approved, if one of you takes
ten minutes to go through the proven testers application process:
https://fedoraproject.org/wiki/Proven_tester
(Admittedly, yeah, +1ing an update you did yourself is bad form. But
surely there's more than two people on the KDE team?)
I'm part of the KDE SIG. I will apply today for proventester to become
the KDE proventester.
--
LG Thomas
Dubium sapientiae initium
2:51 p.m.
Thomas Janssen wrote:
I'm part of the KDE SIG. I will apply today for proventester to
become
the KDE proventester.
Actually, Rex Dieter already started the application process, so you'll
probably become "a" KDE proventester, not "the" KDE proventester. ;-)
But the more proventesters we have, the better!
Kevin Kofler
3:07 p.m.
On Wed, Aug 18, 2010 at 9:51 PM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Thomas Janssen wrote:
> I'm part of the KDE SIG. I will apply today for proventester to become
> the KDE proventester.
Actually, Rex Dieter already started the application process, so you'll
probably become "a" KDE proventester, not "the" KDE proventester. ;-)
I'm glad to see you still know how to make friends ;) BTW I'm already
"a" proventester.
Another BTW, if you think you have to write "something", a simple
'thank you for stepping up' would have been enough.
--
LG Thomas
Dubium sapientiae initium
3:20 p.m.
Thomas Janssen wrote:
Another BTW, if you think you have to write "something", a
simple
'thank you for stepping up' would have been enough.
Well, yes, thank you for stepping up, your help is very much appreciated! I
didn't mean to offend you!
(And thanks to Rex Dieter as well, by the way.)
Kevin Kofler
10:29 a.m.
On Fri, Aug 13, 2010 at 01:27:18AM +0200, Kevin Kofler wrote:
"fix" breaks that. Plus, edits can also be only to the
description or bug
references, Bodhi doesn't allow me to edit those without editing the whole
update.
Bodhi also allows you to edit the stable karma value and unless it is
implemented differently (or has changed again), you can just use a
stable karma value of 1 and ask someone except the update submitter to
provide the +1 karma and the update can be pushed to stable. This is
imho reasonable even after only a one line change to a build.
Regards
Till
10:54 a.m.
Till Maas wrote:
Bodhi also allows you to edit the stable karma value and unless it
is
implemented differently (or has changed again), you can just use a
stable karma value of 1 and ask someone except the update submitter to
provide the +1 karma and the update can be pushed to stable. This is
imho reasonable even after only a one line change to a build.
You still need to get somebody to +1 the update, and more if people -1ed it
in the past due to regressions which are already fixed in the current edited
version. (Yes, update groups will be edited instead of obsoleted if we
change what we're pushing. It's the only practical way to handle them.
That's why we have this discussion about edits in the first place.)
Kevin Kofler
11:49 a.m.
On Fri, Aug 13, 2010 at 05:54:30PM +0200, Kevin Kofler wrote:
Till Maas wrote:
> Bodhi also allows you to edit the stable karma value and unless it is
> implemented differently (or has changed again), you can just use a
> stable karma value of 1 and ask someone except the update submitter to
> provide the +1 karma and the update can be pushed to stable. This is
> imho reasonable even after only a one line change to a build.
You still need to get somebody to +1 the update,
Yes, this is what I wrote. And I think it is reasonable. Especially with
the whole Plasma SIG, which are probably more than two people, you
should have no problem finding them.
and more if people -1ed it
in the past due to regressions which are already fixed in the current edited
version. (Yes, update groups will be edited instead of obsoleted if we
The same people that provided the -1 karma can provide a +1 karma. And
you only need have of these people to change their karma vote to get
back to zero karma. This should also not be a major problem, unless
there are people providing unjustified -1 karma to cause problems. But
you did not mention this.
Regards
Till
1:16 p.m.
Till Maas wrote:
The same people that provided the -1 karma can provide a +1 karma.
And
you only need have of these people to change their karma vote to get
back to zero karma. This should also not be a major problem, unless
there are people providing unjustified -1 karma to cause problems. But
you did not mention this.
People often provide well-meaning, but ultimately unjustified -1 karma. E.g.
we've often had -1 votes for regressions caused by some other package in a
completely different update or update set, or even for Bodhi or PackageKit
bugs which affect all updates and which don't affect the functionality of
the update in any way, just its display.
Kevin Kofler
7:39 p.m.
On Fri, 2010-08-13 at 17:54 +0200, Kevin Kofler wrote:
Till Maas wrote:
> Bodhi also allows you to edit the stable karma value and unless it is
> implemented differently (or has changed again), you can just use a
> stable karma value of 1 and ask someone except the update submitter to
> provide the +1 karma and the update can be pushed to stable. This is
> imho reasonable even after only a one line change to a build.
You still need to get somebody to +1 the update, and more if people -1ed it
This is *really* not an onerous requirement. It simply means 'have one
other person - any other person in the world with a FAS account - run
your code and make sure it actually works before you release it'. If you
don't think that's a good idea, well, I'm not sure what to say.
in the past due to regressions which are already fixed in the current
edited
version. (Yes, update groups will be edited instead of obsoleted if we
Please stop mixing minor bugs in the process in with high-flown rhetoric
about the bureaucratic Board and whatever. This is simply a bug (or,
possibly, an incomplete design; whatever you want to call it), in Bodhi.
I think it's even already been reported and is planned to be addressed
in future Bodhi. Luke?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:08 a.m.
Adam Williamson wrote:
On Fri, 2010-08-13 at 17:54 +0200, Kevin Kofler wrote:
> in the past due to regressions which are already fixed in the current
> edited version. (Yes, update groups will be edited instead of obsoleted
> if we
Please stop mixing minor bugs in the process in with high-flown rhetoric
about the bureaucratic Board and whatever. This is simply a bug (or,
possibly, an incomplete design; whatever you want to call it), in Bodhi.
I think it's even already been reported and is planned to be addressed
in future Bodhi. Luke?
How do you want to address this? By resetting the karma to 0 on any edit?
That just makes the problem even worse, because it means editing will also
lose all the positive karma.
Kevin Kofler
4:43 a.m.
W dniu 14.08.2010 11:08, Kevin Kofler pisze:
Adam Williamson wrote:
> On Fri, 2010-08-13 at 17:54 +0200, Kevin Kofler wrote:
>> in the past due to regressions which are already fixed in the current
>> edited version. (Yes, update groups will be edited instead of obsoleted
>> if we
>
> Please stop mixing minor bugs in the process in with high-flown rhetoric
> about the bureaucratic Board and whatever. This is simply a bug (or,
> possibly, an incomplete design; whatever you want to call it), in Bodhi.
> I think it's even already been reported and is planned to be addressed
> in future Bodhi. Luke?
How do you want to address this? By resetting the karma to 0 on any edit?
That just makes the problem even worse, because it means editing will also
lose all the positive karma.
Kevin Kofler
This is just a consequence. If the timer is to be reset, so should be
the karma or vice-versa.
Julian
11:33 a.m.
On 08/13/2010 11:29 AM, Till Maas wrote:
On Fri, Aug 13, 2010 at 01:27:18AM +0200, Kevin Kofler wrote:
> "fix" breaks that. Plus, edits can also be only to the description or bug
> references, Bodhi doesn't allow me to edit those without editing the whole
> update.
Bodhi also allows you to edit the stable karma value and unless it is
implemented differently (or has changed again), you can just use a
stable karma value of 1 and ask someone except the update submitter to
provide the +1 karma and the update can be pushed to stable. This is
imho reasonable even after only a one line change to a build.
I think this is currently a viable option.
luke
12:57 a.m.
On 08/13/2010 01:23 AM, Luke Macken wrote:
On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
>> - Minimum time-in-testing requirements
>> - Every day bodhi will look for updates that have been
>> in testing for N days (fedora: N=7, epel: N=14), and will
>> add a comment notifying the maintainer that the update is
>> now able to be pushed to stable.
>
> Suppose I submit a package to testing and it gets pushed. Six days
> later, I find a terrible bug in the package (or a user reports this to
> me). I fix the package and edit the update, request the fixed package
> to be pushed to testing again and it gets pushed the next day.
>
> Now without any further testing the package can be pushed to stable,
> which contradicts the purpose of this whole change in bodhi.
>
> I think, for packages that are modified during the testing period,
> this N should be calculated from the day the last push was made to
> testing.
This would very unhelpful.
Yes, this was my initial intention. However, looking at the code a
bit
closer, your scenario would currently be allowed, as it currently only
calculates the time-in-testing based on the first push to testing.
This behavior is
helpful, because otherwise updates would "starve".
Ralf
10:10 a.m.
Ralf Corsepius wrote:
>> I think, for packages that are modified during the testing
period,
>> this N should be calculated from the day the last push was made to
>> testing.
This would very unhelpful.
> Yes, this was my initial intention. However, looking at the code a bit
> closer, your scenario would currently be allowed, as it currently only
> calculates the time-in-testing based on the first push to testing.
This behavior is helpful, because otherwise updates would "starve".
+1
Once again, we're in violent agreement!
Kevin Kofler
11:51 a.m.
On 08/13/2010 05:10 PM, Kevin Kofler wrote:
Ralf Corsepius wrote:
>>> I think, for packages that are modified during the testing period,
>>> this N should be calculated from the day the last push was made to
>>> testing.
>
> This would very unhelpful.
>
>> Yes, this was my initial intention. However, looking at the code a bit
>> closer, your scenario would currently be allowed, as it currently only
>> calculates the time-in-testing based on the first push to testing.
> This behavior is helpful, because otherwise updates would "starve".
+1
Once again, we're in violent agreement!
Real world case I've occasionally encountered:
I submitted a package to testing. It did not receive any feedback,
however I started using it.
Several weeks later, I notice another (often minor) bug and fix it with
a "few liner patch" rsp. upstream releases a new "minor bug fix
release".
With the new procedure, I have 2 choices:
1. Push the known to be buggy package to avoid this timer to be reset,
knowingly exposing the users to this bug and the bugs this update was
supposed to fix.
2. Push an update comprising resetting the timer.
=> Users will have to wait another timeout period for the bugs they are
waiting to see fixed.
Neither of both choices are helpful.
With the timer not being reset, I could push the package with the "new
bug fix applied", knowing the package would not immediately malfunction
and would have the "new fix" applied.
Another similar, scenario is upstreams releasing packages in a higher
frequency than fedora can handle them.
Though these cases are fairly rare, I also have seen them happen
(Classical case: upstream release update, package makes it into Fedora,
Several weeks/months later, upstream notices major problems and releases
"hot fix releases" at high frequency).
Ralf
11:45 a.m.
On 08/13/2010 01:57 AM, Ralf Corsepius wrote:
On 08/13/2010 01:23 AM, Luke Macken wrote:
> On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
>> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
>>> - Minimum time-in-testing requirements
>>> - Every day bodhi will look for updates that have been
>>> in testing for N days (fedora: N=7, epel: N=14), and will
>>> add a comment notifying the maintainer that the update is
>>> now able to be pushed to stable.
>>
>> Suppose I submit a package to testing and it gets pushed. Six days
>> later, I find a terrible bug in the package (or a user reports this to
>> me). I fix the package and edit the update, request the fixed package
>> to be pushed to testing again and it gets pushed the next day.
>>
>> Now without any further testing the package can be pushed to stable,
>> which contradicts the purpose of this whole change in bodhi.
>>
>> I think, for packages that are modified during the testing period,
>> this N should be calculated from the day the last push was made to
>> testing.
This would very unhelpful.
> Yes, this was my initial intention. However, looking at the code a bit
> closer, your scenario would currently be allowed, as it currently only
> calculates the time-in-testing based on the first push to testing.
This behavior is helpful, because otherwise updates would "starve".
The only case for update starvation that I can think of is if you keep
adding/removing builds from an update before it reaches a week in
testing or the karma thresholds.
luke
11:55 a.m.
On 08/13/2010 06:45 PM, Luke Macken wrote:
On 08/13/2010 01:57 AM, Ralf Corsepius wrote:
> On 08/13/2010 01:23 AM, Luke Macken wrote:
>> On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
>>> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
>>>> - Minimum time-in-testing requirements
>>>> - Every day bodhi will look for updates that have been
>>>> in testing for N days (fedora: N=7, epel: N=14), and
will
>>>> add a comment notifying the maintainer that the update
is
>>>> now able to be pushed to stable.
>>>
>>> Suppose I submit a package to testing and it gets pushed. Six days
>>> later, I find a terrible bug in the package (or a user reports this to
>>> me). I fix the package and edit the update, request the fixed package
>>> to be pushed to testing again and it gets pushed the next day.
>>>
>>> Now without any further testing the package can be pushed to stable,
>>> which contradicts the purpose of this whole change in bodhi.
>>>
>>> I think, for packages that are modified during the testing period,
>>> this N should be calculated from the day the last push was made to
>>> testing.
>
> This would very unhelpful.
>
>> Yes, this was my initial intention. However, looking at the code a bit
>> closer, your scenario would currently be allowed, as it currently only
>> calculates the time-in-testing based on the first push to testing.
> This behavior is helpful, because otherwise updates would "starve".
The only case for update starvation that I can think of is if you keep
adding/removing builds from an update before it reaches a week in
testing or the karma thresholds.
C.f. my other mail - Such cases happen.
Another scenario I haven't mentioned yet is packaging bugs.
One day, a packager fixes one, 4 days later he (or a tester) notices
another one, fixes it, 6 days later the next one is being fixed, ... ad
infinitum.
Now take dependency chains into account ...
Ralf
12:09 p.m.
Luke Macken wrote:
The only case for update starvation that I can think of is if you
keep
adding/removing builds from an update before it reaches a week in
testing or the karma thresholds.
For any large update group, that's just always going to happen. There's
always another important fix you need to get in.
Kevin Kofler
3:59 p.m.
W dniu 13.08.2010 01:12, Orcan Ogetbil pisze:
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
> - Minimum time-in-testing requirements
> - Every day bodhi will look for updates that have been
> in testing for N days (fedora: N=7, epel: N=14), and will
> add a comment notifying the maintainer that the update is
> now able to be pushed to stable.
Suppose I submit a package to testing and it gets pushed. Six days
later, I find a terrible bug in the package (or a user reports this to
me). I fix the package and edit the update, request the fixed package
to be pushed to testing again and it gets pushed the next day.
Now without any further testing the package can be pushed to stable,
which contradicts the purpose of this whole change in bodhi.
I think, for packages that are modified during the testing period,
this N should be calculated from the day the last push was made to
testing.
Orcan
Is the karma getting reset upon an edit?
Julian
10:02 p.m.
On Fri, 2010-08-13 at 22:59 +0200, Julian Sikorski wrote:
Is the karma getting reset upon an edit?
I don't have an answer to the question, but FYI, there is an open ticket
about it:
https://fedorahosted.org/bodhi/ticket/388
--
Matt
6:47 p.m.
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
- Minimum time-in-testing requirements
- When someone tries to push an update to stable, bodhi will
look to see if it has the appropriate karma, or if it has
been in testing for more than N days.
I have another question:
What happens if a package is submitted to testing the same day on
F-(x) and F-(x+1), then the F-(x) package reaches +3 karma the next
day and is automatically pushed to stable? Let's say the F-(x+1)
package still has 0 karma (or maybe even negative karma).
The F-(x) package will have higher EVR than the F-(x+1) one. This
will break the upgrade path. Is there any measures to prevent this?
Sorry for bringing up the corner cases, but it is best to discuss
these early before someone is hurt.
Orcan
7:04 p.m.
Orcan Ogetbil wrote:
The F-(x) package will have higher EVR than the F-(x+1) one. This
will break the upgrade path. Is there any measures to prevent this?
No. In fact FESCo specifically refused to consider this as an issue, they
say separate releases need separate testing and so they refuse to accept the
Fn karma as grounds to push the Fn+1 update. No amount of arguing helped.
Such broken upgrade paths are now going to be extremely common with this
useless, broken and inflexible procedure.
Kevin Kofler
10:24 a.m.
Hello Kevin,
On Thursday, August 12, 2010, 8:04:12 PM, Kevin Kofler wrote:
Orcan Ogetbil wrote:
> The F-(x) package will have higher EVR than the F-(x+1) one. This
> will break the upgrade path. Is there any measures to prevent this?
No. In fact FESCo specifically refused to consider this as an issue,
they
say separate releases need separate testing and so they refuse to accept the
Fn karma as grounds to push the Fn+1 update. No amount of arguing helped.
Such broken upgrade paths are now going to be extremely common with
this
useless, broken and inflexible procedure.
Kevin Kofler
You are assuming that it is somehow a good idea to push release Fn, in
spite of no (or negative) testing. My understanding is that _that_ is
what FESCo refused to consider.
A saner approach would be that for related changes, release Fn-1
should not be pushed to stable until release Fn is _also_ ready to go.
This prevents the EVR problem, and ensures that regressions caught on
release Fn that are also applicable to release Fn-1 will not escape.
Al
11:07 a.m.
Al Dunsmuir wrote:
You are assuming that it is somehow a good idea to push release Fn,
in
spite of no (or negative) testing.
Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see
why testing on ANY F* isn't sufficient. Please don't bring the same old
argument that "sometimes" breakage happens only on some releases even with
the same specfile: in practice this is so rare that it doesn't matter at
all, it's much more likely that regressions slip through despite the
testing. (And I have years of experience with KDE updates to draw from when
making that assertion. Sadly, I can't really prove it because Bodhi deletes
all the records for EOL releases, so you'll have to rely on my memory.
Release-specific regressions happened only 1 or 2 times overall (and the 1
time I remember was a maintainer using string comparisons for %{fedora}
which broke on the 9→10 transition, something that 1. can't cause breakage
again until Fedora 100 and 2. shouldn't happen to an experienced maintainer,
I'm sure that particular maintainer won't make that particular mistake ever
again after me yelling at him for the breakage ;-) ), regressions missed by
testing, despite lots of positive karma, were much more frequent. In fact,
we completely ignored the karma value for our KDE updates so far, it doesn't
really say anything about the quality of the update!) Testing will NEVER be
a 100% perfect process anyway, so why do we care about some .001% chance of
breakage? It's much more important to be able to rapidly fix things when the
testing failed, and that's exactly what direct stable pushes are needed for
and what the new process breaks.
A saner approach would be that for related changes, release
Fn-1
should not be pushed to stable until release Fn is _also_ ready to go.
This prevents the EVR problem, and ensures that regressions caught on
release Fn that are also applicable to release Fn-1 will not escape.
This can stall updates for ages waiting for all the branches to get the
required testing. Testing requirements quickly multiply: e.g. if you require
2 karma, of which 1 proventester (which is what's required for "critical"
packages), requiring it on all branches makes this a requirement of 6 karma,
of which 3 proventesters! It takes a VERY long time to get so many karma
points, plus they need to be on the correct releases or they'll be
worthless.
Kevin Kofler
11:12 a.m.
On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote:
Al Dunsmuir wrote:
> You are assuming that it is somehow a good idea to push release Fn, in
> spite of no (or negative) testing.
Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see
why testing on ANY F* isn't sufficient. Please don't bring the same old
argument that "sometimes" breakage happens only on some releases even with
the same specfile: in practice this is so rare that it doesn't matter at
all, it's much more likely that regressions slip through despite the
testing.
Last week I pushed a yum update to f12, f13 and f14 - same pkg, same
patches, same config.
On f12, however, the version of sqlite that f12 had handles an error
condition differently than on f13 and f14. It meant that instead of
raise an exception and letting us move along that it raised an exception
and then exited.
So - the pkg checked out on f13 and f14 just fine but not on f12.
I had to issue a new update for all of them to keep them in sync.
That's a real world case that happens all the time.
-sv
11:18 a.m.
This is where Kevin blames the scenario on not having the same sqlite on all of the Fedora
releases, which is another evil plot hatched by the devils of FESCo....
"seth vidal" <skvidal(a)fedoraproject.org> wrote:
On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote:
> Al Dunsmuir wrote:
> > You are assuming that it is somehow a good idea to push release Fn, in
> > spite of no (or negative) testing.
>
> Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see
> why testing on ANY F* isn't sufficient. Please don't bring the same old
> argument that "sometimes" breakage happens only on some releases even with
> the same specfile: in practice this is so rare that it doesn't matter at
> all, it's much more likely that regressions slip through despite the
> testing.
Last week I pushed a yum update to f12, f13 and f14 - same pkg, same
patches, same config.
On f12, however, the version of sqlite that f12 had handles an error
condition differently than on f13 and f14. It meant that instead of
raise an exception and letting us move along that it raised an exception
and then exited.
So - the pkg checked out on f13 and f14 just fine but not on f12.
I had to issue a new update for all of them to keep them in sync.
That's a real world case that happens all the time.
--
Sent from my Android phone. Please excuse my brevity and top post.
12:30 p.m.
On Friday, August 13, 2010, 1:11:49 PM, Kevin wrote:
Jesse Keating wrote:
> This is where Kevin blames the scenario on not having the same sqlite on
> all of the Fedora releases, which is another evil plot hatched by the
> devils of FESCo....
Right. If F12 has a buggy SQLite, then that SQLite should be fixed!
Kevin Kofler
If the SQLite bug can be fixed, then it should be done and the package
that found the bug should be updated to list that version as a minimum
requirement. That dependency change requires at least an install
test.
If the bug can not be fixed in F12 in a compatible way, then the
package that found the bug may need to take a different approach and
find a new way of doing things that works in all supported SQLite
releases.
In either case, releasing things to stable before the regression is
eliminated should not be an option.
Al
12:32 p.m.
On Fri, 2010-08-13 at 13:30 -0400, Al Dunsmuir wrote:
On Friday, August 13, 2010, 1:11:49 PM, Kevin wrote:
> Jesse Keating wrote:
>> This is where Kevin blames the scenario on not having the same sqlite on
>> all of the Fedora releases, which is another evil plot hatched by the
>> devils of FESCo....
> Right. If F12 has a buggy SQLite, then that SQLite should be fixed!
> Kevin Kofler
If the SQLite bug can be fixed, then it should be done and the package
that found the bug should be updated to list that version as a minimum
requirement. That dependency change requires at least an install
test.
If the bug can not be fixed in F12 in a compatible way, then the
package that found the bug may need to take a different approach and
find a new way of doing things that works in all supported SQLite
releases.
In either case, releasing things to stable before the regression is
eliminated should not be an option.
Al
and that's what the testing helped with. The bug was noticed. It was
patched upstream to accomodate the versions of sqlite that act
differently and we moved along.
So, in fact, testing worked exactly as we wanted it to.
-sv
1:19 p.m.
seth vidal wrote:
and that's what the testing helped with. The bug was noticed. It
was
patched upstream to accomodate the versions of sqlite that act
differently and we moved along.
So, in fact, testing worked exactly as we wanted it to.
But if SQLite had consistently been tracking upstream bugfix releases, this
F12-only breakage wouldn't have happened in the first place.
Kevin Kofler
12:41 p.m.
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
Jesse Keating wrote:
> This is where Kevin blames the scenario on not having the same sqlite on
> all of the Fedora releases, which is another evil plot hatched by the
> devils of FESCo....
Right. If F12 has a buggy SQLite, then that SQLite should be fixed!
What if it isn't a bug, but just different behavior? To do such an
update in F12, you need to audit the other users of SQLite (of which
there are many) and check them against a new version, possibly updating
many dependent packages as well.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
2:30 p.m.
On Fri, Aug 13, 2010 at 08:20:04PM +0200, Kevin Kofler wrote:
Chris Adams wrote:
> What if it isn't a bug, but just different behavior?
Do you really think it's acceptable for a library to terminate the whole
application when an error happens??? There's a reason rpmlint complains
loudly about "shared-library-calls-exit".
The way I read skvidal's post was that the exception being issued changed.
Yum was coded to catch the exception that was being issued with later
versions of sqlite. Testing on f12 discovered that the older sqlite used
a different exception.
-Toshio
12:13 p.m.
seth vidal wrote:
On f12, however, the version of sqlite that f12 had handles an error
condition differently than on f13 and f14. It meant that instead of
raise an exception and letting us move along that it raised an exception
and then exited.
Jesse already anticipated my reply there. :-) The SQLite in F12 needs to be
fixed, and in fact should ALREADY have been fixed by proactively pushing
upstream bug fixes instead of waiting for a Fedora user to complain.
I had to issue a new update for all of them to keep them in sync.
Isn't that what the -n.fc12.1 versioning scheme is for?
Kevin Kofler
4:22 a.m.
On Fri, 13 Aug 2010 12:12:47 -0400, seth wrote:
On Fri, 2010-08-13 at 18:07 +0200, Kevin Kofler wrote:
> Al Dunsmuir wrote:
> > You are assuming that it is somehow a good idea to push release Fn, in
> > spite of no (or negative) testing.
>
> Yes I am! If I build the EXACT SAME specfile for all F*, then I don't see
> why testing on ANY F* isn't sufficient. Please don't bring the same old
> argument that "sometimes" breakage happens only on some releases even with
> the same specfile: in practice this is so rare that it doesn't matter at
> all, it's much more likely that regressions slip through despite the
> testing.
Last week I pushed a yum update to f12, f13 and f14 - same pkg, same
patches, same config.
On f12, however, the version of sqlite that f12 had handles an error
condition differently than on f13 and f14. It meant that instead of
raise an exception and letting us move along that it raised an exception
and then exited.
So - the pkg checked out on f13 and f14 just fine but not on f12.
I had to issue a new update for all of them to keep them in sync.
That's a real world case that happens all the time.
+1, +10, +1000 … happens with Fedora and also with Fedora EPEL.
I've always warned about mass-pushing updates to multiple dists,
and I'm glad I'm not the only one.
4:33 a.m.
Michael Schwendt wrote:
+1, +10, +1000 … happens with Fedora and also with Fedora EPEL.
I've always warned about mass-pushing updates to multiple dists,
and I'm glad I'm not the only one.
EPEL is an entirely different matter, since:
* there are literally YEARS between the RHEL releases and
* RHEL has a very conservative update model, exacerbating the differences
between releases.
This kind of trouble is much less likely in Fedora (proper) than in EPEL.
Kevin Kofler
5:22 a.m.
On Sat, 14 Aug 2010 11:33:02 +0200, Kevin wrote:
> I've always warned about mass-pushing updates to multiple
dists,
> and I'm glad I'm not the only one.
EPEL is an entirely different matter, since:
* there are literally YEARS between the RHEL releases and
* RHEL has a very conservative update model, exacerbating the differences
between releases.
This kind of trouble is much less likely in Fedora (proper) than in EPEL.
IMO, that's splitting-hairs. Since I don't have the time to fill this list
with dozens of messages, probably this one will be the last for today in
this thread.
It doesn't matter much if it's "less likely" or "likely".
We've had minor
version upgrades of libraries that broke the API and the ABI and lead to
app misbehaviour at run-time. Syncing all of Fedora N with Fedora N+1 is
not an option, or else we would arrive at the rolling-release model and
would not need to prepare "final releases" and distinguish between Fedora N
and N+1.
If only *some* components are replaced after the final dist release,
we basically need to redo the integration testing for each and every
update. And that hasn't been done so far. Not for changes in Python
modules, and not for other packages either.
Broken deps are just the tip of the iceberg. An unresolvable dep is a
show-stopper, as it makes installing an update impossible. But packagers,
who mass-build upgrades to multiple dists and mark them "stable" without
testing for each of the targeted dist, make it worse.
It's a packager's attitude problem. Mass-building updates for multiple
dists bears risks. Adding EPEL as additional target for the same
updates adds an extra problem. [Currently, some EPEL packagers admit they
haven't done any testing at all because they don't run a corresponding
EL dist installation.]
P.S. I'm not completely positive about the extra hurdles in bodhi either
(or crap like inheritance of Update Notes), but that is unrelated to my
view about "testing" and lack thereof.
11:48 a.m.
On 08/12/2010 07:47 PM, Orcan Ogetbil wrote:
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
> - Minimum time-in-testing requirements
> - When someone tries to push an update to stable, bodhi will
> look to see if it has the appropriate karma, or if it has
> been in testing for more than N days.
I have another question:
What happens if a package is submitted to testing the same day on
F-(x) and F-(x+1), then the F-(x) package reaches +3 karma the next
day and is automatically pushed to stable? Let's say the F-(x+1)
package still has 0 karma (or maybe even negative karma).
The F-(x) package will have higher EVR than the F-(x+1) one. This
will break the upgrade path. Is there any measures to prevent this?
Bodhi checks for broken upgrade paths upon submission, but this would
not mitigate the breakage that you describe here.
luke
6:20 a.m.
On Thu, 12 Aug 2010 17:57:28 -0400, Luke wrote:
A new version of bodhi has just hit production. This release
contains
a number of bugfixes and improvements, along with some important process
changes.
- Minimum time-in-testing requirements
- Every day bodhi will look for updates that have been
in testing for N days (fedora: N=7, epel: N=14), and will
add a comment notifying the maintainer that the update is
now able to be pushed to stable.
This sent notifications also for packages in "pending".
| bodhi - 2010-08-12 21:09:52 (karma: 0)
| This update has reached 274 days in testing and can be pushed
| to stable now if the maintainer wishes
11:31 a.m.
On 08/13/2010 07:20 AM, Michael Schwendt wrote:
On Thu, 12 Aug 2010 17:57:28 -0400, Luke wrote:
> A new version of bodhi has just hit production. This release contains
> a number of bugfixes and improvements, along with some important process
> changes.
> - Minimum time-in-testing requirements
> - Every day bodhi will look for updates that have been
> in testing for N days (fedora: N=7, epel: N=14), and will
> add a comment notifying the maintainer that the update is
> now able to be pushed to stable.
This sent notifications also for packages in "pending".
| bodhi - 2010-08-12 21:09:52 (karma: 0)
| This update has reached 274 days in testing and can be pushed
| to stable now if the maintainer wishes
Yes, this happened due to a last-minute tweak I made in the
approve_testing_updates job. I have since reverted this change.
Ideally, we shouldn't have obsolete updates in the pending state. I
think when an update is unpushed, it currently gets moved back to
pending. I'll most likely change this to make it 'obsolete' the update
instead.
luke
9:16 a.m.
On Thu, Aug 12, 2010 at 05:57:28PM -0400, Luke Macken wrote:
- Show 7 days worth of entries in our RSS feeds, as opposed to 20
entries (https://fedorahosted.org/bodhi/ticket/339)
This is nice, I forgot to add myself to the CC list, so I did not notice
this before.
- Only verify the autokarma thresholds if it is enabled (Thanks to
Till Maas)
This is still faulty. Is there a way to get access to a running bodhi
instance that I can patch and test directly? A local instance set up
according to
https://fedorahosted.org/bodhi/wiki/Development
does not allow to edit updates, because of tagging problems. Making this
possible would of course be great.
Regards
Till
6:07 p.m.
On 08/13/2010 10:16 AM, Till Maas wrote:
On Thu, Aug 12, 2010 at 05:57:28PM -0400, Luke Macken wrote:
> - Show 7 days worth of entries in our RSS feeds, as opposed to 20
> entries (https://fedorahosted.org/bodhi/ticket/339)
This is nice, I forgot to add myself to the CC list, so I did not notice
this before.
> - Only verify the autokarma thresholds if it is enabled (Thanks to
> Till Maas)
This is still faulty. Is there a way to get access to a running bodhi
instance that I can patch and test directly? A local instance set up
according to
https://fedorahosted.org/bodhi/wiki/Development
does not allow to edit updates, because of tagging problems. Making this
possible would of course be great.
I just pushed out a fix that should allow you to edit updates with your
local development instance.
luke
6:17 a.m.
On Fri, Aug 13, 2010 at 07:07:44PM -0400, Luke Macken wrote:
I just pushed out a fix that should allow you to edit updates with
your
local development instance.
Thank you very much, it works. Patches for the autokarma javascript will
soon be attached to bodhi's trac. With these, there is only a cosmetic
issue left afaics.
Btw. would you mind if I triage some Bodhi tickets and close the ones I
think are fixed in the current version? If they are not, the original
submitter can still re-open them.
Regards
Till
12:44 p.m.
On 08/14/2010 07:17 AM, Till Maas wrote:
On Fri, Aug 13, 2010 at 07:07:44PM -0400, Luke Macken wrote:
> I just pushed out a fix that should allow you to edit updates with your
> local development instance.
Thank you very much, it works. Patches for the autokarma javascript will
soon be attached to bodhi's trac. With these, there is only a cosmetic
issue left afaics.
Excellent, thank you!
Btw. would you mind if I triage some Bodhi tickets and close the ones
I
think are fixed in the current version? If they are not, the original
submitter can still re-open them.
That would be great.
luke
10:03 a.m.
On Fri, Aug 13, 2010 at 3:27 AM, Luke Macken wrote:
A new version of bodhi has just hit production. This release
contains
a number of bugfixes and improvements, along with some important process
changes.
https://admin.fedoraproject.org/updates
I expect more fine tuning will be needed for these changes but thanks for
all your work on this.
Rahul
5006
days inactive
5012
days old
112 comments
29 participants
participants (29)
-
Adam Jackson -
Adam Williamson -
Al Dunsmuir -
Bill Nottingham -
Chris Adams -
David Malcolm -
Jaroslav Reznik -
Jesse Keating -
Julian Sikorski -
Kevin Fenzi -
Kevin Kofler -
List Troll -
Luke Macken -
Martin Sourada -
Matt McCutchen -
Michael Cronenworth -
Michael Schwendt -
Nathanael D. Noblet -
Orcan Ogetbil -
Rahul Sundaram -
Ralf Corsepius -
Ryan Rix -
Seth Vidal -
Stephen John Smoogen -
Sven Lankes -
Thomas Janssen -
Till Maas -
Tomas Mraz -
Toshio Kuratomi