Al Dunsmuir wrote:
> Often the reason that folks are using an older stable release because
> they *can not* update to the new stable release because it doesn't
> work for them,
But that's exactly why we want to continue pushing those updates that do
work for them. :-)
> or they *choose*
Hello Kevin,
Thursday, March 11, 2010, 8:09:02 AM, you wrote:
> Al Dunsmuir wrote:
>> For older releases, the presumption/requirement for stability is
>> higher.
> Nonsense. The previous and current stable releases are both equally
> supported, there isn't one which is "more stable" than
Al Dunsmuir wrote:
> For older releases, the presumption/requirement for stability is
> higher.
Nonsense. The previous and current stable releases are both equally
supported, there isn't one which is "more stable" than the other.
> If you don't have the resources to ensure that older rel
On Wednesday, March 10, 2010, 7:11:31 PM, Kevin Kofler wrote:
> Al Dunsmuir wrote:
>> The update to an older stable release should be made widely available
>> in that release's updates-testing after the equivalent (not
>> necessarily identical) fix has been widely tested in the latest
Al Dunsmuir wrote:
> The update to an older stable release should be made widely available
> in that release's updates-testing after the equivalent (not
> necessarily identical) fix has been widely tested in the latest stable
> release.
Uh, no, just no.
They should go to updates-testi
On Tuesday, March 9, 2010, 8:09:40 PM, Kevin Kofler wrote:
>> Jesse Keating wrote:
>> On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote:
>>> It seems to cast doubt on the value of karma -- just because something
>>> gets lots of positive karma on N doesn't mean that N-1 is ok. Then
>>> again, t
Jesse Keating wrote:
> On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote:
>> It seems to cast doubt on the value of karma -- just because something
>> gets lots of positive karma on N doesn't mean that N-1 is ok. Then
>> again, the same concern is present in any grouped update if the voters
>>
On Wed, 2010-03-10 at 11:13 -0600, Bruno Wolff III wrote:
> On Tue, Mar 09, 2010 at 15:43:04 -0500,
> James Laska wrote:
> >
> > 1. repoclosure/conflicts - no package update can introduce broken
> > deps or conflicts. I'd recommend we apply this to both
> > 'updates-testin
On Wed, 2010-03-10 at 13:18 +, Paul Howarth wrote:
> On 09/03/10 20:43, James Laska wrote:
> > Some basics I'd propose as a starting point for defining acceptance
> > criteria include:
> >
> > 1. repoclosure/conflicts - no package update can introduce broken
> > deps or conflicts
On Tue, 2010-03-09 at 17:18 -0800, Adam Williamson wrote:
> On Tue, 2010-03-09 at 17:13 -0700, Kevin Fenzi wrote:
>
> > > Some basics I'd propose as a starting point for defining acceptance
> > > criteria include:
> > >
> > > 1. repoclosure/conflicts - no package update can introduce broken
On Tue, Mar 09, 2010 at 15:43:04 -0500,
James Laska wrote:
>
> 1. repoclosure/conflicts - no package update can introduce broken
> deps or conflicts. I'd recommend we apply this to both
> 'updates-testing' and 'updates' (but that's detailed below)
> 2. Package sanity
On 09/03/10 20:43, James Laska wrote:
> Some basics I'd propose as a starting point for defining acceptance
> criteria include:
>
> 1. repoclosure/conflicts - no package update can introduce broken
> deps or conflicts. I'd recommend we apply this to both
> 'updates-testing'
- "Adam Williamson" wrote:
> There actually already *is* a review point
> prior to moving to -updates, but it's currently owned by rel-eng and
> is
> not highly publicized, and very little gets rejected. It is there,
> though: rel-eng explained this earlier in the threads, and explained
> that
On 03/09/2010 06:56 PM, Michael Schwendt wrote:
> On Tue, 9 Mar 2010 12:21:04 -0500 (EST), Kamil wrote:
> If you - and the QA team - want to expand your testing activities, focus
> on the CRITPATH packages first. Do a good job there. Nobody from QA has
> ever given feedback to any of my updates, a
On Tue, 2010-03-09 at 17:13 -0700, Kevin Fenzi wrote:
> > Some basics I'd propose as a starting point for defining acceptance
> > criteria include:
> >
> > 1. repoclosure/conflicts - no package update can introduce broken
> > deps or conflicts. I'd recommend we apply this to both
>
On 03/09/2010 04:11 PM, Jesse Keating wrote:
> Even if you put an update for N and N-1 in the same form, once you
> submit the request it splits it into two requests, one per Fedora
> release. This means you'd have one set of karma per Fedora release.
Aha, I forgot that. Thanks.
Josh
--
devel
On Tue, 09 Mar 2010 15:43:04 -0500
James Laska wrote:
> We'll make adjustments based on feedback so far. But I want to point
> out that one goal for this policy is to reach consensus on a set of
> criteria that all [1] packages must adhere to in order to be accepted
> as Fedora updates. The imp
On Tue, 2010-03-09 at 16:08 -0800, Josh Stone wrote:
> On 03/09/2010 03:43 PM, Kevin Kofler wrote:
> > James Laska wrote:
> >> 3. Package must be newer than previously released versions - can't
> >> ship newer package in N-1.
> >
> > Definitely, but we must make sure that it's still p
On 03/09/2010 03:43 PM, Kevin Kofler wrote:
> James Laska wrote:
>> 3. Package must be newer than previously released versions - can't
>> ship newer package in N-1.
>
> Definitely, but we must make sure that it's still possible to queue the same
> update for N and N-1 at the same tim
James Laska wrote:
> 3. Package must be newer than previously released versions - can't
> ship newer package in N-1.
Definitely, but we must make sure that it's still possible to queue the same
update for N and N-1 at the same time (= without having to wait for a push
between queuei
On Tue, 2010-03-09 at 19:50 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > The proposal isn't really about expanding testing activities, it's about
> > formally codifying how the updates process is actually supposed to work.
> > Right now, we don't in fact define how the Fedora update proc
Hello James,
Tuesday, March 9, 2010, 2:53:22 PM, you wrote:
> On Tue, 2010-03-09 at 13:41 -0500, Seth Vidal wrote:
>>
>> On Tue, 9 Mar 2010, Michael Schwendt wrote:
>>
>> > If you - and the QA team - want to expand your testing activities, focus
>> > on the CRITPATH packages first. Do a good jo
On Tue, 2010-03-09 at 13:41 -0500, Seth Vidal wrote:
>
> On Tue, 9 Mar 2010, Michael Schwendt wrote:
>
> > If you - and the QA team - want to expand your testing activities, focus
> > on the CRITPATH packages first. Do a good job there. Nobody from QA has
> > ever given feedback to any of my upda
On Tue, Mar 09, 2010 at 07:38:44PM +0100, Michael Schwendt wrote:
> On Tue, 09 Mar 2010 10:12:41 -0800, Adam wrote:
>
> > Please provide details on what's mad about Kamil's proposal.
>
> Here:
>
> | The package updates must spend at least 14 days [1] in the
> | 'updates-testing' repository, or a
On Tue, 2010-03-09 at 11:00 -0800, Adam Williamson wrote:
> > It isn't a snapshot of how it works currently, though.
>
> It's fairly close. As far as I can see, all it intentionally changes
> from the current process is that it provides a review point prior to
> acceptance into -testing.
Additi
On Tue, 2010-03-09 at 19:38 +0100, Michael Schwendt wrote:
> > Please provide details on what's mad about Kamil's proposal.
>
> Here:
>
> | The package updates must spend at least 14 days [1] in the
> | 'updates-testing' repository, or at least 7 days [1] provided they have
> | karma of at least
Adam Williamson wrote:
> The proposal isn't really about expanding testing activities, it's about
> formally codifying how the updates process is actually supposed to work.
> Right now, we don't in fact define how the Fedora update process is
> supposed to work: how updates get submitted, how they
On Tue, 9 Mar 2010, Michael Schwendt wrote:
> If you - and the QA team - want to expand your testing activities, focus
> on the CRITPATH packages first. Do a good job there. Nobody from QA has
> ever given feedback to any of my updates, and it won't happen in the
> future either.
I would not b
On Tue, 09 Mar 2010 10:12:41 -0800, Adam wrote:
> Please provide details on what's mad about Kamil's proposal.
Here:
| The package updates must spend at least 14 days [1] in the
| 'updates-testing' repository, or at least 7 days [1] provided they have
| karma of at least 3 [1] and no negative fe
On Tue, 2010-03-09 at 18:56 +0100, Michael Schwendt wrote:
> Why not? The end is near, it seems to me. It's like fear of castration.
> These mad proposals deserve to be flamed. Thanks to the "Fedora School
> Of Developing Bad Attitudes", I see myself gaining experience on how to
> become a 2nd lev
On Tue, 9 Mar 2010 12:21:04 -0500 (EST), Kamil wrote:
> The proposal is here:
>
> https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_policy
> If you dislike some
> idea, please don't consider it the end of the world, that is
> worth creating another endless flame-war discussion
Hello,
I have been (together with the QA team) working on a 'Package
update policy' proposal. Because Matthew Garrett yesterday
presented his own proposal regarding this topic, we decided
to also present our proposal, albeit still unfinished.
The proposal is here:
https://fedoraproject.org/wik
32 matches
Mail list logo
