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 11-02-2008, 10:38 PM
Brian Pepple
 
Default FESCo Meeting Summary for 2008-10-29

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

== Summary ==
=== Features ===
* FESCo pushed the EFI(1) feature to F11, since it wasn't complete by
the devel freeze.
* FESCo approved Java Liveconnect(2) as a feature for F10, even though
it was submitted late. They felt this feature warranted giving an
exception to, since it's a feature that was created by in-house at
Fedora, and there was no open source solution that provided Liveconnect
support. NOTE: In the interest of being fair, FESCo will look at giving
the features that were dropped due to not meeting the feature freeze
deadline the same exception, providing they were completed by the devel
freeze.
1. https://fedoraproject.org/wiki/Features/EFI
2. http://fedoraproject.org/wiki/Features/Liveconnect

=== Elections ===
* Briefly discussed the dates (Dec. 7 - Dec 20) for the upcoming FESCo
election.

=== Comps ===
* FESCo brain-stormed for a bit on ways to improve comps. Some of the
ideas were:
* Having a Grand Arbitrator of Comps (notting's name was thrown as
a possible candidate)
* Use pkgdb to manage comps
* Making comps a MUST item in the package review.
* In the interim, notting will update the comps wiki page to better
clarify what should be included in comps, and FESCo will discuss some
more whether to make comps a MUST item in the review process.

IRC log can be found at:
http://bpepple.fedorapeople.org/fesco/FESCo-2008-10-29.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 11-02-2008, 11:13 PM
"Christopher Stone"
 
Default FESCo Meeting Summary for 2008-10-29

2008/11/2 Brian Pepple <bpepple@fedoraproject.org>:
> === Comps ===
> * FESCo brain-stormed for a bit on ways to improve comps. Some of the
> ideas were:
> * Having a Grand Arbitrator of Comps (notting's name was thrown as
> a possible candidate)
> * Use pkgdb to manage comps
> * Making comps a MUST item in the package review.
> * In the interim, notting will update the comps wiki page to better
> clarify what should be included in comps, and FESCo will discuss some
> more whether to make comps a MUST item in the review process.

All packages should go in comps. I don't know why notting is against
this?!!? Why should my php-pear-* packages be excluded from comps for
example? Just because some newb might not want to install them does
not mean a php web developer would not use comps to install them.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-02-2008, 11:54 PM
Matthew Miller
 
Default FESCo Meeting Summary for 2008-10-29

On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:
> All packages should go in comps. I don't know why notting is against
> this?!!? Why should my php-pear-* packages be excluded from comps for
> example? Just because some newb might not want to install them does
> not mean a php web developer would not use comps to install them.

If all packages are to go in comps, we need a more fine-grained comps.

--
Matthew Miller <mattdm@mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs
Computing & Information Technology
Harvard School of Engineering & Applied Sciences

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 12:00 AM
"Christopher Stone"
 
Default FESCo Meeting Summary for 2008-10-29

On Sun, Nov 2, 2008 at 4:54 PM, Matthew Miller <mattdm@mattdm.org> wrote:
> On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:
>> All packages should go in comps. I don't know why notting is against
>> this?!!? Why should my php-pear-* packages be excluded from comps for
>> example? Just because some newb might not want to install them does
>> not mean a php web developer would not use comps to install them.
>
> If all packages are to go in comps, we need a more fine-grained comps.

I concur.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 02:27 AM
Seth Vidal
 
Default FESCo Meeting Summary for 2008-10-29

On Sun, 2 Nov 2008, Christopher Stone wrote:


On Sun, Nov 2, 2008 at 4:54 PM, Matthew Miller <mattdm@mattdm.org> wrote:

On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:

All packages should go in comps. I don't know why notting is against
this?!!? Why should my php-pear-* packages be excluded from comps for
example? Just because some newb might not want to install them does
not mean a php web developer would not use comps to install them.


If all packages are to go in comps, we need a more fine-grained comps.


I concur.


more fine-grained how?

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 09:46 AM
Denis Leroy
 
Default FESCo Meeting Summary for 2008-10-29

Matthew Miller wrote:

On Sun, Nov 02, 2008 at 04:13:07PM -0800, Christopher Stone wrote:

All packages should go in comps. I don't know why notting is against
this?!!? Why should my php-pear-* packages be excluded from comps for
example? Just because some newb might not want to install them does
not mean a php web developer would not use comps to install them.


If all packages are to go in comps, we need a more fine-grained comps.


Comps evolved over time into something that doesn't make a whole bunch
of sense to me. Is the main use of comps still for installation groups
within yum and anaconda ? A lot of packages are not installation
"targets" but simply libraries that should only be installed by being
pulled in from dependency resolution. Now if we're trying to
"categorize" all packages nonetheless, it'd be better to have a
tag-based system from packagedb, where packages can be "tagged"
a-la-gmail, and also belong into multiple tag groups as some things

really belong into multiple categories...

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 09:58 AM
"Nicolas Mailhot"
 
Default FESCo Meeting Summary for 2008-10-29

Le Lun 3 novembre 2008 11:46, Denis Leroy a écrit :

> Comps evolved over time into something that doesn't make a whole bunch
> of sense to me. Is the main use of comps still for installation groups
> within yum and anaconda ? A lot of packages are not installation
> "targets" but simply libraries that should only be installed by being
> pulled in from dependency resolution. Now if we're trying to
> "categorize" all packages nonetheless, it'd be better to have a
> tag-based system from packagedb, where packages can be "tagged"
> a-la-gmail, and also belong into multiple tag groups as some things
> really belong into multiple categories...

This tag-based system still needs to have a human-editable file
deployment format since we do want third-party and private
repositories to be categorised and 'just install packagedb' won't ever
fly.

Right now this deployment format is comps.

I agree it is less than ideal, but so far no clear entity has stepped
up to make it evolve (and any evolution would need
anaconda/yum/packagedb/packagekit/spin-tools buy-in).

--
Nicolas Mailhot

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 02:28 PM
Matthew Miller
 
Default FESCo Meeting Summary for 2008-10-29

On Sun, Nov 02, 2008 at 10:27:05PM -0500, Seth Vidal wrote:
>>> If all packages are to go in comps, we need a more fine-grained comps.
>> I concur.
> more fine-grained how?

If comps ends up with a thousand programs under Games and Entertainment,
another thousand under Graphical Internet, etc., it's even more useless than
having nothing in comps at all. What would be the point? On the other hand,
having a thousand small comps groups is also no good.

--
Matthew Miller <mattdm@mattdm.org>
Senior Systems Architect
Cyberinfrastructure Labs
Computing & Information Technology
Harvard School of Engineering & Applied Sciences

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 02:43 PM
Toshio Kuratomi
 
Default FESCo Meeting Summary for 2008-10-29

Nicolas Mailhot wrote:
>
> Le Lun 3 novembre 2008 11:46, Denis Leroy a écrit :
>
>> Comps evolved over time into something that doesn't make a whole bunch
>> of sense to me. Is the main use of comps still for installation groups
>> within yum and anaconda ? A lot of packages are not installation
>> "targets" but simply libraries that should only be installed by being
>> pulled in from dependency resolution. Now if we're trying to
>> "categorize" all packages nonetheless, it'd be better to have a
>> tag-based system from packagedb, where packages can be "tagged"
>> a-la-gmail, and also belong into multiple tag groups as some things
>> really belong into multiple categories...
>
> This tag-based system still needs to have a human-editable file
> deployment format since we do want third-party and private
> repositories to be categorised and 'just install packagedb' won't ever
> fly.
>
> Right now this deployment format is comps.
>
> I agree it is less than ideal, but so far no clear entity has stepped
> up to make it evolve (and any evolution would need
> anaconda/yum/packagedb/packagekit/spin-tools buy-in).
>
+1

I think we should be storing tag information into the packagedb. But I
think it should be used to generate static files that are used in other
tools.

I'm leaning towards the idea that there should be separate files for the
installer and general use (so that the installer isn't sprinkled with
thousands of libraries but one could still use yum to search for "all
packages that have a 'python' 'library' to do 'ssl'").

Note that this requires quite a bit of work. The packagedb currently
operates on SRPMS-only. It should be easy to add built packages to the
data model but the whole infrastructure of populating that data,
displaying it, etc will need to be built. If someone would like to work
on it, I'd be very happy to help get you working with the codebase.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 02:48 PM
Seth Vidal
 
Default FESCo Meeting Summary for 2008-10-29

On Mon, 3 Nov 2008, Toshio Kuratomi wrote:


I think we should be storing tag information into the packagedb. But I
think it should be used to generate static files that are used in other
tools.

I'm leaning towards the idea that there should be separate files for the
installer and general use (so that the installer isn't sprinkled with
thousands of libraries but one could still use yum to search for "all
packages that have a 'python' 'library' to do 'ssl'").



We can add these to the items that yum already searches from a 'yum
search' fairly easily.




Note that this requires quite a bit of work. The packagedb currently
operates on SRPMS-only. It should be easy to add built packages to the
data model but the whole infrastructure of populating that data,
displaying it, etc will need to be built. If someone would like to work
on it, I'd be very happy to help get you working with the codebase.


The only trick I can think of is how to store this info so it is:
1. compact
2. not constantly being re-downloaded.
3. not irrationally over-tagged so you get waaaay too many matches.


-sv

--
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 12:25 PM.

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