On Fri, 13 Aug 2010 00:31:58 +0200
Kevin Kofler wrote:
> I think that this is really going to break our workflow!
I think it's going to help our workflow and provide our users with more
stable updates. Time will tell.
> For example, for the Fedora 14 under development, we now have to wait
> a
Kevin Fenzi wrote:
> Well, this has nothing to do with that. We are currently only pushing
> to stable those updates that are needed to fix Alpha release blockers
> in F14. So, it wouldn't matter here.
It will matter after the Alpha release when urgent dependency fixes will be
withheld for 1 week
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
Bruno Wolff III wrote:
> I hope to occasionally push back a little against this. When LZMA squashfs
> makes it upstream (it looks like it won't happen in time for F14) we will
> probably gain about 10% on what we can fit in a given size image.
It's quite sad that we're waiting for upstream there.
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
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
>>
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 dur
Luke Macken wrote:
> Fixed in
> https://fedorahosted.org/bodhi/changeset/97b1a9d1f9ceecaaa2128837cc5bbd7f8e495f36
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
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
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
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
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
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
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
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
Linuxguy123 wrote:
>
> http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
>
>
I'm interested in this. I have noticed that for the past (several months?)
my system would freeze at apparently random times, while disk goes busy, for
periods of 20-30 seconds. This did not used to happen
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
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
On Fri, Aug 13, 2010 at 3:02 AM, Kevin Kofler 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'
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 th
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
On 8/12/2010 9:16, Peter Lemenkov wrote:
> I'm currently in process of automatic enlisting of all ~10K Fedora Git
> repos at Ohloh.
Do you have some way of automatically adding new packages as they are
added to Fedora in the future?
--
devel mailing list
devel@lists.fedoraproject.org
https://adm
On Fri, Aug 13, 2010 at 01:18:29 +0200,
Kevin Kofler wrote:
> Bruno Wolff III wrote:
> > I hope to occasionally push back a little against this. When LZMA squashfs
> > makes it upstream (it looks like it won't happen in time for F14) we will
> > probably gain about 10% on what we can fit in a gi
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
There will be an outage starting at 2010-08-15 01:00 UTC, which will last
approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2010-08-15 01:00 UTC'
Reason for outage:
Network work is being done in our pr
Bruno Wolff III wrote:
> We'll until Lougher writes something that Linus will accept, we need to
> wait.
But WHY? IMHO, an upstream tarball is just a base to apply our patches onto.
We shouldn't be prisoners of upstream, especially when upstream processes
are just too slow to fit our needs. Back
Once upon a time, Kevin Kofler 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 distribut
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 deve
Hi,
> Bruno Wolff III wrote:
>> We'll until Lougher writes something that Linus will accept, we
>> need to wait.
> But WHY? IMHO, an upstream tarball is just a base to apply our
> patches onto.
Because the kernel team doesn't agree with you, of course.
This should be unsurprising
Fedora 14 Alpha RC4 is now available [1]. Please refer to the following
pages for download links and testing instructions.
Installation:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
Desktop:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
Ideally, all
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,
Chris Ball wrote:
> This should be unsurprising, because the stated objectives of the
> Fedora project as a whole don't agree with you either:
>
> http://fedoraproject.org/wiki/Objectives
> http://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Those same objectives say that Fedora shou
-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
-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 10:16 PM, Kevin Kofler wrote:
> Chris Ball wrote:
>> This should be unsurprising, because the stated objectives of the
>> Fedora project as a whole don't agree with you either:
>>
>> http://fedoraproject.org/wiki/Objectives
>> http://fedo
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
On Thu, 2010-08-12 at 22:26 -0700, Jesse Keating wrote:
> Do you have any sort of proof that it's a "political" reason? It would
> seem to me that our kernel maintainers do not wish to include code that
> hasn't been blessed by Linus in our packages. Doing so has burned us in
> the past, and perh
On Fri, 2010-08-13 at 07:56 +0200, Ralf Corsepius wrote:
> On 08/13/2010 07:11 AM, Matt McCutchen wrote:
> > 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.
> ... and people are free to ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 10:59 PM, Matt McCutchen wrote:
> That's why I'm so frustrated that Fedora seems to be committed
> to keeping the Mozilla trademarks, which moot any discussion of whether
> to deviate for those packages. But this is only my opinion. Fe
101 - 139 of 139 matches
Mail list logo
