Quoting Joe Harrington <jh@xxxxxxxxxxxxxxxxxxxxxxxxx>: > > They have the same format as the Red Hat Linux and Red Hat Enterprise > > Linux announcements instead, no? > > > * Most other distros do it our way (only Fedora Project differs that I know > > of, though there are probably others). > > Perhaps. My point is one of utility, not compatibility. I was > pointing out that FP does it this way to show what I like, not to > raise a compatibility point. Understood, but you asked for other's opinions, so you got it. > However, there is a compatibility point, now that you mention it. > People using this service are coming off of FP, not off some other > distro. At this time, subject to change in the future, most people in FLP are still using RHL versions, and hence they are used to this format from Red Hat, and not the Fedora Project format. So your point isn't technically correct yet, for the current community. This will change over time as RHL machines drop, and more FC users join the FLP. > It would be good to keep the same form of communication, > particularly where some people use automated means to process the > information. Matthew Miller mentioned to me that he also processes > those messages with scripts. As do I. But I use scripts which process the Red Hat version, not the Fedora Project version. This is probably because I run about 100 RHL machines, and 0 FC machines. ;) > If you are referring to people working on the project, I can see the > need for response/attention in under a day. For people using the > service in its recommended form (i.e., nightly yum updates), the > advisories are not so urgent, assuming their update systems are > working. The FLP does not recommend night yum updates via cron, which is what I think you are recommending here. Is this the recommendation of the Fedora Project? Red Hat and FLP both recommend you read the advisory notice *before* you install the update, as the advisory notice might have critical information in it about the update (installation order, problems with the installation you can expect, additional steps needed to complete the updates, etc). > > I don't like it, for the following reasons: > > > * More work for the people cutting updates (unless they can automate this > > more for the future) > > * More work for me (I update the advisories on the web site from the > e-mails > > sent to the announce list) > > These show a developer's point of view, not a user's (though on a > volunteer project with limited resources, it may be defensible to put > developers' needs over users'). It depends on the user. If the user assumes that he wants the updates out as soon as possible (since they are security updates), then he would not want to make more work for the people cutting the updates as that would slow them down. Okay, I conceed my second one is only more work for me, and the user probably doesn't care squat about the web page in most cases. You have me there. > > * Too many e-mails (and sometimes digest formats just aren't desirable). > > As a user, you'd like to be able to filter out the ones that are for > you, and preferably also check that you got the updates in an > automated way (by the way, I said in my post that I'd attach the > script and didn't, so see below). As a user, I very often want to know: 1) Whether an update *doesn't* apply to me. So I want to get all the updates, read them, and *know* that it doesn't apply to me. So if my boss, wife, who ever asks me "did you install the latest XYZ update?" or "should I install the latest XYZ update?" or "Why didn't you install the latest XYZ update?" or what ever, I can say with confidence "I researched the issue and that vulnerability doesn't apply in our case." > Jesse Keating said that the emails are sent automatically, written by > Python scripts. Yes, but the people who write them have, just recently, counterdicted him and said they all produce them by hand. Unless this has changed, then Jesse is wrong. So I'm not 100% sure of the story right now, but I think they are still done by hand. > It wouldn't be too outrageous to grab the scripts > from FP and have them post to a second list (or even a list per > release). I'm not against a separate list for individual notices. I just don't want to change the current list. I'm not sure Red Hat would let us set up a (more or less) infinite number of mailing lists though (one for each new release). And I'm not sure having two announce lists (one with individual and one with combined) wouldn't be more confusing than helpful. But I'm open to further discussion. > People would be able to subscribe to either and everyone > would be happy. My impression is that these scripts should not be > hard to maintain, particularly if you're grabbing one set from FP > rather than writing them yourselves. We can discuss this further, preferably with the input from those who create/maintain the scripts, and those who cut the updates/releases. > --jh-- -- Eric Rostetter -- fedora-legacy-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-legacy-list
