Toshio Kuratomi wrote:
> So, on the whole, I agree with you. My only question is whether we're in
> a transitional period or if the culture is changing so slowly that we'll
> never get out of this treatment of our time resources.
I think it's neither. It's that the "new way of working" being sugg
On Thu, 2010-08-12 at 13:39 -0500, Mike McGrath wrote:
> Would an 8[1] month cycle cause fewer slips per release? Fewer bugs?
Personally, I'd like to see a 9-12 month cycle. Much as I'm sure
everyone out there instantly upgrades every system the moment a new
release comes out, and doesn't mind a
Peter Jones said the following on 08/16/2010 11:50 AM Pacific Time:
> On 08/16/2010 02:06 PM, Mike McGrath wrote:
>> On Mon, 16 Aug 2010, Peter Jones wrote:
>>
>>> On 08/12/2010 02:39 PM, Mike McGrath wrote:
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>> "BN" == Bill Nottingh
Mike McGrath said the following on 08/16/2010 12:18 PM Pacific Time:
> On Mon, 16 Aug 2010, Peter Jones wrote:
>
>> On 08/16/2010 02:06 PM, Mike McGrath wrote:
>>> On Mon, 16 Aug 2010, Peter Jones wrote:
>>>
On 08/12/2010 02:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitt
Till Maas said the following on 08/16/2010 11:41 AM Pacific Time:
> On Mon, Aug 16, 2010 at 01:06:46PM -0500, Mike McGrath wrote:
>> On Mon, 16 Aug 2010, Peter Jones wrote:
>>
>>> On 08/12/2010 02:39 PM, Mike McGrath wrote:
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>> "BN"
Adam Williamson said the following on 08/13/2010 05:21 PM Pacific Time:
> On Thu, 2010-08-12 at 16:11 -0600, Linuxguy123 wrote:
>
>> On the data side, it would be very interesting to go back to each one of
>> those slips and identify the component(s) that caused the slip and then
>> question the in
On Mon, Aug 16, 2010 at 02:10:16PM -0700, Adam Williamson wrote:
>
> As I mentioned briefly on IRC, I think the problem is that we're kinda
> stuck between two models:
[snip]
>
> For instance, right now, according to the Ideal Plan, everyone should
> have started on their Big Plans for F15 in Ra
On Mon, 2010-08-16 at 14:18 -0500, Mike McGrath wrote:
> I think this is worth further discussion. If the number is towards the
> 48-63 days level and that's what window people are actually doing
> development that may be a problem because it is an extremely short time
> period.
>
> It's also in
On Mon, 16 Aug 2010, Peter Jones wrote:
> On 08/16/2010 02:06 PM, Mike McGrath wrote:
> > On Mon, 16 Aug 2010, Peter Jones wrote:
> >
> >> On 08/12/2010 02:39 PM, Mike McGrath wrote:
> >>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
> >>>
> > "BN" == Bill Nottingham writes:
>
>
On 08/16/2010 02:06 PM, Mike McGrath wrote:
> On Mon, 16 Aug 2010, Peter Jones wrote:
>
>> On 08/12/2010 02:39 PM, Mike McGrath wrote:
>>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>>>
> "BN" == Bill Nottingham writes:
BN> I can't help but note that the slips have become
On Mon, Aug 16, 2010 at 01:06:46PM -0500, Mike McGrath wrote:
> On Mon, 16 Aug 2010, Peter Jones wrote:
>
> > On 08/12/2010 02:39 PM, Mike McGrath wrote:
> > > On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
> > >
> > >>> "BN" == Bill Nottingham writes:
> > >>
> > >> BN> I can't help but not
On Mon, 16 Aug 2010, Peter Jones wrote:
> On 08/12/2010 02:39 PM, Mike McGrath wrote:
> > On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
> >
> >>> "BN" == Bill Nottingham writes:
> >>
> >> BN> I can't help but note that the slips have become more frequent as we
> >> BN> started to actually
On 08/12/2010 02:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>
>>> "BN" == Bill Nottingham writes:
>>
>> BN> I can't help but note that the slips have become more frequent as we
>> BN> started to actually *have* release criteria to test against. We
>> BN> did
On Thu, 2010-08-12 at 16:11 -0600, Linuxguy123 wrote:
> On the data side, it would be very interesting to go back to each one of
> those slips and identify the component(s) that caused the slip and then
> question the individuals behind them to find out what happened. Then
> take that information
On Fri, Aug 13, 2010 at 19:07:57 +0200,
Kevin Kofler wrote:
> Bruno Wolff III wrote:
> > Most features are fairly independent and don't cause problems when they
> > run late or have problems, outside of that feature. Some are somewhat
> > disruptive and can make it hard to test other things whil
Bruno Wolff III wrote:
> Most features are fairly independent and don't cause problems when they
> run late or have problems, outside of that feature. Some are somewhat
> disruptive and can make it hard to test other things while they are having
> their kinks worked out or just waiting for rebuilds
Nathanael D. Noblet wrote:
> Just an idea, without _fully_ understanding the infrastructure, man
> power etc ramifications.
>
> Since the move to git, would it not be easier to allow features to
> branch rawhide, get their individual bits together (syncing with 'trunk'
> periodically)... Then like
On Fri, 13 Aug 2010, Bruno Wolff III wrote:
> On Fri, Aug 13, 2010 at 09:49:42 -0600,
> "Nathanael D. Noblet" wrote:
> >
> > Since the move to git, would it not be easier to allow features to
> > branch rawhide, get their individual bits together (syncing with 'trunk'
> > periodically)... Then
On Fri, Aug 13, 2010 at 09:49:42 -0600,
"Nathanael D. Noblet" wrote:
>
> Since the move to git, would it not be easier to allow features to
> branch rawhide, get their individual bits together (syncing with 'trunk'
> periodically)... Then like the kernel does, merge back the working bits
> t
On Friday, August 13, 2010, 11:52:33 AM, Kevin wrote:
> Mike McGrath wrote:
>> :( I'm saddened you think so little of us Kevin. I'd have thought we
>> could do both.
> And you think Santa Claus exists, too? ;-)
> Kevin Kofler
http://www.snopes.com/holidays/christmas/photos/badsanta.asp
On Thu, Aug 12, 2010 at 22:22:18 -0700,
Jesse Keating wrote:
>
> How do you suggest we be "more conservative"? If you expect the
> developers to do this on their own, good luck. If you want there to be
> some sort of enforcement I welcome suggestions.
My suggestion would be to ask developers
On 08/13/2010 09:22 PM, Kevin Kofler wrote:
> Mike McGrath wrote:
>> :( I'm saddened you think so little of us Kevin. I'd have thought we
>> could do both.
> And you think Santa Claus exists, too? ;-)
No, his goal is certainly achievable and worth trying. The frequent
slips are a problem and w
Mike McGrath wrote:
> :( I'm saddened you think so little of us Kevin. I'd have thought we
> could do both.
And you think Santa Claus exists, too? ;-)
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Just an idea, without _fully_ understanding the infrastructure, man
power etc ramifications.
Since the move to git, would it not be easier to allow features to
branch rawhide, get their individual bits together (syncing with 'trunk'
periodically)... Then like the kernel does, merge back the wor
On Fri, 13 Aug 2010, Kevin Kofler wrote:
> Mike McGrath wrote:
> > I'll admit, this is a convenient view to have. The problem is we're not
> > in high school anymore. We're professionals. We're expected to set and
> > keep schedules because people besides ourselves rely on those schedules.
> >
Mike McGrath wrote:
> I'll admit, this is a convenient view to have. The problem is we're not
> in high school anymore. We're professionals. We're expected to set and
> keep schedules because people besides ourselves rely on those schedules.
> There are other distros that set and keep schedules
On Thu, Aug 12, 2010 at 9:34 PM, Nicolas Mailhot
wrote:
> Le jeudi 12 août 2010 à 13:51 -0500, Jason L Tibbitts III a écrit :
>
>> I guess I'm just saying that, if we had the developer time to do it, it
>> would be super nice if we could get the "pre-F15 rawhide is useless" bit over
>> and done wi
On Fri, 13 Aug 2010, Jaroslav Reznik wrote:
> On Thursday, August 12, 2010 09:33:17 pm Lennart Poettering wrote:
> > On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
> > > Since 2006 I counted 18 slips (I think one or two of those may just be a
> > > single slip listed twice). Le
On Thursday, August 12, 2010 09:33:17 pm Lennart Poettering wrote:
> On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
> > Since 2006 I counted 18 slips (I think one or two of those may just be a
> > single slip listed twice). Lets not yell, lets not flame war, lets not
> > point f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 12:33 PM, Lennart Poettering wrote:
> On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
>
>> Since 2006 I counted 18 slips (I think one or two of those may just be a
>> single slip listed twice). Lets not yell, lets not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 12:05 PM, Bruno Wolff III wrote:
> On Thu, Aug 12, 2010 at 12:00:29 -0700,
> Adam Williamson wrote:
>>
>> We usually catch most initial blockers for any given release at the
>> first TC stage. Bugs we slip for are usually ones identifi
Nicolas Mailhot wrote:
> So perhaps the delay between "invasive features autorized" and "alpha"
> is too short.
It's true that sometimes very invasive features have been rushed in right
before the feature freeze, often irrespective of the (lack of) benefits (at
least at their state of developmen
drago01 wrote:
> It isn't broken so there is nothing to fix; slipping to fix issues
> found is a feature not a bug.
> We don't have any reason to "rush".
+1
Slips DO and WILL happen. It's just a matter of fact. It also happens in
other projects. We just need to accept this.
If we really want to
Will Woods wrote:
> This is a good point, and it's one of the reasons the 'critpath' stuff
> exists. It's the same concept, applied somewhat differently: rather than
> freeze the 'CoreOS' stuff earlier, we freeze it harder - we require more
> testing for those pieces.
The problem is, "freezing har
Nathaniel McCallum wrote:
> I disagree, the feature is shipping on time. Shipping on time enables
> others in the Fedora community (people who build on, deploy, etc) know
> with some assurance what their schedules will look like. If I were a
> project manager looking at using a Linux OS in my pro
Jason L Tibbitts III wrote:
> To me this implies that we should begin testing earlier (or, perhaps,
> never stop testing) and treat any new failure as an event of
> significance. It's tough to meet a six month cycle if we spend half of
> it telling people to expect everything to be broken.
We HAV
Bruno Wolff III wrote:
> We've tried that in the past and it didn't work. Slipping the whole
> schedule right away is better than slipping piecewise when it comes to
> planning.
Huh? What's the worst that can happen? That we slip again, being at the same
release date as with the cascading slip sy
On Thu, 2010-08-12 at 13:19 -0500, Mike McGrath wrote:
> How can we fix this?
Step 1 is to realize/admit there is a problem. You've tactfully done
that.
Step 2 is to gather data and knowledge. That doesn't appear to be
happening in these posts.
On the data side, it would be very interesting to
I'll reply here but I'm also bringing together some things in the rest of
the thread... sorry about that.
On Thu, Aug 12, 2010 at 01:19:29PM -0500, Mike McGrath wrote:
>
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets no
On Thu, 2010-08-12 at 15:02 -0400, Nathaniel McCallum wrote:
> If our schedules aren't reasonably fixed, than others have a hard time
> working with us. Loosing users (especially companies with resources to
They are reasonably fixed. Please don't blow this out of proportion. I
don't believe we'v
On 08/12/2010 02:22 PM, Bill Nottingham wrote:
> Jon Ciesla (l...@jcomserv.net) said:
>> I disagree that a clockwork release schedule is required for quality, or
>> even perceived quality. If that's the sort of metric being looked at,
>> the user is probably best suited to RHEL, CentOS, etc.
> I
On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets not flame war, lets not
> point fingers. How can we fix this? It's clearly not one group or one
> individ
Le jeudi 12 août 2010 à 13:51 -0500, Jason L Tibbitts III a écrit :
> I guess I'm just saying that, if we had the developer time to do it, it
> would be super nice if we could get the "pre-F15 rawhide is useless" bit over
> and done with by the time F15 branches. But back in reality, I know
> tha
On Thu, 2010-08-12 at 13:39 -0500, Mike McGrath wrote:
> Would an 8[1] month cycle cause fewer slips per release? Fewer bugs?
For me, one of the guiding principles for Fedora QA's work on tools and
policies has been this: time, by itself, doesn't fix anything.
Making the schedules longer isn't
On Thu, 2010-08-12 at 21:33 +0200, Lennart Poettering wrote:
> I want to mention one thing: on opensuse the "base"
> system has a different schedule then the rest of the OS. i.e. the
> kernel, gcc, glibc and the low-level tools freeze first, while
> everything else may be hacked on a couple of wee
On Thu, Aug 12, 2010 at 2:19 PM, Mike McGrath wrote:
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets not flame war, lets not
> point fingers. How can we fix this?
[snip]
> This is a collective failure.
While I agree t
On Thu, 2010-08-12 at 21:33 +0200, Lennart Poettering wrote:
> On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
>
> > Since 2006 I counted 18 slips (I think one or two of those may just be a
> > single slip listed twice). Lets not yell, lets not flame war, lets not
> > point fing
Jon Ciesla (l...@jcomserv.net) said:
> I disagree that a clockwork release schedule is required for quality, or
> even perceived quality. If that's the sort of metric being looked at,
> the user is probably best suited to RHEL, CentOS, etc.
It would be interesting to look at RHEL/CentOS to see
On 08/12/2010 02:14 PM, Nathaniel McCallum wrote:
> On 08/12/2010 03:08 PM, Jon Ciesla wrote:
>>On 08/12/2010 01:39 PM, Mike McGrath wrote:
>>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>>>
> "BN" == Bill Nottingham writes:
BN> I can't help but note that the slips have
On 08/12/2010 03:08 PM, Jon Ciesla wrote:
> On 08/12/2010 01:39 PM, Mike McGrath wrote:
>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>>
"BN" == Bill Nottingham writes:
>>> BN> I can't help but note that the slips have become more frequent as we
>>> BN> started to actually *have
On 08/12/2010 03:03 PM, Bruno Wolff III wrote:
> On Thu, Aug 12, 2010 at 13:19:29 -0500,
> Mike McGrath wrote:
>> Since 2006 we've slipped at least 16-18 weeks by my count. That's more
>> than half of a full release cycle.
>>
>> Thoughts?
>
> One thing I have noticed is people landing big chang
On 08/12/2010 01:51 PM, Jason L Tibbitts III wrote:
>> "MM" == Mike McGrath writes:
> MM> Possibly also stop changing earlier?
>
> Not necessarily. We should certainly try to get the earth shattering
> changes done as early as possible (i.e. soon after branch) but I
> recognize that there
On 08/12/2010 01:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>
>>> "BN" == Bill Nottingham writes:
>> BN> I can't help but note that the slips have become more frequent as we
>> BN> started to actually *have* release criteria to test against. We
>> BN> di
On Thu, Aug 12, 2010 at 12:00:29 -0700,
Adam Williamson wrote:
>
> We usually catch most initial blockers for any given release at the
> first TC stage. Bugs we slip for are usually ones identified at that
> stage that we couldn't fix in time, bugs introduced between TC and RC by
This is anoth
On Thu, Aug 12, 2010 at 13:19:29 -0500,
Mike McGrath wrote:
> Since 2006 we've slipped at least 16-18 weeks by my count. That's more
> than half of a full release cycle.
>
> Thoughts?
One thing I have noticed is people landing big changes (such as python and
systemd) that break things for a wh
On 08/12/2010 02:39 PM, drago01 wrote:
> On Thu, Aug 12, 2010 at 8:19 PM, Mike McGrath wrote:
>
>> Since 2006 I counted 18 slips (I think one or two of those may just be a
>> single slip listed twice). Lets not yell, lets not flame war, lets not
>> point fingers. How can we fix this?
>
> It is
On Thu, 2010-08-12 at 13:50 -0500, Mike McGrath wrote:
> Any of the QA guys have any way to measure the the most common cause of
> our slips? Is it usually stuff we're our own upstream for? Is it
> integration? Is it bugs that were introduced months ago but only recently
> found or bugs that we
On Thu, Aug 12, 2010 at 14:50:38 -0400,
Nathaniel McCallum wrote:
>
> One thing I am curious about is why, when slipping for an Alpha target,
> the whole schedule slips. Can't we just take a week out of the Beta
> cycle? The amount of testing time is roughly the same.
We've tried that in the
> "MM" == Mike McGrath writes:
MM> Possibly also stop changing earlier?
Not necessarily. We should certainly try to get the earth shattering
changes done as early as possible (i.e. soon after branch) but I
recognize that there isn't sufficient developer time available to both
stabilize one
On 08/12/2010 02:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>
>>> "BN" == Bill Nottingham writes:
>>
>> BN> I can't help but note that the slips have become more frequent as we
>> BN> started to actually *have* release criteria to test against. We
>> BN> did
On Thu, 12 Aug 2010, Bill Nottingham wrote:
> Matthias Clasen (mcla...@redhat.com) said:
> > > This is a collective failure.
> >
> > I'd like to question that premise. Why is it a failure if we adjust our
> > release schedule to meet our release criteria ?
>
> Well, ideally we'd be able to sched
On 12/08/10 19:19, Mike McGrath wrote:
How can we fix this? It's clearly not one group or one
> individual or we'd just go talk to them. This is a collective failure.
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both hard\virtual-ware.
On 12/08/10 19:19, Mike McGrath wrote:
How can we fix this? It's clearly not one group or one
> individual or we'd just go talk to them. This is a collective failure.
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both hard\virtual-ware.
On Thu, 2010-08-12 at 13:29 -0500, Jason L Tibbitts III wrote:
> > "BN" == Bill Nottingham writes:
>
> BN> I can't help but note that the slips have become more frequent as we
> BN> started to actually *have* release criteria to test against. We
> BN> didn't slip nearly as much when we weren'
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
> > "BN" == Bill Nottingham writes:
>
> BN> I can't help but note that the slips have become more frequent as we
> BN> started to actually *have* release criteria to test against. We
> BN> didn't slip nearly as much when we weren't testing it.
On Thu, Aug 12, 2010 at 8:19 PM, Mike McGrath wrote:
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets not flame war, lets not
> point fingers. How can we fix this?
It isn't broken so there is nothing to fix; slipping to
On Thu, Aug 12, 2010 at 2:19 PM, Mike McGrath wrote:
... snip ...
> Since 2006 we've slipped at least 16-18 weeks by my count. That's more
> than half of a full release cycle.
>
Actually, I don't think that the slips in the releases have _accumulated_ to
be
'half' of a full release cycle' beca
> "BN" == Bill Nottingham writes:
BN> I can't help but note that the slips have become more frequent as we
BN> started to actually *have* release criteria to test against. We
BN> didn't slip nearly as much when we weren't testing it.
To me this implies that we should begin testing earlier (o
Matthias Clasen (mcla...@redhat.com) said:
> > This is a collective failure.
>
> I'd like to question that premise. Why is it a failure if we adjust our
> release schedule to meet our release criteria ?
Well, ideally we'd be able to schedule such that we can accomplish
our release criteria wit
On Thu, 2010-08-12 at 13:19 -0500, Mike McGrath wrote:
> This is a collective failure.
I'd like to question that premise. Why is it a failure if we adjust our
release schedule to meet our release criteria ?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/m
70 matches
Mail list logo
