On Wed, 2006-05-17 at 11:01 -0500, Eric Rostetter wrote:
>
> As can be seen in the sendmail upgrade, lots of other things (alternatives,
> pam, etc) can come into play that are not immediately obvious.
>
Right, thinks like sendmail are hard. Things like gaim, or evince, or
other top level appli
Quoting James Kosin <[EMAIL PROTECTED]>:
not to start any kind of flame war, but just for accuracy's sake,
the recent sendmail release *was* tested before public release - i
Yes, but IMHO not enough, but that is totally another matter.
that may say that our required testing is insufficient;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Yates wrote:
> On Mon, 15 May 2006, James Kosin wrote:
>
>> I agree with Jesse here; but, I would like to add that the
>> packages should be tested on the released platform by someone and
>> not just released in this case. SendMail was a recent bl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> 1, 2, and 3, are totally great points for backport vs upgrade. I
> don't even begin to think that upgrading is a better solution.
> However I'm going for consistency with what our 'upstream' is
> doing. The Fedora project doesn
On 5/16/06, James Kosin <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> So in the RHL space, the choice was clear. Backport whenever possible.
> However the Fedora landscape is different. "Upstream" Core does not do
> backporting, they more often
On Tue, 2006-05-16 at 10:06 -0400, James Kosin wrote:
> -James
1, 2, and 3, are totally great points for backport vs upgrade. I don't
even begin to think that upgrading is a better solution. However I'm
going for consistency with what our 'upstream' is doing. The Fedora
project doesn't backport
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> So in the RHL space, the choice was clear. Backport whenever possible.
> However the Fedora landscape is different. "Upstream" Core does not do
> backporting, they more often than not version upgrade to resolve
> security issu
Quoting Michal Jaegermann <[EMAIL PROTECTED]>:
I never tried to imply that automatic "version chase" is a good
thing, and is definitely bad in case of libraries, but there are
situations when you simply do not have a choice. Avoiding security
updates because you do not want to change versions is
On Tue, 2006-05-16 at 02:38 +0200, Nils Breunese (Lemonbit Internet)
wrote:
>
> Maybe the front page of fedoralegacy.org should be changed as well
> then. It currently reads: "(...) The goal of The Fedora Legacy
> Project is to work with the Linux community to provide security and
> critical
Jesse Keating wrote:
On Mon, 2006-05-15 at 16:12 -0500, Eric Rostetter wrote:
You can though think it does make sense to change the handling
because
it is EOL, independent of who is touching it. EOL means end of
development
which means end of upgrades, at least to some.
Can we agree to n
On Mon, May 15, 2006 at 04:16:59PM -0500, Eric Rostetter wrote:
>
> Think about all the problems we would have if we upgraded from PHP 4.x
> to PHP 5.x. Man, that would be a nightmare for the users...
I never tried to imply that automatic "version chase" is a good
thing, and is definitely bad in
Quoting Stephen John Smoogen <[EMAIL PROTECTED]>:
On 5/15/06, Eric Rostetter <[EMAIL PROTECTED]> wrote:
Quoting Stephen John Smoogen <[EMAIL PROTECTED]>:
Third, how expert are you (the patcher) on what the vulnerability is,
what the code is, and how you are 'stopping' the vulnerability from
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> And follow upstream example if possible. If "upstream" Fedora
> upgrades to fix an issue, we probably should to for the Fedora's
> we're supporting (shouldn't be more than 2 after this next
> transition), but if they decide to
On Mon, 2006-05-15 at 16:12 -0500, Eric Rostetter wrote:
> You can though think it does make sense to change the handling because
> it is EOL, independent of who is touching it. EOL means end of development
> which means end of upgrades, at least to some.
Can we agree to not use the term EOL in t
On 5/15/06, Eric Rostetter <[EMAIL PROTECTED]> wrote:
Quoting Jesse Keating <[EMAIL PROTECTED]>:
> Sure, for RHL it is about stability. But with FC it was more about
> extending the lifespan. And to me, it really doesn't make sense to
> change the way in which the Fedora Project treats a relea
Quoting Michal Jaegermann <[EMAIL PROTECTED]>:
On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote:
Depends on what transparent means. If you want to be transparent in the
sense of not breaking people's working machines, then no, you should
backport.
When people intimately famili
On 5/15/06, Eric Rostetter <[EMAIL PROTECTED]> wrote:
Quoting Stephen John Smoogen <[EMAIL PROTECTED]>:
> Third, how expert are you (the patcher) on what the vulnerability is,
> what the code is, and how you are 'stopping' the vulnerability from
> being there.
I'm not sure that should come i
Quoting Jesse Keating <[EMAIL PROTECTED]>:
Sure, for RHL it is about stability. But with FC it was more about
extending the lifespan. And to me, it really doesn't make sense to
change the way in which the Fedora Project treats a release just because
a different set of folks are touching it.
Quoting Stephen John Smoogen <[EMAIL PROTECTED]>:
I think that we should try and take some reasonable goals for
timelines for security:
I don't think we have the man-power to set goals for all patches.
But we should and do use the timeliness criterium for whether to
backport or upgrade already
On Mon, 2006-05-15 at 16:40 -0400, Marc Deslauriers wrote:
> I'd say let's try and use backports, and use upgrades if it's the most
> logical solution.
>
And follow upstream example if possible. If "upstream" Fedora upgrades
to fix an issue, we probably should to for the Fedora's we're supportin
On Mon, 2006-05-15 at 16:16 -0400, Jesse Keating wrote:
> On Mon, 2006-05-15 at 16:14 -0400, Marc Deslauriers wrote:
> >
> > Every time we've decided to upgrade a package instead of backporting
> > security fixes, we've broken other stuff and have had to work twice as
> > hard to get things back i
On Mon, 2006-05-15 at 13:29 -0700, David Rees wrote:
> This seems like a sane policy to me!
Honestly, I think this is the model that "upstream" fedora uses too.
--
Jesse Keating RHCE (geek.j2solutions.net)
Fedora Legacy Team (www.fedoralegacy.org)
GPG Public Key (geek.j2soluti
On 5/15/06, Pekka Savola <[EMAIL PROTECTED]> wrote:
My opinion here is: do whichever is the easiest. In some cases, doing
a backport may be easier than upgrade [*]. One should also look at
the approach chosen by other Fedora Core/RHEL releases. Other things
being equal, prefer backporting.
Th
On Mon, 2006-05-15 at 16:14 -0400, Marc Deslauriers wrote:
>
> Every time we've decided to upgrade a package instead of backporting
> security fixes, we've broken other stuff and have had to work twice as
> hard to get things back into working order.
>
> I don't think we have the resources to upg
On Mon, 2006-05-15 at 15:20 -0400, Jesse Keating wrote:
> So in the RHL space, the choice was clear. Backport whenever possible.
> However the Fedora landscape is different. "Upstream" Core does not do
> backporting, they more often than not version upgrade to resolve
> security issues. Why shou
On Mon, May 15, 2006 at 02:29:03PM -0500, Eric Rostetter wrote:
>
> Depends on what transparent means. If you want to be transparent in the
> sense of not breaking people's working machines, then no, you should
> backport.
When people intimately familiar with a given code, because they
authored
On Mon, 2006-05-15 at 15:53 -0400, Tres Seaver wrote:
> -1 to preferring upgrades. FL is about 'stability', which is an
> explicit non-goal for FC. Except in cases where a backport is more
> likely to create instability than an upgrade, we should prefer
> backporting.
>
Sure, for RHL it is abou
On 5/15/06, Jesse Keating <[EMAIL PROTECTED]> wrote:
So in the RHL space, the choice was clear. Backport whenever possible.
However the Fedora landscape is different. "Upstream" Core does not do
backporting, they more often than not version upgrade to resolve
security issues. Why should Legacy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jesse Keating wrote:
> So in the RHL space, the choice was clear. Backport whenever possible.
> However the Fedora landscape is different. "Upstream" Core does not do
> backporting, they more often than not version upgrade to resolve
> security issue
On 5/15/06, Eric Rostetter <[EMAIL PROTECTED]> wrote:
Quoting Jesse Keating <[EMAIL PROTECTED]>:
> If we want to be
> transparent to end users we should follow what "upstream" does.
Depends on what transparent means. If you want to be transparent in the
sense of not breaking people's working ma
On Mon, 15 May 2006, Jesse Keating wrote:
So in the RHL space, the choice was clear. Backport whenever possible.
However the Fedora landscape is different. "Upstream" Core does not do
backporting, they more often than not version upgrade to resolve
security issues. Why should Legacy be any dif
Quoting Jesse Keating <[EMAIL PROTECTED]>:
So in the RHL space, the choice was clear. Backport whenever possible.
True.
However the Fedora landscape is different. "Upstream" Core does not do
backporting, they more often than not version upgrade to resolve
security issues. Why should Legac
So in the RHL space, the choice was clear. Backport whenever possible.
However the Fedora landscape is different. "Upstream" Core does not do
backporting, they more often than not version upgrade to resolve
security issues. Why should Legacy be any different? If we want to be
transparent to end
33 matches
Mail list logo
