separate emails to fedora-legacy-announce for each OS

[Eric Rostetter]

Quoting Joe Harrington <jh at oobleck.astro.cornell.edu>:

> > 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