Re: Module Proposal: Zeitgeist

Hi Olav,
Thanks a lot for clearing it up. This makes a lot of sense.

As I see it there is two ways to approach this:
1) Implement first then propose as an external dependency:The risk is
that implementation is done and GNOME decides the dependency is
unacceptable, thus rendering a couple of months work useless. And if
the application persists then it is almost like its shoving a
dependency down the communities throat.
2) It is blessed to use the technology. This way we valuable time is
saved and there is consensus.

I prefer option 2. What do you think?

On Sun, Apr 22, 2012 at 12:14 PM, Olav Vitters <olav vitters nl> wrote:
> On Sat, Apr 21, 2012 at 08:33:43PM -0700, Sriram Ramkrishna wrote:
>> What about you want to use a new technology but you don't want any new
>> features but rather using this new external dependency will simpifiy things
>> and making maintainance easier?  I suppose that itself is the feature?
>> Easier maintenance?
> That's #3 actually; propose a new external dependency (same as you do
> when you want to increase a new one).
> I know the process is still imperfect (e.g. I think we didn't do a
> feature request announcement yet, we should clearly announce which ones
> are 'accepted' + should've monitored the progress on accepted features).
> Result is that it that the 'rules' are unclear. I think in the end
> focussing on features instead of external dependencies is better. But
> I think the thought is still underway.
> Risk for the feature focus is that the external dependencies "rules" are
> forgotten. E.g. I noticed that gnome-boxes increased its libosinfo
> version requirement in 3.4.1. That's not so nice when distribution is in
> a version freeze.
> --
> Regards,
> Olav
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]