On Thu, 10 Jun 2010 04:59:30 +0200
Kevin Kofler wrote:
> > Now, if the policies that are being approved do not actually
> > benefit the greater good of the community, we have bigger problems.
>
> Yet that's exactly the problem we're having. :-(
snip...
> So why are we now going to use the
* Kevin Kofler [10/06/2010 17:21] :
>
> Why are we trying to emulate the failed Fedora Legacy
> process rather than the successful Fedora Extras one? Why can't we learn
> from our past?
I think you're rather quick to conclude that Extras succeded because it
allowed maintainers to
On Thu, Jun 10, 2010 at 05:10:36PM +0200, Kevin Kofler wrote:
>Josh Boyer wrote:
>> There are a number of people who disagree with the value of that goal,
>> including most of the past and current FESCo.
>
>You conveniently ignored the part of the mail where I pointed out WHY that
>goal is broken.
Josh Boyer wrote:
> There are a number of people who disagree with the value of that goal,
> including most of the past and current FESCo.
You conveniently ignored the part of the mail where I pointed out WHY that
goal is broken. Why are we trying to emulate the failed Fedora Legacy
process rath
On Thu, Jun 10, 2010 at 04:59:30AM +0200, Kevin Kofler wrote:
>Luke Macken wrote:
>> Neither of you have mentioned "your" definition of the word "success".
>> Care to enlighten us?
>
>Success is the achievement of a worthwhile goal. If the original goal which
>was set is worthless, "succeeding" at
On Thu, 2010-06-10 at 05:03 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > Users also want regressions not to happen
>
> This is exactly why we need quick fixes, i.e. direct stable pushes: to be
> able to push a fixed update IMMEDIATELY if somebody caught a regression.
We danced that ta
Adam Williamson wrote:
> Users also want regressions not to happen
This is exactly why we need quick fixes, i.e. direct stable pushes: to be
able to push a fixed update IMMEDIATELY if somebody caught a regression.
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https:/
Luke Macken wrote:
> Neither of you have mentioned "your" definition of the word "success".
> Care to enlighten us?
Success is the achievement of a worthwhile goal. If the original goal which
was set is worthless, "succeeding" at it is meaningless.
> Now, if the policies that are being approved
On Wed, 2010-06-09 at 09:35 +0200, Marcela Mašláňová wrote:
> that I've already fixed. Users want fixes immediately, they are not
> interested in some processes. Many users don't even have FAS account and
Users also want regressions not to happen (see how much belly-aching
there is over the nss
On Wed, 2010-06-09 at 09:51 +0200, Michael Schwendt wrote:
> from times when the fedora-easy-karma script wasn't available and
> didn't make it possible to mass-vote on updates.
easy-karma doesn't allow you to mass vote, you still have to vote on
each update individually. it simply streamlines th
On Tue, 2010-06-08 at 16:51 -0400, Luke Macken wrote:
> I recently wrote some code to generate detailed statistics of Fedora & EPEL
> updates within bodhi. Eventually this will be auto-generated and exposed
> within bodhi itself, but for now here are the initial metrics.
>
> This report definite
On Wed, Jun 9, 2010 at 6:03 PM, Luke Macken wrote:
> The majority of karma is "this ran without exploding", which is far from
> sufficient testing, but it's still valuable information.
Indeed. And to be honest, i can't agree with all that whining that
karma isn't useful. It means the user tried/u
On Wed, 09 Jun 2010 12:03:50 -0400, Luke wrote:
> According to the new acceptance critera, updates will have to "spend
> some minimum amount of time in updates-testing, currently one week".
> Now, as to whether or not bodhi should auto-push after that week, that
> I'm not quite sure.
Rest assured
On 06/09/2010 01:18 AM, Kevin Kofler wrote:
> If the packages have good quality, that means more testing is NOT
> needed, no matter what the actual amount of testing was.
Apart from the Bodhi issue, I disagree with the logic of your statement.
Quality doesn't exist (or at least is not provable) i
On Wed, Jun 9, 2010 at 8:31 AM, Adam Miller
wrote:
> Did we really need to
> take some raw numbers that Luke was kind enough to put together and make it
> into some sort of QA methods holy war?
The lesson here is that for data mining to make sense there must a
consensus understanding of the quest
On Wed, 2010-06-09 at 09:10 +0200, Ralf Corsepius wrote:
> On 06/09/2010 08:54 AM, Luke Macken wrote:
> > On Wed, 2010-06-09 at 08:38 +0200, Kevin Kofler wrote:
> >> Luke Macken wrote:
> >>> By "success" I mean that I felt we were successful in drafting,
> >>> implementing, deploying, and utilizing
Luke's dictionary is more correct than yours.
anyone else see how horrid the line I just wrote sounded in your head
when you read it? That's what this thread sounds like. Did we really need to
take some raw numbers that Luke was kind enough to put together and make it
into some sort of QA met
On Wed, 2010-06-09 at 09:35 +0200, Marcela Mašláňová wrote:
> On 06/08/2010 10:51 PM, Luke Macken wrote:
> > I recently wrote some code to generate detailed statistics of Fedora& EPEL
> > updates within bodhi. Eventually this will be auto-generated and exposed
> > within bodhi itself, but for no
On Wed, 9 Jun 2010, Kevin Kofler wrote:
Marcela Mašláňová wrote:
I can't agree that this update policy is success (in any dictionary).
Since I'm forced to wait
two weeks for pushing into stable, I have more tickets about packages
that I've already fixed. Users want fixes immediately, they are
Marcela Mašláňová wrote:
> I can't agree that this update policy is success (in any dictionary).
> Since I'm forced to wait
> two weeks for pushing into stable, I have more tickets about packages
> that I've already fixed. Users want fixes immediately, they are not
> interested in some processes. M
On Wednesday 09 June 2010, Rahul Sundaram wrote:
> There are well known cases of that happening. Kevin has been public
> about his position on that. Hopefully we can automatically catch and
> prevent the obvious breakages soon.
For the record, I did test (on one release) the latest bunch of upd
On 06/09/2010 05:12 PM, Josh Boyer wrote:
> That is true if you are making the assumption that the package maintainer did
> no testing themselves. I would hope that isn't the common case.
>
There are well known cases of that happening. Kevin has been public
about his position on that. Hopef
On Wed, Jun 09, 2010 at 09:51:59AM +0200, Michael Schwendt wrote:
>On Tue, 8 Jun 2010 16:51:36 -0400 (EDT), Luke wrote:
>
>> =====
>> Bodhi Statistics Report (Generated
On Wed, Jun 09, 2010 at 10:58:15AM +0530, Rahul Sundaram wrote:
>On 06/09/2010 10:48 AM, Kevin Kofler wrote:
>> Stephen John Smoogen wrote:
>>
>>> Well the only person I see mentioning quality is Kevin. And for some
>>> reason he is expecting it immediately
>>>
>> You can't claim that there
On Tue, Jun 08, 2010 at 04:51:36PM -0400, Luke Macken wrote:
> You can find the code that generates these statistics here:
> https://fedorahosted.org/bodhi/browser/bodhi/tools/metrics.py
> https://fedorahosted.org/bodhi/browser/bodhi/tools/log_stats.py. If you have
> any ideas or suggestions for
On Tue, 8 Jun 2010 16:51:36 -0400 (EDT), Luke wrote:
> =
> Bodhi Statistics Report (Generated on June 8th, 2010)
> =
>
> Out of 17412 total updates, 2958 received feedback (1
On 06/08/2010 10:51 PM, Luke Macken wrote:
> I recently wrote some code to generate detailed statistics of Fedora& EPEL
> updates within bodhi. Eventually this will be auto-generated and exposed
> within bodhi itself, but for now here are the initial metrics.
>
> This report definitely conveys t
On 06/09/2010 08:54 AM, Luke Macken wrote:
> On Wed, 2010-06-09 at 08:38 +0200, Kevin Kofler wrote:
>> Luke Macken wrote:
>>> By "success" I mean that I felt we were successful in drafting,
>>> implementing, deploying, and utilizing the mentioned policies as
>>> expected, and the results show incre
On Wed, 2010-06-09 at 08:38 +0200, Kevin Kofler wrote:
> Luke Macken wrote:
> > By "success" I mean that I felt we were successful in drafting,
> > implementing, deploying, and utilizing the mentioned policies as
> > expected, and the results show increased community engagement.
>
> This definitio
Luke Macken wrote:
> By "success" I mean that I felt we were successful in drafting,
> implementing, deploying, and utilizing the mentioned policies as
> expected, and the results show increased community engagement.
This definition of "success" does not match mine nor the one you'll find in
a di
On Tue, 2010-06-08 at 21:20 -0400, Matthias Clasen wrote:
> On Tue, 2010-06-08 at 16:51 -0400, Luke Macken wrote:
>
> >
> > Fedora 13
> > ==
On Tue, 2010-06-08 at 16:51 -0400, Luke Macken wrote:
>
> Fedora 13
>
>
> * 231 updates automatically pushed due to karma (6.49%)
On Wed, 2010-06-09 at 01:46 +0200, Kevin Kofler wrote:
> Luke Macken wrote:
> > This report definitely conveys the shortcomings in our testing, however,
> > it does show us improving with each release.
By 'shortcomings in our testing', I mean, 'shortcomings in the process
by which we currently us
On 06/09/2010 10:48 AM, Kevin Kofler wrote:
> Stephen John Smoogen wrote:
>
>> Well the only person I see mentioning quality is Kevin. And for some
>> reason he is expecting it immediately
>>
> You can't claim that there are "shortcomings in our testing" (the exact
> words Luke used!) with
Stephen John Smoogen wrote:
> Well the only person I see mentioning quality is Kevin. And for some
> reason he is expecting it immediately
You can't claim that there are "shortcomings in our testing" (the exact
words Luke used!) without a metric of quality. A shortcoming in testing
means less te
On Tue, Jun 8, 2010 at 6:41 PM, Brandon Lozza wrote:
> On Tue, Jun 8, 2010 at 7:46 PM, Kevin Kofler wrote:
>> Luke Macken wrote:
>>> This report definitely conveys the shortcomings in our testing, however,
>>> it does show us improving with each release. For Fedora 13, we implemented
>>> the No F
On Tue, 2010-06-08 at 16:51 -0400, Luke Macken wrote:
>
> Fedora 13
>
>
> * 3562 updates
> * 3065 stable updates
> * 427 testin
On Tue, Jun 8, 2010 at 7:46 PM, Kevin Kofler wrote:
> Luke Macken wrote:
>> This report definitely conveys the shortcomings in our testing, however,
>> it does show us improving with each release. For Fedora 13, we implemented
>> the No Frozen Rawhide process with improved Critical Path policies,
Luke Macken wrote:
> This report definitely conveys the shortcomings in our testing, however,
> it does show us improving with each release. For Fedora 13, we implemented
> the No Frozen Rawhide process with improved Critical Path policies, which
> were definitely a success. With these enhanced pro
i/browser/bodhi/tools/log_stats.py. If you have
any ideas or suggestions for different types of metrics to generate, or if you
find any bugs in my code, please let me know.
luke
=====
Bodhi Statistics Report (Generated on June
40 matches
Mail list logo
