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-03-2008, 02:36 PM
Seth Vidal
 
Default Comps/groups/tags-concepts

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.



So we're in the same boat if we start 'tagging' packages and/or if we just
group them (which is essentially tagging from the other direction).



Let's take a step back. How do we group several thousand things such that
they don't make the avg user lose his/her mind to look at them.


do we need groups of groups? A tree hierarchy the user can drill through?
Font-sized tags like flickr/bloggers, etc?


I'm open to ideas, really.


-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 02:54 PM
Matthew Miller
 
Default Comps/groups/tags-concepts

On Mon, Nov 03, 2008 at 10:36:53AM -0500, Seth Vidal wrote:
> Let's take a step back. How do we group several thousand things such that
> they don't make the avg user lose his/her mind to look at them.
> do we need groups of groups? A tree hierarchy the user can drill through?
> Font-sized tags like flickr/bloggers, etc?
> I'm open to ideas, really.

Me too. I'm just raising the notion that we need the shed painted. This
time, I don't care what color it is.

--
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:56 PM
"Nicolas Mailhot"
 
Default Comps/groups/tags-concepts

Le Lun 3 novembre 2008 16:36, Seth Vidal a écrit :
>
>>
>> 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.
>>
>
> So we're in the same boat if we start 'tagging' packages and/or if we
> just
> group them (which is essentially tagging from the other direction).
>
>
> Let's take a step back. How do we group several thousand things such
> that
> they don't make the avg user lose his/her mind to look at them.
>
> do we need groups of groups? A tree hierarchy the user can drill
> through?
> Font-sized tags like flickr/bloggers, etc?
>
> I'm open to ideas, really.

Also:
- Hierarchical or tag-oriented classification ?
- Relationship between classification and spins/repositories/tasks?
- Single view of available repositories or multiple simplified
(task-oriented? spin-oriented?) views?
- Should we build those views from a single classification or can we
afford to maintain different classification efforts per spin?
- How are we going to merge classification from different repositories?
- What is the classification workflow for Fedora? For
third-party/private repositories without pkgdb access?
- Do we need the comps mandatory/default/optional tristate or
something else?
- How do we scale from a three-package private repository to a
Fedora-everything repository?
- Do we need to manipulate packages? Package groups? Something else?
- Do we need multilevel inheritance? (group A is in group B which is
in group C, etc)
- What is the right file format. XML, something else?
- How can a classification file/set of files be audited for syntax
errors (preferably in automated way)
- i18n needs?
- CLI tool needs?
- GUI tools needs?

There are lots of questions. Short term just putting everything into
comps is the way to go but for mid-term to happen it should start
soonish.

Regards,

--
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:59 PM
Seth Vidal
 
Default Comps/groups/tags-concepts

On Mon, 3 Nov 2008, Matthew Miller wrote:


On Mon, Nov 03, 2008 at 10:36:53AM -0500, Seth Vidal wrote:

Let's take a step back. How do we group several thousand things such that
they don't make the avg user lose his/her mind to look at them.
do we need groups of groups? A tree hierarchy the user can drill through?
Font-sized tags like flickr/bloggers, etc?
I'm open to ideas, really.


Me too. I'm just raising the notion that we need the shed painted. This
time, I don't care what color it is.



A couple of simple ideas:
tagging a-la flickr. If we key it on pkg name, we can keep the metadata
from changing a lot. We could do a pre-made sqlite db, for example, and
keep querying simple.


But let's say an average of 5 tags per pkg name at 7000 pkgs ends up being
35000 tags. Searching shouldn't be ridiculously hard and having a table
that maps the other way tag->pkg shouldn't be too bad, either.


Toshio, any thoughts on if that's enough info?

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 03:06 PM
Toshio Kuratomi
 
Default Comps/groups/tags-concepts

Seth Vidal wrote:
>>
>> 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.
>>
>
> So we're in the same boat if we start 'tagging' packages and/or if we
> just group them (which is essentially tagging from the other direction).
>
>
> Let's take a step back. How do we group several thousand things such
> that they don't make the avg user lose his/her mind to look at them.
>
> do we need groups of groups? A tree hierarchy the user can drill
> through? Font-sized tags like flickr/bloggers, etc?
>
> I'm open to ideas, really.
>
When I see the group word applied to packages it's almost always a
single group per package usage. Having multiple tags per package would
allow the user to narrow their browsing like this:

tags: games 1000 entries - (action, strategy, cards, boardgame, rpg,
[...]).
tags: games, strategy - 276 entries (wargame, cards, no others, rpg,
[...])
tags: games, strategy, cards - 17 entries (no others, wargame)
Only tags: games, strategy, card - 15 entries ()
Browse results

font-sized tags are a good idea in this context but not applicable to
the commandline. Ordering of the possible tags to intersect with by
popularity is an approximation of this.

A tree hierarchy has good qualities compared to the comps groups that we
have now but I think that intersecting tags have most of the advantages
of a more rigid group.

Rigid groups do have the feature of growing at a more leisurely pace
whereas tags are somewhat of a free for all where more tags are usually
better. (May be important if we're trying to stuff all of the
catagorization information into repo metadata to download.)

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 03:07 PM
Les Mikesell
 
Default Comps/groups/tags-concepts

Seth Vidal wrote:


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.



So we're in the same boat if we start 'tagging' packages and/or if we
just group them (which is essentially tagging from the other direction).



Let's take a step back. How do we group several thousand things such
that they don't make the avg user lose his/her mind to look at them.


do we need groups of groups? A tree hierarchy the user can drill
through? Font-sized tags like flickr/bloggers, etc?


I'm open to ideas, really.


The thing I've always wanted is:

Duplicate the installed packages on this other, existing machine
with options as to whether you want the same package versions or the
currnt versions.


And done in a way where the existing machine publishes it's list so the
person installing just picks the example instead of wading through the
thousands of packages every time.


Bonus points for installing from the same repositories as the original
packages...


This could replace the concept of 'spins' with a minimal install and a
command that says 'make it like that one' that someone with some
expertise has configured for a similar purpose.


--
Les Mikesell
lesmikesell@gmail.com

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 03:11 PM
Seth Vidal
 
Default Comps/groups/tags-concepts

The thing I've always wanted is:

Duplicate the installed packages on this other, existing machine
with options as to whether you want the same package versions or the currnt
versions.


And done in a way where the existing machine publishes it's list so the
person installing just picks the example instead of wading through the
thousands of packages every time.


Bonus points for installing from the same repositories as the original
packages...


This could replace the concept of 'spins' with a minimal install and a
command that says 'make it like that one' that someone with some expertise
has configured for a similar purpose.




That's really off-subject, though. That's something you do WITH the
metadata, not how to format the metadata to begin with.


And the above is doable as things are now, it's just not been written.

Tag-based viewing isn't doable now.

-sv


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 03:14 PM
Seth Vidal
 
Default Comps/groups/tags-concepts

On Mon, 3 Nov 2008, Toshio Kuratomi wrote:


When I see the group word applied to packages it's almost always a
single group per package usage. Having multiple tags per package would
allow the user to narrow their browsing like this:

tags: games 1000 entries - (action, strategy, cards, boardgame, rpg,
[...]).
tags: games, strategy - 276 entries (wargame, cards, no others, rpg,
[...])
tags: games, strategy, cards - 17 entries (no others, wargame)
Only tags: games, strategy, card - 15 entries ()
Browse results

font-sized tags are a good idea in this context but not applicable to
the commandline. Ordering of the possible tags to intersect with by
popularity is an approximation of this.




A tree hierarchy has good qualities compared to the comps groups that we
have now but I think that intersecting tags have most of the advantages
of a more rigid group.


A tree hierarchy + font/ordered tags might make sense for delving through
all the pkgs. For example


You see a page like:

Games, Utilities, System, Mail, WebServices, Development, etc

Then you click on Games and it expands out the tags sorted or fonted by
most common tag, etc (not including games) in that group. So you create
implicit subgroups by going to what you want most.



That should be relatively easy to do, I think.

-sv

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 03:18 PM
Toshio Kuratomi
 
Default Comps/groups/tags-concepts

Seth Vidal wrote:
>
> A couple of simple ideas:
> tagging a-la flickr. If we key it on pkg name, we can keep the metadata
> from changing a lot. We could do a pre-made sqlite db, for example, and
> keep querying simple.
>
> But let's say an average of 5 tags per pkg name at 7000 pkgs ends up
> being 35000 tags. Searching shouldn't be ridiculously hard and having a
> table that maps the other way tag->pkg shouldn't be too bad, either.
>
> Toshio, any thoughts on if that's enough info?
>
That should be enough to create the UI I was thinking of.

My main question would be, do we want this to be wholly separate from
comps or to integrate somehow? If it's separate then we can implement
this and the feature is ready to go. If it's integrated then Nicolas
Mailhot's questions become important to answer.

-Toshio

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 11-03-2008, 03:26 PM
Seth Vidal
 
Default Comps/groups/tags-concepts

On Mon, 3 Nov 2008, Toshio Kuratomi wrote:


Seth Vidal wrote:


A couple of simple ideas:
tagging a-la flickr. If we key it on pkg name, we can keep the metadata
from changing a lot. We could do a pre-made sqlite db, for example, and
keep querying simple.

But let's say an average of 5 tags per pkg name at 7000 pkgs ends up
being 35000 tags. Searching shouldn't be ridiculously hard and having a
table that maps the other way tag->pkg shouldn't be too bad, either.

Toshio, any thoughts on if that's enough info?


That should be enough to create the UI I was thinking of.

My main question would be, do we want this to be wholly separate from
comps or to integrate somehow? If it's separate then we can implement
this and the feature is ready to go. If it's integrated then Nicolas
Mailhot's questions become important to answer.



I think we do POC on its own and then figure out if:
1. it should be merged into comps
or
2. comps should be merged to it
or
3. if all group selection should be redone to match up with a tag-based
pseudo-hierarchy.


-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 01:48 PM.

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