Team,
In the last meeting, we discussed experimenting with the meeting order.
I've come up with a first draft for our next meeting
(http://en.opensuse.org/GNOME/Meetings/20071018).
Please review and let me know what you think.
Cheers,
Magnus
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Meetings:
* Target audience:
- We discuss both hardcore dev issues as well as "soft" issues, so to make it
easier for everyone, hardcore stuff will be discussed last.
* Meeting formats:
- Will experiment with different formats to allow more participation
- Will try cut&paste panned intro
*** AI - experiment with meeting theming (captain_magnus)
*** AI - experiment with order in meetings (captain_magnus)
* Length & frequency of meetings:
- Keep weekly meetings, but limit to 45 mins/1 hour, although will use time as
needed for the time being
- Rotate times for getting people from Asia
*** AI - experiment with limited time for individual items (JP)
*** AI - review meeting formats in 3 more items (JP)
Bug squashing:
- Need to deal with GNOME bugs for old opensuse versions.
- Move all bugs that are still seen in <= 10.3 to 11.0 unless it's critical
*** AI - organize bug squashing (mtgordon)
Packaging policy:
- G:Community policy still blocked on packaging guidelines
- http://en.opensuse.org/GNOME/Community_Inclusion_Policy
*** AI - figure out where wishlist items live in the feature process (JP, captain_magnus, cyberorg)
Feature requests & mini-projects:
- Only discussion, still no access to FATE for external people
- http://en.opensuse.org/GNOME/FeaturePlanning
*** AI - Create a 11.0 features wish list page
Task review:
- GM live CDs need to be tested
- G:STABLE is now up-to-date but still does not compile due to BS bug
- Glossary not started yet
Q&A:
- Need more feedback about bug plan before starting on 'debugging topics'
- Need a due date column on our tasks list
- Create an icalendar for tasks with alarms
- Obsolete orphan pages in the wiki
- Will evaluate PackageKit for package manager
- Lots of improvements needed in yast-gtk package manager
--
Rodrigo Moya <rodrigo(a)novell.com>
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Folks,
I just started to look at the AI's from the last meeting, and realized
that I'm not 100% clear what we meant with "Theming".
Theming is simply adding a specific Topic to be discussed in that
meeting or Theming is a topic that runs throughout the meeting.
If someone could clarify this to me, then I can get on with my AI's :-)
Cheers,
Captain Meeting
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
On Fri, 2007-10-12 at 15:45 +0100, Ricardo Cruz wrote:
> The mockup looks great, thanks. Christian Jäger also suggested the use
> of icons. However, I am afraid we can only hack that for installed
> software.
> Zypp downloads a file from the repos that has some informations about
> the packages (names, descriptions, ...), but it doesn't have an inlined
> icon -- it doesn't even have all the RPM header info. We would need to
> download the entire package to extract that information.
> What we can do, for the available packages, is to use the icon of the
> group they belong to. E.g. for bombermaze, I guess the games/action.
>
# I could imagine a stacked icon retrieval algo.; top to bottom:
- Use the "icon" property supplied by package tag from zypper/metadata
(described below)
- Use GNOME icon lookup interface with specific package name
- Package Category's icon (Icon naming spec gives us appropriate icons)
- Use generic icon for application/x-rpm
Of course the biggest challenge are icons for not installed packages.
An idea to solve this...
# Get icon metadata from packager up to the software stack:
- .spec files allow "Icon:" tags, let's put them to use to specify an
icon name for a package
- Generated repository metadata gets "icon" attribute which is read from
the .spec file
- Zypper gets "icon" attribute support in the API
- Packagemanager is able to use/read the "icon" information (which now
comes all the way from the .spec file) and use it in the icon lookup
process
While this would add the ability for packagers to specify an "Icon:" tag
with a name according to the icon naming spec and thus at least already
gain a good set of icons to use, it still would not work for completely
custom icons.
# External icons
Here, we would require to get those from some place in the internets.
I think one solution would be to extend the "Icon:" tag to be able to
specify names, filenames and URLs so the build process might pull the
appropriate images into the final repository (probably the repodata/ or
src/ directory renamed according to the package).
If the icons are put in some directory in the repository they could be
accessible from the createrepo generated html pages, from within the
build service's package listings or even some supergeeky AJAX frontend
(oh, like http://software.opensuse.org/search/)
Again, just an idea and for sure needs a final specification to become
reality.
> We already have exchanged some ideas privately about the interface. You
> guys can start a public discussion, if you wish. We'll certainly listen
> to the feedback. Maybe during next week I can start working on it;
> before changing the interface, I will want to re-work the code to
> support for this, which can take more time.
>
> Some stuff we need:
> * support for filters. Besides the name search, we need filtering based
> on statuses and repositories. Would be great if they could be used
> together. Maybe have a left pane for them, hiding them with expanders by
> default (the search would always be visible of course).
>
I think as soon as filters are added the two pane package management
becomes obsolete in my eyes. No doubt they are needed and to be hidden
by default for less than rookie users.
> * browse. Whenever the user wants to check out what other word processor
> (to give an example) are available, browsing is more reliable than
> search, that can miss something. So, browse should really be a first
> class citizen. Maybe we could have it together with search, on the
> filters pane, though it makes only sense for packages. Anyway, we
> probably want something external like yast-qt has, because it gives more
> flexibility to the user to list all Server Programs, without having to
> go through all nodes. And we really need icons for the browser, to make
> it easier to navigate.
>
Browsing wins. ;)
Perhaps the optimal useability might be achieved with making the package
selection "filebrowser" like. Folders are categories/patterns/languages
and files correspond to packages.
> * dedicated interface for upgrading. We need to give the user more
> information on the upgrades (and downgrades) available. A nice extra
> could be doing a diff between the installed ChangeLog and the available
> one, so the user can check easily what's new. (they aren't very nice).
> Maybe an extra Upgrade tab page (or Version) should be available when a
> package has multiple versions.
That would be nice.
Anyways, keep up the great work.
--- Martin
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Hello all,
It's easy to get lost during a meeting unless you know what's being
discussed in more detail. An easy way to rectify this would be to add
URL's for each subject that will be discussed. I propose that we do
something like my "mockup" for our agenda;
http://en.opensuse.org/User:MBoman#Mockup_for_GNOME_Meeting_Agenda
Good? Bad?
Cheers,
Magnus
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Guys,
I really think that the default for the gnome gtk package selector view
should be "in patterns" because none of us jr. geeks knows how to choose
all the dependencies for anything. starting with patterns as a default
lets me go to "web and Lamp" and add perl support for instance.
This adds continuity to the process of finding software in both the
"more applications" menu and the package selector.
--.
James Tremblay
Director of Technology
Newmarket School District
213 S. Main st
Newmarket NH, 03857
603-659-3271 *318
CNE 3,4,5
MCSE w2k
CLE in training
Registered Linux user #440182
http://en.opensuse.org/educationk
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Greetings GNOME/openSUSE lovers. After holding a very successful first
meeting, the GNOME team will be holding its next meeting this Thursday
at noon EDT/18:00CST/1600 GMT).
In general we will follow the meeting guidelines
(http://en.opensuse.org/Meetings/About) outlined for the openSUSE
project, except we use #opensuse-gnome as the IRC channel. Please add
agenda items and questions to the meeting page. This particular meeting
will be centered around 10.3 cleanup, 11.0 planning and the
process/planning improvements for the team (ie having these meetings,
and re-organizing the wiki like we've done over the past couple of
weeks).
Last meeting:
http://en.opensuse.org/GNOME/Meetings/20071004
Next meeting:
http://en.opensuse.org/GNOME/Meetings/20071011
or
http://en.opensuse.org/GNOME/Meetings/Current
Meeting info:
http://en.opensuse.org/GNOME/Meetings
-JP
--
JP Rosevear <jpr(a)novell.com>
Novell, Inc.
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
On Tue, 2007-10-09 at 17:29 -0600, Boyd Lynn Gerber wrote:
> On Tue, 9 Oct 2007, Rodrigo Moya wrote:
> > - Most of the opensuse-gnome team going to the Boston summit
> >
> > Wiki status:
> > - Initial task done, will continue to update to get good GNOME-related information
> > - Still no mail notifications
> > AI *** Boyd to poke Henne on mail notifications
>
> Is there another Boyd? I do not remember getting this action item. What
> am I to do?
>
unless you are the same Boyd that was on the meeting, no, it's not for
you :-) But we're glad to get any help, so if you want, just go ahead
and help the other Boyd :-)
--
Rodrigo Moya <rodrigo(a)novell.com>
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
This kind of HOWTOs should be what we have on our wiki :-)
http://www.howtoforge.com/the_perfect_desktop_opensuse10.3
--
Rodrigo Moya <rodrigo(a)novell.com>
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org
Okay everyone, this is round 2 of a quick sanity check of the
yast2-gtk package selector. I know that there are a bunch of other
problems with the package selector in general, but as a first cut,
these are the problems addressed in this fix:
1. Items in the left (Available Software) and right (Installed
Software) panes should be sorted alphabetically
2. Installed packages should _not_ be listed on the left unless
there's a newer version
3. Packages should appear in the left column when selecting "plain
list", "pattern", "language", etc.
I need everyone's help at testing these above-mentioned fixes before I
feel comfortable committing the code and releasing a newer version of
yast2-gtk. Please try it out and make sure that we haven't regressed
or broken something. If all goes well, I'll update the package for
10.3 and these things will at least be fixed and we can move on to
bigger and even more important fixes.
You can get the updated package here:
http://151.155.4.222/opensuse-10.3/
Thanks!
-Boyd
--
To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-gnome+help(a)opensuse.org