Re: new module decisions [was Re: gnome-screensaver]
quote who=Rodrigo Moya My list in the GEP includes all this and more ;) yeah, I think your list + some evaluation team scrutiny could work much better than looking for complete consensus on the mailing list. That evaluation team *is* the release team. But the release team doesn't make decisions independently of the community they serve, so an effort is made to represent their needs and direction. - Jeff -- FOSDEM 2006: Brussels, Belgiumhttp://www.fosdem.org/2006 you misspelt 'world dominatrix' - James Wilkinson ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: For completeness, I should also note that there are two other big problems involved which I don't know how to solve on a short timescale (e.g. before 2.16): - Havoc's recent points about identifying our target audience is important in many ways; in relation to this email, it's hard to judge what should be part of the desktop when we don't have a defined target audience (some who are working on Gnome have a defined target audience, but I don't think all of those who do agree) The more I think about it, the more I have become convinced that our target audience, if not simply Linux/BSD/Solaris/Whatever Distributions should be People who HAVE to use GNOME. This basically means corporate workers stuck in cubicles staring at computers all day, I suppose. It also means that these end users are likely to have sysadmin support. So, for example, this tells us that the sysadmin and printing parts of GNOME are more important than the, say, cd-ripping or DVD playing parts. (hmm, maybe playing DVDs is important in corporations these days?) It also tells us that laptop, PDA and wireless support is more important than, say, gaming support. Another thing it tells us is that stability is more important than configurability. Etc., etc. What do you think? It makes sense to me, but I am not privy to the thoughts of the inner circle. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On Fri, 2006-02-17 at 01:12 -0800, Alex Graveley wrote: *cough* tomboy *cough* Tomboy is a great example. Its a great piece of software that does new exciting things. If tomboy would be excluded from the desktop for some technicality I would be very sad. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc [EMAIL PROTECTED][EMAIL PROTECTED] He's a war-weary albino cyborg living undercover at Ringling Bros. Circus. She's a foxy bisexual mermaid from beyond the grave. They fight crime! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On Fri, 2006-02-17 at 09:38 +0100, Alexander Larsson wrote: On Fri, 2006-02-17 at 01:41 +0100, Rodrigo Moya wrote: So, what if we just set a list of things a module has to conform with to get accepted and base our decisions on that? For instance, we could have: * uses at least basic platform libs (GTK mainly) * uses existing platform libraries for everything possible (that is, does not use libs implementing an already existing feature in GNOME platform) * follows GNOME standards (coding standards, freedesktop specs, HIG, documentation, licensing, release dates and freezes, etc) * is source in GNOME CVS? If we have a complete and concise list, the decision is easy to be made, since you just have to tick or not the corresponding column in the list. When all columns are ticked, the module gets accepted. This strikes me as totally wrong, focusing only on certain, not very interesting aspects of the modules. Much more important are things like: it was just an example * Does it conflict/compete/overlap with other software in the desktop * Does it integrate with the desktop * Is it good, interesting software * Is this something that we think is important for a desktop to contain. good, now we have a more complete list -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
Murray Cumming wrote: On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: - David's recent point in this thread about the desktop release set not being so important also rings true to me. It's a binary in-or-out yet there are lots of really rocking Gnome programs that are well integrated but aren't in the set. It's foolish to imagine that being in the desktop release set is essential. But it's also foolish to ignore the big benefits to focusing our efforts (in a synchronized way) on particular implementations of the features that we want. It allows us to release software for distros to use. Do we have any evidence that any distro actually cares what we consider to be in and out of the desktop release? Is there some distro out there loyally shipping epiphany as its default browser and waiting for us to certify GIMP before they allow it into the default desktop install? -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On Fri, 2006-02-17 at 09:11 -0500, Dan Winship wrote: Murray Cumming wrote: On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: - David's recent point in this thread about the desktop release set not being so important also rings true to me. It's a binary in-or-out yet there are lots of really rocking Gnome programs that are well integrated but aren't in the set. It's foolish to imagine that being in the desktop release set is essential. But it's also foolish to ignore the big benefits to focusing our efforts (in a synchronized way) on particular implementations of the features that we want. It allows us to release software for distros to use. Do we have any evidence that any distro actually cares what we consider to be in and out of the desktop release? I think so, yes. And when integrate things, they have almost no choice. And when we adopt what distros have already adopted, we get the benefit of better translation, documentation, usability, integration, and timely-releases for that software. It doesn't hurt us that distros were using it before we decided to focus our efforts on it. Is there some distro out there loyally shipping epiphany as its default browser and waiting for us to certify GIMP before they allow it into the default desktop install? Again, you don't need to prove that the Desktop release set means everything to prove that it means something. It's a straw man argument. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
Hi, I think our thinking historically has been that distro's who really care about GNOME don't really 'care' that much about our list of stuff in the desktop release as they have a pretty good idea themselves what they want/don't want. Distro's which don't care much about GNOME on the other hand might look at our desktop release list, as a guide at least, for what to package. So for instance KDE focused distro's who wants to be able to checklist GNOME might look at it to see what should be packaged. Christian On Fri, 2006-02-17 at 09:11 -0500, Dan Winship wrote: Murray Cumming wrote: On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: - David's recent point in this thread about the desktop release set not being so important also rings true to me. It's a binary in-or-out yet there are lots of really rocking Gnome programs that are well integrated but aren't in the set. It's foolish to imagine that being in the desktop release set is essential. But it's also foolish to ignore the big benefits to focusing our efforts (in a synchronized way) on particular implementations of the features that we want. It allows us to release software for distros to use. Do we have any evidence that any distro actually cares what we consider to be in and out of the desktop release? Is there some distro out there loyally shipping epiphany as its default browser and waiting for us to certify GIMP before they allow it into the default desktop install? -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: - David's recent point in this thread about the desktop release set not being so important also rings true to me. It's a binary in-or-out yet there are lots of really rocking Gnome programs that are well integrated but aren't in the set. It's foolish to imagine that being in the desktop release set is essential. But it's also foolish to ignore the big benefits to focusing our efforts (in a synchronized way) on particular implementations of the features that we want. It allows us to release software for distros to use. Nobody is actually saying that the desktop release set is the whole story, so there's not much point arguing that it isn't. We've talked about franchising the release process and blurring the in-or-out line, but don't yet really know how to do that and haven't gotten any traction on the problem. By example, I hope. Bindings was a start, and should be followed by SysAdmin Tools and then hopefully by Productivity and Power Tools. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: On 2/16/06, Danilo Šegan [EMAIL PROTECTED] wrote: Hi Vincent, Today at 8:24, Vincent Untz wrote: We'll be trying something new for new modules in 2.16. I think most of us agree that it didn't turn out well for this cycle. Like: lets remove all desktop modules, and reevaluate them again? Not that it would bring any concrete results, but I'd love the flamefest (d-d-l is seriously lacking these days :) Now, seriously, can you at least give us a hint of what you have in mind? And who is we dammit? :) There are a couple of ideas floating around, so there's no concrete change to propose yet. But you'll note that we have sucked at new module decisions in all release cycles for the past who-knows-how-long. I personally think part of the problem is that the end date for new module proposals coincides with the date for the final decision. The discuss it period is also way too wide open making it hard to keep on top of. One of the suggestions is to have the cut-off date for new module proposals be sooner, have a focused and relatively short (a week or so?) discussion period after that (though still allowing the open ended discussion period that currently exists, just making it in some sense less official than the focused one), and then followed by an actual date by which decisions need to be made. I brought this up at a recent release-team meeting and other ideas were also brought up that were somewhat similar in nature (read: I don't remember the details). We didn't have anything concrete and were running out of time, and besides, 2.14 is taking precedence right now. So we agreed to discuss more later and get some community input maybe near or after 2.14 is out. But now that it has come up... Anyone else have any ideas on making us not suck at getting module decisions done two months before the release as specified on the schedule as opposed to one month like we usually achieve? one thing I don't like is how the decisions get done. That is, if someone raises some concerns about a proposed module, then some people don't like it is the reason given for not accepting the module (ie, see gnome-power-manager/screensaver thread). Of course, there would always be someone who doesn't like something about a proposed module. So, what if we just set a list of things a module has to conform with to get accepted and base our decisions on that? For instance, we could have: * uses at least basic platform libs (GTK mainly) * uses existing platform libraries for everything possible (that is, does not use libs implementing an already existing feature in GNOME platform) * follows GNOME standards (coding standards, freedesktop specs, HIG, documentation, licensing, release dates and freezes, etc) * is source in GNOME CVS? If we have a complete and concise list, the decision is easy to be made, since you just have to tick or not the corresponding column in the list. When all columns are ticked, the module gets accepted. Also, any concern about proposed modules should be only valid if accompanied by a detailed bug report. -- Rodrigo Moya [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On 2/16/06, Rodrigo Moya [EMAIL PROTECTED] wrote: On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: On 2/16/06, Danilo Šegan [EMAIL PROTECTED] wrote: Hi Vincent, Today at 8:24, Vincent Untz wrote: We'll be trying something new for new modules in 2.16. I think most of us agree that it didn't turn out well for this cycle. Like: lets remove all desktop modules, and reevaluate them again? Not that it would bring any concrete results, but I'd love the flamefest (d-d-l is seriously lacking these days :) Now, seriously, can you at least give us a hint of what you have in mind? And who is we dammit? :) There are a couple of ideas floating around, so there's no concrete change to propose yet. But you'll note that we have sucked at new module decisions in all release cycles for the past who-knows-how-long. I personally think part of the problem is that the end date for new module proposals coincides with the date for the final decision. The discuss it period is also way too wide open making it hard to keep on top of. One of the suggestions is to have the cut-off date for new module proposals be sooner, have a focused and relatively short (a week or so?) discussion period after that (though still allowing the open ended discussion period that currently exists, just making it in some sense less official than the focused one), and then followed by an actual date by which decisions need to be made. I brought this up at a recent release-team meeting and other ideas were also brought up that were somewhat similar in nature (read: I don't remember the details). We didn't have anything concrete and were running out of time, and besides, 2.14 is taking precedence right now. So we agreed to discuss more later and get some community input maybe near or after 2.14 is out. But now that it has come up... Anyone else have any ideas on making us not suck at getting module decisions done two months before the release as specified on the schedule as opposed to one month like we usually achieve? one thing I don't like is how the decisions get done. That is, if someone raises some concerns about a proposed module, then some people don't like it is the reason given for not accepting the module (ie, see gnome-power-manager/screensaver thread). Of course, there would always be someone who doesn't like something about a proposed module. So, what if we just set a list of things a module has to conform with to get accepted and base our decisions on that? For instance, we could have: * uses at least basic platform libs (GTK mainly) * uses existing platform libraries for everything possible (that is, does not use libs implementing an already existing feature in GNOME platform) * follows GNOME standards (coding standards, freedesktop specs, HIG, documentation, licensing, release dates and freezes, etc) * is source in GNOME CVS? I tried to create such a list in a GEP, ages ago: http://developer.gnome.org/gep/gep-10.html Bottom line: * there are some obvious ones (licensing, CVS, etc.) but those are easy and no one (to the best of my knowledge) has ever proposed anything that didn't meet them, or wasn't trivially moved to them. * you must include evaluations of quality/completeness that are necessarily subjective until the project is evaluated by a wider crowd, and ideally on others, like a11y, that we should include but that realistically no one has time/ability to make the assessments on. So you're always going to have the subjective components, even on reasonably subjective things (is the quality good? is it accessible?) * if the desktop is to remain at all coherent, you must include evaluations of target market/etc. that frankly, as a group, we're basically unable to handle right now. There is no simple, easy, list, unless you have no meaningful standards. Software isn't simple and easy, unfortunately. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
What I'm seeing seems like lack of guidance along with the other points
you mentioned. For instance this release team reason:
+ gnome-power-manager: people like it, but some mor work is needed,
and more integration should be done. It won't go in for 2.14, but
we'd like to see a good integration work starting soon for 2.16.
This reason is a bit too vague and looking back over the thread, I can't
see real positions beyond this. I've made some notes from re-reading
the gnome-screensaver thread, not to point out anyone (and sorry to
those I point out, it's not about you). But to point out how vague the
final reasons end up being.
In the requesting official list of modules and versions for GNOME 2.14
thread I noted some of these reasons. (all quoted, out of context, and
probably unfair to the authors [sorry])
Vincent: It looks great, but it doesn't look integrated enough
to me, yet.
Davyd: Let's let vendors decide. This module could do with both
UI and technical review. The persistant use of the notification
area, the number of popup bubbles (see above comments on popup
spam)
Davyd: hope to get some clarification on what is good
notification and bad notification that is suitable for the HIG
shortly.
...
I am proposing that gnome-power-manager has no notification UI
[...]
{Lots of discussion on how people think g-p-m could be improved}
As far as I can tell this is the community consensus and the release
team ends up having a similar consensus, both of which are vague and
lacking direction for everyone involved.
I think it would do a lot of good to see the release team format their
decisions more like action items. That way the module maintainer knows
what needs to be done (as william pointed out) and there can be some
actual debate about the true need for doing it.
Some proposed action items (from me):
* HIG has no real notification area guidelines
To me this doesn't mean g-p-m is doing anything wrong, just that
we design / usability people are behind the game and need to get
our act together.
Here's the current start:
http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html#desktop-notification-balloon
* Needs technical review signed off by the following people, say Davyd,
David, Vincent, and some others? Those people give a technical signoff
that the bubble You've been hacked due to a fault in the programming of
g-p-m, Thank you and have a good day doesn't show up.
This is a purely technical review, not about if it handles
notification bubbles wrong. The release team can select a few
people who's job it is to openly review the application and sign
off on it, maintainers of relevant areas are probably good
candidates.
GNOME gets a few people who are responsible for the official ok,
the review is done in the open so anyone can participate and we
actually get something done because a set of people are
accountable.
* UI Review, all new modules are supposed to get this the most. It's
most likely all my fault that none of this has been done.
Similar to running the technical review, select some people to
be in charge and they get a certain amount of time to work on it
in the open. The maintainer should get enough time to respond
and change, then those people have to give their yes/no vote to
the release team.
Reasons that wouldn't count, and have counted in the past:
* Not enough integration (sorry vincent, not picking on you; i think
i've said this before too).
The reason is a bit too vague for anyone to fix and an excellent
way to become more integrated to to pull these modules into the
mainline.
* There is some existing functionality that would need to be deprecated.
As an action item sure, but this shouldn't block inclusion at
all
We do this all the time, out with the old in with the new even
if it means multiple modules. (GGV, GPDF - Evince is one
example)
Hope I'm helping,
~ Bryan
On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote:
There are a couple of ideas floating around,
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On Thu, 2006-02-16 at 20:06 -0500, Bryan Clark wrote: Some proposed action items (from me): * HIG has no real notification area guidelines To me this doesn't mean g-p-m is doing anything wrong, just that we design / usability people are behind the game and need to get our act together. Here's the current start: http://developer.gnome.org/projects/gup/hig/draft_hig_new/desktop-notification-area.html#desktop-notification-balloon Hero! Bryan, I don't know if you read through my use case-y examples with Paul, but if you haven't - perhaps some of that might be useful (or perhaps it's all shit). --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
