Hello list,
I have a couple of questions regarding the design of the network gui/text screen. Before I ask, it maybe helpful to explain my setup and situation:
I have a network adapter with two ports. The first port (eth0, static IP) is connected to the public network and the other port (eth1, dhcp) is connected to my private network (same subnet as the NFS installation and DHCP servers). After I grab a dynamic IP for eth1 and setup the partitions, I end up in the network gui. Here, I enter the static IP address of eth0. I cannot, however, edit the gateway or DNS settings (which are different than eth1) for this port (eth0). So:
1) Is Anaconda designed to simply configure the adapter/port that accesses the install data? I assume the responsibility would then fall on the user to configure the other adapters during the firstboot process or setup agent screen.
2) If #1 is true, then I am curious as to why Anaconda allows the user to configure the IP, but the not the gateway/DNS information, for other adapters since it relies on firstboot, etc.
Thanks in advance for the help/explanations.
Regards, -Dan
Daniel F de Araujo wrote:
Hello list,
I have a couple of questions regarding the design of the network gui/text screen. Before I ask, it maybe helpful to explain my setup and situation:
I have a network adapter with two ports. The first port (eth0, static IP) is connected to the public network and the other port (eth1, dhcp) is connected to my private network (same subnet as the NFS installation and DHCP servers). After I grab a dynamic IP for eth1 and setup the partitions, I end up in the network gui. Here, I enter the static IP address of eth0. I cannot, however, edit the gateway or DNS settings (which are different than eth1) for this port (eth0). So:
- Is Anaconda designed to simply configure the adapter/port that
accesses the install data? I assume the responsibility would then fall on the user to configure the other adapters during the firstboot process or setup agent screen.
- If #1 is true, then I am curious as to why Anaconda allows the user
to configure the IP, but the not the gateway/DNS information, for other adapters since it relies on firstboot, etc.
Thanks in advance for the help/explanations.
Anaconda collects enough information to write out files in /etc/sysconfig/network-scripts. We write out ifcfg-ethX files. The gateway and DNS settings are not stored per-interface. The gateway is written to /etc/sysconfig/network since you can only have one default gateway. DNS settings are written to /etc/resolv.conf and are also system-wide rather than per interface.
Anaconda will allow you to configure each network interface in the system. You can set it up for manual or dynamic configuration and flag it as ONBOOT or not.
David Cantrell wrote:
Daniel F de Araujo wrote:
Hello list,
I have a couple of questions regarding the design of the network gui/text screen. Before I ask, it maybe helpful to explain my setup and situation:
I have a network adapter with two ports. The first port (eth0, static IP) is connected to the public network and the other port (eth1, dhcp) is connected to my private network (same subnet as the NFS installation and DHCP servers). After I grab a dynamic IP for eth1 and setup the partitions, I end up in the network gui. Here, I enter the static IP address of eth0. I cannot, however, edit the gateway or DNS settings (which are different than eth1) for this port (eth0). So:
- Is Anaconda designed to simply configure the adapter/port that
accesses the install data? I assume the responsibility would then fall on the user to configure the other adapters during the firstboot process or setup agent screen.
- If #1 is true, then I am curious as to why Anaconda allows the user
to configure the IP, but the not the gateway/DNS information, for other adapters since it relies on firstboot, etc.
Thanks in advance for the help/explanations.
Anaconda collects enough information to write out files in /etc/sysconfig/network-scripts. We write out ifcfg-ethX files. The gateway and DNS settings are not stored per-interface. The gateway is written to /etc/sysconfig/network since you can only have one default gateway. DNS settings are written to /etc/resolv.conf and are also system-wide rather than per interface.
Flawed logic there. I have a laptop. Which network device should provide the default route depends.... One is 11b wireless, sometimes I connect to wire for increased speed. So does my boss.
It would be reasonable for which ever is more-recently activated to prevail, and for removing wire to restore wireless (if it's still present).
Anaconda will allow you to configure each network interface in the system. You can set it up for manual or dynamic configuration and flag it as ONBOOT or not.
John Summerfield wrote:
David Cantrell wrote:
Daniel F de Araujo wrote:
Hello list,
I have a couple of questions regarding the design of the network gui/text screen. Before I ask, it maybe helpful to explain my setup and situation:
I have a network adapter with two ports. The first port (eth0, static IP) is connected to the public network and the other port (eth1, dhcp) is connected to my private network (same subnet as the NFS installation and DHCP servers). After I grab a dynamic IP for eth1 and setup the partitions, I end up in the network gui. Here, I enter the static IP address of eth0. I cannot, however, edit the gateway or DNS settings (which are different than eth1) for this port (eth0). So:
- Is Anaconda designed to simply configure the adapter/port that
accesses the install data? I assume the responsibility would then fall on the user to configure the other adapters during the firstboot process or setup agent screen.
- If #1 is true, then I am curious as to why Anaconda allows the
user to configure the IP, but the not the gateway/DNS information, for other adapters since it relies on firstboot, etc.
Thanks in advance for the help/explanations.
Anaconda collects enough information to write out files in /etc/sysconfig/network-scripts. We write out ifcfg-ethX files. The gateway and DNS settings are not stored per-interface. The gateway is written to /etc/sysconfig/network since you can only have one default gateway. DNS settings are written to /etc/resolv.conf and are also system-wide rather than per interface.
Flawed logic there. I have a laptop. Which network device should provide the default route depends.... One is 11b wireless, sometimes I connect to wire for increased speed. So does my boss.
It would be reasonable for which ever is more-recently activated to prevail, and for removing wire to restore wireless (if it's still present).
The answer to this situation is NetworkManager, not the installer. Enable it post-install:
chkconfig NetworkManagerDispatcher on chkconfig NetworkManager on
Use it. Never futz with the ifcfg-ethX scripts again.
David Cantrell wrote:
John Summerfield wrote:
David Cantrell wrote:
Daniel F de Araujo wrote:
Hello list,
I have a couple of questions regarding the design of the network gui/text screen. Before I ask, it maybe helpful to explain my setup and situation:
I have a network adapter with two ports. The first port (eth0, static IP) is connected to the public network and the other port (eth1, dhcp) is connected to my private network (same subnet as the NFS installation and DHCP servers). After I grab a dynamic IP for eth1 and setup the partitions, I end up in the network gui. Here, I enter the static IP address of eth0. I cannot, however, edit the gateway or DNS settings (which are different than eth1) for this port (eth0). So:
- Is Anaconda designed to simply configure the adapter/port that
accesses the install data? I assume the responsibility would then fall on the user to configure the other adapters during the firstboot process or setup agent screen.
- If #1 is true, then I am curious as to why Anaconda allows the
user to configure the IP, but the not the gateway/DNS information, for other adapters since it relies on firstboot, etc.
Thanks in advance for the help/explanations.
Anaconda collects enough information to write out files in /etc/sysconfig/network-scripts. We write out ifcfg-ethX files. The gateway and DNS settings are not stored per-interface. The gateway is written to /etc/sysconfig/network since you can only have one default gateway. DNS settings are written to /etc/resolv.conf and are also system-wide rather than per interface.
Flawed logic there. I have a laptop. Which network device should provide the default route depends.... One is 11b wireless, sometimes I connect to wire for increased speed. So does my boss.
It would be reasonable for which ever is more-recently activated to prevail, and for removing wire to restore wireless (if it's still present).
The answer to this situation is NetworkManager, not the installer. Enable it post-install:
chkconfig NetworkManagerDispatcher on chkconfig NetworkManager on
Use it. Never futz with the ifcfg-ethX scripts again.
Then the installer should set this up.
David, I don't like off-list replies. They don't filter well (I use the list-id header), and they break threads.
Do you think you could coax the list manager to change this list's settings so that its default is for replies to go to the list, as is appropriate for a discussion list?
Thanks.
On Sun, Dec 10, 2006 at 05:50:55 +0900, John Summerfield debian@herakles.homelinux.org wrote:
Do you think you could coax the list manager to change this list's settings so that its default is for replies to go to the list, as is appropriate for a discussion list?
You can use a mail-followup-to header to ask for group replies to not copy you directly. Or if you don't want anyone replying directly to you, set the reply-to header to the list when sending email.
John Summerfield wrote:
David Cantrell wrote:
John Summerfield wrote:
David Cantrell wrote:
Daniel F de Araujo wrote:
Hello list,
I have a couple of questions regarding the design of the network gui/text screen. Before I ask, it maybe helpful to explain my setup and situation:
I have a network adapter with two ports. The first port (eth0, static IP) is connected to the public network and the other port (eth1, dhcp) is connected to my private network (same subnet as the NFS installation and DHCP servers). After I grab a dynamic IP for eth1 and setup the partitions, I end up in the network gui. Here, I enter the static IP address of eth0. I cannot, however, edit the gateway or DNS settings (which are different than eth1) for this port (eth0). So:
- Is Anaconda designed to simply configure the adapter/port that
accesses the install data? I assume the responsibility would then fall on the user to configure the other adapters during the firstboot process or setup agent screen.
- If #1 is true, then I am curious as to why Anaconda allows the
user to configure the IP, but the not the gateway/DNS information, for other adapters since it relies on firstboot, etc.
Thanks in advance for the help/explanations.
Anaconda collects enough information to write out files in /etc/sysconfig/network-scripts. We write out ifcfg-ethX files. The gateway and DNS settings are not stored per-interface. The gateway is written to /etc/sysconfig/network since you can only have one default gateway. DNS settings are written to /etc/resolv.conf and are also system-wide rather than per interface.
Flawed logic there. I have a laptop. Which network device should provide the default route depends.... One is 11b wireless, sometimes I connect to wire for increased speed. So does my boss.
It would be reasonable for which ever is more-recently activated to prevail, and for removing wire to restore wireless (if it's still present).
The answer to this situation is NetworkManager, not the installer. Enable it post-install:
chkconfig NetworkManagerDispatcher on chkconfig NetworkManager on
Use it. Never futz with the ifcfg-ethX scripts again.
Then the installer should set this up.
Agreed. I'd like the network configuration stage of anaconda to be supplemented with a screen before it that asks "Would you like to enable NetworkManager?" accompanied by a description of network manager and the benefits and such. If the user selects yes, it skips of the network configuration screen. If they select no, we go to the network configuration screen. I have it on a to do list somewhere.
David, I don't like off-list replies. They don't filter well (I use the list-id header), and they break threads.
Do you think you could coax the list manager to change this list's settings so that its default is for replies to go to the list, as is appropriate for a discussion list?
Also agreed. I'll see what I can do. No promises and no guarantees that I won't forget about this 5 seconds after sending the email.
On Mon, 2006-12-11 at 11:59 -0500, David Cantrell wrote:
Agreed. I'd like the network configuration stage of anaconda to be supplemented with a screen before it that asks "Would you like to enable NetworkManager?" accompanied by a description of network manager and the benefits and such. If the user selects yes, it skips of the network configuration screen. If they select no, we go to the network configuration screen. I have it on a to do list somewhere.
I'd far rather just enable NetworkManager -- let's figure out the case of things that you can currently do with the anaconda UI that don't work with NetworkManager, fix them, and then stop trying to pretend. Pushing the question to the user is entirely the wrong answer.[1] There's no way you can provide sufficient information for them to make an educated decision here.
Jeremy
[1] We'll still want to keep most of the configuration via kickstart as that's somewhat important. And it's possible that we also keep the screen around if you're building a non-NetworkManager-enabled (legacy :-) distribution.
Hi.
Jeremy Katz katzj@redhat.com wrote:
I'd far rather just enable NetworkManager -- let's figure out the case of things that you can currently do with the anaconda UI that don't work with NetworkManager, fix them, and then stop trying to pretend.
Static IPs come to mind.
Jeremy Katz wrote:
On Mon, 2006-12-11 at 11:59 -0500, David Cantrell wrote:
Agreed. I'd like the network configuration stage of anaconda to be supplemented with a screen before it that asks "Would you like to enable NetworkManager?" accompanied by a description of network manager and the benefits and such. If the user selects yes, it skips of the network configuration screen. If they select no, we go to the network configuration screen. I have it on a to do list somewhere.
I'd far rather just enable NetworkManager -- let's figure out the case of things that you can currently do with the anaconda UI that don't work with NetworkManager, fix them, and then stop trying to pretend. Pushing the question to the user is entirely the wrong answer.[1] There's no way you can provide sufficient information for them to make an educated decision here.
I'm all for that, but I don't think NetworkManager at that point yet. Regardless of what component handles network configuration, those users with static network setups will need to input those values somewhere. NM will have to ask somehow, or we leave it up to anaconda (or firstboot?). NM certainly has far more flexibility in this respect and maybe we should just say, "ok, it's now the responsibility of NM, however it wants to handle it." But that means networking could be non-functional on first boot for new installations if the users have static network configurations.
I hate asking for network configuration information because it's too confusing to new users and it's pointless for experienced users since they bypass it anyway.
At any rate, this is a discussion that should moves towards the NM people as well as anaconda people.
[1] We'll still want to keep most of the configuration via kickstart as that's somewhat important. And it's possible that we also keep the screen around if you're building a non-NetworkManager-enabled (legacy :-) distribution.
Of course, we wouldn't want to _remove_ code. :)
On Mon, Dec 11, 2006 at 04:23:32PM -0500, David Cantrell wrote:
with static network setups will need to input those values somewhere. NM will have to ask somehow, or we leave it up to anaconda (or firstboot?). NM certainly has far more flexibility in this respect and
How can it be left up to firstboot, without making kickstart mandatory for network installs?
On Mon, 2006-12-11 at 16:26 -0500, Matthew Miller wrote:
On Mon, Dec 11, 2006 at 04:23:32PM -0500, David Cantrell wrote:
with static network setups will need to input those values somewhere. NM will have to ask somehow, or we leave it up to anaconda (or firstboot?). NM certainly has far more flexibility in this respect and
How can it be left up to firstboot, without making kickstart mandatory for network installs?
Network installs (obviously?) have to bring up the network still -- but that's a little different than the post-install network config screen, although related
Jeremy
Matthew Miller wrote:
On Mon, Dec 11, 2006 at 04:23:32PM -0500, David Cantrell wrote:
with static network setups will need to input those values somewhere. NM will have to ask somehow, or we leave it up to anaconda (or firstboot?). NM certainly has far more flexibility in this respect and
How can it be left up to firstboot, without making kickstart mandatory for network installs?
I menat to say, if Anaconda's run headless, firstboot must be able to too.
fwiw I rarely see firstboot. Must be something to do with the way I install.
David Cantrell wrote:
Jeremy Katz wrote:
On Mon, 2006-12-11 at 11:59 -0500, David Cantrell wrote:
Agreed. I'd like the network configuration stage of anaconda to be supplemented with a screen before it that asks "Would you like to enable NetworkManager?" accompanied by a description of network manager and the benefits and such. If the user selects yes, it skips of the network configuration screen. If they select no, we go to the network configuration screen. I have it on a to do list somewhere.
I'd far rather just enable NetworkManager -- let's figure out the case of things that you can currently do with the anaconda UI that don't work with NetworkManager, fix them, and then stop trying to pretend. Pushing the question to the user is entirely the wrong answer.[1] There's no way you can provide sufficient information for them to make an educated decision here.
I'm all for that, but I don't think NetworkManager at that point yet. Regardless of what component handles network configuration, those users with static network setups will need to input those values somewhere. NM will have to ask somehow, or we leave it up to anaconda (or firstboot?). NM certainly has far more flexibility in this respect and maybe we should just say, "ok, it's now the responsibility of NM, however it wants to handle it." But that means networking could be non-functional on first boot for new installations if the users have static network configurations.
I hate asking for network configuration information because it's too confusing to new users and it's pointless for experienced users since they bypass it anyway.
I think more experienced users are more likely to use kickstart.
but then, more experienced users are likely to miss new stuff in ks.
At any rate, this is a discussion that should moves towards the NM people as well as anaconda people.
[1] We'll still want to keep most of the configuration via kickstart as that's somewhat important. And it's possible that we also keep the screen around if you're building a non-NetworkManager-enabled (legacy :-) distribution.
I always assumed that if I want to build Valhalla, then I should use the Valhalla version of the snake.
Perhaps all this legacy code I didn't know about is why it took well over 12 hours to upgrade my Satellite 1400 (Cel 1.3, 256 Mbyte, 40 Gbyte fairly new hdd) from FC3 to FC5.
Of course, we wouldn't want to _remove_ code. :)
On Monday 11 December 2006 11:59, David Cantrell wrote:
Do you think you could coax the list manager to change this list's settings so that its default is for replies to go to the list, as is appropriate for a discussion list?
Also agreed. I'll see what I can do. No promises and no guarantees that I won't forget about this 5 seconds after sending the email.
Please no. That's why email clients have "list-reply" buttons/functions.
http://www.unicom.com/pw/reply-to-harmful.html
Jesse Keating wrote:
On Monday 11 December 2006 11:59, David Cantrell wrote:
Do you think you could coax the list manager to change this list's settings so that its default is for replies to go to the list, as is appropriate for a discussion list?
Also agreed. I'll see what I can do. No promises and no guarantees that I won't forget about this 5 seconds after sending the email.
Please no. That's why email clients have "list-reply" buttons/functions.
Until all email clients RH ships support that, it's nonsense. Thus far, I've not seen a way to use it in any email client I regularly use. RH does not ship either email client the author mentions.
That document is the opinion of one person. If the RFCs he mentions support his view, he should mention them, quote them. As he says, they're lengthy and boring documents.
How often do you want to reply off-list? I almost never do, when I'm on a discussion list. The functionality I want is the ability to reply directly to the list most easily.
The "reply to all" he mentions does not work either. It replies to all recipient addresses in the headers, including the list everyone's on. And sometimes, to other lists including those the responder's _not_ on, leading to bounce messages or 'did you really mean that?' messages.
To "fix" this problem, mailman doesn't, by default, send to those who it thinks have their own private copy. That means that, not only do recipients get the wrongly-address message, they don't get one that's correctly-addresses. This limits their ability to filter effectively, not only into folders as I do, but using whitelists as others do.
n my view, it's perfectly reasonable for a list manager to sa, "I will set the reply-to to the list because for this list, that's what most people will want and expect, it's what will work best for my users. If they want to reply to the author, they can copy the address."
At present, I often find myself editing addresses for the more usual case, and that's barmy.
-
Cheers John
-- spambait 1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
Please do not reply off-list
On Monday 11 December 2006 16:25, John Summerfield wrote:
Until all email clients RH ships support that, it's nonsense. Thus far, I've not seen a way to use it in any email client I regularly use. RH does not ship either email client the author mentions.
That document is the opinion of one person. If the RFCs he mentions support his view, he should mention them, quote them. As he says, they're lengthy and boring documents.
How often do you want to reply off-list? I almost never do, when I'm on a discussion list. The functionality I want is the ability to reply directly to the list most easily.
Evolution, Kmail, and sylpheed support a reply-list function. Thunderbird I think is still braindead in this department.
I find myself replying off list many times. In fact, I probably should have for this message. I all too often see private messages hitting the public list because somebody didn't notice that reply-to was munged, and when they asked their client to reply to the sender, the client didn't do what was expected due to the munging. This I think is far more dangerous then the opposite.
Jesse Keating wrote:
On Monday 11 December 2006 16:25, John Summerfield wrote:
Until all email clients RH ships support that, it's nonsense. Thus far, I've not seen a way to use it in any email client I regularly use. RH does not ship either email client the author mentions.
That document is the opinion of one person. If the RFCs he mentions support his view, he should mention them, quote them. As he says, they're lengthy and boring documents.
How often do you want to reply off-list? I almost never do, when I'm on a discussion list. The functionality I want is the ability to reply directly to the list most easily.
Evolution, Kmail, and sylpheed support a reply-list function. Thunderbird I think is still braindead in this department.
I choose email clients based on what I want. I don't like Evolutiion, sylpheed not that obviously available for the systems I use - I see it's un RHL 7.3, but I rarely used that now. The "email" button on RH systems generally starts up Evolution (even when it's not installed!).
If you think Thunderbird's broken, you're in a good place to have if "fixed." Ditto kmail. Until those support "reply to list" easily, don't even think about expecting users to use it.
I find myself replying off list many times. In fact, I probably should have for this message.
I would not have welcomed it.
I all too often see private messages hitting the public
list because somebody didn't notice that reply-to was munged, and when they asked their client to reply to the sender, the client didn't do what was expected due to the munging. This I think is far more dangerous then the opposite.
If you're on a list (as I was) where people promote their products & services, and solicit replies, then the list should set reply-to to the author. Mailman supports that.
_This_ is not that kind of list, it's a discussion list where everyone is already subscribed.
On Monday 11 December 2006 16:53, John Summerfield wrote:
I choose email clients based on what I want. I don't like Evolutiion, sylpheed not that obviously available for the systems I use - I see it's un RHL 7.3, but I rarely used that now. The "email" button on RH systems generally starts up Evolution (even when it's not installed!).
Sylpheed is in Fedora Extras, which is enabled for every Fedora install since FC4~. If it's not in RHEL now, it will most likely show up in EPEL, Extra Packages for Enterprise Linux.
If you think Thunderbird's broken, you're in a good place to have if "fixed." Ditto kmail. Until those support "reply to list" easily, don't even think about expecting users to use it.
I didn't say Kmail was broken, kmail does this easily (and its one of the reasons why kmail is my client of choice). As far as thunderbird, the bug has been filed upstream, however upstream seems not interested in fixing this. RHEL has chosen Evolution as the default mailer, and since it supports this there is little interest in spending more time on Thunderbird to hack it in, especially if upstream won't take it.
I find myself replying off list many times. In fact, I probably should have for this message.
I would not have welcomed it.
That's too bad, this conversation is very off topic for this list.
I all too often see private messages hitting the public
list because somebody didn't notice that reply-to was munged, and when they asked their client to reply to the sender, the client didn't do what was expected due to the munging. This I think is far more dangerous then the opposite.
If you're on a list (as I was) where people promote their products & services, and solicit replies, then the list should set reply-to to the author. Mailman supports that.
_This_ is not that kind of list, it's a discussion list where everyone is already subscribed.
soliciting replies isn't the only 'dangerous' thing. Private messages, private discussions, flames, etc.. many of these things could/should happen off-list. We (Fedora) are starting to standardize the settings across all the lists we host. Whether or not this particular list falls under that standardization is left to be seen, but I'm pretty sure that reply-to munging will not be part of that standard.
But I digress, this is _really_ off topic for this list, and discussion can continue in my inbox if you so care.
Jesse Keating wrote:
On Monday 11 December 2006 16:53, John Summerfield wrote:
I choose email clients based on what I want. I don't like Evolutiion, sylpheed not that obviously available for the systems I use - I see it's un RHL 7.3, but I rarely used that now. The "email" button on RH systems generally starts up Evolution (even when it's not installed!).
Sylpheed is in Fedora Extras, which is enabled for every Fedora install since FC4~. If it's not in RHEL now, it will most likely show up in EPEL, Extra Packages for Enterprise Linux.
I never look past the install media. Unless extras is on my DVD, I will not install it. It takes too long over modem.
If you think Thunderbird's broken, you're in a good place to have if "fixed." Ditto kmail. Until those support "reply to list" easily, don't even think about expecting users to use it.
I didn't say Kmail was broken, kmail does this easily (and its one of the reasons why kmail is my client of choice). As far as thunderbird, the bug
I used kmail for some years; I don't recall that it did this then, but things do change. I quit using it because I decided I prefer the Mozilla/Thunderbird way of handing read mail and threads.
has been filed upstream, however upstream seems not interested in fixing
Try Debian's icedove. If you can persuade Debian it's broken, the maintainers will almost certainly fix it. Debian is very big on compliance.
this. RHEL has chosen Evolution as the default mailer, and since it supports
Did I mention I really do not like Evolution?
this there is little interest in spending more time on Thunderbird to hack it in, especially if upstream won't take it.
I find myself replying off list many times. In fact, I probably should have for this message.
I would not have welcomed it.
That's too bad, this conversation is very off topic for this list.
The management of a list is never OT for the list. You and I could come to a private agreement, but unless you or I manages the list, it won't change a thing.
I all too often see private messages hitting the public
list because somebody didn't notice that reply-to was munged, and when they asked their client to reply to the sender, the client didn't do what was expected due to the munging. This I think is far more dangerous then the opposite.
If you're on a list (as I was) where people promote their products & services, and solicit replies, then the list should set reply-to to the author. Mailman supports that.
_This_ is not that kind of list, it's a discussion list where everyone is already subscribed.
soliciting replies isn't the only 'dangerous' thing. Private messages, private discussions, flames, etc.. many of these things could/should happen
Flames should always go to /dev/null. There is no point in offending someone.
If you have a correction to something I say, it's almost always preferable to send it to the list so that others (including those who read the archives) will benefit from your superior wisdom.
When I get a round tuit, I plan to make it impossible for people to reply to directly me, or even to get the email address I receive mail on. The mail address I write _from_ will simply not accept mail from sources other than the list hosts I use, and possibly not from those except when I subscribe.
It's not to stopoff-list replies, it's to stop spamharvesters from subscribing to these lists (they do, previous editions of my spambait addresses get mail) and getting my address.
off-list. We (Fedora) are starting to standardize the settings across all the lists we host. Whether or not this particular list falls under that standardization is left to be seen, but I'm pretty sure that reply-to munging will not be part of that standard.
But I digress, this is _really_ off topic for this list, and discussion can continue in my inbox if you so care. https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Mon, December 11, 2006 3:03 pm, Jesse Keating wrote:
But I digress, this is _really_ off topic for this list,
List settings don't seem off-topic for a list at all. I agree with John that it makes sense for a discussion list to set reply-to to the list. Other redhat lists (kickstart, nahant, taroon, rhelv5-beta at least) do exactly that. It's inconsistent for anaconda-devel to be the exception. (If reply-to-list is 'dangerous', one needs to re-think what they are committing to print.)
-Ed
On Mon, Dec 11, 2006 at 06:28:15PM -0700, Edward F. Brown wrote:
But I digress, this is _really_ off topic for this list,
List settings don't seem off-topic for a list at all. I agree with John
Yes they are off-topic, for the love of an entire pantheon. It's a metadiscussion that should be taken care of out-of-band.
Matthew Miller wrote:
On Mon, Dec 11, 2006 at 06:28:15PM -0700, Edward F. Brown wrote:
But I digress, this is _really_ off topic for this list,
List settings don't seem off-topic for a list at all. I agree with John
Yes they are off-topic, for the love of an entire pantheon. It's a metadiscussion that should be taken care of out-of-band.
If mailing lists can be regarded as virtual meetings, and I for one see significant similarities, then a discussion about the conduct of a list can be regarded as a virtual procedural motion, and in a meeting, not only are procedural motions permitted at (almost) any time, they take precedence over substantive motions.
It is appropriate that a list be conducted in accord with the members' wishes, and the only way the members can have an open, recorded, discussion about the list's conduct is to do so on the list. How else can all those affected and who wish to do so participate?
For sure, Matthew, had David and I discussed the question privately, we could have made a private agreement you didn't like, and as you didn't know the question had been raised, you might have been somewhat miffed.
On Mon, Dec 11, 2006 at 11:59:29AM -0500, David Cantrell wrote:
Agreed. I'd like the network configuration stage of anaconda to be supplemented with a screen before it that asks "Would you like to enable NetworkManager?" accompanied by a description of network manager and the
Hmmm. Does anaconda really need *more* questions?
anaconda-devel@lists.stg.fedoraproject.org