FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 08-21-2008, 12:29 AM
Brian Pepple
 
Default FESCo Meeting Summary for 2008-08-20

=== Members Present ===
* Brian Pepple (bpepple)
* Kevin Fenzi (nirik)
* Josh Boyer (jwb)
* Karsten Hopp (kick_)
* Jarod Wilson (j-rod)
* Bill Nottingham (notting)
* David Woodhouse (dwmw2)

=== Members Absent ===
* Jon Stanley (jds2001)
* Dennis Gilmore (dgilmore)

== Summary ==
=== New Sponsor ===
* FESCo has approved the sponsor requests for Dan Horák.
* Note: any Fedora packager that wishes to become a sponsor, can
contact me or go directly to:
http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors

=== Features ===
* FESCo approved the following feature for F10:
* https://fedoraproject.org/wiki/Features/30SecondStartup
* https://fedoraproject.org/wiki/Features/SbinSanity
* https://fedoraproject.org/wiki/Features/VirtRemoteInstall
* https://fedoraproject.org/wiki/Features/VirtStorage
* https://fedoraproject.org/wiki/Features/TimeZoneAndLocation
They approved this feature, but did have a few questions they
wanted clarified.
* https://fedoraproject.org/wiki/Features/KernelModesetting
* https://fedoraproject.org/wiki/Features/NetBeans
* https://fedoraproject.org/wiki/Features/HDTVEnhancements

* FESCo voted against making the Prover(1) a feature, since they felt it
didn't meet the criteria(2) of being a new feature. Note: This isn't to
say that this isn't a good thing, but they felt the target audience was
fairly limited.
1. https://fedoraproject.org/wiki/Features/Provers
2. https://fedoraproject.org/wiki/Features/Policy/Definitions

* FESCo vote against making the Minimal Install(1) a feature, since it
appeared to be a wish list item since no one was working on it
presently.
1. https://fedoraproject.org/wiki/Features/MinimalInstall

* FESCo held off on approving the Online Account Service(1) feature,
since they had some questions regarding it.
1. https://fedoraproject.org/wiki/Features/OnlineAccountsService

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-08-20.html

Later,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-21-2008, 08:50 AM
"Richard W.M. Jones"
 
Default FESCo Meeting Summary for 2008-08-20

On Wed, Aug 20, 2008 at 08:29:12PM -0400, Brian Pepple wrote:
> * FESCo voted against making the Prover(1) a feature, since they felt it
> didn't meet the criteria(2) of being a new feature. Note: This isn't to
> say that this isn't a good thing, but they felt the target audience was
> fairly limited.
> 1. https://fedoraproject.org/wiki/Features/Provers
> 2. https://fedoraproject.org/wiki/Features/Policy/Definitions

It's very disappointing that this isn't considered a feature, largely
(so it seems from the IRC log) because the target audience is
considered "very limited".

Although provers are used only by a few experts to check that software
is correct, the benefits of using formally checked software
(functions, data structures, libraries, etc.) accrue to all users of
that software.

I hope that David & others working on this don't get discouraged and
this work continues, perhaps as a Fedora SIG.

Rich.

--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-21-2008, 01:09 PM
Karsten Hopp
 
Default FESCo Meeting Summary for 2008-08-20

Richard W.M. Jones schrieb:

On Wed, Aug 20, 2008 at 08:29:12PM -0400, Brian Pepple wrote:

* FESCo voted against making the Prover(1) a feature, since they felt it
didn't meet the criteria(2) of being a new feature. Note: This isn't to
say that this isn't a good thing, but they felt the target audience was
fairly limited.
1. https://fedoraproject.org/wiki/Features/Provers
2. https://fedoraproject.org/wiki/Features/Policy/Definitions


It's very disappointing that this isn't considered a feature, largely
(so it seems from the IRC log) because the target audience is
considered "very limited".

Although provers are used only by a few experts to check that software
is correct, the benefits of using formally checked software
(functions, data structures, libraries, etc.) accrue to all users of
that software.

I hope that David & others working on this don't get discouraged and
this work continues, perhaps as a Fedora SIG.

Rich.



+1, please don't get discouraged when FESCo rejects a feature proposal.
Rejecting something as a feature doesn't mean that the package isn't accepted
into fedora. It just means that it doesn't met the requirements described in
https://fedoraproject.org/wiki/Features/Policy/Definitions#Features.


Karsten

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-22-2008, 12:54 AM
"Alan Dunn"
 
Default FESCo Meeting Summary for 2008-08-20

As one of "others working on this", and having talked to David today,
I can assure you that this doesn't particularly change our plans one
way or another - you will continue to see more formal methods tools.
(Actually, I have a related package waiting for a CVS request, and
likely another automated theorem prover will be ready for review this
weekend or soon after.)

- Alan

On Thu, Aug 21, 2008 at 9:09 AM, Karsten Hopp <karsten@redhat.com> wrote:
> Richard W.M. Jones schrieb:
>>
>> On Wed, Aug 20, 2008 at 08:29:12PM -0400, Brian Pepple wrote:
>>>
>>> * FESCo voted against making the Prover(1) a feature, since they felt it
>>> didn't meet the criteria(2) of being a new feature. Note: This isn't to
>>> say that this isn't a good thing, but they felt the target audience was
>>> fairly limited.
>>> 1. https://fedoraproject.org/wiki/Features/Provers
>>> 2. https://fedoraproject.org/wiki/Features/Policy/Definitions
>>
>> It's very disappointing that this isn't considered a feature, largely
>> (so it seems from the IRC log) because the target audience is
>> considered "very limited".
>>
>> Although provers are used only by a few experts to check that software
>> is correct, the benefits of using formally checked software
>> (functions, data structures, libraries, etc.) accrue to all users of
>> that software.
>>
>> I hope that David & others working on this don't get discouraged and
>> this work continues, perhaps as a Fedora SIG.
>>
>> Rich.
>>
>
> +1, please don't get discouraged when FESCo rejects a feature proposal.
> Rejecting something as a feature doesn't mean that the package isn't
> accepted
> into fedora. It just means that it doesn't met the requirements described in
> https://fedoraproject.org/wiki/Features/Policy/Definitions#Features.
>
>
> Karsten
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-22-2008, 09:13 AM
Alex Lancaster
 
Default FESCo Meeting Summary for 2008-08-20

>>>>> "KH" == Karsten Hopp writes:

[...]

>> It's very disappointing that this isn't considered a feature,
>> largely (so it seems from the IRC log) because the target audience
>> is considered "very limited".

>> Although provers are used only by a few experts to check that
>> software is correct, the benefits of using formally checked
>> software (functions, data structures, libraries, etc.) accrue to
>> all users of that software.
>> I hope that David & others working on this don't get discouraged
>> and this work continues, perhaps as a Fedora SIG.
>> Rich.

KH> +1, please don't get discouraged when FESCo rejects a feature
KH> proposal.
KH> Rejecting something as a feature doesn't mean that the package
KH> isn't accepted into fedora. It just means that it doesn't met the
KH> requirements described in
KH> https://fedoraproject.org/wiki/Features/Policy/Definitions#Features.

Given FESCo's decision on this feature, I wonder how the Bioconductor
feature . which packages a set of bioinformatics R add-on packages
would fare:

http://fedoraproject.org/wiki/Features/Bioconductor

It's similar in spirit to Fedora Electronic Lab, although I don't have
any actual data, I suspect a slightly larger target audience than
Provers. I am helping Pierre-Yves (aka pingou) with this feature.

Alex

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-28-2008, 12:22 AM
Brian Pepple
 
Default FESCo Meeting Summary for 2008-08-20

=== Members Present ===
* Brian Pepple (bpepple)
* Kevin Fenzi (nirik)
* Jarod Wilson (j-rod)
* Bill Nottingham (notting)
* Jon Stanley (jds2001)
* Dennis Gilmore (dgilmore)

=== Absent ===
* Josh Boyer (jwb)
* Karsten Hopp (kick_)
* David Woodhouse (dwmw2)

== Summary ==
=== Fedora Packaging Committee Proposals ===
* FESCo had no objections to the proposals presented by the FPC.
https://www.redhat.com/archives/fedora-devel-list/2008-August/msg01206.html

=== Features ===
* FESCo approved the following feature for F10:
** https://fedoraproject.org/wiki/Features/OnlineAccountsService

=== F10 Schedule ===
* FESCo approved a proposal from Release Engineering (rel-eng) to delay
F10 by three weeks. The revised schedule can be found here:
http://poelstra.fedorapeople.org/schedules/f-10/f-10-three-week-change.html

=== Signing and Pushing New Keys ===
* Long discussion on how to handle the package key migration for users.
FESCo ended up approving Warren's proposal, which can be found here:
http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001622.html
* NOTE: Once this is implemented we can start issuing updates again,
which I think is what most people are interested in hearing about.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-08-27.html

Later,
/B
--
Brian Pepple <bpepple@fedoraproject.org>

https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-28-2008, 12:38 AM
Toshio Kuratomi
 
Default FESCo Meeting Summary for 2008-08-20

Alex Lancaster wrote:

"KH" == Karsten Hopp writes:


[...]


It's very disappointing that this isn't considered a feature,
largely (so it seems from the IRC log) because the target audience
is considered "very limited".



Although provers are used only by a few experts to check that
software is correct, the benefits of using formally checked
software (functions, data structures, libraries, etc.) accrue to
all users of that software.
I hope that David & others working on this don't get discouraged
and this work continues, perhaps as a Fedora SIG.
Rich.


KH> +1, please don't get discouraged when FESCo rejects a feature
KH> proposal.
KH> Rejecting something as a feature doesn't mean that the package
KH> isn't accepted into fedora. It just means that it doesn't met the
KH> requirements described in
KH> https://fedoraproject.org/wiki/Features/Policy/Definitions#Features.

Given FESCo's decision on this feature, I wonder how the Bioconductor
feature . which packages a set of bioinformatics R add-on packages
would fare:

http://fedoraproject.org/wiki/Features/Bioconductor

It's similar in spirit to Fedora Electronic Lab, although I don't have
any actual data, I suspect a slightly larger target audience than
Provers. I am helping Pierre-Yves (aka pingou) with this feature.


You have to show why it's a feature.

* What work is Fedora doing to make this happen as opposed to merely
packaging work done upstream?

* What makes the Feature more than a collection of packages?
* What kind of coherent plan is being laid out by the people driving this?
* Show how the Feature could be presented in the F10 release notes to
higlight the work that Fedora has done.
* Do the people working on the Feature care enough to show up and argue
their case at the meeting?

* Remember to update your Feature page with all of your arguements.

python-nss was voted a feature in the end while provers were not. I
happen to think this was mostly because that python-nss got better
marketing than provers (which, to be fair, is what both of them wanted
out of being an F-10 feature. If the marketing left FESCo wondering why
it was a Feature it would also leave our end-users wondering why it was
a Feature.)


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-28-2008, 02:05 PM
Richard Hughes
 
Default FESCo Meeting Summary for 2008-08-20

On Wed, 2008-08-27 at 20:22 -0400, Brian Pepple wrote:
> === Signing and Pushing New Keys ===
> * Long discussion on how to handle the package key migration for users.
> FESCo ended up approving Warren's proposal, which can be found here:
> http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001622.html
> * NOTE: Once this is implemented we can start issuing updates again,
> which I think is what most people are interested in hearing about.

Might have been nice for someone to ping me if you guys were talking
about PackageKit.

> > wwoodsf13: yeah, it's weaksauce, but you remember the failure
> > condition for PK was *SO BAD* that we added last-minute horrible
> > hacks to anaconda over jeremy's (valid) objections

I guess by hacks you meant that I wanted anaconda to auto-import the
fedora signing key at install time.

To be blunt, if the media is compromised, then unsigned updates are the
_last_ of your problems -- think what would happen if a compromised
kernel or sshd was installed - a remote exploit without even installing
a single update.

The only way you can guarantee the authenticity of the media is to post
it's sha1sum in a well known place that we test the image against -
which is basically what we do now.

Asking the user to agree that key abcdef12345 corresponds to the fedora
project at first boot is just security through obscurity. Ubuntu and
other distributions don't make you do this.

> > dgilmore: pk is an ugly mess

I assume you filed bugs, or were you just interested in mud-throwing? I
would prefer if you talked to me about any issues or concerns you had --
comments like that really do not show professionalism.

Thanks.

Richard.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-28-2008, 03:52 PM
Toshio Kuratomi
 
Default FESCo Meeting Summary for 2008-08-20

Richard Hughes wrote:

wwoodsf13: yeah, it's weaksauce, but you remember the failure
condition for PK was *SO BAD* that we added last-minute horrible
hacks to anaconda over jeremy's (valid) objections


I guess by hacks you meant that I wanted anaconda to auto-import the
fedora signing key at install time.

To be blunt, if the media is compromised, then unsigned updates are the
_last_ of your problems -- think what would happen if a compromised
kernel or sshd was installed - a remote exploit without even installing
a single update.

The only way you can guarantee the authenticity of the media is to post
it's sha1sum in a well known place that we test the image against -
which is basically what we do now.

Asking the user to agree that key abcdef12345 corresponds to the fedora
project at first boot is just security through obscurity. Ubuntu and
other distributions don't make you do this.

I can't speak to the other stuff that people were saying but this one
actually is a problem in the current situation. In this situation we
trust the media but don't trust the signing key that's on the media. We
need to get the new key installed and the old key uninstalled (probably
going to be dealt with as a separate problem) so that we can verify updates.


-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 08-28-2008, 05:00 PM
Will Woods
 
Default FESCo Meeting Summary for 2008-08-20

On Thu, 2008-08-28 at 15:05 +0100, Richard Hughes wrote:
> On Wed, 2008-08-27 at 20:22 -0400, Brian Pepple wrote:
> > === Signing and Pushing New Keys ===
> > * Long discussion on how to handle the package key migration for users.
> > FESCo ended up approving Warren's proposal, which can be found here:
> > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001622.html
> > * NOTE: Once this is implemented we can start issuing updates again,
> > which I think is what most people are interested in hearing about.
>
> Might have been nice for someone to ping me if you guys were talking
> about PackageKit.

I guess? At this point it's all a solved problem - the key import
mechanism in *current* PK is fine. It's just the version from original
F9 that was problematic.

> > > <wwoods> f13: yeah, it's weaksauce, but you remember the failure
> > > condition for PK was *SO BAD* that we added last-minute horrible
> > > hacks to anaconda over jeremy's (valid) objections
>
> I guess by hacks you meant that I wanted anaconda to auto-import the
> fedora signing key at install time.

That's what I was referring to, yes. I agree with the principle of
importing the signing keys at install-time. I just wish we could have
had time to discuss it and choose a solution (and implementation)
agreeable to all.

So: I used the phrase "horrible hacks" because we had scant *hours* to
find and implement the simplest possible workaround, rather than
actually discussing the problem and fixing as we normally do.

-w
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 08:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org