Re: Sound Juicer support and/or EoL

[Olav Vitters]

On Tue, Dec 03, 2019 at 11:14:15PM +0100, Kevin Degeling wrote:

ps. First time ever on a mailing list, so please let me know if I'm way
to formal or if I make a very Dutch impression.


As far as I know, there's nothing wrong with making a very Dutch 
impression!


--
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Missing releases and state of 3.33.90

[Olav Vitters]

On Tue, Aug 13, 2019 at 02:40:19PM -0400, Ray Strode via desktop-devel-list 
wrote:
> On Tue, Aug 13, 2019, 2:24 PM Olav Vitters  wrote:
> 
> > Hi,
> >
> > I had various issues packaging GNOME 3.33.90. It seems that there's
> > various modules which haven't made a release, e.g.:
> > - no gdm 3.33.90
> > - no gnome-session 3.33.90
> >
> sorry,  will do them.

Ah!! I thought it was intentional (more testing needed or something) as
usually release team would chase as well. I didn't expect it just to be
forgotten, else I would not have used d-d-l. Sorry for possibly being
impolite.

Many thanks.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Missing releases and state of 3.33.90

[Olav Vitters]

Hi,

I had various issues packaging GNOME 3.33.90. It seems that there's
various modules which haven't made a release, e.g.:
- no gdm 3.33.90
- no gnome-session 3.33.90

Further, gnome-shell 3.33.90 incorporates an gnome-desktop API/ABI (?)
change, but it doesn't actually check that gnome-desktop is new enough.

Especially with the various changes it would be nice to have a few more
checks in e.g. meson.

The packaging for this beta was quite a bit more involved than any other
.90 version (though having a stable GTK+ did ease things quite a bit). I
didn't notice much discussion so I'm also wondering if it was just me
facing various issues?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)

[Olav Vitters]

On Fri, May 03, 2019 at 12:09:11PM +0200, Bastien Nocera wrote:
> On Thu, 2019-04-25 at 11:46 +1000, Michael Gratton wrote:
> > Hi all,
> > 
> > I'd like to formally propose as a GNOME Goal that GNOME modules
> > replace references to the terms "master" and "slave". [...] The scope
> > would be to replace occurrences of the terms appearing [...] git
> > repositories
> 
> I don't think it makes sense to carry on the unfocused discussion in
> the original thread to talk about:
> Replacing "master" reference in git branches
> as the subject line says.

That such a change (git branch name) is needed has been questioned
various times. The response to that has been underwhelming. There's no
clear explanation.

Elsewhere you said the git master name is different from master/slave
naming in general. Yet the master/slave is used as a prime example that
git master should be renamed. This is not consistent.

> - Why?
[..]
> I understand that the connection is more tenuous than straight up
> "master/slave" references, which is why I want to emphasise that we
> don't need any more comments about whether the negative connotations of
> "master" alone don't apply in your language or culture.

You seem to suggest to just do it (sole master reference), instead of
determining why. If so, that's what loads of people have objected to.

> - How?

In practice this will mean master will still be around, used and visible
in the UI+git. For the UI (gitlab) maybe a hack can be added… but that
still will leave it around. Therefore the "How?" is not a "how" IMO,
instead of one master branch there will be two names for the same thing.

> - Why not in git directly?
> 
> Because that's already hard enough to propose something like this in a
> welcoming community like GNOME's. I've already seen offline comments
> made to people who participated in this thread, and this would go down
> about as well as like Linux' adoption of a code of conduct[6].

So no attempt was made, just assumptions about how it would be
perceived? It feels like a limited number of people trying to force this
through to a huge group (like GNOME3! j/k).

> - And to what?
> 
> A few possible names were mentioned/used. "mainline" was thought to
[..]

One module was already changed though. First things broke, then
eventually it worked again, though then showing "master" again. It
doesn't come across as a thought out change.

> - Next steps
> 
> The GNOME community needs to decide whether this change can be done.
> 
> Most of the original thread was specifically about the git branch name
> change, and changing lone "master" references is where most of the
> opposition was.
> 
> I expect Michael to send a recap mail about "master/slave" references
> in the original thread shortly.

For master/slave there seem to be consensus to not use such phrasings.
For master alone (e.g. git) there seem to be a near consensus against
changing it, all IMO.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: Replace all references to master/slave in GNOME modules

[Olav Vitters]

On Thu, Apr 25, 2019 at 02:02:43PM +0200, jtojnar--- via desktop-devel-list 
wrote:
> On Thu, 25 Apr, 2019 at 11:21 AM, Daniel Playfair Cal via desktop-devel-list
>  wrote:
> > "master/slave" -> "leader/follower"
> 
> Please note that leader/follower terms are commonly associated with
> exploitation of people by cults and should be avoided as well.

Within Salsa leader/follower is commonly used. Also often man/woman,
but leader/follower is more inclusive than man/woman as it doesn't
really matter who leads.

I read later in the thread the leader concept has bad associations in
German. This while the word has been introduced with good intentions
(within Salsa) as to be more inclusive (plus more accurate).

Renaming the master branch only within GNOME is a bit odd. As mentioned,
master has multiple meanings. For the branch there's a different
meaning. Mainline also has multiple meanings. If I ignore the ones which
make sense there's also various non-inclusive meanings of mainline. The
whole proposal feels like grasping at straws IMO.

I don't read every email but why not propose such a change to git? Why
only GNOME?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: This video is dedicated to all of you

[Olav Vitters]

On Thu, Oct 25, 2018 at 05:25:56PM +0200, Bastien Nocera wrote:
> On Wed, 2018-10-17 at 21:52 +0000, Olav Vitters wrote:
> > On Wed, Oct 17, 2018 at 06:32:44PM +0100, Emmanuele Bassi via
> > desktop-devel-list wrote:
> > > On Wed, 17 Oct 2018 at 18:30, Bastien Nocera 
> > > wrote:
> > > 
> > > > On Wed, 2018-10-17 at 19:24 +0200, Alberto Salvia Novella via
> > > > desktop-
> > > > devel-list wrote:
> > > > > https://youtu.be/
> > > > 
> > > > How is this person still allowed to post on d-d-l?
> > > > 
> > > 
> > > Yes, can we please enable some moderation? Not only this stuff is
> > > obnoxious
> > > trolling, but people are replying to it. I dontyreally want this
> > > stuff in
> > > my inbox.
> > 
> > Mailing lists suck IMO, especially mailman2 where you need to
> > remember a password and in case you forgot you'll need to ask a
> > sysadmin to make a new password for every moderator. Mailman3 would
> > fix this, but super slow development pace last time I checked.
> > Ideally it would be a more free for all.
> > 
> > I didn't see the previous emails from Mr. Novella. He sent something
> > many months ago. I find d-d-l rather quiet. This email I would even
> > have
> > opened based upon the subject as it is pretty spammy.
> > 
> > I've set the moderation bit on Mr. Novella but do think asking for
> > moderation is overlooking that if you follow various other GNOME
> > discussion methods you'll find a way lower signal to noise ratio
> > (many useless comments per hour).
> 
> What does this have to do with the fact that the mailing-list needs to
> be moderated? It's just whataboutism.

The need to remember an annoying password makes moderating annoying.
Further, the interface sucks, there's loads of spam in the moderation
queue and for months there's nothing to do. Further, someone sending
some not so nice messages doesn't mean moderation you immediately need
moderation.

> If keeping track of the mailing-list admin password is too complicated,
> I'd be happy to help moderate it.

The admin password is whataboutism :-P I was talking about the
moderation password. Andre Klapper offered to assist as well. I didn't
see a new password, feel free to request a reset a new one from AV, then
share with whomever is interested.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: This video is dedicated to all of you

[Olav Vitters]

On Wed, Oct 17, 2018 at 06:32:44PM +0100, Emmanuele Bassi via 
desktop-devel-list wrote:
> On Wed, 17 Oct 2018 at 18:30, Bastien Nocera  wrote:
> 
> > On Wed, 2018-10-17 at 19:24 +0200, Alberto Salvia Novella via desktop-
> > devel-list wrote:
> > > https://youtu.be/
> >
> > How is this person still allowed to post on d-d-l?
> >
> 
> Yes, can we please enable some moderation? Not only this stuff is obnoxious
> trolling, but people are replying to it. I dontyreally want this stuff in
> my inbox.

Mailing lists suck IMO, especially mailman2 where you need to remember a
password and in case you forgot you'll need to ask a sysadmin to make a
new password for every moderator. Mailman3 would fix this, but super
slow development pace last time I checked. Ideally it would be a more
free for all.

I didn't see the previous emails from Mr. Novella. He sent something
many months ago. I find d-d-l rather quiet. This email I would even have
opened based upon the subject as it is pretty spammy.

I've set the moderation bit on Mr. Novella but do think asking for
moderation is overlooking that if you follow various other GNOME
discussion methods you'll find a way lower signal to noise ratio
(many useless comments per hour).

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, tips of the week and question of the week

[Olav Vitters]

On Thu, Feb 08, 2018 at 04:34:24PM +0200, Alberts Muktupāvels wrote:
> It is not only script, right? Because repositories.txt does not exist under
> gitlab.gnome.org.

Please cut down on the excessive quoting.

I assume Gitlab has some API to show the available repositories. As
such, script is only thing which needs to change.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [GitLab] Projects moved, tips of the week and question of the week

[Olav Vitters]

On Tue, Feb 06, 2018 at 03:41:03PM +0200, Alberts Muktupāvels wrote:
> On Tue, Feb 6, 2018 at 3:33 PM, Alberto Ruiz  wrote:
> 
> > Hello Alberts,
> >
> > I believe the hooks for emails are still installed, so there will be no
> > regressions in this regard regardless of the web frontend. If the migrated
> > projects are not sending commits to the mailing list we're doing something
> > wrong.
> >
> 
> 
> Migrated projects are sending commits to mailing list, problem is that it
> is not possible to subscribe to these projects. Migrated projects has
> disappeared from "Which topic categories would you like to subscribe to?"
> list -  https://mail.gnome.org/mailman/options/commits-list.

The following script needs to be adjusted:
https://gitlab.gnome.org/Infrastructure/sysadmin-bin/blob/master/mail/set-topics-svn-commits-list


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GitLab migration status and roadmap

[Olav Vitters]

On Fri, Aug 11, 2017 at 08:48:34PM +0200, Carlos Soriano wrote:
> Bugs can be migrated with https://gitlab.com/aruiz/gitlab-gnome-tools, is
> up to the maintainer what to do with them.

Note that this script has a lot of things it does NOT handle. As agreed
with Alberto I'm going to fork this into a better script.

Basic things like:
- ensuring old bugs correctly link to new bugs (bugzilla 123 -> github
  something)
- links from existing comments to other bugs (comment specifying
  bugzilla 123... which now could be anywhere)
- migrate users
- ensure users still get notifications on their open bugs
- what to do with e.g. keywords

are not handled by the current script.

Note this is not a complaint as I agreed to work on this.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME hackers (developers) group on Telegram

[Olav Vitters]

Hello,

Since last GUADEC we've created a hidden GNOME hackers group on
Telegram. The members are people going to GNOME hackfests, GUADEC, etc.
Telegram is NOT free software (IIRC) and its encryption is iffy at best.

If you'd like to be added and you fit above description please send an
email to me with your phone number in international format (e.g.
something like +316123456 in case you're Dutch).

Topics discussed: nothing. The group receives little to no texts.
Sometimes during a hackfest people discuss where to eat. That's
basically it. Still, if interested send an email (best to my gmail…
ovitt...@gmail.com).

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switching from Autotools to CMake for core evolution products

[Olav Vitters]

On Wed, Oct 05, 2016 at 07:54:02AM -0500, Michael Catanzaro wrote:
> This is fine from a release team perspective, as we're already set up
> to handle CMake modules. Just make sure to update the JHbuild
> moduselets and Continuous manifest at the same time you make the
> change. There are already examples of how to handle CMake projects
> (e.g. WebKitGTK+).

Not sure why you say this so easily. GNOME modules at the moment are
really easy to package. CMake is annoying. Having each module choose its
own build system is a step backwards.

There's certain requirement each module has to follow, e.g. versioning
scheme and so on. That's for good reasons and one of the benefits. GNOME
releases loads and loads of modules. Its important that we deviate as
little as possible in what we provide.

> I'm a little surprised at the use of CMake instead of meson, but that's
> your choice to make.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reminder: editbugs+canconfirm on Bugzilla

[Olav Vitters]

It's been announced quite a while ago, but seems good to remind
everyone:
- If you're a developer you can add/remove other developers from your
  product
- any developer can hand out canconfirm+editbugs permissions and please
  feel free to do so easily


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Fwd: Thank's for Gnome

[Olav Vitters]

FYI

-- 
Regards,
Olav
--- Begin Message ---
Hello
I want to say Thank You to all people who work on Gnome 3 Project.
I love that calm and peace when i start working on my Fedora.
I love where there is nothing on my Desktop, and I only think about my work
and what i must do. Gnome 3 help me to do that, and I am very calm when i
using that.

Earlier i was using Windows 8 and Windows 10.
On my Desktop was everything, and it was terrible.

I think GNOME 3 way is the future.
Please send it or show it to all people who are working on Gnome 3.

-- 
*Pozdrawiam*
Łukasz Czepiec
POLAND
___
security-list mailing list
security-l...@gnome.org
https://mail.gnome.org/mailman/listinfo/security-list
automatically sent to *all* subscribers of the release-team mailing list--- End Message ---
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Collaboration on standard Wayland protocol extensions

[Olav Vitters]

On Mon, Mar 28, 2016 at 10:50:23PM +0300, Martin Peres wrote:
> We thus wanted to let distros take care of most of the policies (which
> does not amount to much and will likely come with the application
> anyway). However, some distros or devices come with a system
> that already defines security policies and they will likely not want
> a proliferation of storage places. Hence why we allowed for
> multiple backends. But this is an exception rather than the rule.

Why should every distribution decide on some policy? The default way
should work sanely and the way that a user would experience it makes
sense. I help out with Mageia (+GNOME), I'm 98% sure Mageia has 0
interest in creating/developing such a policy.

e.g. Linus complaining about (IIRC) needing to provide a root password
after plugging in a printer. If we create such a situation again I might
even understand why he's rants :-P

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Design & Development

[Olav Vitters]

Accidentally approved this one. Please ignore
-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Remembering Thomas Wood

[Olav Vitters]

On Fri, Feb 12, 2016 at 03:34:00PM +, Allan Day wrote:
> As some of you might have heard, Thomas Wood passed away last month. This
> is extremely sad news for those of us who knew him: he was a great guy, who
> was always supportive of the GNOME project.

:-(

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [Builder] Developer experience (DX) hackfest 2016

[Olav Vitters]

On Mon, Dec 28, 2015 at 10:03:55AM -0300, Hugo Alejandro wrote:
> http://rtcquickstart.org/
> 
> Daniel Pocock Daniel has always offered their help in creating and improving
> communications through opensource protocols.

That's pretty far off from what we're looking for. Above describes how
to setup an extensive infrastructure to do pretty much everything
related to communications. That such an extensive document is called
"quickstart" gives me the shivers!

Is there an existing (hosted) solution alternative to hangouts? Pretty
much as simple as: "go to this URL"?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.16 Release Notes

[Olav Vitters]

On Tue, Feb 17, 2015 at 02:24:56PM +, Allan Day wrote:
 The release notes wiki page is still missing a lot of detail. Please
 take a minute to check it over - we'll be starting to write them up
 soon.

I'll go over everything again once .90 is out. I added a bunch of stuff
using the combined NEWS files
(https://download.gnome.org/core/3.15/3.15.4/NEWS etc). Most of the
interesting stuff will land at .90.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Killing off UNCONFIRMED in Bugzilla

[Olav Vitters]

On Sun, Feb 15, 2015 at 11:07:50AM +0100, Sébastien Wilmet wrote:
 On Sat, Feb 14, 2015 at 10:12:22PM +0100, Andre Klapper wrote:
  So triage incoming bug reports and set proper expectations by setting
  status RESOLVED WONTFIX for such tickets right away, instead of spending
  the approx. same amount of time for changing status UNCONF to NEW?
 
 Ok, but what to do with all the old bugs that are not well triaged?
 gedit contains more than 400 bugs, and triaging all of them takes a lot
 of time. If one day all of them are well triaged, then yes, it makes
 sense to remove the UNCONFIRMED status (but in that case we must be sure
 to well triage all new incoming bugs, and history has shown that it's
 not always the case).

400 bugs is not a huge number to triage. It seems you're talking about
multiple things. For triaging bugs, you have to deal with loads of bugs
which are in UNCO status, but have been triaged. Meaning: they are real
bug but never moved out of UNCO. When looking for bugs to fix, you'll
have to look at UNCO as well as NEW. But looking for bugs to fix is not
triaging. While triaging it is easier to say that you looked at it vs
knowing it really is a bug. Together with the amount of emails being
sent I usually leave things as UNCO.

Ideally you'd first have everything handled by a triage team, then it
goes to a developer. If there's a new developer you'd want to give them
a list of bugs. I don't see how UNCO vs NEW in the current usage is
beneficial.

Practically for most products no distinction is made _at all_. Bugs are
randomly spread across both statuses.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Killing off UNCONFIRMED in Bugzilla

[Olav Vitters]

With Bugzilla 4.4 we can disable UNCONFIRMED on a per-product basis.
With that option available, I suggest to kill off the UNCONFIRMED status
for all products except whomever wants it. I think we had this
discussion before, but couldn't easily find that.

Reasoning to kill unconfirmed:
Unconfirmed at various times gives the impression the bug will not be
looked at. Not having this state would solve that.

Action required:
  IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!!


Steps (for all products except the ones opting out):
- Change use unconfirmed to false (product specific setting)
- Mass change all unconfirmed bugs to new for all

Timeline:
I want to do this Friday 27 February 2015.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Killing off UNCONFIRMED in Bugzilla

[Olav Vitters]

On Fri, Feb 13, 2015 at 06:39:29PM +0100, Rick Opper wrote:
 OK... So they just stay new then... I'm not sure that would give the
 original reporter the impression that something is being done, but as
 long as the bugs do get confirmed, sorted, whatever then any
 simplification may be helpful... 

Things will be done no matter which status it is for the majority of the
products. Some products are not maintained at all anymore, for those the
status still won't make much difference.

The separate step might make sense in case you had a big bugsquad team
looking at all the incoming bugs. We don't.

The unconfirmed vs new status has little or no meaning. Loads of bugs
actually go from unconfirmed to new. I tend to only mark it as new if
there's a bunch of people on it and because some people don't understand
that if I disagree with the bug, I would've already marked it WONTFIX.

If people want to look at bugs they want to triage, there's already
bugs filed in the last 7 days. Further, bugs without a response. In
the current state, unconfirmed is not going to help you much.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Killing off UNCONFIRMED in Bugzilla

[Olav Vitters]

On Fri, Feb 13, 2015 at 04:51:58PM +0100, Olav Vitters wrote:
 Action required:
   IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!!

I'm keeping track of opt-outs at
https://wiki.gnome.org/BugzillaMaintainers/NoUnconfirmed

Feel free to edit, though would appreciate a comment why you opt out.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Commit auto-links in bugzilla comments

[Olav Vitters]

On Tue, Feb 10, 2015 at 08:38:39AM +0100, Milan Crha wrote:
 Is there a way to tell the comment parser that the commit itself 
 belongs to another product than the one the bug is filled for?

I could add support for something like:
  module $FOO commit $BAR

Just as now you can do:
  comment 13
  bug 163163 comment 13

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: OUTAGE: bugzilla.gnome.org, 09th February (09:00 CET) - 10th February (22:00 CET)

[Olav Vitters]

On Tue, Feb 10, 2015 at 09:58:49AM +0100, Alexandre Franke wrote:
 As I already told Sri on IRC yesterday, if anything is wrong with our
 current bugzilla, you should start by filing bugs. Then we can start
 looking for solutions and someone to implement them. Otherwise we
 can't guess what you guys think the problem is.

As well: This is almost the default Bugzilla UI, and yeah, it is that
terrible by default. Read
http://blogs.gnome.org/aklapper/2015/02/10/gnome-bugzilla-upgraded-to-4-4/
for the list of things. Loads of overlapping functionality. We've been
using Bugzilla for so long while the UI has not improved much, nor the
way that it works (just received more options or made it less easy to
remove the unneeded functionality). Andre raised it various times, but
they're not really getting it.

Just to classify bugs into various lists you have:
Classifications, Products, Components, Hardware, OS, Keywords, Tags,
Flags, Target Milestone. That's wayyy too many.

During FOSDEM a Mozilla Bugzilla hacker reached out to see if assistance
was needed. We didn't contact yet, but maybe this is better.

BTW: https://bugzilla.mozilla.org/ is a heavily customized Bugzilla.
Upstream Bugzilla should just work by default IMO.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Anyone going to be using ConsoleKit for 3.16 ?

[Olav Vitters]

On Tue, Feb 03, 2015 at 03:36:36PM -0500, Ray Strode wrote:
 Hi,
 
 On Tue, Feb 3, 2015 at 12:00 PM, Olav Vitters o...@vitters.nl wrote:
  Can't we hide it behind a --this-is-going-away-in-3.18 configure switch?
 That was certainly a possibility, but, what's the advantage of doing
 it?  The bug Antoine pointed to shows that distros that use ConsoleKit
 in 3.14 are already shipping patches to keep it working. No one who
 has chimed in has said that one more would be a big deal.
 And this is really only for one release, by 3.18 everyone should be
 using the newer apis, and then the patches will go away.
 
 It wouldn't be a big deal to deprecate for a release but no one who
 will be using ConsoleKit in 3.16 advocated for that.  And cutting out
 the code is a net win for the codebase, so I'd rather do it now than
 later.

Because I'm wondering if we're reaching everyone with this announcement,
and it is a bit late in the cycle. Having a configure option would not
mean it is suddenly gone (if they miss this email, they'd also not know
about the patch), but it clearly tells them it'll be gone.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Anyone going to be using ConsoleKit for 3.16 ?

[Olav Vitters]

On Wed, Feb 04, 2015 at 09:48:19AM -0500, Ray Strode wrote:
 On Wed, Feb 4, 2015 at 4:24 AM, Olav Vitters o...@vitters.nl wrote:
  Having a configure option would not
  mean it is suddenly gone (if they miss this email, they'd also not know
  about the patch), but it clearly tells them it'll be gone.
 
 Okay so there's a pretty good middle ground we can come up with here.
 I'll leave the --with-console-kit argument in configure, but if it
 gets used, then
 I'll error out and point to the wiki page mclasen suggests in another message.

Ah, that's awesome!

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Anyone going to be using ConsoleKit for 3.16 ?

[Olav Vitters]

On Tue, Feb 03, 2015 at 10:54:12AM -0500, Ray Strode wrote:
[..]
   I'm wondering if there are distros/platforms that are planning on
   using 3.16 and ConsoleKit together.
[..]
  I would not mind removing such support for 3.16 if and only if
  reverting the removal is easy and not too intrusive.
  FreeBSD will also be using ConsoleKit for 3.16. Antoine pretty much
  said everything that goes for us already.
 Okay guys, so what I'll do then is take the code out but post a patch to
 
 https://bugzilla.gnome.org/show_bug.cgi?id=743940
 
 that adds it back. You guys can ship that with 3.16 and then drop it
 with 3.18 when LoginKit is integrated into your distros.

Can't we hide it behind a --this-is-going-away-in-3.18 configure switch?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feedback from downstreams presentation from DX hackfest 2015

[Olav Vitters]

On Mon, Feb 02, 2015 at 08:05:00AM +, Philip Withnall wrote:
 It was suggested that I send the presentation to DDL, since it might be
 of general interest. I haven’t modified it from the hackfest version, so
 please let me know if you have any questions.

Can we assume that most still needs to be actioned? Also interested what
discussions there were during the hackfest to improving this. E.g.
Should we maybe reach out to our advisory board? Some things mentioned
lack of documentation. So with DX hackfest and documentation at same
time I also wonder if there were any possibilities to improve this.

 Slides:
 http://people.collabora.com/~pwith/feedback-from-downstreams/presentation.pdf
 Handout:
 http://people.collabora.com/~pwith/feedback-from-downstreams/handout.pdf
 Source:
 http://cgit.collabora.com/git/user/pwith/feedback-from-downstreams.git/
 Tarball:
 http://people.collabora.com/~pwith/feedback-from-downstreams/source.tar.xz

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Feedback from downstreams presentation from DX hackfest 2015

[Olav Vitters]

On Mon, Feb 02, 2015 at 02:37:32PM +, Philip Withnall wrote:
 What do you mean by reaching out to the advisory board? Reaching out for
 further feedback from them as downstreams, or reaching out for resources
 to fix such issues? I think the former would be interesting. I’m not
 sure the latter is worth their time, since it’s a very loosely defined
 goal.

I meant for resources.

Though we should have a team to continuously reach out, find out issues
and act on them. If we don't act/respond (which could be about going
back and saying we cannot change it), then no point in asking.

  4. Instant gratification: documentation changes should be visible
 instantly, rather than waiting 6 months for a GNOME release before
 the docs hit developer.gnome.org.

The current infrastructure really requires tarballs. We could reuse
continuous integration builds to spit out tarballs to feed to
developer.gnome.org. It would not be instant, but you'd cut it down to
15 minutes maybe? It would be a huge improvement.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome / systemd

[Olav Vitters]

On Mon, Jan 12, 2015 at 09:50:49AM -0600, Michael Catanzaro wrote:
 I assume you're contacting us because you're considering GNOME for your
 default desktop environment. That's something that I would like to
 encourage. :) I also assume you've already willing to reimplement the
 various D-Bus interfaces provided by systemd, and that logind is your
 concern here.

I've asked Devuan to post here a while ago. It seems that it was stuck
in the moderation queue. Despite various things[1] I've noticed assume
people mean well worked quite well. I don't participate in their
mailing list anymore as the atmosphere is (was?) toxic. I believe we're
sometimes too aggressive in our replies/communication.

Regarding Devuan: They've made something which provides a logind API
with ConsoleKit2 as a backend. See https://github.com/dimkr/LoginKit.

-- 
Regards,
Olav

[1] the do our bidding website, huge amount of trolls in their mailing
list, simplistic blaming GNOME, etc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome / systemd

[Olav Vitters]

On Mon, Jan 12, 2015 at 08:25:26AM -0800, Sri Ramkrishna wrote:
 Internet.  The greatest way of changing minds and hearts is to be calm and
 coherent on what we're trying to do.  That said, this thread and its replies
 are a perfect example of how we should approach issues.  If we want to gain
 mindshare, we need to be better than the Internet. :-)

Almost forgot: Devuan does have a few people who you can communicate
with. Entirely reasonable people who are willing and have put in work.
They might (initially) not have a good understanding or maybe think
things were done out of forcing, but things changed around quickly
with just explaining things.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announce release of non-official module

[Olav Vitters]

On Thu, Aug 14, 2014 at 11:49:49AM +0200, Juan Rafael García Blanco wrote:
 So my question is, should I wait a bit more because moderators are busy? Or
 did I do wrong sending an announcement to gnome-announce-list?

I think we need more moderators. I cleared the queue now. I think we
usually clear the queue once per GNOME release.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git.gnome.org changes and new doap file requirements

[Olav Vitters]

On Sun, Aug 03, 2014 at 08:05:21AM +0200, scl wrote:
 What am I doing wrong? Needs the git hook to be fixed?

Right, instead of testing that it gives an error, I should also have
tested that it works as intended. I fixed about 3 bugs now, please try
again. :-P

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announce release of non-official module

[Olav Vitters]

On Sun, Aug 03, 2014 at 04:41:26PM +0200, Juan R. Garcia Blanco wrote:
 So my question is: could I send an announcement to gnome-announce-list
 without submitting a tarball, just tagging the repo?

If you announce a release, distributions will want to download a tarball
from somewhere. So you'd need to put that somewhere. For
gnome-announce-list: doesn't require that the software is on
download.gnome.org.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

git.gnome.org changes and new doap file requirements

[Olav Vitters]

 [ Please reply to desktop-devel-list@gnome.org ]

André Klapper suggested we should make more use of the doap files. As a
result of that together with GUADEC, the following changes have been
made on git.gnome.org:

1. New categories: Core, Core Apps, Apps
   Note: Not every module has been put into right category. If you spot
   errors, please let release-t...@gnome.org know. I'm planning to add
   some cross checks in the release team scripts to ensure everything
   is and stays aligned.

2. Owner field shows programming language
   This is taken from the programming-language field in the doap file.
   You can specify multiple programming languages. Piotr Drąg and André
   Klapper ensured that most Core/Core Apps/Apps modules have these
   fields. This should make it easier for someone to suggest a good up
   to date overview of modules to start off with.
   Note: Unfortunately cannot rename the Owner field into programming
   language ☹

3. Stats per week/month/quarter/year
   https://git.gnome.org/browse/gtk+/stats/?period=qofs=10
   e.g. Matthias Clasen apparently does most gtk+ commits.


To ensure that the doap file can be used for more purposes, the
following additional fields are now mandatory for Core/Core Apps/Apps
modules:

- programming-language
- description

DOAP files are only checked when you change them. Changes are reflected
almost immediately.

For the full details behind these DOAP files, see:
https://wiki.gnome.org/Git/FAQ#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F


Aside from above I also slightly changed the wiki.gnome.org header
(e.g. shows RecentChanges+Schedule again). The Schedule is IMO quite
important.
-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Translation commits pushed when rolling a tarball

[Olav Vitters]

On Thu, Jul 31, 2014 at 05:24:55PM +0200, Sébastien Wilmet wrote:
 I think there is no equivalent of 'svn lock' for git, so sending a mail
 is a solution.

I think we could add something as equivalent to svn lock. It takes a bit
of time to setup though, and damned lies (l10n.gnome.org) would have to
be able to handle errors from git.gnome.org.

If enough devs speak up I could maybe make something to lock a
repository against pushes. Maybe with a timeout, maybe not. With SVN
anyone could force a lock to be removed. Not sure of what is best. I
assume a lock should at most be held for 2 hours.

I'd appreciate a bit of insight from some tarball creators aka
maintainers :-P

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Archived git modules

[Olav Vitters]

On Wed, Jul 30, 2014 at 05:12:53PM +0200, Olav Vitters wrote:
 The following git modules have been archived:

- clutter-gstreamermm
- divifund
- drgeo
- firestarter
- gimmie
- gnome-docker
- gnome-launch-box
- gnome-mime-data
- gnome-python-extras
- guikachu
- hipo
- jana
- jumpnbumpmenu
- libgail-gnome
- libgnomecanvas
- libgnomecanvasmm
- nautilus-cd-burner
- nautilus-media
- nautilus-vcs

All above (except gnomecanvas C++ binding) didn't have DOAP files,
though various translators have been committing. IMO waste of translator
time.

Anything can be unarchived of course.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Archived git modules

[Olav Vitters]

The following git modules have been archived:
 - sabayon
 - nanny
 - gnome-python
 - gtk-theme-engine-clearlooks
 - drivel
 - annum
 - at-poke
 - docbook-dtds
 - pygtkglext
 - java-gobject-introspection
 - model-examples
 - j5tester
 - pyorbit
 - podsleuth
 - perl-Champlain
 - perl-Gtk2-Champlain
 - glide
 - pygoocanvas
 - hippo-canvas
 - gnome-python-desktop
 - gnome-globalmenu
 - horizon
 - pygio

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.13.2

[Olav Vitters]

On Thu, May 29, 2014 at 01:33:11PM -0400, Jasper St. Pierre wrote:
 I have made systemd optional in mutter:
 
 https://git.gnome.org/browse/mutter/commit/?id=806a66695077672c6848dd14c6a55781c27ba0e6
 
 This disables the build of our native backend based on KMS, but Wayland
 support is still there in the X11 nested backend. Wayland is still a
 hard-dependency, and currently Wayland hasn't been ported to other systems
 yet. I am still planning on making Wayland optional at some point before
 the 3.14 release.
 
 Our Wayland native implementation will not be portable to non-systemd
 systems, Linux or otherwise. The way I would port things is to port Weston
 to other systems first, and then add a wl_fullscreen_shell backend to
 mutter, which will allow us to run mutter nested under Weston.

Could you write this up on wiki.gnome.org and link it from
https://wiki.gnome.org/PortabilityMatrix? I think it would be good to
already have some basic thoughts on there, even if some things aren't
yet known or subject to change. We could mention on the page that things
are still changing. Once done, we can announce to distributor-list.

Meaning: Don't spend too much time on it, but good to already inform
anyone who might not follow GNOME dev that we'd appreciate them working
on porting Weston, etc.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Offtopic: Git workflow with external repository and git.gnome.org

[Olav Vitters]

Hi,

Bugzilla converted their repository into git. I'd like to host the
changes compared to upstream on git.gnome.org. But at the same time
easily merge the changes from upstream. Further, I'd like to somehow be
able to also move between versions. E.g. from v4.4 to 4.6.

I've asked below to the Bugzilla developers list, but they're silent.

I don't know much about git. Exact commands to type in would be really
helpful. E.g. sometimes a guide assumes you already put the upstream
repository with your changes on another location. Even that small step
makes me think ehh?.

Note: Upstream bugzilla still has a bzr mirror.

Please see below for the original mail I sent to
develop...@bugzilla.org.

=

Is there any recommended workflow people are using in the following
situation:
- be able to commit changes in a self hosted Bugzilla repository
- use that self hosted Bugzilla repository for own installation (easy)
- be able to merge changes from git.mozilla.org
- be able to move from 4.2 branch to 4.4 branch, etc
- be able to see the difference between local and pristine upstream
- how to set all of this up initially?

Any recommended workflow to follow?

I'm pretty much an idiot with git. I've found various guides, just
wondering what people use in practice.

e.g.
http://joshbranchaud.com/blog/2014/01/17/Updating-Forked-Git-Repository-With-Latest-Upstream-Changes.html

Is that what people do? How do you set up the initial fork?

===

Any advice very welcome.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 feature: polari

[Olav Vitters]

On Thu, Oct 03, 2013 at 06:32:04PM +0200, Florian Müllner wrote:
 Polari is a simple IRC client designed for GNOME 3. Tentative designs
 have been around for a while, but hacking only started around Guadec.
 It is obviously not end-user ready at that point, but I'm confident
 that it can be in time for 3.12, thus this feature proposal.

The name is not consistent with other GNOME 3 applications. We now have
Web, Files, Photos, Music, etc. Will the Polari name be kept? Any
concious decision between maintainers and designers? Just wondering why
it is different, we had Bijiben, but it now also calls itself Notes.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 feature: polari

[Olav Vitters]

On Fri, Oct 11, 2013 at 01:08:11PM +0100, Allan Day wrote:
 Olav Vitters o...@vitters.nl wrote:
  On Thu, Oct 03, 2013 at 06:32:04PM +0200, Florian Müllner wrote:
  Polari is a simple IRC client designed for GNOME 3. Tentative designs
  have been around for a while, but hacking only started around Guadec.
  It is obviously not end-user ready at that point, but I'm confident
  that it can be in time for 3.12, thus this feature proposal.
 
  The name is not consistent with other GNOME 3 applications. We now have
  Web, Files, Photos, Music, etc. Will the Polari name be kept? Any
  concious decision between maintainers and designers? Just wondering why
  it is different, we had Bijiben, but it now also calls itself Notes.
 
 The core applications are unbranded and have generic names. The idea
 is that these apps should be installed by default. The generic name is
 appropriate in this case because (a) the app is essentially part of
 the OS and (b) it tells new users what all the default apps do.
 
 I don't think the suggestion is that Polari will be a core app, or
 that distros should install it by default - hence it has a brand of
 its own. It is still a GNOME app though, in the sense that it is
 created by GNOME and follows the GNOME 3 design patterns.

Cool, thanks for clarifying.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Middle click, dumbing down Slashdotted

[Olav Vitters]

On Thu, Sep 26, 2013 at 04:44:17AM -0700, Leslie S Satenstein wrote:
 As Gnome is emulating the Android interface, you should know that if I
 wanted a Android interface to Linux, I would certainly go the Android
 route.   

This is going highly offtopic. Android?!?

People really care about the middle click button. Ok, understood.

Now let's move on or quiet down please.

-- 
Regards,
Olav (I have the ability to moderate)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.12 feature: GNOME Software

[Olav Vitters]

On Tue, Sep 24, 2013 at 02:46:14PM +0100, Richard Hughes wrote:
 - On some distributions, we have basic fonts previews in the addon category
 
 - On some distributions, we have input methods in the addon category

Is there anything a distribution should do? I noticed you wanted
something changed in the Fedora build system. Did I have that right and
do we need similar changes in other distributions?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Correct .doap file syntax for the name tag

[Olav Vitters]

On Wed, Aug 21, 2013 at 12:15:32AM +0200, Andrea Veri wrote:
 2. many other scripts are relying on name matching the exact
 repository-name.

Which ones? No script that I am aware of uses this to figure out the
repository name. It uses https://git.gnome.org/repositories.doap, and
that contains the real repository name.


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Correct .doap file syntax for the name tag

[Olav Vitters]

On Thu, Aug 22, 2013 at 12:28:43PM +0200, Andrea Veri wrote:
 No, sorry for not pointing that out on my previous email, you can use a
 name tag of your choice but it would be simply awesome to have all the
 GitRepositories tags in place.

GitRepositories is really not needed. A script adds that, there is no
need to add such information IMO.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Correct .doap file syntax for the name tag

[Olav Vitters]

On Thu, Aug 22, 2013 at 12:11:11PM +0100, David King wrote:
 However, it is a minor thing, and the current mirror script works
 without it. None of the current sysadmin scripts use the
 GitRepository property, other than injecting it into
 repositories.doap.

You missed handle-ldap-modules.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcing GNOME's official GitHub mirror

[Olav Vitters]

On Mon, Aug 19, 2013 at 05:08:06PM +0200, Mathieu Stumpf wrote:
 Le 2013-08-18 23:13, Olav Vitters a écrit :
 On Sun, Aug 18, 2013 at 01:14:47PM -0400, Super Bisquit wrote:
 Since when did you become a Dr without having an actual doctorate-
 honorary ones don't mean shit?
 
 Since when is such behaviour socially acceptable? Anyway, you're
 banned
 from both lists, bye.
 
 Seriously, having harsh personal discourses is a pity, but
 escalading to
 bare censorship is a shame. Hiding symptom don't help to resolve
 problems.
 
 Freedom come with the ability to make mistakes, including saying
 non-constructive things.

He's totally free to go personal with someone via private email. It is
offtopic for this list, totally inappropriate and socially unacceptable.
Suggest to read the descriptions for these mailing lists. Note that
mailman is free software and anyone is also free to host their own
mailing list.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]

[Olav Vitters]

On Fri, Aug 16, 2013 at 10:00:38AM +0200, Matteo Settenvini wrote:
 If there's interest, we could draft a paragraph or two, so that a bit of
 uniformity in communicating our ideals takes the form of a wider
 protest.

I recommend not doing this.

The code is published under the GPL. If you don't want it used in ways
that goes against whatever you want, change the license. If you think
free software is really important, advocate that. If you have some pet
peeve against Github, GNOME infrastructure is not meant for advocacy
against something. Promote free software and explain why it is good all
your want. All the other stuff: it is like preaching to the choir plus
pretty double standard to complain about something that
a) makes free software more available to people
b) totally allowed by the license

and I do mean the thought behind the license, not just the legal wording.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]

[Olav Vitters]

On Fri, Aug 16, 2013 at 04:50:14PM +0200, Matteo Settenvini wrote:
 In the end, I might just do so, if everyone turns out to be uninterested
 in the fundamental values of free software. For once, I might start by
 canceling my monthly donations. And with me, others — fewer than you
 would gain by aggressive marketing, sure, but still. I always advocate
 for GNOME. I'd hate starting to advocate against it.

Such threats are really not appropriate (aside from questionable form of
communication, I have received loads of threats over the years).

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Passive resistance [was: Re: Announcing GNOME's official GitHub mirror]

[Olav Vitters]

On Fri, Aug 16, 2013 at 10:20:31PM +0300, fr33domlover wrote:
 Therefore, by turning off mirroring for a module, you don't block
 anything or stop anything - you just avoid pointing to a proprietary
 service, which is legitimate in my opinion.

git.gnome.org is also available on Google. It indexes the entire
website, which has the entire code. It is also available on various
other search engines. I find it rather strange that there is such a
focus on something which will spread the idea of free software.
Gitorious existence doesn't make it automatically viable btw.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcing GNOME's official GitHub mirror

[Olav Vitters]

On Sun, Aug 18, 2013 at 01:14:47PM -0400, Super Bisquit wrote:
 Since when did you become a Dr without having an actual doctorate-
 honorary ones don't mean shit?

Since when is such behaviour socially acceptable? Anyway, you're banned
from both lists, bye.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: loomio

[Olav Vitters]

On Tue, Apr 16, 2013 at 10:08:31PM +0100, Marco Scannadinari wrote:
 So you want to have random people suddenly join, be of the decision 
 and
 have equal say? I find that a little bit weird.
 
 As opposed to the method that we have now which is..?

People who are part of the team. If you're investing time into things
you'll have more say.

I think you're mixing up decisions with doing a study? E.g. you assume
because of such a tool suddenly 'GNOME 3' will work different? (to be
clear: I'm asking, not suggesting)

-- 
Regards,
Olav

PS: Please do not cc me on replies.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: loomio

[Olav Vitters]

On Tue, Apr 16, 2013 at 10:06:51PM +0100, Marco Scannadinari wrote:
 If someone posts a proposal on gnome-devel, for example, it would not be
 efficient or easy for each user to give their approval: Yeah I love

Here you clearly assume that it will be used for software development.

If you want to test something, a usability study should be done. Not
random people who show up for some decision. That's going to be just as
biased as having the decision taken by the current people.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: loomio

[Olav Vitters]

On Wed, Apr 17, 2013 at 05:34:55PM +0100, Marco Scannadinari wrote:
 On Tue, Apr 16, 2013 at 10:06:51PM +0100, Marco Scannadinari wrote:
  If someone posts a proposal on gnome-devel, for example, it would 
 not be
  efficient or easy for each user to give their approval: Yeah I love
 
 Here you clearly assume that it will be used for software development.
 
 I did say for example - this service can be used globally accross the
 GNOME Foundation and its groups.
 
 If you want to test something, a usability study should be done. Not
 random people who show up for some decision. That's going to be just 
 as
 biased as having the decision taken by the current people.
 
 I'm not saying that we should invite everyone to the discussion, but
 even so, having random people would be completely un-biased, as they
 would probably have no affiliation with the project (for usability
 studies anyway).

A usability study is totally different than voting! Furthermore, if you
invite random people to join, things *will* be biased. Only people who
care enough will show up.

The objective should be to have usable software. For that, there should
be usability studies. IMO there are not enough usability studies done at
the moment.

But if we lack usability studies, I don't see voting as a solution. IMO
it'll just make things worse.

 We could probably have a discussion locked to members of the
 design-team, devel-team(?), translation-team, etc, and have invites sent
 if someone is not part of the team and would be appreciated in the
 discussion. Even if this feature does not exist, the source is free and
 can be modified on GNOME's own loomio instance if the devs are not
 willing to implement the potential commit(s).

Release team just votes in an IRC channel and we make minutes and write
those on a wiki. Sometimes we're meeting in person and we vote by asking
'who agrees'. I'm not saying a web tool might not help with such cases,
but you're arguing two different things at the same time. Partly about
voting within existing teams, partly that other people should join with
IMO the assumption that would improve usability (I disagree, others
already gave enough explanation why).

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: loomio

[Olav Vitters]

On Mon, Apr 15, 2013 at 05:21:15PM +0100, Marco Scannadinari wrote:
 [0] (Restricted in that users do not know that it exists, or that they
 are allowed to participate. And if they do, they may not be notified of
 a decision meeting when it occurs.)

I don't get this at all.

This implies that there are decision meetings and that the decision is
taken equally by the number of people part of the decision. I don't see
how having a web based tool changes anything regarding being able to be
allowed to participate.

I think it is nice that it will be tried out in practice, but please
don't assume all kinds of things that are somehow supposed to happen.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: loomio

[Olav Vitters]

On Tue, Apr 16, 2013 at 01:49:48PM -0700, Sriram Ramkrishna wrote:
 On Tue, Apr 16, 2013 at 12:53 PM, Olav Vitters o...@vitters.nl wrote:
 
  On Mon, Apr 15, 2013 at 05:21:15PM +0100, Marco Scannadinari wrote:
   [0] (Restricted in that users do not know that it exists, or that they
   are allowed to participate. And if they do, they may not be notified of
   a decision meeting when it occurs.)
 
  I don't get this at all.
 
  This implies that there are decision meetings and that the decision is
  taken equally by the number of people part of the decision. I don't see
  how having a web based tool changes anything regarding being able to be
  allowed to participate.
 
 
 They do exist.  We in the marketing team make tactical and strategic
 decisions all the time.  It might be in code space, but other teams do use
 them.
 
 I think this particular tools documents what decision was made and in what
 context.  That's a little hard to do if you have to scan through emails at
 least for hte marketinig team.  Of course it implies that we have some
 discipline to do this. :-)

So you want to have random people suddenly join, be of the decision and
have equal say? I find that a little bit weird.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: loomio

[Olav Vitters]

On Sun, Apr 14, 2013 at 11:36:54AM +0300, אנטולי קרסנר wrote:
 What do you think?

How are you involved in this? I get the impression that you're involved
and will use GNOME in your marketing material.

Initial impressions:
- lacks silent thinking ideas
- surveys should not be public during voting period
- surveys assume all people have an equal say, this is not the case

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: loomio

[Olav Vitters]

On Mon, Apr 15, 2013 at 03:33:06PM +0300, אנטולי קרסנר wrote:
 So I'm not attacking the relevance of existing tools. I'm suggesting a
 tool which may be better for some use cases. Maybe it can, maybe it
 can't, but don't judge so quickly.

It just seems some basics are missing. What is missing from what we
currently have, what are the benefits or what we currently have. Then go
on to check what can solve it in a better way.

At the moment I'm guessing:
1. wish for all decisions to be documented
2. decisions to be easily findable by people who are not involved
3. all components of a decision to be logged

If above is a good summary, then:
#1 is nice to have, #3 is IMO unrealistic, #2 is not the right focus,
should be better if people taking decisions can log their reasoning more
easily.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How long should it take to fix a obvious memory leak?

[Olav Vitters]

On Thu, Apr 04, 2013 at 10:44:22PM +0800, Ma Xiaojun wrote:
 Are suggesting that GNOME are maintained by a group of hobbyist?
 How to prove your seriousness about your distributed software?

sarcasm
I am a hobbyist. I am aware that there is something wrong with that, for
which I apologize. Where I work we do indeed pride ourselves behaving
any way we like, because it does not matter at all how people are
treated, as we are getting paid.
/sarcasm

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How long should it take to fix a obvious memory leak?

[Olav Vitters]

On Thu, Apr 04, 2013 at 11:51:50PM +0800, Ma Xiaojun wrote:
 I understand it's good to ask nicely.
 But for this bug, such job is done by other people already.

Are you really saying that you're out to be annoying? Not sure how you
expect to get things done with such an attitude (in this project).

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How long should it take to fix a obvious memory leak?

[Olav Vitters]

On Thu, Apr 04, 2013 at 11:19:49PM +0800, Ma Xiaojun wrote:
 On Thu, Apr 4, 2013 at 11:15 PM, Alberto Ruiz ar...@gnome.org wrote:
  And?
 
 No need to further rant how you tend to make excuses of bugs rather
 than try hard to fix them.

Every software has bugs. GNOME has loads. We have Bugzilla to track
them. Help is appreciated to fix these, but pretty much all the
developers know that there are bugs.

Sometimes bugs are forgotten and just a ping is enough to get some
progress in a bug.

The entire OMG there is a bug thing is not impressive.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How long should it take to fix a obvious memory leak?

[Olav Vitters]

On Thu, Apr 04, 2013 at 11:16:21PM +0800, Ma Xiaojun wrote:
 On Thu, Apr 4, 2013 at 11:14 PM, Karen Sandler ka...@gnome.org wrote:
  Community dynamics are an important part of how GNOME functions generally
  and all discussion here should be mindful of that fact. Harsh and negative
  tone frustrates productive discussion and often causes unnecessary
  reaction traffic which just wastes people's time.
 
 Everyone would be happy if any of you fix the real problem rather than
 educating about community dynamics.

Don't speak on my behalf or anyone else here please.

I'm not a developer, nor is Karen. We seem to be in agreement that your
tone is not very encouraging and trying to make that clear to you.

If you don't care, cool. But at least understand that we're fine with
not being developers.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: How long should it take to fix a obvious memory leak?

[Olav Vitters]

On Fri, Apr 05, 2013 at 12:36:09AM +0800, Ma Xiaojun wrote:
 This is nice answer.
 But people didn't answer the OP question honestly.
 They just try to prove that I was rude and try to make excuses of the OP bug.

You already got an answer that pygtk is not maintained, and that gobject
introspection is the thing which is maintained. Seems really clear.

Further, that you want to have this bug fixed does not mean anything to
me. I'm not a developer. You see this as excuses, seems a somewhat
strange interpretation to me.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Love flyer and help

[Olav Vitters]

On Thu, Apr 04, 2013 at 02:55:58PM -0400, Marina Zhurakhinskaya wrote:
 Thanks to design and edits by Fabiana Simões and Andreas Nilsson and
 edits by Flavia Weisghizzi, Karen Sandler, and me, we now have a GNOME
 Love flyer! Please bring it to any conference or event where you can
 encourage people to join GNOME, especially if there is a GNOME booth
 at the event.
 
 https://live.gnome.org/GnomeMarketing/ConferenceMaterial#Flyer
 
 Also, it would be really great to have more people helping out
 newcomers on #gnome-love IRC channel and
 https://mail.gnome.org/mailman/listinfo/gnome-love mailing list. There
 are often questions there and help answering them would be really
 appreciated!

When replying, please change foundation-list-bounces into
foundation-list.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fix check for systemd in modules that talk to logind

[Olav Vitters]

On Thu, Mar 21, 2013 at 07:03:24AM +0100, Martin Pitt wrote:
 This affects the following GNOME modules:
 
   gnome-shell gnome-session gnome-screensaver gdm gnome-system-monitor
 
 and the following software around/beneath GNOME:
 
   pulseaudio accountsservice upower udisks dbus
 
 I will file bugs with patches for those in the next days. IMHO they
 are unintrusive enough to be included into GNOME 3.8.1, but if you
 want to wait until 3.9.x we can just distro-patch packages until then.

As upstream agrees with you, let's include this in either 3.8.0 or
3.8.1.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Porting GNOME to Wayland

[Olav Vitters]

On Mon, Mar 18, 2013 at 05:31:38PM +, Patrick Welche wrote:
 More of a Wayland FAQ, but on which OSes does Wayland run?

I thought it is not Linux-only, but I am not sure. Anyone know?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Porting GNOME to Wayland

[Olav Vitters]

On Fri, Mar 15, 2013 at 02:32:51PM -0400, Matthias Clasen wrote:
 Spring is in the air - things change, people are looking for things to
 try and new goals. I propose that we set ourselves a new goal: port
 GNOME to Wayland

Based on the lack of negative feedback, I've updated
https://live.gnome.org/ReleasePlanning/WhatWeRelease with the following:

| Recommended components
| 
| It is assumed and encouraged (but not required!) that distributions
| make use of the following technologies:
|  * Wayland
|  * systemd

The assumed and encouraged means that you might run into bugs we have
not noticed because we (most GNOME developers) do not test the other
code paths much. Obviously that is a slow gradual process for Wayland.
At the moment, no Wayland thing. In future you might have to file some
bugs. Plan is to revisit this at GNOME 3.10.

Please do not forget it also specifies but not required.

On a personal note I highly encourage Linux distributions to use systemd
irrespective of any not required.
-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Porting GNOME to Wayland NFS performance in GNOME 3

[Olav Vitters]

On Tue, Mar 19, 2013 at 12:48:40AM +0100, stefan skoglund(agj) wrote:
 The RedHat thing is a really longlived bug in redhats bugzilla about
 gvfs metadata induced overload of NFS servers. That bug is rather bad
 and i think that if it isn't resolved it will make GNOME3 impossible to
 run in NFS-environments.

Could you please stop using vague phrases like 'RedHat thing'. I have no
idea what you're talking about. Either be specific, or just stop. It
seems you're referring to GNOME, which is not a 'RedHat thing'. But
actually I have no clue at all what you're suggesting with that. I am
pretty sure that you're wrong though.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bijiben

[Olav Vitters]

On Tue, Mar 12, 2013 at 06:44:24PM +0100, Pierre-Yves Luyten wrote:
 I'm requesting a new module inclusion : Bijiben
 It's another note taking application [1] - goal is to implement Notes
 design [2]

Shown as a preview app in 3.8 release notes:
https://help.gnome.org/misc/release-notes/3.8/more-apps.html.en
username/password: gnome / ftw

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcement/RFC: jhbuild continuous integration testing

[Olav Vitters]

On Thu, Feb 14, 2013 at 07:12:10AM +0100, Martin Pitt wrote:
 That is indeed the long-term plan, but there's still some work to be
 done before we can do that. The machine we are running this on has 64
 2.7 GHz cores and 64 GB of RAM, that really isn't a bottleneck right
 now. The main two problems right now are that the jhbuild update
 stage takes some 5 minutes to update all the ~ 160 git trees, and
 that jhbuild build doesn't parallelize at all, i. e. build modules
 which don't depend on each other could build in parallel.

Could you perhaps do a test that does 10 git checkouts at once (real
ones, while things are updated and so on)? I think you might eventually
run into issues with the bandwidth between Red Hat NOC and Canonical
NOC.

If you see a bottleneck problem, please say so so that it can be worked
on at the same time as parallelizing jhbuild. E.g. there was a plan to
mirror git.gnome.org, but there are also a few GNOME servers @
Canonical that could be reused.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcement/RFC: jhbuild continuous integration testing

[Olav Vitters]

On Wed, Feb 13, 2013 at 06:53:17AM +0100, Martin Pitt wrote:
 Travis Reitter [2013-02-12 13:21 -0800]:
  On Tue, 2013-02-12 at 07:43 +0100, Martin Pitt wrote:
   To make this really useful, we can't rely on developers checking this
   every hour or every day, of course; instead we need push notifications
   as soon as a module starts failing. That's the bit which needs broader
   discussion and consent.
  
  I'd like to offer:
  
  (0) auto-file an urgent/critical bug against the module in the case of
  build breaks (and maybe high/major for test breaks?)
 
 Claudio Saavedra [2013-02-12 23:24 +0200]:
  (3) Automatically filing a bug in the broken module with the details of
  the breakage and additionally CC: whoever might be interested in keeping
  an eye on the continuous integration?
 
 This creates more overhead, but I like this proposal as well. I guess
 one can use python-bzutils and the like to auto-create bugs, and
 remember on the Jenkins side which bug was opened for which module,
 and auto-close it once the build works again.
 
 The main issue that I see with this is that it's much harder to filter
 away/opt out, so it requires some broader consensus that we want to do
 this. We can still add a module blacklist if needed, though.

I think build issues should be filed as Bugzilla bugs. At most we maybe
want to set some keyword / status whiteboard. But I guess the summary
would be consistent and people will quickly learn of it.

You can use information from DOAP files to figure out the Bugzilla
product. This is not always needed. Then commit whatever DOAP fixes are
needed (the DOAP files are not bug free :P. In case someone wants to opt
out, we can add a new gnome-specific option to the DOAP file specifying
that any Continuous Integration is not welcome.

What I do in ftpadmin (see sysadmin-bin) is:
- Check if there is a bug-database with 'bugzilla.gnome.org'
  For those URL(s): Check if the URL containers product=$SOMETHING
- If there is a good product: use that
- else: assume tarball = bugzilla product (will fail for jhbuild, often
  modules are renamed and you don't know the real one)

Note: Not all products are on bugzilla.gnome.org. Maybe after GNOME
bugzilla, strive for 'bugs.freedesktop.org'?

For monitoring these bugs, you can easily watch people in Bugzilla.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcement/RFC: jhbuild continuous integration testing

[Olav Vitters]

On Wed, Feb 13, 2013 at 11:23:52AM +0100, Bastien Nocera wrote:
 On Wed, 2013-02-13 at 10:59 +0100, Olav Vitters wrote:
  On Wed, Feb 13, 2013 at 06:53:17AM +0100, Martin Pitt wrote:
   The main issue that I see with this is that it's much harder to filter
   away/opt out, so it requires some broader consensus that we want to do
   this. We can still add a module blacklist if needed, though.
  
  I think build issues should be filed as Bugzilla bugs. At most we maybe
  want to set some keyword / status whiteboard. But I guess the summary
  would be consistent and people will quickly learn of it.
 
 They should be filed as Bugzilla bugs *after a timeout*. We already see
 build failures on ostree popping up on the #testable channel, and those
 are usually fixed in a timely manner.

Hmm, makes sense. Maybe start of small?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome shell is really awesome

[Olav Vitters]

On Fri, Dec 07, 2012 at 10:47:04AM -0800, Christopher Wortman wrote:
 I hear that you are adding Gnome 2 features, and I have sat and thought and 
 pondered this for a long time.

It is still under development, but you can see some non-even alpha
quality screenshots:
http://blogs.gnome.org/mclasen/2013/01/25/gnome-3-7-at-the-halfway-mark/

I guess it'll take a few GNOME versions to get fully 'right' (we get way
more feedback once it is in a few stable distributions, some of which
can conflict with what is heard during the development cycle).


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [PATCH] rename session-save to -quit in man page

[Olav Vitters]

On Sat, Nov 24, 2012 at 11:50:18PM -0500, nick black wrote:
 The gnome-session-properties(1) man page references gnome-session-save,
 which has been renamed to gnome-session-quit. Trivial patch. Please apply.
 This patch originated in development for SprezzOS 1.0.0.

Please attach it to Bugzilla. Most people use a script called git-bz to
easily submit git formatted patches to Bugzilla. See
https://live.gnome.org/Git/Developers.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

configure.in

[Olav Vitters]

I saw a plan that auto* is planning to drop support for configure.in,
and only support configure.ac. Should we do a GNOME goal to ensure
everyone uses configure.ac or is this an easy 'waiting for champagne @
24.00' task?

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome goals for 3.6

[Olav Vitters]

On Mon, Dec 17, 2012 at 10:44:32AM +0100, Daniel Mustieles García wrote:
 Just a quick question about this topic.
 
 Which is the attribute equivalent to small? I'm migrating
 gnome-terminal and I need to change this value.

$ python
Python 2.7.3 (default, Aug  5 2012, 23:17:03)
[GCC 4.7.1] on linux2
Type help, copyright, credits or license for more information.
 import pango
 pango.SCALE_
pango.SCALE_LARGE pango.SCALE_SMALL pango.SCALE_XX_SMALL
pango.SCALE_X_SMALL
pango.SCALE_MEDIUMpango.SCALE_XX_LARGE  pango.SCALE_X_LARGE
 pango.SCALE_LARGE
1.2
 pango.SCALE_SMALL
0.8


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla upgrade work

[Olav Vitters]

On Mon, Dec 17, 2012 at 11:03:39AM +0100, Milan Crha wrote:
 thanks a lot for that. I'm wondering, will you cover also bugs targeted
 to Bugzilla 4.2, say those with patches? [1] Some looks harder, some
 simpler, on the first look, and I thought it'll be good to get rid of
 them together with the upgrade. What do you think?

Initially the focus is just on porting whatever we have now. After that
is running (which takes enough time), bugs can be fixed. I will probably
WONTFIX some things though.

Note that it makes more sense to just target 4.4.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla upgrade work

[Olav Vitters]

On Sat, Dec 15, 2012 at 11:06:03AM -0800, Sriram Ramkrishna wrote:
 Is there some way we could make these extensions and patches we can put in
 a puppet install?  I realize the database portion is going to be the manual
 stuff, but it seems that it would be easier to be able to automate it.  Of
 course, this is just my observation and I have not looked at the process.

That is just deploying. The major problem is the changes to the code
(doing development). What is minor is installing all the Bugzilla
dependencies, this is already in Puppet.

Not sure if the bzr setup is in Puppet, but that is minor effort. Feel
free to help out with that, I think it'll need changes anyway as likely
the current Puppet config is not right for Bugzilla 4.2/4.4.


-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Bugzilla upgrade work

[Olav Vitters]

If anyone wants to join, I'll work on Bugzilla during Dec 22 - Dec 30
together with Andrea.

Recommended to know:
 - Bugzilla
 - GNOME Bugzilla (it is not standard :P)
   see https://launchpad.net/bugzilla.gnome.org for the code and
   instructions to see the diff vs vanilla 3.4)
 - Perl
 - read up on Bugzilla extensions
 - understand the various extensions I've written
   (http://bzr.mozilla.org/bugzilla/extensions/: Browse, DescribeUser,
   Developers, GNOME, PatchReport, ProductInterests, StockAnswers,
   WeeklyBugSummary)

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla upgrade? [was: Re: GNOME Bugmail: Gmail threading finally working!]

[Olav Vitters]

On Wed, Dec 12, 2012 at 06:33:17PM +0100, Andre Klapper wrote:
 On Wed, 2012-12-12 at 18:10 +0100, Olav Vitters wrote:
  That is why there is a GNOME extension as well.
 
 Then there's likely missing documentation about dependencies. 
 Currently no README file in the Browse extension would even tell you
 that it comes from GNOME. Hence non-insiders wouldn't know that the
 GNOME extension is needed.

There were 3+ months between writing these extensions and getting my
Mozilla bzr account reactivated. I lost interest somewhere in those 3
months. Eventually I wanted to go at it again, but my machine at home is
not quick enough to handle a full GNOME Bugzilla database conversion
from 3.4 to 4.2 (OOM after 24+ hours; from previous upgrades I know I'll
test the conversion many many times). Coupled with the various lack of
RHEL licenses to create VMs @ GNOME, inability to create VMs myself,
etc.

My main focus with these extensions was bugzilla.gnome.org. That they
might not work on other installations is on the todo list, but patches
welcome.. should not be difficult.

Bugzilla 4.4 meanwhile is either out or almost out, so more work to see
what changed for extensions.

I'm planning to buy a new machine with loads more memory, but to be
honest there are so many things which go wrong every time, it is not
something which I often thing as something nice.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME Bugmail: Gmail threading finally working!

[Olav Vitters]

On Wed, Dec 12, 2012 at 02:15:30PM +0100, Andrea Veri wrote:
 I introduced a little fix yesterday night that will modify how bugmail's
 subjects appear, that for Gmail's threading to work properly. (as you may
 know Gmail doesn't look for the In-Reply-To: header but for the subject
 instead)
 
 New bugs won't be marked with the 'New:' tag anymore while replies will
 append a 'Re:' as it usually happens with the majority of mail clients.
 
 I would like to thank Jasper St. Pierre for pushing this forward!

I undid that change as you didn't say to me you were making changes.
Furthermore it it broke my filtering, it won't work in every case, it
should be pushed upstream first, secondly you made the change on the
server, not in the repository.

Regarding does not work, Re: is not needed for threading. In-Reply-To
and so on are. Gmail only threads by subject, so any time the subject is
adjusted it'll break again.

Please make the change *upstream* first, I cannot maintain Bugzilla as
it is now.

I do really appreciate all the work you're doing. Please do not see
above as a stop, but prefer if someone would takeover the maintenance,
not small changes which increase maintenance.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla upgrade? [was: Re: GNOME Bugmail: Gmail threading finally working!]

[Olav Vitters]

On Wed, Dec 12, 2012 at 04:48:43PM +0100, Andrea Veri wrote:
 Thanks for bringing this up Andre. I can try to work on the upgrade but I
 never touched Bugzilla before since Olav was used to manage it. I've
 searched around for the upgrade documentation [1] and it doesn't look like
 an hard operation. We should probably wait for Olav to provide some more
 details about the modifications that GNOME made to customize our
 installation, that might be the only bottleneck for a possible upgrade.

Those modifications is the sole reason we're running 3.4.

 But let's keep all the ports open, having someone to assist me during the
 operations will definitely speed everything up for this matter.

Do *NOT* touch Bugzilla. As mentioned before, there are *load* and
*loads* of customizations and I don't mind anyone taking over
maintenance. However, there is a real big difference between taking over
maintainer role and installing a pristine new upstream version on
bugzilla.gnome.org.

 2012/12/12 Andre Klapper ak...@gmx.net
 
  On Wed, 2012-12-12 at 16:06 +0100, Andrea Veri wrote:
   This was just a temporary measure until we upgrade our Bugzilla to the
  4.2
   release.

The change you made was not communicated to the people maintaining it,
furthermore although you say the change is upstream, the change you
applied is not what is upstream, nor similar. It broke my filtering and
I wonder what other impact it had.

I not want to turn this into stop energy, but please communicate a
little bit.

  Which brings us to the bigger question how to get GNOME Bugzilla from
  3.4 to 4.2. I don't even know if somebody cares to check and backports
  security upgrades to GNOME Bugzilla.
  IIRC, when upgrading from 2.20 to 3.4 we received gracious sponsoring by
  Canonical to pay Max for this task.
  If nobody has plans to try, this might be something to defer to the
  foundation board in order to organize sponsoring?

I'm not backporting any security fixes. Only did that while 3.4 was
still maintained upstream.

  I guess I don't need to copy and paste all improvements from the last
  three upstream release notes to explain why I push for upgrading.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla upgrade? [was: Re: GNOME Bugmail: Gmail threading finally working!]

[Olav Vitters]

On Wed, Dec 12, 2012 at 04:58:48PM +0100, Olav Vitters wrote:
 Do *NOT* touch Bugzilla. As mentioned before, there are *load* and

with the not touching I meant in case of an intended action of just
upgrading to a new vanilla upstream version.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla upgrade? [was: Re: GNOME Bugmail: Gmail threading finally working!]

[Olav Vitters]

On Wed, Dec 12, 2012 at 05:17:54PM +0100, Andre Klapper wrote:
 On Wed, 2012-12-12 at 16:48 +0100, Andrea Veri wrote:
  Thanks for bringing this up Andre. I can try to work on the upgrade
  but I never touched Bugzilla before since Olav was used to manage it.
  I've searched around for the upgrade documentation [1] and it doesn't
  look like an hard operation.
 
 It will be hard. GNOME Bugzilla is heavily customized (e.g. patch status
 dropdown) and some changes need to be converted to proper extensions
 (like Browse, PatchReview, WeeklyBugSummary, StockAnswers).

I did that already.

  We should probably wait for Olav to provide some more details about
  the modifications that GNOME made to customize our installation, that
  might be the only bottleneck for a possible upgrade.
 
 Would be helpful if Olav could outline that, yes. There's a raw codedump
 of some stuff at http://bzr.mozilla.org/bugzilla/extensions/ which is
 untested and non-working in its current state.

Sure? It does work and I did do loads of testing.. but been a long time
since I worked on it.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Bugzilla upgrade? [was: Re: GNOME Bugmail: Gmail threading finally working!]

[Olav Vitters]

On Wed, Dec 12, 2012 at 05:42:16PM +0100, Andre Klapper wrote:
 On Wed, 2012-12-12 at 17:24 +0100, Olav Vitters wrote:
   Would be helpful if Olav could outline that, yes. There's a raw codedump
   of some stuff at http://bzr.mozilla.org/bugzilla/extensions/ which is
   untested and non-working in its current state.
  
  Sure? It does work and I did do loads of testing.. but been a long time
  since I worked on it.
 
 Maybe it works on the GNOME Bugzilla *database*, true.

I tested it on a clean database.

 I only tested on a clean Bugzilla with default fields (as there are no
 dumps of GNOME Bugzilla data so nobody could test anyway, right?). 
 On a clean BZ I get lots of issues due to GNOME-specific implementations
 like expecting the existence of the GNOME Target custom field etc.

That is why there is a GNOME extension as well.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Gnome-main-menu maintainership goes to MATE

[Olav Vitters]

On Tue, Nov 27, 2012 at 04:03:38PM -0600, Federico Mena Quintero wrote:
 Both Nelson and Stefano have requested git.gnome.org accounts; the code
 will still live there.  I'll take care of giving them Bugzilla
 privileges.

Note that if you want anyone else in the MATE project to have git
accounts, just have them request git accounts and select
'gnome-main-menu' as voucher module. Make sure you've been in the DOAP
file for 24+ hours before doing that. You'll get an (automated) email
once you're able to approve accounts.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[Olav Vitters]

On Wed, Nov 21, 2012 at 06:47:35PM -0600, Ma Xiaojun wrote:
 Though it seems hopeless to change the decision, I find some tendency 
 annoying.

You missed the obvious answer:
- Need to ensure that the driver supports what the hardware is capable
  of.

 2. Folks can use LLVMpipe.

llvmpipe is not meant as a replacement. The solution is good drivers,
llvmpipe should be seen as a workaround to at least be able to use GNOME 3.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fallback mode is going away - what now ?

[Olav Vitters]

On Wed, Nov 21, 2012 at 08:17:16AM -0500, Matthias Clasen wrote:
 We haven't made a final decision yet on how to let users turn on this
 'classic mode' - it may be a switch in gnome-tweak-tool or something
 else.

I'm wondering if we cannot just change the fallback mode switch into a
traditional toggle (IMO classical is not the right word). I know it
goes against the vision, etc, but I don't care. If this is supported it
should be easily findable, not rely on gnome-tweak-tool.

We should exactly define what it does though, not expand on that.

Suggest to also include a small note that this mode is not what we
designed things for, and as a result some things might work worse than
intended.
-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal for 3.8: Python 3 -- impact for pygobject itself

[Olav Vitters]

On Mon, Nov 05, 2012 at 10:28:35AM +0100, Martin Pitt wrote:
 Should I just change the default to python3, so that jhbuild will
 from now on build for py3 unless you explicitly configure for python2?
 That would go along with that goal, but would break modules which
 expect pygobject for py2.

The default should be changed. If jhbuild could still something like a
fake pygobject-python2 which still builds the py2 supports then it
should be quite an easy change.

 Or should we hack the build system to build for both 2 and 3 at the
 same time? This would involve tearing apart some chicken in the
 autotools setup, and no other Python module does it that way, but it
 might help with the transition?

I prefer a jhbuild hack as it seems easier. Any distribution likely
already dealt with this.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal for 3.8: Python 3 -- impact for pygobject itself

[Olav Vitters]

On Mon, Nov 05, 2012 at 06:45:04AM -0500, Matthias Clasen wrote:
 On Mon, Nov 5, 2012 at 4:56 AM, Olav Vitters o...@vitters.nl wrote:
 
 
  I prefer a jhbuild hack as it seems easier. Any distribution likely
  already dealt with this.
 
 
 For Fedora, we have a python3-gobject package.
 
 I think what the goal page is missing is some advice on how to
 concretely do the porting.

Aren't the references enough?

 Is it enough to export PYTHON=/usr/bin/python3 and check that everything 
 works ?

There is also a script to change v2 to v3. Then I assume run it and
done. There might be more involved when you're not using gobject
introspection.

 Should we replace python by python3 in shebang lines ?

Yes, that is recommended.

 I'm not much of a python persom myself, so I don't know the answers.

Note that there are also automatic statistics.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal for 3.8: Python 3 -- impact for pygobject itself

[Olav Vitters]

On Mon, Nov 05, 2012 at 08:04:50AM -0500, Colin Walters wrote:
 Longer answer: The Python3 porting should really be focused along
 runtime/devel lines first.  What I mean by this is that ideally for a

If someone could add some priority to the modules I'd appreciate. The
Python3 porting is one of the few things I think I can actually assist
with ;)
Haven't used anything other than v2 atm though.
-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Blocker bug status

[Olav Vitters]

On Mon, Sep 17, 2012 at 12:32:41PM +0100, Bastien Nocera wrote:
 Em Mon, 2012-09-17 às 12:37 +0200, Andre Klapper escreveu:
  On Mon, 2012-09-17 at 12:19 +0200, Bastien Nocera wrote:
   I can't reproduce the problem, and nobody spent
   time root-causing it, so I can't do anything.
  
  Any instructions how to provide useful info that could be added to the
  report for users running into this?
 
 I've pushed a patch that should make it easier to debug.

I can reproduce at will. Disabling the remember-numlock gsetting avoids
the issue. Don't use jhbuild, but can do something after .92.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: High Resolution Gnome

[Olav Vitters]

On Fri, Sep 07, 2012 at 06:06:12AM -0400, Matthias Clasen wrote:
 From my quick reading, the shell should pick up the same cursor theme
 as gtk applications, but I could missing something...

Jason: Please file a bug on this against gnome-shell. Maybe we need a
tracker bug to fix all the cases where the cursor theme size is not
followed, but suggest to start off with just 1 bug.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Support both gstreamer 0.10 and 1.0 for GNOME 3.6?

[Olav Vitters]

On Wed, Aug 01, 2012 at 04:45:14PM +0200, Marc-André Lureau wrote:
 I think gnome-media should be moved to a deprecated read-only
 directory (or something similar), and we focus on Florent effort to
 build a better recorder for gnome. But I can imagine some people would
 prefer to have the current gnome-sound-recorder ported to 1.0 first.
 In this case, we could still create a seperate recorder project and
 move things there, until we decide to switch to Florent's version.

gnome-media also contains gstreamer-properties. Is that needed? Maybe
should be part of gstreamer itself.

Regarding gnome-sound-recorder: Would that new recorder be usable for
GNOME 3.6? Don't forget that UI and feature freeze is on Aug 20!

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: compiler warnings, -Werror, etc.

[Olav Vitters]

On Fri, Jul 27, 2012 at 01:24:39PM -0400, Colin Walters wrote:
 Not everything uses GNOME_COMPILE_WARNINGS, but that's not a big deal -
 my main goal here is to in order:
 
 1) Convince module maintainers not to use -Wall -Werror

In Mageia we either file bugs for -Werror, or the -Werror is patched
out. This is done randomly. So making -Werror useful again would be
nice.

Note that if -Werror is patched out, that patch is reused until it does
not apply.

 2) Ensure we *do* use -Werror=format-security and the other core ones.
That one is often injected by distributions right now, and it only
therefore potentially gets noticed fixed after release when tarballs
are rolled or whatever.

I'd really appreciate the format-security one. I usually just commit
fixes for that. Other packagers sometimes file bugs, sometimes not.
Always patched downstream though.

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Again: please clarify the decision on IBus integration

[Olav Vitters]

On Tue, Jul 10, 2012 at 05:55:53PM +0800, Aron Xu wrote:
 You actually don't know. Do you use input method everyday? If you do,
 then I'm wrong; if not, then you are wrong. This is simple to
 understand. Please be modest  when talking about techinical stuff, you
 are not an expert of inputing system for complex character sets, are
 you?

These discussions seems to be going nowhere?

Yesterday release team was asked if the code could be merged or not.
Various gave a +1. We're having a meeting were we'll quickly discuss
this as well, but I really do not see why I shouldn't have given a +1.
-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Again: please clarify the decision on IBus integration

[Olav Vitters]

On Mon, Jul 09, 2012 at 10:45:34AM +0800, Aron Xu wrote:
 I would like to get your clarification about what's your decision on
 IBus integration because all of us haven't reached to an agreement on
 the whole thing. While I feel that you'll do it regardless of

From what I understood, you can still have different input methods. It
is just that IBus will be default. With work, you can still setup
something different.

Please don't revert commits, that's is not the way to do things.

FWIW, I found previous threads to be utterly confusing. I had to read
the LWN summary to make sense out of them
(https://lwn.net/Articles/503320/).

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and high-DPI screens

[Olav Vitters]

On Tue, Jul 03, 2012 at 11:34:04PM -0700, Brion Vibber wrote:
 What can regular users and casual developers do to help today? Should we
 report things that don't scale as expected, or wait for something to get
 into place before we start?

For starters, bugs should be filed. There is one Gtk+ bug for high dpi
screens:
https://bugzilla.gnome.org/show_bug.cgi?id=546711
it got a bit unreadable though.

But I guess it needs some thought. E.g. DPI data cannot be relied upon
(as discussed many times before). I saw another Gtk+ bug on windows
where apparently an application has to notify that it supports high DPI
screens.

 I'm sure there won't be any fast fix-all solutions, but as screens with 1.5
 and 2x the resolution of classic screens trickle out to more laptops in the
 future, this'll be something that needs addressing...

Agree. Best to give developers high DPI screens (not kidding).

-- 
Regards,
Olav
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list