Hello
Please reply to gentoo-dev in case ML daemon changes Reply-To.
### TL; DR ###
By introducing feature patches which menu options are disabled by
default to genpatches, we can deduplicate *-sources maintainers as well
as large groups of users work. By introducing a distribution section
in
On 1 July 2013 22:41, Tom Wijsman tom...@gentoo.org wrote:
### TL; DR ###
By introducing feature patches which menu options are disabled by
default to genpatches, we can deduplicate *-sources maintainers as well
as large groups of users work. By introducing a distribution section
in the
On 1 July 2013 10:41, Tom Wijsman tom...@gentoo.org wrote:
Hello
Please reply to gentoo-dev in case ML daemon changes Reply-To.
### TL; DR ###
By introducing feature patches which menu options are disabled by
default to genpatches, we can deduplicate *-sources maintainers as well
as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 10:41 AM, Tom Wijsman wrote:
Hello
Please reply to gentoo-dev in case ML daemon changes Reply-To.
### TL; DR ###
By introducing feature patches which menu options are disabled by
default to genpatches, we can deduplicate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 06:20 PM, Rick Zero_Chaos Farina wrote:
On 07/01/2013 10:41 AM, Tom Wijsman wrote:
What does a patch introducing new features really do? Or rather,
what should it do when we add it? Let me summarize:
1) The features should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 01 Jul 2013 12:20:09 -0400
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
Some patches are reasonably easy to combine, such as genpatches and
aufs. Some patches are difficult to combine, such as hardened and *.
When you combine
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 01:35 PM, Tom Wijsman wrote:
On Mon, 01 Jul 2013 12:20:09 -0400
Rick \Zero_Chaos\ Farina zeroch...@gentoo.org wrote:
Some patches are reasonably easy to combine, such as genpatches and
aufs. Some patches are difficult to combine,
On Mon, Jul 01, 2013 at 04:41:49PM +0200, Tom Wijsman wrote:
This problem is not only visible for patches, but also in the config.
Meet CONFIG_DEVTMPFS; forget to enable it, greet a failing boot. We're
telling users to enable it in some places, in the handbook it's a single
line you must
On 07/01/2013 11:20 AM, Jeff Horelick wrote:
On 1 July 2013 10:41, Tom Wijsman tom...@gentoo.org wrote:
Hello
Please reply to gentoo-dev in case ML daemon changes Reply-To.
### TL; DR ###
By introducing feature patches which menu options are disabled by
default to genpatches, we can
On 1 July 2013 19:17, Greg KH gre...@gentoo.org wrote:
greg stick to the vanilla-sources k-h
Before these changes were introduced, the gentoo-sources and
vanilla-sources were quite similar in the sense that genpatches used
to contain
patches already in Linus' tree. However, given that
On Mon, 1 Jul 2013 11:17:49 -0700
Greg KH gre...@gentoo.org wrote:
Meet CONFIG_DEVTMPFS; ...
This is not the only build option that users must enable to get a
booting system by far. So why single this one out?
Because it is an example. Later on I explicitly mention There are a
small set
On Mon, 1 Jul 2013 19:38:48 +0100
Markos Chandras hwoar...@gentoo.org wrote:
I certainly don't feel safe anymore running non-upstream code in
production boxes.
You don't run it unless you explicitly tick on that you want
experimental functionality _as well as_ the optional features in
On Mon, 01 Jul 2013 14:30:51 -0400
Anthony G. Basile bluen...@gentoo.org wrote:
I was going to say depend on CONFIG_EXPERIMENTAL in
Kconfig, but this is deprecated. See scripts/checkpatch.pl
Yes, I think it wasn't clear from my first post; but the intention was
to introduce such option under
On Mon, Jul 1, 2013 at 1:56 PM, Tom Wijsman tom...@gentoo.org wrote:
On Mon, 1 Jul 2013 19:38:48 +0100
Markos Chandras hwoar...@gentoo.org wrote:
I certainly don't feel safe anymore running non-upstream code in
production boxes.
You don't run it unless you explicitly tick on that you want
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
CONFIG_EXPERIMENTAL
What is CONFIG_VANILLA? I don't see that in the upstream kernel tree
On Mon, Jul 01, 2013 at 02:30:51PM -0400, Anthony G. Basile wrote:
Tom, you already know my opinion because we discussed it. I'm all
for it. Just a reminder: there's always problems somewhere in the
kernel which can be triggered by various options. The kernel is not
one big take it or leave
On Mon, 1 Jul 2013 14:09:57 -0500
Matthew Summers quantumsumm...@gentoo.org wrote:
I think the point was well-made by grehkh.
You missed my response to that point.
If the patchset patches the kernel's core, it doesn't matter what
CONFIG_* option is set the core kernel code
On Mon, 1 Jul 2013 12:23:24 -0700
Greg KH gre...@gentoo.org wrote:
Earlier I mentioned 3) The patch should not affect the build by
default.; if it does, we have to adjust it to not do that, this is
something that can be easily scripted. It's just a matter of
embedding each + block in the
On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote:
On Mon, 1 Jul 2013 14:09:57 -0500
Matthew Summers quantumsumm...@gentoo.org wrote:
If the patchset patches the kernel's core, it doesn't matter what
CONFIG_* option is set the core kernel code _has_now_been_changed_.
This is the
On Mon, 1 Jul 2013 12:24:36 -0700
Greg KH gre...@gentoo.org wrote:
On Mon, Jul 01, 2013 at 02:30:51PM -0400, Anthony G. Basile wrote:
Tom, you already know my opinion because we discussed it. I'm all
for it. Just a reminder: there's always problems somewhere in the
kernel which can be
On Mon, 1 Jul 2013 12:33:30 -0700
Greg KH gre...@gentoo.org wrote:
On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote:
On Mon, 1 Jul 2013 14:09:57 -0500
Matthew Summers quantumsumm...@gentoo.org wrote:
If the patchset patches the kernel's core, it doesn't matter what
CONFIG_*
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
--
Fabio Erculiani
El lun, 01-07-2013 a las 21:55 +0200, Fabio Erculiani escribió:
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
I don't see them exclusionary, look different issues to me :/ (with
On Mon, Jul 1, 2013 at 9:59 PM, Pacho Ramos pa...@gentoo.org wrote:
El lun, 01-07-2013 a las 21:55 +0200, Fabio Erculiani escribió:
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
I
On Mon, 1 Jul 2013 21:55:23 +0200
Fabio Erculiani lx...@gentoo.org wrote:
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
There's been a start on this, but we're looking at you now;
On 1 July 2013 20:09, Matthew Summers quantumsumm...@gentoo.org wrote:
On Mon, Jul 1, 2013 at 1:56 PM, Tom Wijsman tom...@gentoo.org wrote:
On Mon, 1 Jul 2013 19:38:48 +0100
Markos Chandras hwoar...@gentoo.org wrote:
I certainly don't feel safe anymore running non-upstream code in
production
2013/7/1 Fabio Erculiani lx...@gentoo.org:
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
+1
The binary use flag for sys-kernel/*-sources in Funtoo implements
exactly that.
--
Fabio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/01/2013 03:55 PM, Fabio Erculiani wrote:
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
++
- -ZC
-BEGIN PGP SIGNATURE-
On Mon, Jul 1, 2013 at 10:14 PM, Markos Chandras hwoar...@gentoo.org wrote:
[...]
It's really scary to have the BFQ in a stable gentoo-sources ebuild.
BFQ is not that scary, it's just an iosched (and it's quite easy to
write an iosched), what could possibly go wrong?
Jokes apart, I've been
On Mon, Jul 1, 2013 at 10:24 PM, Christoph Junghans ott...@gentoo.org wrote:
2013/7/1 Fabio Erculiani lx...@gentoo.org:
I believe that end users would benefit more from kernel binary ebuilds
(ebuilds building an actual kernel with an official config), rather
than all this.
+1
The binary use
On Mon, 1 Jul 2013 21:14:45 +0100
Markos Chandras hwoar...@gentoo.org wrote:
And besides that, I am sure that 98% of our users out there do not
know they run a (heavily?) modified upstream kernel when they emerge
the official/supported gentoo-sources.
This point I do understand.
The
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
CONFIG_EXPERIMENTAL
What is CONFIG_VANILLA? I don't see that in the
On 07/01/2013 03:24 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 02:30:51PM -0400, Anthony G. Basile wrote:
Tom, you already know my opinion because we discussed it. I'm all
for it. Just a reminder: there's always problems somewhere in the
kernel which can be triggered by various options. The
On 07/01/2013 04:25 PM, Fabio Erculiani wrote:
On Mon, Jul 1, 2013 at 10:14 PM, Markos Chandras hwoar...@gentoo.org wrote:
[...]
It's really scary to have the BFQ in a stable gentoo-sources ebuild.
BFQ is not that scary, it's just an iosched (and it's quite easy to
write an iosched), what
On Mon, Jul 01, 2013 at 05:17:07PM -0400, Anthony G. Basile wrote:
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
On Mon, Jul 1, 2013 at 11:26 PM, Anthony G. Basile bluen...@gentoo.org wrote:
I'm pretty sure I hit a genuine deadlock with it. I've been trying to
reproduce with debugging on but nothing yet.
But, having said that:
BFQ [Experimtental]
This introduced an experimental io scheduler. Have
On 07/01/2013 05:24 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 05:17:07PM -0400, Anthony G. Basile wrote:
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These
On 07/01/2013 05:30 PM, Fabio Erculiani wrote:
On Mon, Jul 1, 2013 at 11:26 PM, Anthony G. Basile bluen...@gentoo.org wrote:
I'm pretty sure I hit a genuine deadlock with it. I've been trying to
reproduce with debugging on but nothing yet.
But, having said that:
BFQ [Experimtental]
This
On Mon, 1 Jul 2013 14:24:54 -0700
Greg KH gre...@gentoo.org wrote:
but suppose people
want BFQ? Why can't we have it in gentoo-sources. It is totally
disabled by not selecting CONFIG_BFQ. Selecting it is no different
than emerging pf-sources with the same other options ported over.
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
CONFIG_EXPERIMENTAL
What is CONFIG_VANILLA? I don't see that in
On 07/01/2013 09:36 PM, Richard Yao wrote:
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
CONFIG_EXPERIMENTAL
On Mon, Jul 01, 2013 at 09:36:21PM -0400, Richard Yao wrote:
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options would depend on !CONFIG_VANILLA or
On 07/01/2013 09:56 PM, Greg KH wrote: On Mon, Jul 01, 2013 at
09:36:21PM -0400, Richard Yao wrote:
On 07/01/2013 03:23 PM, Greg KH wrote:
On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
Q: What about my stable server? I really don't want to run this
stuff!
A: These options
Furthermore, should the kernel kernel choose to engage that out-of-tree
code, my expectation is that its quality will improve as they do testing
and write patches.
What do you mean by this?
I probably should have clarified that there was a typo in that. I meant
the kernel team, not the
On 07/01/2013 11:29 PM, Richard Yao wrote:
On 07/01/2013 09:56 PM, Greg KH wrote: On Mon, Jul 01, 2013 at
09:36:21PM -0400, Richard Yao wrote:
That is because fixes for other filesystems are either held back by a
lack of system kernel updates or held hostage by regressions in newer
kernels on
45 matches
Mail list logo