FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 03-09-2010, 02:56 PM
Matthew Garrett
 
Default Proposed udpates policy change

On Tue, Mar 09, 2010 at 03:26:15PM +0100, Dominik 'Rathann' Mierzejewski wrote:

> -1 to this. I've packaged a number of things that I know just one user of.
> I have no idea how many people actually use my packages or how to reach
> them. Therefore it will most likely be impossible for me to get +3 on each
> update and they'll never get out of testing. Do you really want this?

No, and it's an entirely fair question. I don't expect this proposal to
be passed as is - there's going to be further discussion of the details,
and the necessary conditions for something to be considered sufficiently
tested are clearly something that we need to think about carefully. If
there's a tiny number of users then we still want the package to be
tested, but hitting +3 may be implausible.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 03:23 PM
Seth Vidal
 
Default Proposed udpates policy change

On Tue, 9 Mar 2010, Matthew Garrett wrote:

> On Tue, Mar 09, 2010 at 03:26:15PM +0100, Dominik 'Rathann' Mierzejewski wrote:
>
>> -1 to this. I've packaged a number of things that I know just one user of.
>> I have no idea how many people actually use my packages or how to reach
>> them. Therefore it will most likely be impossible for me to get +3 on each
>> update and they'll never get out of testing. Do you really want this?
>
> No, and it's an entirely fair question. I don't expect this proposal to
> be passed as is - there's going to be further discussion of the details,
> and the necessary conditions for something to be considered sufficiently
> tested are clearly something that we need to think about carefully. If
> there's a tiny number of users then we still want the package to be
> tested, but hitting +3 may be implausible.

Thanks,
-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 04:05 PM
Stephen John Smoogen
 
Default Proposed udpates policy change

On Tue, Mar 9, 2010 at 7:12 AM, Seth Vidal <skvidal@fedoraproject.org> wrote:
>
>
> On Tue, 9 Mar 2010, Karel Zak wrote:
>
>> It's not (only) about Linus. It's about working environment and
>> strong focus on technical things.
>>
>> Please, read:
>> http://www.kernel.org/doc/Documentation/ManagementStyle
>>
>>> Yes, we don't have Linus here ;-) But usually I like his decisions - mostly
>>> strongly technical ones based on arguments = less politics.
>>
>> Yes, less politics.
>>
>
> Less politics? Seriously?
>
> man that's funny.
>

Its human nature. If people discuss things and someone's proposal gets
dissed/not added it gets listed as "politics and bureaucracy", if it
gets accepted "its meritocracy at its best." You see this a lot of
times on linux-kernel list (or in the sub-email lists). You also see a
heck of a lot of politics about where a patch needs to be fixed up to
be included. It just doesn't look like Fedora politics because its not
written down and does not have to be relied on ever again. [If Linus
wants one week of patches to be in the form of haiku and the next in
the form of sonnets.. well thats what people will produce.]


--
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 04:26 PM
Luke Macken
 
Default Proposed udpates policy change

On Mon, Mar 08, 2010 at 09:59:29PM +0000, Matthew Garrett wrote:
> This is the policy that I expect to be discussed during the Fesco
> meeting tomorrow. This is entirely orthogonal to the ongoing discussions
> regarding whether updates in stable releases should be expected to
> provide features or purely bugfixes, and I don't see any conflict in
> introducing it before those discussions have concluded.
>
> Introduction
> ------------
>
> We assume the following axioms:
>
> 1) Updates to stable that result in any reduction of functionality to
> the user are unacceptable.
>
> 2) It is impossible to ensure that functionality will not be reduced
> without sufficient testing.
>
> 3) Sufficient testing of software inherently requires manual
> intervention by more than one individual.
>
> Proposal
> --------
>
> The ability for maintainers to flag an update directly into the updates
> repository will be disabled. Before being added to updates, the package
> must receive a net karma of +3 in Bodhi.

I don't think this is ideal.

I'm having déjà vu from a lot of these discussions & proposals -- we've
been here before. When I created bodhi, it initially disallowed pushes
directly to stable. This behavior... didn't sit well with The
Community, for a variety of reasons. As you can tell by the uproar in
every single one of these threads, if these same restriction are put in
place again we will lose a lot of important contributors.

Instead of re-implementing old controversial behavior, lets look at some
recent behavioral changes in bodhi and see if we can build on top of
those to solve these problems.

For example, I recently implemented various policy restrictions for
critical path/no frozen rawhide updates for pending releases. In order
for a critical path update to get marked as 'stable' for a pending
release, it must have at least +1 karma from releng/qa members, and at
least +1 from an authenticated user. These values, of course, are
configurable.

I think a much better solution would be to require similar critical path
policies, across *all* releases, not just pending ones, while still
allowing non-critpath packages to go directly to stable.

Requiring a static amount of karma across all updates is not going to be
sufficient, especially with the current karma system (which I think
needs improvement). Especially now with the easy-karma script, people can
+1 dozens of updates at a time, reaching +3 will be almost too easy for
certain packages, and yet not not easy enough for others. Having
configurable karma thresholds for different packages seems to be
sufficient, and it allows package maintainers to use their intuition to
tweak these thresholds accordingly to fit their workflow and tester
base. For example, the kernel maintainers disable karma automation
entirely, and one could argue that this flexibility is important.

Regarding the current karma system, I think Doug Ledford brought up some
good ideas in the earlier thread 'Bodhi karma feature request', and
I know other bodhi developers agree.

With an improved karma system, stricter critpath update handling, AutoQA
integration, and giving The User more fine-grained control over what
types of updates they actually want, I think we'll be much better off
than we currently are.

luke
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 05:13 PM
Jesse Keating
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 00:18 +0100, Kevin Kofler wrote:
> > It is the expectation of Fesco that the majority of updates should
> > easily be able to garner the necessary karma in a minimal space of time.
>
> You gotta be kidding! Just look at the current update landscape to see how
> far from the truth this is.
>
> (And I also wonder with what authority you speak in the name of FESCo as a
> whole. The fact that what you're saying is so clearly wrong makes this all
> the more an issue.)
>

The proposal is for FESCo to adopt that position. It is not a statement
of current fact.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 05:22 PM
Josh Stone
 
Default Proposed udpates policy change

On 03/09/2010 05:32 AM, Joe Orton wrote:
> On Tue, Mar 09, 2010 at 02:20:20PM +0100, Mathieu Bridon wrote:
>> If the issues this update was solbing really bothered them, they would
>> have provided feedback earlier.
>
> Hah, right. Back in the real world, most users expect free cake and
> complain if they don't get it.

We re-educate. You can have your free cake but we won't frost it until
you've helped us make sure it's properly baked.

Josh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 05:36 PM
Kevin Kofler
 
Default Proposed udpates policy change

Luke Macken wrote:
> For example, the kernel maintainers disable karma automation entirely, and
> one could argue that this flexibility is important.

We also systematically disable karma automatism for KDE updates. We found
the numeric karma to be a very poor indicator of the quality of the update.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 05:41 PM
Kevin Kofler
 
Default Proposed udpates policy change

Matthew Garrett wrote:
> As I've said elsewhere, this is a problem that needs solving. But I
> don't believe that it's a problem that's best solved by allowing people
> to push directly to stable.

* What other solution do you propose?
* Your proposal is doing much more than just banning pushing directly to
stable (which by its own would already be annoying enough).

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 05:48 PM
Jon Masters
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 12:26 -0500, Luke Macken wrote:

> I think a much better solution would be to require similar critical path
> policies, across *all* releases, not just pending ones, while still
> allowing non-critpath packages to go directly to stable.

That is an acceptable fallback. But just for the record, I consider the
critical path on my desktop to include not just kernel/udev/modules/etc.
but also GNOME, cups, and other things I use each day. I don't
personally care if KDE is updated 20 times a week, or about other
packages that aren't installed by default being rebased often.

Jon.


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 03-09-2010, 06:01 PM
Jesse Keating
 
Default Proposed udpates policy change

On Tue, 2010-03-09 at 19:41 +0100, Kevin Kofler wrote:
> * Your proposal is doing much more than just banning pushing directly to
> stable (which by its own would already be annoying enough).
>

Actually his proposal would allow for pushing directly to stable,
provided the update ticket got enough karma before the push action.

--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 02:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org