On Thu, 28 Apr 2011, Mehdi Dogguy wrote:
1) At the beginning of the developement cycle, (with the new plan) you
start from testing, and not the new stable. So, you don't start with a
base that's rc-bug free, or at least, as polished as the new stable is.
First, the beginning of the development
On 28/04/2011 17:30, Raphael Hertzog wrote:
See
http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/
for a more detailed answer and related suggestions to limit this problem.
I'm still reading and thinking… so, don't have an answer yet. But, it
you'd
Mehdi Dogguy wrote:
There are other issues I want to mention here (you may judge them as
minor, but let's see):
1) At the beginning of the developement cycle, (with the new plan) you
start from testing, and not the new stable. So, you don't start with a
base that's rc-bug free, or at least,
On 28/04/2011 17:25, Lucas Nussbaum wrote:
On 28/04/11 at 16:52 +0200, Mehdi Dogguy wrote:
1) At the beginning of the developement cycle, (with the new plan) you
start from testing, and not the new stable. So, you don't start with a
base that's rc-bug free, or at least, as polished as the new
Raphael Hertzog wrote:
There are other possible changes but I want to discuss them separately
because even without those changes, the testing without freeze is a
worthwhile goal in itself.
Still, since you seem to insist, here are ideas I'd like to investigate:
- reduce the set of
On 28/04/2011 17:30, Raphael Hertzog wrote:
On Thu, 28 Apr 2011, Mehdi Dogguy wrote:
1) At the beginning of the developement cycle, (with the new plan) you
start from testing, and not the new stable. So, you don't start with a
base that's rc-bug free, or at least, as polished as the new stable
Joey,
nice to see you agreeing. :)
On 2011-04-28, Joey Hess jo...@debian.org wrote:
To most users of testing, a 5 month period when it doesn't update as
much, but is also more constantly usable is mostly a draw; that period
is when testing has the most new users.
That's also my observation.
On 28/04/11 at 18:04 +0200, Mehdi Dogguy wrote:
On 28/04/2011 17:25, Lucas Nussbaum wrote:
On 28/04/11 at 16:52 +0200, Mehdi Dogguy wrote:
1) At the beginning of the developement cycle, (with the new plan) you
start from testing, and not the new stable. So, you don't start with a
base
On 28/04/11 at 12:05 -0400, Joey Hess wrote:
And at the same time, having a non-frozen rolling release available
during freeze time could easily distract people from working on
testing/frozen at all, because a shiny rolling release that they and
some users can use is still available. I am
On 28/04/11 at 18:54 +0200, Mehdi Dogguy wrote:
You want a constantly usable testing, but are you working these days on
fixing RC bugs affecting testing? Don't get me wrong. I'm not
finger-printing. I didn't find time to do that myself. But, if we all try
to do that, things will be much more
* Lucas Nussbaum lu...@lucas-nussbaum.net [110428 20:21]:
On 28/04/11 at 12:05 -0400, Joey Hess wrote:
And at the same time, having a non-frozen rolling release available
during freeze time could easily distract people from working on
testing/frozen at all, because a shiny rolling release
Hi guys,
On Wed, Apr 27, 2011 at 08:23:33PM +, Philipp Kern wrote:
* RM's can still choose to migrate packages from (not frozen) testing as
long as it's practical to do so.
* When deps/transitions/etc prevent testing migration, release N
proposed updates is used for
Philipp Kern wrote:
Improvement to update testing more quickly by easing the pain of
transitions, like rebuilding everything in a self-contained way
to avoid entanglements, would be well appreciated.
As it's not the first time I see this mentionned (but still fail to
understand it fully),
On 28/04/11 at 20:45 +0200, Bernhard R. Link wrote:
* Lucas Nussbaum lu...@lucas-nussbaum.net [110428 20:21]:
On 28/04/11 at 12:05 -0400, Joey Hess wrote:
And at the same time, having a non-frozen rolling release available
during freeze time could easily distract people from working on
On Thu, 28 Apr 2011, sean finney wrote:
On Thu, Apr 28, 2011 at 02:55:31PM +0200, Raphael Hertzog wrote:
Good. I just want to point out that frozen built on top on rolling
(which is what we're proposing here) is different from frozen built on
top of unstable (which is what we had before the
On Thu, 28 Apr 2011, Joey Hess wrote:
Another problem is that testing can be frozen in stages, which allows
development from unstable on eg, leaf package to continue on filter into
testing until relatively close to the release. Rolling could disrupt
that, since uploads to unstable targeted at
On Thu, April 28, 2011 19:03, Lucas Nussbaum wrote:
On 28/04/11 at 12:05 -0400, Joey Hess wrote:
And at the same time, having a non-frozen rolling release available
during freeze time could easily distract people from working on
testing/frozen at all, because a shiny rolling release that they
On 04/28/2011 07:15 PM, Lucas Nussbaum wrote:
Could we try to stay on focus and constructive, and avoid bringing
poneys in the discussion?
Yes. I'm sorry! I always write a first stupid version and then change it to
something reasonable (or drop it), but I forgot to change that sentence.
It
On 2011-04-28, Raphael Hertzog hert...@debian.org wrote:
But I don't plan to work on any of those if the project does not agree to
promote testing to something that can be advertised as usable by end-users
and as something that we strive to support on a best-effort basis.
The usual troll of
On Thu, 28 Apr 2011 22:55:01 +, Philipp Kern wrote:
At least if
they're wired up to at least get announcements if something's screwing
up systems gravely. That channel seems to be missing, though.
apt-listbugs?
Not very widely known, IME ...
Cheers,
gregor
--
.''`. Homepage:
On Thu, 28 Apr 2011 18:54:32 +0200, Mehdi Dogguy wrote:
You want a constantly usable testing, but are you working these days on
fixing RC bugs affecting testing? Don't get me wrong. I'm not
finger-printing. I didn't find time to do that myself. But, if we all try
to do that, things will be
On Thu, 28 Apr 2011 22:16:27 +0200, Raphael Hertzog wrote:
On Thu, 28 Apr 2011, sean finney wrote:
If the latter case, I think the best thing to do would be to formalize
the proposal (DEP maybe?), set up the test archives/autobuilds, and get
right to it.
I'd be glad to help you drive a
Lucas Nussbaum lu...@lucas-nussbaum.net writes:
On 28/04/11 at 18:04 +0200, Mehdi Dogguy wrote:
I agree that it's a problem. However:
- we are likely to get more rolling+unstable users than the current
testing+sid users, so rolling release will get more testing
until the freeze.
On 13/04/2011 14:21, Raphael Hertzog wrote:
On Wed, 13 Apr 2011, sean finney wrote:
I don't think I've heard anything back from anyone who's actually on
the release team regarding this, but if they were at least non-comittedly
open to the idea, I'd be willing to throw my hat into the ring to
Hi Mehdi,
On Wed, Apr 27, 2011 at 05:58:46PM +0200, Mehdi Dogguy wrote:
Funny… reading your recent blogpost, you seem to not understand yet what
you want to put into Rolling (and how). So, how can we comment on
something that's not set or clearly described yet? Make a plan first, ask
for
On 2011-04-27, sean finney sean...@debian.org wrote:
* unstable always feeds to testing
* release N == testing, until the freeze.
* when freezing for release N
* testing is pointed at release N+1, and no longer automatically
feeds release N.
[...]
* RM's can still choose to
(throttled the conversation back a bit, hoping that someone from the
release team might take the time to chime in)
On Wed, Apr 13, 2011 at 02:21:38PM +0200, Raphael Hertzog wrote:
In the way I had thought of things, rolling == testing. That's to
say that nextstable branches off the main
(Moving to -devel, since -release is not a discussion list, and keeping
lots of context because of this)
Hi,
On Sun, 10 Apr 2011, sean finney wrote:
I think the quality of our releases has always been stellar, but the
freezes cause quite a bit of slowdown and even demotivation for those
who
Hi Raphaël,
On Wed, Apr 13, 2011 at 08:50:04AM +0200, Raphael Hertzog wrote:
On Sun, 10 Apr 2011, sean finney wrote:
My suggestion/feedback would be that we find a way where releases aren't
managed so linearly, and can be be handled in a more parallel manner
without such disruptive
On Wed, 13 Apr 2011, sean finney wrote:
I was only 50% at the last DebConf and missed the CUT BoF, but thought
I missed the BoF too (I was not at DebConf).
reading blogposts etc afterwards that people weren't as focused on the
branch out stable approach that I'm talking about, and rather were
On Thu, Apr 07, 2011 at 02:11:38PM +0200, Michelle Konzack wrote:
Installing NM by default will break systems which where running the last
12 years without flaws.
No, it will not. It will not impact *running* systems at all. It will only
impact newly installed systems.
--
To UNSUBSCRIBE,
On Thu, Apr 07, 2011 at 02:18:38PM +0200, Michelle Konzack wrote:
This is Exacly what I mean with NM. I do not wan to be bothered with
reading some hours documentations on how to tweek NM to work with my
four 10GE NICs.
And you wouldn't be - because, once again - you are not forced to
Hello Jon Dowland,
Am 2011-04-11 10:37:54, hacktest Du folgendes herunter:
On Thu, Apr 07, 2011 at 02:11:38PM +0200, Michelle Konzack wrote:
Installing NM by default will break systems which where running the last
12 years without flaws.
No, it will not. It will not impact *running*
Hello Jon Dowland,
Am 2011-04-11 12:02:09, hacktest Du folgendes herunter:
And you wouldn't be - because, once again - you are not forced to use whatever
the default solution is, you have the freedom to switch to another, just like
people who currently *do* use network-manager have taken
Le lundi 11 avril 2011 à 13:18 +0200, Michelle Konzack a écrit :
I think, DI has to support a Fast-Install-Option for Desktop and Server
where the first one installs NM by default and the second one IFUPDOWND.
This is what is already done for squeeze.
If OTOH we get d-i to run NM natively,
On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
Retrospective
-
The first thing we would like to do is to consider how the previous
release went. We'd like to know what went well, what went badly, and
what to improve for the next release.
Once again, we will use
On Thu, Mar 31, 2011 at 01:28:01PM +0200, Stefano Zacchiroli wrote:
I propose the following additions:
1) No uninstallable packages, according to their dependencies, are
snip
2) No packages with (detectable) conflicts are shipped as part of a
snip
After Ralf's ack to document them for
Zitat von Stanislav Maslovski stanislav.maslov...@gmail.com:
On Wed, Apr 06, 2011 at 10:51:08PM +0200, Hendrik Sattler wrote:
Am Mittwoch 06 April 2011, 19:05:11 schrieb Stanislav Maslovski:
On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote:
Then you can stack all soft of
Hello Philip Hands,
Am 2011-04-06 10:13:19, hacktest Du folgendes herunter:
I think this is the vital difference -- those that prefer ifupdown do so
because they prefer to be in tight control of what is happening on their
systems, whereas those that prefer NM don't want to be bothered about
Hello Hendrik Sattler,
Am 2011-04-07 12:56:33, hacktest Du folgendes herunter:
I am also not totally happy about network-manager but I still use it
as it gives me a working wireless network on my laptop without
having to spend hours reading endless documentation and writing
multiple
Hello,
On Wed, 06 Apr 2011 07:29:05 +0200
Josselin Mouette j...@debian.org wrote:
Your limited knowledge is like jam. The less you have, the more you
spread it.
Well, you have just confirmed this statement.
What you actually like about ifupdown is that it cannot do anything
but extremely
On 06 Apr 09:10, Andrew O. Shadoura wrote:
Hello,
On Wed, 06 Apr 2011 07:29:05 +0200
Josselin Mouette j...@debian.org wrote:
Your limited knowledge is like jam. The less you have, the more you
spread it.
Well, you have just confirmed this statement.
What you actually like about
On Wed, 06 Apr 2011 07:29:05 +0200, Josselin Mouette j...@debian.org wrote:
... and since it’s not event-based you have to hard-code the way your
network is set up.
I think this is the vital difference -- those that prefer ifupdown do so
because they prefer to be in tight control of what is
Stanislav Maslovski stanislav.maslov...@gmail.com (Sun Apr 3 12:37:26 2011):
On Sun, Apr 03, 2011 at 10:11:03AM +0200, martin f krafft wrote:
But if network-manager would become default and ifupdown an optional
replacement, I would question Debian's capacity to make technically
excellent
On Wed, Apr 6, 2011 at 9:45 AM, Heiko Schlittermann h...@schlittermann.de
wrote:
Stanislav Maslovski stanislav.maslov...@gmail.com (Sun Apr 3 12:37:26
2011):
On Sun, Apr 03, 2011 at 10:11:03AM +0200, martin f krafft wrote:
But if network-manager would become default and ifupdown an
On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote:
Le mardi 05 avril 2011 à 02:08 +0400, Stanislav Maslovski a écrit :
Well, that is not the question of how many, that is the question of
can you do a given task or not with a given tool. NM is limited in all
possible ways I
On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote:
Then you can stack all soft of stuff on top of it, and get them to
work manually for your specific setup, and since it’s not event-based
you have to
Am Mittwoch 06 April 2011, 19:05:11 schrieb Stanislav Maslovski:
On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote:
Then you can stack all soft of stuff on top of it, and get them to
work manually for your specific setup, and since it’s not event-based
On Wed, Apr 06, 2011 at 10:51:08PM +0200, Hendrik Sattler wrote:
Am Mittwoch 06 April 2011, 19:05:11 schrieb Stanislav Maslovski:
On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote:
Then you can stack all soft of stuff on top of it, and get them to
work manually for your
Ben Hutchings b...@decadent.org.uk writes:
On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote:
Josselin Mouette j...@debian.org writes:
Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
Martin F. Krafft started to implement a replacement of ifupdown that
is better designed.
Hello,
On Mon, 4 Apr 2011 11:56:15 +0100
Ben Hutchings b...@decadent.org.uk wrote:
Does this imply that fixing ifupdown to query the state(s) via
netlink instead of relying on state files would solve most of the
problems?
I expect so, but it would be a very big 'fix'.
Well, ifupdown
Hello,
On Tue, 5 Apr 2011 14:16:30 +0300
Andrew O. Shadoura bugzi...@tut.by wrote:
Another thing is that they may be ignored when the interface
isn't really 'up', as per kernel.
I mean, isn't up when doing ifup, of isn't down when doing ifdown.
--
WBR, Andrew
signature.asc
Description:
On Tue, Apr 05, 2011 at 02:16:30PM +0300, Andrew O. Shadoura wrote:
Hello,
On Mon, 4 Apr 2011 11:56:15 +0100
Ben Hutchings b...@decadent.org.uk wrote:
Does this imply that fixing ifupdown to query the state(s) via
netlink instead of relying on state files would solve most of the
Hello,
On Tue, 5 Apr 2011 13:30:53 +0100
Ben Hutchings b...@decadent.org.uk wrote:
Why is that necessary? So far as I can see, the purpose of the state
files is:
- Let ifup refuse to reapply a configuration (even if it failed to
apply it in the first place)
- Allow ifdown to take
On Tue, Apr 05, 2011 at 06:34:18PM +0300, Andrew O. Shadoura wrote:
Hello,
On Tue, 5 Apr 2011 13:30:53 +0100
Ben Hutchings b...@decadent.org.uk wrote:
Why is that necessary? So far as I can see, the purpose of the state
files is:
- Let ifup refuse to reapply a configuration (even if
On Tue, Apr 05, 2011 at 04:59:02PM +0100, Ben Hutchings wrote:
ifdown should not *need* to know how the interface was brought up.
And given that many people apparently like ifup because they can
change the active configuration without it interfering, it would be
a good thing if ifdown could
Le mardi 05 avril 2011 à 02:08 +0400, Stanislav Maslovski a écrit :
Well, that is not the question of how many, that is the question of
can you do a given task or not with a given tool. NM is limited in all
possible ways I can imagine, and also buggy. On the contrary, with
ifupdown, one for
On 08:18 Mon 04 Apr , Raphael Hertzog wrote:
RH Hi,
RH On Mon, 04 Apr 2011, Dmitry E. Oboukhov wrote:
Stupid scheme (intended for stupid users) should be based on ifupdown
but shouldn't replace it.
RH Please refrain from calling people stupid users just because they use a
RH software that
On Mon, Apr 04, 2011 at 10:52:33AM +0400, Dmitry E. Oboukhov wrote:
On 08:18 Mon 04 Apr , Raphael Hertzog wrote:
RH Hi,
RH On Mon, 04 Apr 2011, Dmitry E. Oboukhov wrote:
Stupid scheme (intended for stupid users) should be based on ifupdown
but shouldn't replace it.
RH Please refrain
On Mon, 4 Apr 2011 00:00:01 -0700
Steve Langasek vor...@debian.org wrote:
There was a way User can do anything, the way was replaced by the way
User can do something in list. Obviously that this action has been
done for stupid users.
Yes, a user can do anything with ifconfig if his time
Henrique de Moraes Holschuh h...@debian.org writes:
On Sun, 03 Apr 2011, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
/etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
* Ben Hutchings b...@decadent.org.uk [2011-04-03 20:56]:
The kernel necessarily holds the working network configuration, though
it lacks e.g. credentials for WPA or 802.1x which are handled by
user-space. User-space can change that state, and can read the state
(including waiting for
On Mon, Apr 04, 2011 at 12:00:01AM -0700, Steve Langasek wrote:
On Mon, Apr 04, 2011 at 10:52:33AM +0400, Dmitry E. Oboukhov wrote:
On 08:18 Mon 04 Apr , Raphael Hertzog wrote:
RH Hi,
RH On Mon, 04 Apr 2011, Dmitry E. Oboukhov wrote:
Stupid scheme (intended for stupid users) should
On Mon, Apr 04, 2011 at 10:24:26AM +0200, Martin Wuertele wrote:
* Ben Hutchings b...@decadent.org.uk [2011-04-03 20:56]:
The kernel necessarily holds the working network configuration, though
it lacks e.g. credentials for WPA or 802.1x which are handled by
user-space. User-space can
On Mon, Apr 04, 2011 at 01:11:15AM +0400, Stanislav Maslovski wrote:
Why on earth would I do that? It does not match my needs at all. For
instance, this laptop sometimes connects to a couple of remote LANs
through VPNs, so that I have to set up routing in a not completely
trivial manner.
I
On Mon, 4 Apr 2011, Neil Williams codeh...@debian.org wrote:
There needs to be a simple tool with few dependencies and there needs
to be a complex solution with all the power that some users need. One
tool does not suit all here. It's not just about daemon vs GUI frontend
or whether to use
On Mon, Apr 04, 2011 at 09:59:43PM +1000, Russell Coker wrote:
On Mon, 4 Apr 2011, Neil Williams codeh...@debian.org wrote:
There needs to be a simple tool with few dependencies and there needs
to be a complex solution with all the power that some users need. One
tool does not suit all
Hello Stanislav Maslovski,
Am 2011-04-04 01:11:15, hacktest Du folgendes herunter:
On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote:
May I suggest that you install a squeeze system with the desktop task,
with a simple DHCP network configuration?
Why on earth would I do that?
On Mon, Apr 04, 2011 at 11:17:59PM +0200, Michelle Konzack wrote:
Hello Stanislav Maslovski,
Am 2011-04-04 01:11:15, hacktest Du folgendes herunter:
On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote:
May I suggest that you install a squeeze system with the desktop task,
On Sun, Apr 03, 2011 at 07:24:36AM +0800, Paul Wise wrote:
On Sun, Apr 3, 2011 at 6:58 AM, Felipe Sateler fsate...@debian.org wrote:
The main problem I see is that NM likes to take interfaces down when
upgrading. This is a problem if upgrading remotely.
Probably using glib/gobject etc is
also sprach Josselin Mouette j...@debian.org [2011.04.02.2229 +0200]:
I wonder what amount of features we are missing for network-manager to
do the job; instead of rewriting a daemon from scratch, we might as well
use one that was designed mostly for the same purpose. It’s
event-driven, it’s
On Sun, Apr 03, 2011 at 10:11:03AM +0200, martin f krafft wrote:
But if network-manager would become default and ifupdown an optional
replacement, I would question Debian's capacity to make technically
excellent decisions and wonder, how much we have been dragged along
by user-friendly distros
* Stefano Zacchiroli z...@debian.org [110403 12:57]:
On Sun, Apr 03, 2011 at 02:37:26PM +0400, Stanislav Maslovski wrote:
If that happens I will seriously think about moving to another distro
(I have been using Debian since around 1999). Or maybe to a *BSD.
You're entitled to choose your
On Sun, 03 Apr 2011 01:59:02 +0530
Josselin Mouette j...@debian.org wrote:
Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
Martin F. Krafft started to implement a replacement of ifupdown that
is better designed. But, due to lack of manpower I think, this project
did not
Le dimanche 03 avril 2011 à 07:24 +0800, Paul Wise a écrit :
Probably using glib/gobject etc is a no-no for a package that needs to
be in base.
And that’s because… ?
The main problem I see is that the design of NM is wrong™ and the
upstream maintainers do not see it that way.
The
On Sun, 03 Apr 2011 16:53:11 +0530
Josselin Mouette j...@debian.org wrote:
Le dimanche 03 avril 2011 à 07:24 +0800, Paul Wise a écrit :
Probably using glib/gobject etc is a no-no for a package that needs to
be in base.
And that’s because… ?
it's an extra dependency which basic systems
Henrique de Moraes Holschuh h...@debian.org writes:
On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
/etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.
I am at a loss about how it could be made compatible with RO /.
On Sun, Apr 03, 2011 at 12:56:40PM +0200, Stefano Zacchiroli wrote:
On Sun, Apr 03, 2011 at 02:37:26PM +0400, Stanislav Maslovski wrote:
If that happens I will seriously think about moving to another distro
(I have been using Debian since around 1999). Or maybe to a *BSD.
You're entitled
On Sun, Apr 3, 2011 at 7:23 PM, Josselin Mouette j...@debian.org wrote:
And that’s because… ?
Good question, the only answer I have is that we probably don't want
to add too much bloat to base.
This is not a design issue, this is what can make it work. If you have
one single, extensible
On Sun, Apr 03, 2011 at 02:09:09PM +0200, Stefano Zacchiroli wrote:
On Sun, Apr 03, 2011 at 01:07:12PM +0200, Bernhard R. Link wrote:
Debian is not about market-share, so losing users is no thread. It is
only an information for us that we no longer helpful to some of our
users.
The
On Sun, Apr 03, 2011 at 04:42:11PM +0400, Stanislav Maslovski wrote:
I understand that you are in a position that forces you to think about
public relations and such, but if I were a DD I would be more happy if
DPL was a bit more focused on real problems.
Non sequitur: the fact that I'm
On Thu, Mar 31, 2011 at 01:28:01PM +0200, Stefano Zacchiroli wrote:
1) No uninstallable packages, according to their dependencies, are
shipped as part of a release. AFAIK this is already monitored
pre-release, and daily monitored at
http://edos.debian.net/uninstallable.php. If this
On Sun, Apr 3, 2011 at 5:11 AM, martin f krafft madd...@debian.org wrote:
[...]
last I checked, for instance, it was not possible to hook up two
network cards with DHCP.
[...]
Hmmm I do have two network cards and they both get IP addresses with
DHCP as I would expect (when they both are
On Sun, Apr 03, 2011 at 03:50:36PM +0200, Stefano Zacchiroli wrote:
On Sun, Apr 03, 2011 at 04:42:11PM +0400, Stanislav Maslovski wrote:
I understand that you are in a position that forces you to think about
public relations and such, but if I were a DD I would be more happy if
DPL was a
Le dimanche 03 avril 2011 à 20:38 +0800, Paul Wise a écrit :
The problem with that design is that it isn't based in *fact*. The
fact is that the kernel is where the current networking status is
held, controlled and modified. AFAICT the NM authors ignored that fact
in their designs and are
Le dimanche 03 avril 2011 à 21:32 +0400, Stanislav Maslovski a écrit :
Analogously, when I see such great technical suggestions as
replacing ifupdown on default installs with network-manager, I can't
help thinking (and sometimes commenting) that if this trend continues,
then at some point in
On Sun, 2011-04-03 at 23:13 +0530, Josselin Mouette wrote:
Le dimanche 03 avril 2011 à 20:38 +0800, Paul Wise a écrit :
The problem with that design is that it isn't based in *fact*. The
fact is that the kernel is where the current networking status is
held, controlled and modified. AFAICT
On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette wrote:
Le dimanche 03 avril 2011 à 21:32 +0400, Stanislav Maslovski a écrit :
Analogously, when I see such great technical suggestions as
replacing ifupdown on default installs with network-manager, I can't
help thinking (and
Hello,
This reply went to debian-russian@ due to a mistake. Next doing a
bounce to d-d was another mistake, so if you receive this message
twice, I am sorry for that!
Still I feel that I cannot leave it unanswered, so here it goes.
On Sun, Apr 03, 2011 at 11:26:20PM +0530, Josselin Mouette
On ma, 2011-04-04 at 00:18 +0400, Stanislav Maslovski wrote:
If you read my mails without a prejudice you will notice it.
I have read all e-mails in this thread, and what constructive criticism
you may have given is buried under uncompromising prejudice. For
example:
If you mean the
On Sun, Apr 03, 2011 at 10:28:42PM +0100, Lars Wirzenius wrote:
I have read all e-mails in this thread, and what constructive criticism
you may have given is buried under uncompromising prejudice. For
example:
If you mean the ifupdown-based configuration, then I cannot agree that
it is
On Sun, 03 Apr 2011, Goswin von Brederlow wrote:
Henrique de Moraes Holschuh h...@debian.org writes:
On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
/etc/adjtime
This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.
I am at
If you mean the ifupdown-based configuration, then I cannot agree that
it is really disastrous (I would agree that the network-manager
approach is really disastrous, however) as at least in my cases (which
are not so trivial) ifupdown works okay (and if not then at least I
would know ways how
Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
Martin F. Krafft started to implement a replacement of ifupdown that
is better designed. But, due to lack of manpower I think, this project
did not finish. See this archives of netconf-de...@lists.alioth.debian.org
for more info.
Josselin Mouette j...@debian.org writes:
Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
Martin F. Krafft started to implement a replacement of ifupdown that
is better designed. But, due to lack of manpower I think, this project
did not finish. See this archives of
On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote:
Josselin Mouette j...@debian.org writes:
Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
Martin F. Krafft started to implement a replacement of ifupdown that
is better designed. But, due to lack of manpower I think, this
On Sat, Apr 02, 2011 at 10:30:43PM +0100, Ben Hutchings wrote:
On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote:
Josselin Mouette j...@debian.org writes:
I wonder what amount of features we are missing for network-manager to
do the job; instead of rewriting a daemon from scratch,
On Sun, 03 Apr 2011 01:59:02 +0530, Josselin Mouette wrote:
Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit :
Martin F. Krafft started to implement a replacement of ifupdown that is
better designed. But, due to lack of manpower I think, this project did
not finish. See this
On Sun, Apr 3, 2011 at 6:58 AM, Felipe Sateler fsate...@debian.org wrote:
The main problem I see is that NM likes to take interfaces down when
upgrading. This is a problem if upgrading remotely.
Probably using glib/gobject etc is a no-no for a package that needs to
be in base.
The main
Quoting Paul Wise (p...@debian.org):
If anyone wants to help there, more info here:
http://wiki.debian.org/OldPkgRemovals#defoma
Main blockers are Xorg, ghostscript and the other remaining backends
(libwmf, vflib3).
Would you agree for us to be advocates of this release goal, Paul?
You
401 - 500 of 840 matches
Mail list logo
