On Thu, 11 Mar 2010, Matthew Woehlke wrote:
> Kevin Kofler wrote:
>> as long as you require only a few 32-bit packages, requesting them
>> explicitly is not the end of the world. So if we were to drop support
>> for that "always install all libs as multilibs" option
>
> Eh? I didn't even know th
Kevin Kofler wrote:
> as long as you require only a few 32-bit packages, requesting them
> explicitly is not the end of the world. So if we were to drop support
> for that "always install all libs as multilibs" option
Eh? I didn't even know there was such an option. And I agree, /that/
should be
I wrote:
> * "yum install glibc.i686".
Actually, you probably want glibc-devel.i686. But my point still stands, as
long as you require only a few 32-bit packages, requesting them explicitly
is not the end of the world. So if we were to drop support for that "always
install all libs as multilib
Matthew Woehlke wrote:
> Hmm, maybe then you are thinking of things that are far less
> stand-alone. The only "run-time environment" we care about is that the
> program can be executed (so, kernel can load it, glibc.i?86 exists,
> etc.). We tend to have very few if any dependencies beyond libc (and
Michael Schwendt wrote:
> On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote:
>> Probably because
>> I need multilib and have never experienced multilib-related problems (or
>> if I have, they were so trivial as to be thoroughly forgettable).
>
> Just out of interest, does enabling a separate 32-bit
On Wed, 10 Mar 2010 11:30:05 -0600, Matthew wrote:
> Probably because
> I need multilib and have never experienced multilib-related problems (or
> if I have, they were so trivial as to be thoroughly forgettable).
Just out of interest, does enabling a separate 32-bit repository on a
64-bit insta
Michael Schwendt wrote:
> On Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote:
>
>>> There are just too many -devel packages and their dependencies to be ever
>>> relevant to someone for multi-arch installs. Far more users install i686 on
>>> 64-bit CPUs, and I have doubts that x86_64 installation us
Matthew Woehlke wrote:
> Kevin Kofler wrote:
>> Matthew Woehlke wrote:
>>> You forget people developing proprietary software...
>>
>> Why would we want to encourage or even support that?
>
> I don't expect Fedora to encourage it (nor should we, IMO)... but that
> doesn't change the reality of $DAYJ
Kevin Kofler wrote:
> Matthew Woehlke wrote:
>> You forget people developing proprietary software...
>
> Why would we want to encourage or even support that?
I don't expect Fedora to encourage it (nor should we, IMO)... but that
doesn't change the reality of $DAYJOB. If Fedora drops multilib, I w
Matthew Woehlke wrote:
> You forget people developing proprietary software...
Why would we want to encourage or even support that?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, 08 Mar 2010 14:29:42 -0600, Matthew wrote:
> > There are just too many -devel packages and their dependencies to be ever
> > relevant to someone for multi-arch installs. Far more users install i686 on
> > 64-bit CPUs, and I have doubts that x86_64 installation users do much
> > development
Michael Schwendt wrote:
> There are just too many -devel packages and their dependencies to be ever
> relevant to someone for multi-arch installs. Far more users install i686 on
> 64-bit CPUs, and I have doubts that x86_64 installation users do much
> development with i686 packages. At most they in
On 03/06/2010 04:07 AM, Kevin Kofler wrote:
> And in this case removing the option would actually allow us
> to improve things (less duplication in the repos, smaller metadata for those
> of us with pure 64-bit systems etc.), unlike some gratuitously removed
> options in e.g. GNOME.
>
Can you
Bill Nottingham wrote:
> Off the top of my head, it would break the install DVD usage case
The install DVD wouldn't have 32-bit baggage. So what? It's not installed by
default anyway. (At least the live images don't contain ANY multilib stuff.
I'm not sure what the DVD does these days.)
> and t
Kevin Kofler (kevin.kof...@chello.at) said:
> > While that would make things simpler and shorter, I doubt it's really
> > practical. Enough people use and want multilib that I don't think we can
> > just unilaterally remove it. Moreover, the multilib portion of the compose
> > isn't the primary ti
Bill Nottingham wrote:
> The issue there is then you have to properly determine what packages
> to remove from the repo (unless you just keep everything, which has its
> own problems); in this case, recomputing actually makes the code simpler.
Sure, it makes the code simpler, but a lot slower! Oft
On Fri, 2010-03-05 at 11:03 +0100, Kevin Kofler wrote:
>
> It was claimed that recomputing is necessary for some obscure multilib
> corner cases. Let me suggest a radical solution for that: drop multilib
> repos! If users really want 32-bit packages, they should enable the 32-bit
> repo. Yes, t
Kevin Kofler (kevin.kof...@chello.at) said:
> > So what? That's not twice as much as FE6, which would not have taken
> > several hours to push into such a repo. Not even when running repoclosure
> > on the needsign repo prior to pushing and when updating repoview pages
> > afterwards. Simply becau
On Fri, 05 Mar 2010 11:03:12 +0100, Kevin wrote:
> Yeah, basically "mash" is a really brute force solution, I think directly
> writing out only the new updates as the first prototypes of Bodhi did and as
> the Extras scripts also did/do is a much smarter solution. Always
> recomputing everythin
(Starting a new thread because this hardly has anything to do with the
original infamous thread.
Dear hall monitors: I hope I won't get put on moderation for posting this,
but this subthread didn't have much to do with the original subject. If you
also want me to stop posting to this split threa
On Fri, 05 Mar 2010 02:41:46 -0500, James wrote:
> > > % yum repolist --releasever=11 updates
> > > repo id repo name status
> > > updates Fedora 11 - x86_64 - Updates9,390
> ...
> > This probably won't go well unless yo
On Thu, 04 Mar 2010 20:11:47 -0500, James wrote:
> On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> > On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
> >
> > > Extras had significantly fewer packages,
> >
> > Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300
On Fri, Mar 5, 2010 at 2:11 AM, James Antill wrote:
> On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
>> On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
>>
>> > Extras had significantly fewer packages,
>>
>> Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300
>>
On Thu, 2010-03-04 at 18:30 -0800, Jesse Keating wrote:
> On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote:
> > On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> > > Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300
> > > less
> > > than F11 stable updates.
On Thu, 2010-03-04 at 20:11 -0500, James Antill wrote:
> On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> > On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
> >
> > > Extras had significantly fewer packages,
> >
> > Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only
On Fri, 2010-03-05 at 00:14 +0100, Michael Schwendt wrote:
> On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
>
> > Extras had significantly fewer packages,
>
> Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
> than F11 stable updates.
>
> http://archive.fedoraproj
On Tue, 02 Mar 2010 20:19:48 -0800, Jesse wrote:
> Extras had significantly fewer packages,
Well, Fedora Extras 6 (x86_64) contained 5129 packages, which is only 300 less
than F11 stable updates.
http://archive.fedoraproject.org/pub/archive/fedora/linux/extras/6/x86_64/repoview/index.html
> no
Chris Adams wrote:
> Once upon a time, Kevin Kofler said:
>> Such as? We're filling a niche, this is one of our unique selling points,
>> you want to throw out the baby with the bathwater!
>
> Who is this "we" you keep speaking of? When did huge dumps of updates
> in supposedly stable releases be
James Antill wrote:
> I think I'm starting to see a pattern here:
>
> . Kevin doesn't use DVD updates, so anything that needlessly breaks DVD
> updates is fine because DVD updates are worthless.
DVD updates are by definition broken, unless you have never run updates
on your previous system.
>
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> The strong argument is that KDE and Fedora release cycles are not in sync
> and our users would thus have to wait months for the new KDE.
As many have stated, not all people *want* those feature updates
to stable release. By pushing them by force, you r
On Wed, 3 Mar 2010, Chris Adams wrote:
> By the same token, if you want rolling update releases, feel free to do
> it in your own private repo. See how well that argument works?
No i don't. I'm using a mainstream distribution and thus I expect to
get them. Just like the upstream has intended t
Juha Tuomala wrote:
> On Wed, 3 Mar 2010, Kevin Kofler wrote:
>>> You're distorting the Fedora model to accommodate KDE roadmaps.
>>
>> No, this goes far beyond KDE. KDE roadmaps are just one strong argument
>> for doing things this way. Many more packages benefit or would benefit
>> from version u
Once upon a time, Juha Tuomala said:
> For note, I'm among those who don't want feature upgrades into
> stable fedora release. If you're so happy to chase latest and
> gratest, feel free to do it in your sf.net private repo.
By the same token, if you want rolling update releases, feel free to do
On Wed, 3 Mar 2010, Kevin Kofler wrote:
>> You're distorting the Fedora model to accommodate KDE roadmaps.
>
> No, this goes far beyond KDE. KDE roadmaps are just one strong argument for
> doing things this way. Many more packages benefit or would benefit from
> version upgrades during a releas
Nicolas Mailhot wrote:
> This is only working for you because KDE is a high-visibility project
> and can mobilize resources even outside the distro normal schedule. The
> other packages you talk of could benefit if QA was cheap and plentiful
> but QA is not cheap and plentiful and pretending we do
James Antill wrote:
> As I would assume any programmer knows: Not all bugs are created equal.
> Trading "no regressions" for "some minor bugs still remain" is a trade
> lots of users are happy to make (see: every customer of every piece of
> commercial software, ever).
Those users can use one of
Mathieu Bridon wrote:
> On Wed, Mar 3, 2010 at 18:27, Kevin Kofler wrote:
>> We can't change Bodhi metadata after the fact at this time. Bodhi admins
>> might be able to do it, but maintainers definitely aren't.
>
> Where's the RFE ticket?
I've never felt the need. This is the first time somebo
Le mercredi 03 mars 2010 à 16:32 +0100, Kevin Kofler a écrit :
> Nicolas Mailhot wrote:
> > If KDE wants to be on an equal footing with GNOME (another of your
> > repeated complains) it needs to learn synchronizing with distro releases
> > like GNOME (and kernel, and xorg did).
>
> I don't see th
James Antill wrote:
> On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote:
>> People who use updates-testing under the current system are signing up to
>> doing testing. Under your proposal, they'd be forced to sign up to get
>> any current updates.
>
> Get current updates => so they can be te
Adam Williamson (awill...@redhat.com) said:
> On Tue, 2010-03-02 at 17:52 -0800, Jesse Keating wrote:
> > On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
> > > But the problem is what to do if the testing ALREADY failed. Then the
> > > best
> > > strategy is to fix the problem ASAP, bypas
On Wed, Mar 03, 2010 at 11:48:18AM -0500, James Antill wrote:
> On Wed, 2010-03-03 at 17:09 +0100, Till Maas wrote:
> > On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote:
> > > If we had less updates, that changed less things and required more
> > > testing before pushing them to users
On Wed, Mar 3, 2010 at 18:27, Kevin Kofler wrote:
> James Antill wrote:
>> I would assume you could just change the updateinfo for the the current
>> update to mark it as "security", this is a tiny amount of extra work on
>> the packager side ... but without it all the work to create the security
James Antill wrote:
> I would assume you could just change the updateinfo for the the current
> update to mark it as "security", this is a tiny amount of extra work on
> the packager side ... but without it all the work to create the security
> types on updates is worthless.
We can't change Bodhi
On Wed, 2010-03-03 at 07:28 -0500, Josh Boyer wrote:
> On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote:
> >On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
> >
> >> We've made a mess and as a member of fesco I'd expect you to be helping in
> >> cleaning up the mess, not making
On Wed, 2010-03-03 at 17:09 +0100, Till Maas wrote:
> On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote:
> > If we had less updates, that changed less things and required more
> > testing before pushing them to users ... this would be entirely
> > possible.
>
> Less updates mean more c
On 03/03/2010 05:24 AM, Björn Persson wrote:
> You mean the system would download updates while I'm working but I would have
> to wait while it installs them? That's of course a little better than waiting
> while it downloads them too, but in my experience the installation phase
> usually takes lon
On Wed, Mar 03, 2010 at 11:02:51AM -0500, James Antill wrote:
> On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote:
> > No, because updates may depend on previous updates to work properly. We
> > can't possibly test or support all possible combinations of updates.
>
> We can't _now_ ... beca
On 03/02/2010 08:42 PM, Kevin Kofler wrote:
> Peter Jones wrote:
>
>> On 03/02/2010 06:15 AM, Kevin Kofler wrote:
>>
> X11 is particularly dangerous for this kind of changes, given how low
> it is in the software stack and how some code necessarily looks like
> (hardware drivers in par
On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote:
> James Antill wrote:
>
> >> I
> >> want many updates, but I don't want to be the guinea pig for updates
> >> which just hit testing,
> >
> > And nobody else wants to be the guinea pig for _you_.
>
> People who use updates-testing under the
Nicolas Mailhot wrote:
> If KDE wants to be on an equal footing with GNOME (another of your
> repeated complains) it needs to learn synchronizing with distro releases
> like GNOME (and kernel, and xorg did).
I don't see this as being practical at all. Not all distros even release at
the same time
On Tue, 2010-03-02 at 23:57 -0800, Adam Williamson wrote:
> I wasn't suggesting that's what happens in Fedora at present, just that
> - given a single update stream in which it's perfectly fine for
> 'security' updates to build on 'feature' updates - it's impossible to
> cherry pick only security
On Wed, 2010-03-03 at 07:52 +0100, Kevin Kofler wrote:
> James Antill wrote:
> > This isn't a hard problem, 3.0 should then be marked as a security
> > update.
>
> But the case we're discussing is that 3.0 was pushed long before it was
> known that it happens to fix a security vulnerability. We'
On Wed, 3 Mar 2010, Thomas Moschny wrote:
2010/3/3 Josh Boyer :
On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote:
On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
We've made a mess and as a member of fesco I'd expect you to be helping in
cleaning up the mess, not making
On Wed, Mar 03, 2010 at 10:54:57AM +0100, Michael Schwendt wrote:
>On Tue, 02 Mar 2010 17:53:40 -0800, Jesse wrote:
>
>> On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote:
>> > Jesse Keating wrote:
>> > > That's a fair point, but there are significantly fewer people around to
>> > > fix critica
2010/3/3 Josh Boyer :
> On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote:
>>On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
>>
>>> We've made a mess and as a member of fesco I'd expect you to be helping in
>>> cleaning up the mess, not making it worse b/c fesco HAS to be about t
On 03/03/2010 08:38 AM, Kevin Kofler wrote:
> > So maybe you are under the impression that all the users who would test
> > your package are anxiously waiting for your packages to be available?
> For those packages where regressions actually matter to people, they
> definitely are. People keep aski
On Tue, Mar 02, 2010 at 11:52:49PM -0800, Adam Williamson wrote:
>On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
>
>> We've made a mess and as a member of fesco I'd expect you to be helping in
>> cleaning up the mess, not making it worse b/c fesco HAS to be about the
>> long term growth and
Nathanael D. Noblet wrote:
> On 03/02/2010 06:06 PM, Björn Persson wrote:
> > Jesse Keating wrote:
> >> On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
> >>> Kevin Kofler wrote:
> Even bugfix releases of KDE require a session restart to fully work.
> >>>
> >>> I consider that a seriou
On Wed, Mar 03, 2010 at 12:33:40AM -0500, James Antill wrote:
> You keep saying that 7 days is "enough" but I haven't seen you provide
> _any_ evidence to support it. Noting that it will often take 3-4 days
> before a package in testing can be seen by all users. So maybe you are
So there is an e
On Mon, Mar 01, 2010 at 01:46:20PM -0500, Seth Vidal wrote:
> On Mon, 1 Mar 2010, Till Maas wrote:
> > What kind of tests need to be done always manually? The only ones I can
> > think are tests for the appearance of applications or tests that require
> > specific hardware. But in the general cas
Le Mer 3 mars 2010 05:49, Kevin Kofler a écrit :
> Jesse Keating wrote:
>> did a poor job in stating our goals for the operating system, and just
>> hoped that our maintainers would see things the way we saw them.
>
> Why should they see them that way rather than the right way? ;-)
Please stop c
On Tue, 02 Mar 2010 17:53:40 -0800, Jesse wrote:
> On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote:
> > Jesse Keating wrote:
> > > That's a fair point, but there are significantly fewer people around to
> > > fix critical issues should they arise on a weekend, and after working 5
> > > weekd
On Wed, 2010-03-03 at 01:25 -0500, James Antill wrote:
> On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
> > Adam Williamson wrote:
> > > you can try and cherry-pick security updates, but then you get the
> > > problem where initial release has Foobar 1.0, then Foobar 3.5 gets
> > > shipped
On Tue, 2010-03-02 at 22:37 -0500, Seth Vidal wrote:
> We've made a mess and as a member of fesco I'd expect you to be helping in
> cleaning up the mess, not making it worse b/c fesco HAS to be about the
> long term growth and sustainability of fedora.
I'm starting to think this thread needs a
On Tue, 2010-03-02 at 17:52 -0800, Jesse Keating wrote:
> On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
> > But the problem is what to do if the testing ALREADY failed. Then the best
> > strategy is to fix the problem ASAP, bypassing testing this time, to get
> > the
> > regression out
James Antill wrote:
> This isn't a hard problem, 3.0 should then be marked as a security
> update.
But the case we're discussing is that 3.0 was pushed long before it was
known that it happens to fix a security vulnerability. We're not going to
arbitrarily push another update and call it "secur
James Antill wrote:
> On Wed, 2010-03-03 at 01:54 +0100, Kevin Kofler wrote:
>> Well, I see where you're getting to now, but this is really not what
>> updates-testing is for! Updates-testing is for TESTING updates, not for
>> being used as production by some users, even those who want more update
On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
> Adam Williamson wrote:
> > you can try and cherry-pick security updates, but then you get the
> > problem where initial release has Foobar 1.0, then Foobar 3.5 gets
> > shipped in updates, then a security problem emerges and Foobar 3.5-2
> >
On Wed, 2010-03-03 at 01:54 +0100, Kevin Kofler wrote:
> James Antill wrote:
> > Users don't get a constant firehose of updates they are basically
> > forced to install, a lot more packages should spend a lot more time in
> > testing (thus. the user can choose to get the updates or updates-testing
Jesse Keating wrote:
> did a poor job in stating our goals for the operating system, and just
> hoped that our maintainers would see things the way we saw them.
Why should they see them that way rather than the right way? ;-)
> Unfortunately that doesn't seem to be the case, and the "anything goe
Mike McGrath wrote:
> I know they do. I'm saying they shouldn't. Yes, we'll fail sometimes.
> That's not to say it shouldn't be a goal. I updated KDE just today and it
> left my taskbar all messed up [1]
While definitely annoying, I don't think that's what's going to keep you
from doing your w
On Wed, 2010-03-03 at 04:52 +0100, Kevin Kofler wrote:
> Sure it was, there were 2 models before the merge, and one resulting model,
> which happens to be close to the better one (the Extras one). The Core model
> wasn't lost entirely, its good points persisted, e.g. there's an updates-
> testing
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Mike McGrath wrote:
> > You can't assume that people are only using software we ship. If someone
> > is using software they've custom developed (think a webapp). We've now
> > forced them to do work. There's several use cases here, people building
> > a
On Tue, 2010-03-02 at 19:55 -0600, Matthew Woehlke wrote:
>
> Okay, I have to ask: why are you right and Kevin is wrong? What makes
> your vision of Fedora more worthy than his? (Especially when his is the
> apparent incumbent?)
Nothing actually and that's the point I'm making. Without guidan
On Wed, 2010-03-03 at 02:52 +0100, Kevin Kofler wrote:
> Such as? We're filling a niche, this is one of our unique selling points,
> you want to throw out the baby with the bathwater!
Your baby is my bathwater. I don't want the operating system you're
trying to build. If you feel that there is
Doug Ledford wrote:
> That or we would have to go with another alternative entirely. People
> have (well, to be fair mainly James, but he's right I think) pointed
> Kevin at rawhide time and time again. And Kevin has pointed out (also
> rightly) that rawhide isn't really consumable. So, we fix t
Once upon a time, Kevin Kofler said:
> What I said was "We're filling a niche" as in "Fedora is filling a niche".
> This is not saying who is behind that (I'd say it just de facto happened,
> without anybody in particular initiating the process) nor whose niche is
> being filled (which shouldn'
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Seth Vidal wrote:
> Again, I fail to see that mess. To me we're actually doing a great job!
>
>> We've made a mess and as a member of fesco I'd expect you to be helping in
>> cleaning up the mess, not making it worse b/c fesco HAS to be about the
>> long
Seth Vidal wrote:
> Winning implies competition. That wasn't the case.
Sure it was, there were 2 models before the merge, and one resulting model,
which happens to be close to the better one (the Extras one). The Core model
wasn't lost entirely, its good points persisted, e.g. there's an updates
Chris Adams wrote:
> Who is the "we"?
What I said was "We're filling a niche" as in "Fedora is filling a niche".
This is not saying who is behind that (I'd say it just de facto happened,
without anybody in particular initiating the process) nor whose niche is
being filled (which shouldn't matte
On Wed, 3 Mar 2010, Kevin Kofler wrote:
> Seth Vidal wrote:
>> I do not agree Kevin's view is incumbent. I think what's happened is we
>> exploded in size when extras came in and when we merged core and extras
>> and we lost control over the process and over assimilating what was the
>> CORE pro
Jesse Keating wrote:
> Except there aren't enough key people available on the weekend to clean
> up the crap if something goes wrong.
On the other hand, several of our volunteer packagers are more likely to be
around and have time to fix things on the weekend than during workdays. (I
was one of
On 03/02/2010 08:55 PM, Matthew Woehlke wrote:
> Jesse Keating wrote:
>> On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
>>> You and everyone else, please stop proposing Rawhide as the solution for me
>>> and people who want the same "update everything that doesn't break things"
>>> policy,
Seth Vidal wrote:
> I do not agree Kevin's view is incumbent. I think what's happened is we
> exploded in size when extras came in and when we merged core and extras
> and we lost control over the process and over assimilating what was the
> CORE process onto extras.
But the Core process wasn't as
Once upon a time, Kevin Kofler said:
> Chris Adams wrote:
> > Who is this "we" you keep speaking of? When did huge dumps of updates
> > in supposedly stable releases become an official "selling point" of
> > Fedora?
>
> It just happened, de facto. Probably because it's filling a niche other
> d
Chris Adams wrote:
> Who is this "we" you keep speaking of? When did huge dumps of updates
> in supposedly stable releases become an official "selling point" of
> Fedora?
It just happened, de facto. Probably because it's filling a niche other
distros are ignoring.
Kevin Kofler
--
deve
On 03/02/2010 06:06 PM, Björn Persson wrote:
> Jesse Keating wrote:
>> On Wed, 2010-03-03 at 01:34 +0100, Björn Persson wrote:
>>> Kevin Kofler wrote:
Even bugfix releases of KDE require a session restart to fully work.
>>>
>>> I consider that a serious design flaw in KDE and a strong argument
Once upon a time, Kevin Kofler said:
> Such as? We're filling a niche, this is one of our unique selling points,
> you want to throw out the baby with the bathwater!
Who is this "we" you keep speaking of? When did huge dumps of updates
in supposedly stable releases become an official "selling p
On Tue, Mar 2, 2010 at 6:52 PM, Kevin Kofler wrote:
> Jesse Keating wrote:
>> If you don't like rawhide for that use case, find another operating
>> system.
>
> Such as? We're filling a niche, this is one of our unique selling points,
> you want to throw out the baby with the bathwater!
>
>> I'm t
On Tue, 2 Mar 2010, Matthew Woehlke wrote:
> Jesse Keating wrote:
>> On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
>>> You and everyone else, please stop proposing Rawhide as the solution for me
>>> and people who want the same "update everything that doesn't break things"
>>> policy, i
On Tue, Mar 02, 2010 at 05:19:03PM -0800, Jesse Keating wrote:
>On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
>> On the other hand, your usecase has a solution, it's called CentOS.
>>
>
>Wrong answer. Fedora can provide rapid adoption of new technology in
>it's 6 month release cycle. It
On Wed, 2010-03-03 at 02:37 +0100, Kevin Kofler wrote:
> Jesse Keating wrote:
> > That's a fair point, but there are significantly fewer people around to
> > fix critical issues should they arise on a weekend, and after working 5
> > weekdays, some of us like taking the weekend off.
>
> Well, I'm
Jesse Keating wrote:
> On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
>> You and everyone else, please stop proposing Rawhide as the solution for me
>> and people who want the same "update everything that doesn't break things"
>> policy, it does NOT fit our usecase at all!
>
> If you don't
On Wed, 2010-03-03 at 02:33 +0100, Kevin Kofler wrote:
> But the problem is what to do if the testing ALREADY failed. Then the best
> strategy is to fix the problem ASAP, bypassing testing this time, to get the
> regression out of the way.
So testing failed, ergo the best way to fix it is to byp
Jesse Keating wrote:
> If you don't like rawhide for that use case, find another operating
> system.
Such as? We're filling a niche, this is one of our unique selling points,
you want to throw out the baby with the bathwater!
> I'm tired of waiting for many many hours while we try to compose out
Peter Jones wrote:
> On 03/02/2010 06:15 AM, Kevin Kofler wrote:
>
X11 is particularly dangerous for this kind of changes, given how low
it is in the software stack and how some code necessarily looks like
(hardware drivers in particular are always scary stuff). The average
le
Jesse Keating wrote:
> That's a fair point, but there are significantly fewer people around to
> fix critical issues should they arise on a weekend, and after working 5
> weekdays, some of us like taking the weekend off.
Well, I'm around on the weekends and the lack of update pushes for the whole
Peter Jones wrote:
> To categorize our analogies, mine is an analogy for Fedora, yours is an
> analogy for your desktop machine. If you feel like running new untested
> packages on your desktop machine, that's fine, we've got rawhide (and
> updates-testing) for that. You can also feel free to parti
On Wed, 2010-03-03 at 02:11 +0100, Kevin Kofler wrote:
>
> You and everyone else, please stop proposing Rawhide as the solution for me
> and people who want the same "update everything that doesn't break things"
> policy, it does NOT fit our usecase at all!
If you don't like rawhide for that us
James Antill wrote:
> The one "minor incident" being where the project leader had to post to
> the world that we'd screwed it up,
Well, I think he overblew it too. ;-) But he just wanted to get the message
out so people can fix it more easily. Still, I don't see how it's a major
issue. The vast
1 - 100 of 500 matches
Mail list logo
