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

[Frederic Peters]

Bastien Nocera wrote:

> I haven't looked at library-web because I have a whole bunch of work
> that I'd need to do with it, but not the bandwidth...

I pushed an untested minimal change.


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

Re: How to manually update https://help.gnome.org/users/$PROJECT?

[Frederic Peters]

Milan Crha wrote:

> I'm not sure whether this is the right list for this, thus I'm sorry if
> it's not. Feel free to redirect me to the right place.

gnome-doc-list@ would be the right place, especially as there are
plans to redo help.gnome.org. (ditto for developer.gnome.org).


> I'd like to ask: how do I manually update content of 
> https://help.gnome.org/users/$PROJECT , please?
> 
> As (I guess) the [1] is no near to be fixed/implemented (even though
> basically whole GNOME is affected, due to released tarballs not
> containing needed files), I'd like to update it manually, if it's

fwiw if someone familiar with Python wants to look at it, this comment
points to the place:
  https://gitlab.gnome.org/Infrastructure/library-web/issues/50#note_330963


Frederic
___
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)

[Frederic Peters]

Bastien Nocera wrote:

> - How?
> 
> It is possible to rename the "master" branch in git. It's also possible
> to add a "link" of sorts so that software that specifically references
> "master" can be made to work with the new name[5].

I checked and there is an hardcoded reference (git) master (branch) in
library-web; while other GNOME changes did destroy much of library-web
(meson without alternative way to get gtk-doc HTML files), it would
still be nice to have the compatibility link (or for someone to step
up and adapt library-web).

And looking at it now, jhbuild, too, has references to the branch.


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

Re: Let's kill gnome-common!

[Frederic Peters]

Milan Crha wrote:

> On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote:
> > Work is in progress to let maintainers upload tarballs with the
> > generate API reference for developer.gnome.org
> 
>   Hi,
> okay, how is that supposed to work in general? As Meson builds out of
> the source tree, is that "work in progress" meant to be Meson specific?

Developer.gnome.org still looks for "markers" in source tarballs (like
include gtk-doc.make in Makefile.am) and use those to extract the
documentation module name (ex: for gtk+ it would extract three doc
modules, gtk4, gdk4, gsk4).

What's new and in progress is the possibility to map those modules to
external documentation tarballs that will contain the generated HTML
files.

Some parts of the process are in place already, from manually
generated documentation tarballs for GTK+, published at:
  https://download.gnome.org/docs/gtk+/3.93/
we can now create https://developer.gnome.org/gtk4/3.93/

(this is very fresh, literally two days ago)

Now no maintainer would want the burden to generate those additional
tarballs and they should be automatically created and published by a
CI system (gnome continuous or buildstream or whatever).

Wrt evolution developer.gnome.org still lacks the code to find the
gtk-doc markers in CMakeLits.txt files. (some experimental code was
added for meson as used in GTK+)


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

Re: Let's kill gnome-common!

[Frederic Peters]

Emmanuele Bassi wrote:

> > I do not want to steal the thread, but when talking about ports to
> > Meson, would it make sense to finally fix the infrastructure to work
> > with other than automake files too [1]? It's when generating the
> > content for developer.|help.gnome.org. Considering that plenty of
> > projects already use Meson, either exclusively or as an alternative for
> > autotools scripts, then it would be a good idea, from my point of view.
> > I'd help myself there, but I do no speak pythonish. I guess someone
> > with the knowledge would have that fixed relatively quickly.
> 
> Work is in progress to let maintainers upload tarballs with the
> generate API reference for developer.gnome.org; I assume
> help.gnome.org would follow the same pattern — but of course we only
> have one Frederic, so help is indeed welcome.

Actually help.gnome.org is different and easier as the mallard files
can be converted to HTML without a full build environment (contrary to
gtk-doc); a plan is laid out in bugzilla (#785522) and should be quite
simple for anybody with some Python experience:

  https://git.gnome.org/browse/library-web/tree/src/lgo.py#n700 should
  be updated to detect other cases, like looking for "set(HELPID" in
  CMakeLists.txt files, or help_files in meson.build.

  Then 
https://git.gnome.org/browse/library-web/tree/src/modtypes/mallard.py#n240
  should be changed to get the list of mallard files from those
  CMakeLists.txt/meson.build files. (alternatively it could just take
  pages and figures and list of languages looking at the filesystem but
  then it may fail with pages/languages that are present in git but not
  supposed to be used).


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

Re: developer.gnome.org and meson

[Frederic Peters]

mcatanz...@gnome.org wrote:

> developer.gnome.org is going to have some problems because for meson modules
> 'ninja dist' does not include generated gtk-doc files in the tarball. At
> least one maintainer is working around this by manually generating tarballs
> with gtk-doc included instead of using 'ninja dist'. I don't recommend doing
> that since that's equivalent to skipping distcheck. It's better to use
> meson's dist target. developer.gnome.org is just going to have to learn to
> build docs itself.

But that often requires a full build environment, which is the reason
it doesn't do that.  Continuous or whatever CI system should include a
step publishing built documentation files, it will then be "easy" for
developer.gnome.org to use those.



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

GNOME 3.21.90 beta tarballs

[Frederic Peters]

Hello all,

This is still GUADEC but we'd really like to have 3.21.90 tarballs
this week, the earlier the better, especially since a notable serie
of modules didn't get 3.21.x releases yet.


Thanks,

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

Re: Keep shipping also generated gtk-doc html/ folder?

[Frederic Peters]

Milan Crha wrote:

> On Thu, 2016-06-23 at 09:55 +0100, Philip Withnall wrote:
> > If I remember correctly, it’s so that the tarballs can be unpacked to
> > give documentation on developer.gnome.org without having to build
> > anything.

Actually gtk-doc did ship the generated files in the tarballs before
developer.gnome.org existed, so when I did that part I reused the
files that already existed.

> I know there had been quite much buzz about the infrastructure
> recently, I hope they won't dislike me, but maybe it would worth to
> reconsider this and do build the devel-doc for the developer.gnome.org
> site (easier to say, than to do, but maybe it could be extracted from
> the Continuous builds?).

developer.gnome.org can certainly be changed to grab generated HTML
files from any place that would have them.

> Also, it seem to me that it's the gtk-doc adding to the tarball that
> folder and couple files, thus the place to focus any changes on might
> be gtk-doc itself.

Also there has been several efforts to build on gobject-introspection
and expand the documentation to more languages, Mathieu Duponchelle is
working on this; if there's interest we can certainly organize a
session on API docs during the GUADEC.



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

GNOME 3.19.2 released

[Frederic Peters]

Hi!

The second snapshot of GNOME 3.19 is now available, it incorporates
updates from 3.18.2 as well as quite a serie of edgier modules.

To compile GNOME 3.19.2, you can use the jhbuild [1] modulesets [2]
(which use the exact tarball versions from the official release).

[1] https://developer.gnome.org/jhbuild/
[2] https://download.gnome.org/teams/releng/3.19.2/

The release notes that describe the changes between 3.18.1 and 3.19.2
are available. Go read them to learn what's new in this release:

core - https://download.gnome.org/core/3.19/3.19.2/NEWS
apps - https://download.gnome.org/apps/3.19/3.19.2/NEWS

The GNOME 3.19.2 release is available here:

core sources - https://download.gnome.org/core/3.19/3.19.2
apps sources - https://download.gnome.org/apps/3.19/3.19.2

WARNING! WARNING! WARNING!
--

This release is a snapshot of early development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development status.

For more information about 3.19, the full schedule, the official
module lists and the proposed module lists, please see:

http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
http://live.gnome.org/Schedule


Cheers,

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

Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]

[Frederic Peters]

Philip Withnall wrote:

> > This was mostly done manually (at least as far I am concerned), but
> > here is an experiment,
> >   https://people.gnome.org/~fpeters/health/wanted-releases.html
> > 
> > And the red modules are first targets.
> > 
> > (this has been generated from my local clones, updated a few hours
> > ago, if it's something we want to pursue it would be quite nice to
> > have this automated and running on GNOME infrastructure) (the disk
> > requirements exclude openshift).
> 
> Nice! If it's not much effort to get this running on GNOME
> infrastructure, I think it would be useful, and have it linked from the
> release reminder e-mails.

Actually I already had https://bugzilla.gnome.org/show_bug.cgi?id=743833
(yeah for bugzilla suggesting duplicates), I added a comment.


> What do the x/y numbers mean?

Numbers are numbers of commits since last tag, first number omits the
translation commits.


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

Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]

[Frederic Peters]

Hi,

Philip Withnall wrote:

> On Wed, 2015-11-25 at 11:07 +0100, Frederic Peters wrote:
> > I'm a bit surprised by 1) but we could certainly automatically
> > produce
> > a list of maintainers / modules/ time/commits since last release, if
> > that could be useful.
> 
> I think 1) would be useful because I have a load of modules which I am
> not sure if they need to follow the main GNOME release schedule. I had
> a nagging fear they should, but then nobody poked me about doing a
> release, so I forgot to check up further. As a result, a lot of my
> modules haven’t had releases following the schedule. (Sorry if I have
> been a total pain because of this.)
> 
> Would such a list be useful for the release team, as a way of tracking
> who needs nagging? If so, then I hope producing it should not be too
> much of a drain on your time — if it is a drain, then you probably
> shouldn’t do it.

This was mostly done manually (at least as far I am concerned), but
here is an experiment,
  https://people.gnome.org/~fpeters/health/wanted-releases.html

And the red modules are first targets.

(this has been generated from my local clones, updated a few hours
ago, if it's something we want to pursue it would be quite nice to
have this automated and running on GNOME infrastructure) (the disk
requirements exclude openshift).


Fred

[code at https://git.gnome.org/browse/releng/tree/tools/health/]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]

[Frederic Peters]

Bastien Nocera wrote:

> > It's been some months we have those reminder emails sent to
> > devel-announce-list.  Maintainers, make sure you are subscribed.
> > 
> > Maintainers (bis), please do try to respect the Monday 23:59 UTC
> > deadline, it's really not fun to chase maintainers for days during
> > release weeks.  If you know you will be late, tell us, either by
> > email
> > at release-t...@gnome.org or simply by pinging us on #release-team.
> 
> I'd rather somebody helped me 1) know which of my modules need
> releasing 2) do releases.

We can of course assist in producing tarballs, just ping us.

I'm a bit surprised by 1) but we could certainly automatically produce
a list of maintainers / modules/ time/commits since last release, if
that could be useful.


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

Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]

[Frederic Peters]

Shaun McCance wrote:

> Question: If I don't intend to make a release because there haven't been
> any changes, do you want me to send an email saying so?

Nope, that's already something we check before chasing people :)

And while it's important to get stable releases out when the only
changes are translation updates it is ok to "ignore" them for (early)
development releases.


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

Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]

[Frederic Peters]

Hi!

> Tarballs are due on 2015-11-23 before 23:59 UTC for the GNOME 3.19.2
> unstable release, which will be delivered on Wednesday. Modules which
> were proposed for inclusion should try to follow the unstable schedule
> so everyone can test them.  Please make sure that your tarballs will
> be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
> will probably be too late to get in 3.19.2. If you are not able to
> make a tarball before this deadline or if you think you'll be late,
> please send a mail to the release team and we'll find someone to roll
> the tarball for you!

It's been some months we have those reminder emails sent to
devel-announce-list.  Maintainers, make sure you are subscribed.

Maintainers (bis), please do try to respect the Monday 23:59 UTC
deadline, it's really not fun to chase maintainers for days during
release weeks.  If you know you will be late, tell us, either by email
at release-t...@gnome.org or simply by pinging us on #release-team.


Thanks for your attention,

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

GNOME 3.17.92 Release Candidate

[Frederic Peters]

Hello all,

Here we are, this is the end of this development cycle and here comes
a release candidate for you to download, build, and test. Enjoy it as
fast as you can, the final release is scheduled next Wednesday.


To compile GNOME 3.17.92, you can use the jhbuild modulesets published
by the release team (which use the exact tarball versions from the
official release).

  https://developer.gnome.org/jhbuild/
  https://download.gnome.org/teams/releng/3.17.92/

We remind you we are string frozen, no string changes may be made
without confirmation from the l10n team (gnome-i18n@) and notification
to both the release team and the GNOME Documentation Project
(gnome-doc-list@).

Hard code freeze is also in place, no source code changes can be made
without approval from the release-team.  Translation and documentation
can continue.

More details about changes and news for this beta are available here:

   core: https://download.gnome.org/core/3.17/3.17.92/NEWS
   apps: https://download.gnome.org/apps/3.17/3.17.92/NEWS


The GNOME 3.17.92 release itself is available here:

   core sources: https://download.gnome.org/core/3.17/3.17.92/
   apps sources: https://download.gnome.org/apps/3.17/3.17.92/



WARNING! WARNING! WARNING!
--

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.17, the full schedule, the official module
lists and the proposed module lists, please see our colorful 3.17 page:
  https://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
  https://wiki.gnome.org/Schedule


Enjoy,

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

Re: How do you hack on GNOME? How can we do better?

[Frederic Peters]

Michael Catanzaro wrote:

> >  3) Hacking on session level components (gnome-session, gnome-shell, 
> > gnome-settings-daemon), and the libraries they use (gnome-desktop, 
> > clutter)
> > [...]
> > Do you log into a jhbuild session? as yourself? as a test user?
> 
> I used to do 3 on rare occasions, but stopped doing that because I no
> longer remember how I ever managed to run a GNOME session under jhbuild
> in the past. There used to be instructions on the wiki, but they got
> deleted at some point because they became outdated. The problems I
> wanted to fix were never so urgent as to convince me to impel me to
> figure it out on my own. Pretty sure new contributors have no chance
> here.

Instructions are still available in the jhbuild documentation itself,
  
https://developer.gnome.org/jhbuild/stable/jhbuild-and-gnome.html.en#running-gnome

There may be errors and parts could be simplified (GDK_USE_XFT...) but
if you're up for it I'd be happy to spend some time with you, during
GUADEC?, to get them working on your laptop, then updated online.

(survey answer: I run such a jhbuild session and I mostly use "jhbuild
make" in the module I'm working on)


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

GNOME 3.17.3 released

[Frederic Peters]

Hey all,

The development of the next GNOME release, 3.17, is going on and a new
snapshot, 3.17.3, is now available.  Give it a shot!  Some of us will
gather in San Francisco next week for the West Coast Summit 2015, and
a month later we will all gather for GUADEC in Gothenburg, Sweden (no
relation whatsoever with a conspiracy that doesn't even exist).

To compile GNOME 3.17.3, you can use the jhbuild[1] modulesets[2]
(which use the exact tarball versions from the official release).

  [1] https://developer.gnome.org/jhbuild/
  [2] https://download.gnome.org/teams/releng/3.17.3/

The release notes that describe the changes between 3.17.2 and 3.17.3
are available. Go read them to learn what's new in this release:

  core - http://download.gnome.org/core/3.17/3.17.3/NEWS
  apps - http://download.gnome.org/apps/3.17/3.17.3/NEWS

The GNOME 3.17.3 release is available here:

  core sources - http://download.gnome.org/core/3.17/3.17.3
  apps sources - http://download.gnome.org/apps/3.17/3.17.3


WARNING! WARNING! WARNING!
--

This release is a snapshot of early development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.17, the full schedule, the official
module lists and the proposed module lists, please see our 3.17 page:
  http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
  http://live.gnome.org/Schedule


Cheers,

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

Re: GNOME Software and fwupd

[Frederic Peters]

Hi Richard

Richard Hughes wrote:
> I've just merged a patch to gnome-software which adds an optional (but
> default enabled) dependency on fwupd[1]. The fwupd project just
> provides a DBus interface for applying low-level firmware to various
> types of devices.
> 
> I don't know if this makes sense for the continuous integration
> server. I don't know if it makes sense to enable by default.
> Installing firmware on more devices would be awesome (and make them
> more secure) but it is Yet Another Dep.
> 
> Comments welcome,

If it stays enabled by default it would have to be added to jhbuild
(or the moduleset changed to disable it forcefully, but that's not
nice), and this would work as long as fwupdate is installed
system-wide, right?

Release-team-hat-on, in time of releases it would help to have
tarballs created with 'make dist(check)' (I think github allows this,
but if that was not the case they could certainly be pushed onto the
GNOME ftp server).


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

TARBALLS DUE: 3.16.1

[Frederic Peters]

Hi!

You've all seen the automated mail posted to devel-announce-list@,
here's another one to remind you that tarballs for 3.16.1 are due
today.

Thanks!

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

Re: GNOME 3.15.92 Release Candidate

[Frederic Peters]

Sriram Ramkrishna wrote:
> On Wed, Mar 18, 2015 at 12:46 PM, Frederic Peters  wrote:
> > Hello all,
> >
> > We have now reached the end of the development cycle and here comes
> > a release candidate for you to download, build, and test. Enjoy it
> > as fast as you can, the final release is scheduled next Wednesday.
> >
> >
> > To compile GNOME 3.15.92, you can use the jhbuild modulesets published
> > by the release team (which use the exact tarball versions from the
> > official release).
> >
> >   https://developer.gnome.org/jhbuild/
> 
> There doesn't seem to be a link for 3.15 or 3.16 here?

The first link is about jhbuild, there's a second link with the
modulesets: https://download.gnome.org/teams/releng/3.15.92/


Still, about the documentation link, I had plans to roll a 3.16
tarball of jhbuild, to get the documentation updates online, I'll get
to it.


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

GNOME 3.15.92 Release Candidate

[Frederic Peters]

Hello all,

We have now reached the end of the development cycle and here comes
a release candidate for you to download, build, and test. Enjoy it
as fast as you can, the final release is scheduled next Wednesday.


To compile GNOME 3.15.92, you can use the jhbuild modulesets published
by the release team (which use the exact tarball versions from the
official release).

  https://developer.gnome.org/jhbuild/
  https://download.gnome.org/teams/releng/3.15.92/

We remind you we are string frozen, no string changes may be made
without confirmation from the l10n team (gnome-i18n@) and notification
to both the release team and the GNOME Documentation Project
(gnome-doc-list@).

Hard code freeze is also in place, no source code changes can be made
without approval from the release-team.  Translation and documentation
can continue.

More details about changes and news for this beta are available here:

   core: https://download.gnome.org/core/3.15/3.15.92/NEWS
   apps: https://download.gnome.org/apps/3.15/3.15.92/NEWS


The GNOME 3.15.92 release itself is available here:

   core sources: https://download.gnome.org/core/3.15/3.15.92/
   apps sources: https://download.gnome.org/apps/3.15/3.15.92/



WARNING! WARNING! WARNING!
--

This release is a snapshot of development code. Although it is
buildable and usable, it is primarily intended for testing and hacking
purposes. GNOME uses odd minor version numbers to indicate development
status.

For more information about 3.15, the full schedule, the official module
lists and the proposed module lists, please see our colorful 3.15 page:
  https://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
  https://wiki.gnome.org/Schedule


Enjoy,

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

TARBALLS DUE: 3.15.92

[Frederic Peters]

Hi!

> Tarballs are due on 2015-03-16 before 23:59 UTC for the GNOME 3.15.92
> rc release, which will be delivered on Wednesday. [...]

Please do your best to keep this Monday deadline, it really helps the
work of the release team.


Thank you all!


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

Re: Canonical jhbuild documentation

[Frederic Peters]

Ekaterina Gerasimova wrote:

> https://wiki.gnome.org/HowDoI/Jhbuild is the one that seems to be
> preferred by most docs newcomers and team members so from my point of
> view it would be good that the final result resembles it and works
> just as well.

Also jhbuild has been absorbing good practices first written down in
that page (default directory layout, no jhbuilrc required), and that
in turn made that page shrink, which is a good thing.


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

Re: Canonical jhbuild documentation

[Frederic Peters]

Allan Day wrote:

> > It would be nice if somebody could contact the authors:
> >   James Henstridge 
> >   C.J. Adams-Collier 
> >   Frederic Peters (ok, done)
> >   David Turner (Cillian64, from GHOP, back in 2007/2008, I can't
> > find an email)
> 
> Oh that's great - thanks Fred. Is there a bug or some other place
> where the license update is being tracked? We'll need a way to record
> the consent of the original authors, if I'm not mistaken.

There's no tracking for that, but yes there should be.


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

Re: Canonical jhbuild documentation

[Frederic Peters]

Germán Poo-Caamaño wrote:

> IMHO, the jhbuild documentation is more like a reference manual, whereas
> the information for newcomers is like a tutorial (or expected to be).

Indeed it's mostly like that at the moment.


> Maybe both could be in the same documentation/place, but the separation
> between both approaches should be clear.

That's what I tried, doing at the same time the conversion from
docbook to mallard, https://people.gnome.org/~fpeters/jhbuild-mallard/

The introduction text could be make shorter, to bring the "getting
started" part closer to the top.


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

Re: Canonical jhbuild documentation

[Frederic Peters]

Allan Day wrote:

> People will always come across the official manual on
> developer.gnome.org, since this ranks highly in search results. So, if
> you really want people to easily find the introductory documentation,
> it will have to live as a part of the official manual. I get the

The most important thing about the manual that lives in the jhbuild
git repository it that it can be translated (currently it's almost
fully available in Spanish, Portuguese (_BR), Greek and Japanese).


> impression that there has been resistance to this in the past, due to
> the desire to keep Jhbuild as a somewhat generic tool. However, I
> don't see how the two use cases (Jhbuild for new GNOME contributors,
> and Jhbuild for everyone else) couldn't be satisfied by structuring
> the manual according to audience.

I believe this is no longer a problem; when I tried to merge the
by-then new "BuildGnome" page into the manual, and converting it to
Mallard, the primary problem was of license incompatibility between
the contents from the wiki and the existing manual.

It would be nice if somebody could contact the authors:
  James Henstridge 
  C.J. Adams-Collier 
  Frederic Peters (ok, done)
  David Turner (Cillian64, from GHOP, back in 2007/2008, I can't
find an email)

Btw the draft integration/conversion is still available at:
  https://people.gnome.org/~fpeters/jhbuild-mallard/


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

Re: Canonical jhbuild documentation

[Frederic Peters]

Sébastien Wilmet wrote:
> Hi,
> 
> On Tue, Feb 10, 2015 at 11:27:11AM -0800, Sriram Ramkrishna wrote:
> > Problem: we have many pages on jhbuild documentation
> 
> Let's list them:
> 1. https://wiki.gnome.org/Projects/Jhbuild
> 2. https://developer.gnome.org/jhbuild/unstable/
> 3. https://wiki.gnome.org/GnomeLove/BuildGnome
> 4. https://wiki.gnome.org/GnomeLove/JhbuildIntroduction
> 5. https://wiki.gnome.org/HowDoI/Jhbuild
> 
> …any others?

Some projects have specific instructions, a recent one is gnome
calendar, https://wiki.gnome.org/Apps/Calendar/JHBuild

There is also quite a serie of blog posts depicting various workflows,
for example
  
http://blog.desmottes.be/?post/2013/11/08/Building-a-single-module-using-jhbuild


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

Tarballs for GNOME 3.15.4

[Frederic Peters]

Hi!

We are releasing 3.15.4 this week, deadline for tarballs is today,
please get them uploaded on time so we can correctly prepare the first
release of the year.

If you cannot make it, please send a mail to the release team to
discuss delays or find someone to roll a tarball.

Thanks!

Fred

[PS: reminder are automatically sent to the devel-announce-list@, if
 you are a maintainer you should subscribe to it.]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: System services & jhbuild

[Frederic Peters]

Zeeshan Ali (Khattak) wrote:

> > It does (basically it sets PKG_CONFIG_PATH to also look into the
> > system directories, so if you have networkmanager development files
> > installed, it will find them), and it even automatically skip modules
> > that are installed with a proper version (but it has to know the
> > required minimum version, and we used to maintain that appropriately
> > with "external deps", less so thosedays).
> 
> 1. Many users won't have the development packages installed for these
> system services and thus this won't be any solution for them. What sri
> meant (correct me if I'm wrong) is to simply leave system services to
> system.

jhbuild sysdeps checks for the presence of the pkg-config file, and
will then ask packagekit to install the proper packages.

And well, if an application needs the NetworkManager development
files, and they are not installed on the system, and that's certainly
less ideal than building correctly, because it had been built
correctly by jhbuild five steps before.


> 2. Not all services provide a library (e.g geoclue currently doesn't)
> so deps are setup for runtime-only. In that case, build of such
> services is almost always redundant.

You were talking about "kicking out all system services from jhbuild";
and many of those services provide libraries.  And geoclue provides a
.pc file and modules are checking for it at configure time (from a
quick grep: empathy, gnome-clocks, gnome-initial-setup, gnome-settings-
daemon).


> > Also, while it's not possible to run system services, it may still be
> > useful to have them in jhbuild, as they provide libraries that will be
> > used by other modules. For example it is required to have
> > accountsservice libraries to build and run gnome-control-center, but
> > most panels will be fine if the service itself is not running.
> 
> If control-center would need latest of accountsservice, its likely
> going to be because of new D-Bus API rather than just some convenience
> API provided by the library, wouldn't it? If control-center (built in
> jhbuild) can use the service from system at runtime, it can also use
> the library from system?

Nope, as Jasper wrote about the case of NetworkManager.


> > Still, we may envision changes; for example it's now possible to have
> > conditional modules, so perhaps we could work to have it both ways,
> > with a default set without the system services, and a flag to enable
> > them, a la "jhbuild --conditions=+system-services build".
> 
> Although I can totally agree with going for this approach, I still
> wonder what would user really achieve with this? Why build things that
> in the end will be useless?

As written before, they are not considered useless; heck, I even
consider building geoclue2 to get its single .pc file installed
useful.


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

Re: System services & jhbuild

[Frederic Peters]

Sriram Ramkrishna wrote:
> On Mon, Sep 8, 2014 at 9:55 AM, Zeeshan Ali (Khattak)
>  wrote:
> >
> > Unless someone has plans on fixing this (somehow) soon, I would
> > suggest we either kick out all system services from jhbuild all
> > together or at least remove them from dependency list of other
> > modules.
> >
> +1 for me,  It should try to use what is already on the system.

It does (basically it sets PKG_CONFIG_PATH to also look into the
system directories, so if you have networkmanager development files
installed, it will find them), and it even automatically skip modules
that are installed with a proper version (but it has to know the
required minimum version, and we used to maintain that appropriately
with "external deps", less so thosedays).

Also, while it's not possible to run system services, it may still be
useful to have them in jhbuild, as they provide libraries that will be
used by other modules. For example it is required to have
accountsservice libraries to build and run gnome-control-center, but
most panels will be fine if the service itself is not running.


> Besides, what is the end goal of jhbuild?  Is it to write code against
> the latest GNOME or is it to build a complete desktop environment?  I
> would argue that we already have gnome-continuous for the latter.
> Reducing jhbuild's scope would help make it an easier tool to manage
> and actually work.

It would certainly be easier but I don't foresee the double goal of
jhbuild changing much, because it still has to fulfil both in some
ways (as it's made to run in a VM, I don't feel like gnome-continuous
provides an appropriate testing/working environment).

Still, we may envision changes; for example it's now possible to have
conditional modules, so perhaps we could work to have it both ways,
with a default set without the system services, and a flag to enable
them, a la "jhbuild --conditions=+system-services build".



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

Re: Merge eBooks support in gnome-documents (was Re: New feature proposals period start)

[Frederic Peters]

Bastien Nocera wrote:

> Here goes with a first proposal, I'd like to be able to merge:
> https://bugzilla.gnome.org/show_bug.cgi?id=704316
> 
> This would add a new application to the GNOME release. It's all
> dependent on Marta providing a viewer widget, though the libgepub[1]
> maintainer is interested in working on a native one.
> 
> And it obviously also depends on the gnome-documents maintainers being
> happy with the path taken, of reusing a majority of gnome-documents'
> codebase to avoid duplication.

Thank you; I started a Feature page:

  https://wiki.gnome.org/ThreePointFifteen/Features/EBookSupport



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

Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]

[Frederic Peters]

I wrote:

> There are a few outstanding bugs (old development versions are pruned
> from the index files but not from the server, and are getting indexed by
> Google), [...]

That particular bug has now been fixed, old development versions are
now properly removed from the server; however I don't know how it will
play out exactly with Google indexing.


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

Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]

[Frederic Peters]

Hi Shaun,

> How much maintenance burden is there for the general infrastructure of
> library-web, versus the burden of the various converters and such that
> we'd have to deal with anyway if plugging them into another system?

There's not much maintenance required, for example new modules are
automatically picked up from the jhbuild modulesets, as well as new
versions of known modules published on ftp.gnome.org.

There are a few outstanding bugs (old development versions are pruned
from the index files but not from the server, and are getting indexed by
Google), and nobody to look at them regularly (I have been doing most of
library-web work during hackfests), maybe because it's difficult to hack
on, but mostly (imho) because there are very few persons working on
infrastructure, documentation, or both.

> RTD has been hugely popular in the Python world, but it's not the only
> continuous deployment or automated docs build system out there. Red Hat
> and Fedora use Publican for almost everything. OpenStack has a big pile
> of Maven code that builds its site. There are plenty of other examples
> that I could dig up.

Indeed; as I wrote earlier I'd prefer to have ideas on the structure we
want before we go looking for the appropriate software (or changes to
the library-web code base).


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

Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]

[Frederic Peters]

Allan Day wrote:

> One of the reasons why I wanted to have this conversation is to find
> out if there are any third party solutions that we could use, rather
> than having to write and maintain our own site from scratch? Is Read
> the Docs [1] an option?

It's a first look from that perspective, I'll be happy to be corrected
if I'm wrong in places.

It's tailored for Sphinx (http://sphinx-doc.org/) but it has a "doc
builder" abstraction, and it looks like it wouldn't be too difficult
to add more types of documents (gtk-doc, mallard, wiki extracts...).

I don't see a way to group multiple modules into bundles (a particular
set of versions), this is not something we have at the moment but we
talked about it in the context of devhelp; this is somehow back to the
"what do we want to publish?" question.

It would need some developments but it would certainly be a useful
experiment to at least create some proof of concept with it.

Do you think it would also be appropriate for help.gnome.org? (as we
share the library-web between developer.gnome.org and help.gnome.org)


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

Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]

[Frederic Peters]

Jasper St. Pierre wrote:
> While I'm sure a dynamic site would be a great idea in the far future, are
> there any small, actionable goals we can make for this?
> 
> We all dream of a great docs scenario, but we never properly plan for it.
> What small wins can we get today, right now, to improve the experience? I
> have some free time to hack on it.

There's a bunch of tasks over there:
https://wiki.gnome.org/DocumentationProject/Tasks/DeveloperDocs#developer.gnome.org

You will also find some in bugzilla, product: website, component:
developer.gnome.org.

Most items are about classification, it's mostly actioned via a single
file in library-web:
https://git.gnome.org/browse/library-web/tree/data/overlay.xml.in


  Add a section for "C++ Development" (put this at the bottom of the
  page). Move the links to the "programming with gtkmm3", libsigc++ and
  libxml++ pages to this section.

"The page" is https://developer.gnome.org/guides.

That page is defined by this snippet:

   
 overview gdp-documentation tutorials faqs devel-guides 
ApplicationsProgramming
 <_title>Guides
 <_abstract>
   A growing selection of development guides on common topics.
 
   

We want a new section, we add c++-development to the  tag;
then we want to define it, and want it at the bottom,

   

And we need to give it a proper title, it's in another file,
catalog.xml.in so it can be translated, we add a new line:

   <_msgstr msgid="c++-development">C++ Development

Then we want some content in that section, we find the "Programming
with gtkmm" link,

   
 devel-guides
   

and change its category, from devel-guides to c++-development. Then
we do the same thing for libsigc++ and libxml++ tutorials, and we're
done with that item.

Voila, I didn't do it for real, I may have made some typo but that's
the general idea; of course there's the hackability problem, it takes
time to have an exact mirror of developer.gnome.org running locally
but it's probably not needed.

Don't hesitate to file bugs with patches, I'll review them quickly.



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

Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]

[Frederic Peters]

Allan Day wrote:

> However, before we go down that route, it seems like we should at
> least discuss whether library-web is the best option going forward. It

I would tend to put goals before technical details, but library-web as
it is nowadays is certainly not the best option; I addressed a few of
the issues in my mail to gnome-doc-devel-list@.


>  * Hackability - from what I've seen, it is very difficult for people
> to hack on developer.gnome.org. The barrier to entry is high,
> documentation is lacking, and it all seems rather obscure.

There's some documentation, and it's even up-to-date up to the point
that several persons got it running locally, but it has a long
hack/build cycle by default (as it will cover all modules from
multiple GNOME releases), and is using XSL transformations, and many
persons find this arcane.

That structure made sense back in the day (2006) but given the way
other tools evolved (gtk-doc, yelp-tools), and better sysadmin
infrastructure (it was difficult to get new packages installed on the
RHEL version that was used until recently), it should be done
differently now.


>  * User experience - we need to decide whether developer.gnome.org
> should look and feel like a static website, or should be more like a
> web app. I was looking at Read the Docs [1] a while ago, and that kind
> of experience seemed like a good fit for API docs especially - search
> is prominent, you can quickly switch between documentation, etc.

I gave my opinion in that previous email, "I'd go with a dynamic
website, as this would solve the issue of stale files, and offer
better ways to integrate important things, like search."

  (the stale files issue is the problem Jasper talked about, we get
   Google indexing files way suboptimally)


>  * Documentation writing workflow. Monolithic modules written in
> Mallard, like gnome-devel-docs, aren't approachable for developer
> documentation writers. The HowDoI series has been reasonably
> successful, partly because it is easy to write documentation on the
> wiki, but finding and navigating that material isn't great [2]. A
> middle ground might be appropriate (Markdown HowDoIs, perhaps).

There are several layers here, most of the documentation still comes
from C files, via gtk-doc, then from docbook, gtk-doc again. This is
the bulk of what gets published, even for more "textual" content
(migrating from GTK+ 2.x to GTK+ 3 for example); then we have other
HTML generators, like Doxygen for the C++ bindings. The other
documents, the Mallard pages in the platform overview or developer
demos, the few wiki pages, are a really tiny part.


But to be honest, while the workflow can definitely be improved, I
don't think it's the main obstacle. I look at user documentation, it
gets written, it gets updated, and it's Mallard in git repositories.

No, I think the obstacle is that we don't have enough people willing
to work on developer documentation over something else, even though
many will recognize the importance it has. It's not new.



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

Re: Glade release to include GtkHeaderBar?

[Frederic Peters]

Allan Day wrote:
> Much of these issues come down to infrastructure, in my opinion. It's
> hard to get into writing docs, the website doesn't show what's new or
> updated, and it is slow to get new material online. Fred's done a
> fantastic job keeping library.gnome.org going, but we probably need
> something else (or at least major improvements).

Since the hackfest in Norwich in January it's possible to get specific
modules online (almost) directly after the git commits.  It is
configured that way for gnome-user-docs and gnome-getting-started-docs
(for help.  gnome.org) and for gnome-devel-docs (developer.gnome.org).

A few months ago I posted some plans and questions to the
gnome-doc-devel-l...@gnome.org mailing list, but probably I should
have asked people to subscribe there first :)  So here they are:

Support for multiple programming languages & multiple versions:

  On a structure level, there are at least two important questions: what
  kind of navigation do we want between programming languages (and
  perhaps on a more fundamental level, how do we expose them?), and
  between different versions of the libraries. At the time it was
  important to have various versions available online, for exemple GTK+
  2.6(?) was available because Nokia(?) used that version in their
  developments, but today we may want to expose a more unified "this is
  the current GNOME API" approach. (and that "bundle" approach would
  also benefit devhelp)

Covered libraries:

  This brings the question of the libraries we want on the developer
  website, it started as just our core libraries, but requests after
  requests, it got its share of other libraries.  (but if we decide to
  put them away, it's certainly also important to have a place for
  them).


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

TARBALLS DUE: 3.13.2.

[Frederic Peters]

Hello all,

Maybe this went unnoticed but we (release team) published the schedule
for 3.13 a few weeks ago, it's at .

And guess what?  We expect tarballs today; in the words of our usual
emails:

  Tarballs are due on 2014-05-26 before 23:59 UTC for the GNOME 3.13.2
  unstable release, which will be delivered on Wednesday. Modules
  which were proposed for inclusion should try to follow the unstable
  schedule so everyone can test them.  Please make sure that your
  tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded
  later than that will probably be too late to get in 3.13.2. If you
  are not able to make a tarball before this deadline or if you think
  you'll be late, please send a mail to the release team and we'll
  find someone to roll the tarball for you!


Cheers,

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

TARBALLS DUE: 3.12.2

[Frederic Peters]

Hello all,

Now is the time for a new update to our stable release, this is 3.12.2.

  Tarballs are due on 2014-05-12 before 23:59 UTC for the GNOME 3.12.2
  stable release, which will be delivered on Wednesday. Modules which
  were proposed for inclusion should try to follow the unstable
  schedule so everyone can test them.  Please make sure that your
  tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded
  later than that will probably be too late to get in 3.12.2. If you
  are not able to make a tarball before this deadline or if you think
  you'll be late, please send a mail to the release team and we'll
  find someone to roll the tarball for you!


For more information about 3.13, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.13
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   https://wiki.gnome.org/Schedule


Cheers,

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

TARBALLS DUE: GNOME 3.12.1

[Frederic Peters]

Hello all,

Isn't running 3.12 sweet?  Did you see the comments?  Christian
Schaller collected some, full of superlatives, have a look:
http://blogs.gnome.org/uraeus/2014/04/02/gnome-3-12-release-comments/

But it doesn't end there, the new step is the 3.12.1 update release,
and we need tarballs on Monday:

  Tarballs are due on 2014-04-14 before 23:59 UTC for the GNOME 3.12.1
  newstable release, which will be delivered on Wednesday. Modules
  which were proposed for inclusion should try to follow the unstable
  schedule so everyone can test them.  Please make sure that your
  tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded
  later than that will probably be too late to get in 3.12.1. If you
  are not able to make a tarball before this deadline or if you think
  you'll be late, please send a mail to the release team and we'll
  find someone to roll the tarball for you!


For more information about 3.11, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.11
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule


Cheers,

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

TARBALLS DUE: GNOME 3.12.0

[Frederic Peters]

Hello all,

With 3.11.92 out, it's time for 3.12.0 tarballs. Let the translations
flow into your modules then get your tarballs out.

Tarballs are due on 2014-03-24 before 23:59 UTC for the GNOME 3.12.0
newstable release, which will be delivered on Wednesday. Modules which
were proposed for inclusion should try to follow the unstable schedule
so everyone can test them.  Please make sure that your tarballs will
be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
will probably be too late to get in 3.12.0. If you are not able to
make a tarball before this deadline or if you think you'll be late,
please send a mail to the release team and we'll find someone to roll
the tarball for you!


For more information about 3.11, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.11
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule


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

TARBALLS DUE: GNOME 3.11.92 release candidate + HARD CODE FREEZE

[Frederic Peters]

Hey all,

Here comes the 3.11.92 release candidate, last stop before 3.12.
Tarballs are expected on Monday, this is the last chance to get your
fixes in, we will then enter the hard code freeze, and you will need a
big bunch of approvals to get changes in.


Let's repeat, tarballs are due on 2014-03-17 before 23:59 UTC for the
GNOME 3.11.92 rc release, which will be delivered on Wednesday.
Please make sure that your tarballs will be uploaded before Monday
23:59 UTC: tarballs uploaded later than that will probably be too late
to get in 3.11.92.

If you are not able to make a tarball before this deadline or if you
think you'll be late, please send a mail to the release team and we'll
find someone to roll the tarball for you!


We will be entering the HARD CODE FREEZE: This is a late freeze to
avoids sudden last-minute accidents which could risk the stability
that should have been reached at this point.  No source code changes
are allowed without approval from the release team, but translation
and documentation should continue. Simple build fixes are, of course,
allowed without asking.


For more information about 3.11, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.11
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule


Cheers,

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

Re: Python Docs (was Re: Coordination for developer documentations)

[Frederic Peters]

Stefan Sauer wrote:

> On 03/08/2014 06:15 PM, Christoph Reiter wrote:
> > I've tried the devhelp export and it seemed to work quite well for the all
> > in one API docs. But I'm not sure how linking between different Sphinx
> > builds would work with devhelp. (but I have no idea how devhelp does it
> > with other sources either..)
> devhelp is basically the index.sgml (ignore the sgml extension, it is
> not) + prerendered html. devhelp does not do anything with the link in
> the html doc, except trying to follow them when one is clicked.

Indeed, the pages rendered by devhelp are HTML pages taken straight
from the filesystem, with no transformation at all.  As I wrote to
Giovanni earlier, it would certainly be possible to reuse YelpView,
to get support for Mallard files.

Next to the document view, for the tree of documents and the keyword
search, devhelp requires a file in its own '.devhelp2' xml format;
it's actually quite simple, it goes like this:


http://www.devhelp.net/book"; title="GTK+ 3 Reference Manual"
  link="index.html" author="" name="gtk3" version="2" language="c">
  

  

...
  
  


!-- but also other types







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

Re: Coordination for developer documentations

[Frederic Peters]

Hi Allan,

Allan Day wrote:
> > So, are you interested?
> 
> It would help to know a bit more about what you think this
> coordination role would involve. Are you concerned with keeping
> technical changes in step, for example, or is it more the content in
> our hand written documentation that we need to be careful about?

I was mostly concerned by our technical infrastructure for developer
documentation, but that itself has of course been driven by the
content we produced (or wanted to produce), so I don't think they can
really be separated.

A recent example is the way gtk-doc comments are written, and how to
accomodate them in order to provide meaningful comments when reused
for other languages (references to manual memory management for
example).


> Maybe the concerned parties just need to be made aware of how their
> work might affect others? Or maybe the dependencies between components
> need to be more clearly spelled out?

Given a vision I believe it will be necessary to coordinate whatever
needs to be done to get to it, having various persons giving the
subject a bit of their time sporadically won't work out (that's what
we've been doing since at least the Berlin hackfest more than four
years ago).

Maybe we do not need a person, maybe tools (like the gnome-devel-doc
list) are enough to get the required coordination, but from what I've
seen of the documentation team, a dedicated and focused person really
helps.

So I agree with you, the first is certainly to get that common vision
nailed down. But then, having a solid developer documentation team,
rather than various individuals, would help tremendously, in defining
the vision, and working towards it afterwards.


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

Coordination for developer documentations

[Frederic Peters]

Hey,

It's been proved again in recent hackfests, we have a really great
team writing user documentations, and thanks have to be given to
Shaun, and now Kat, for coordinating the effort.

On the other hand we have absolutely no coordination for developer
docs, I maintain developer.gnome.org with the little time I have,
Aleksander helps with Devhelp, there are some punctual changes from
various persons, David maintains gnome-devel-docs, Tomeu did work on
generating python documentation from gobject-introspection a while
ago, Giovanni did it for gjs recently, Jon improved markdown support
in gtk-doc, etc. but all this happens without coordination and it
happens people step on each other's toes, and it hurts.

Developer documentation will be a topic during the Developer
Experience Hackfest, but I believe we will fail again to provide
lasting effects if nobody takes on a coordination role.

So, are you interested?


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

Re: Announce: Gjs documentation almost ready!

[Frederic Peters]

Giovanni Campagna wrote:

> > 1) are there plans to get this into devhelp? We need to figure a namespace
> > scheme for binding docs. The devhelp app itself already understands
> > different languages. All we need is a index file like the ones gtk-doc
> > generates.
> 
> No, there are no plans to get this in devhelp. The HTML output is
> really just a way to get them somewhere in the internet without
> blocking on library-web, but the real deliverable is mallard, and
> devhelp does not understand that (while library-web does)

If the HTML output is somehow distributed, or can be built with
minimal tooling (i.e. not a complete GNOME build environment), they
can certainly be integrated into developer.gnome.org.  You can file
bug reports against product: website, compotent: developer.gnome.org.

The situation is roughly the same for Devhelp, if HTML files are
distributed it's easy for Devhelp to display them; displaying the
Mallard files directly is certainly more difficult, maybe it's
possible to use libyelp YelpView. Anyway, bug reports are welcome.


Thanks,

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

Re: About writing new apps from scratch

[Frederic Peters]

Hi Tristan,

> I think I have adequately expressed here my distaste of how things
> have changed since module proposal period was conveniently swept
> under the rug, around the time of the release of GNOME 3.

The situation is that at some point it was considered useful to have a
broader view of changes, there are diverse reasons to that but one
that is important has been voiced by Allan Day, "Change is hard.
Established apps tend to have loyal users and extensive
functionality.", and those changes were not considered by the module
proposal period, after all, the module name was still the same.

To get back to the present situation, imagine Totem, it's now being
changed to Videos, it would have been at the discretion of the module
maintainers back then, but now the proposed change is being exposed
early on in the "Features" pages (for several cycles even, in that
case), and can be discussed on this list.

Looking quickly at important threads this cycle I notice a discussion
about Polari (why just IRC, which integration with our current parts)
and a few other mails on other features.

Surely we (== the release team in this case) have to change some
things (at least I'm not perfectly happy yet), and if you feel
participation is no longer welcome, do you have any idea of things you
would like to see?

https://wiki.gnome.org/ThreePointEleven/Features



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

TARBALLS DUE: GNOME 3.11.90, The Freeze, and other things

[Frederic Peters]

Hello all,

We are now at 3.11.90, you should publish your tarball on Monday, so
that the release team and friends get enough time to assemble and test
it all.

Also we are reaching "The Freeze", API/ABI changes, UI changes, and
new features should now be well in place and stop moving, details are
available in the wiki[1], and of course you can reach the release
team, by mail or on IRC, if you have questions.

  [1] https://wiki.gnome.org/ReleasePlanning/Freezes#The_Freeze

Another thing, we will be entering the string change announcement
period, e.g.  string changes can still be made (e.g. for typo fixes or
translatability improvements). All string changes must be announced to
both gnome-i18n@ and gnome-doc-list@.

Writing of release notes will begin and there will most likely be a
call for help, we are counting on you.


  Tarballs are due on 2014-02-17 before 23:59 UTC for the GNOME
  3.11.90 beta release, which will be delivered on Wednesday. Modules
  which were proposed for inclusion should try to follow the unstable
  schedule so everyone can test them.  Please make sure that your
  tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded
  later than that will probably be too late to get in 3.11.90. If you
  are not able to make a tarball before this deadline or if you think
  you'll be late, please send a mail to the release team and we'll
  find someone to roll the tarball for you!



For more information about 3.11, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.11
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule


Cheers,

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

TARBALLS DUE: GNOME 3.11.5

[Frederic Peters]

Hello all,

It's FOSDEM weekend, if you're there, come and say hi! to the GNOME
booth. Tomorrow, after you safely got home, it will be time to roll
some tarballs for 3.11.5.

You know the drill:

  Tarballs are due on 2014-02-03 before 23:59 UTC for the GNOME 3.11.5
  unstable release, which will be delivered on Wednesday. Modules
  which were proposed for inclusion should try to follow the unstable
  schedule so everyone can test them.  Please make sure that your
  tarballs will be uploaded before Monday 23:59 UTC: tarballs uploaded
  later than that will probably be too late to get in 3.11.5. If you
  are not able to make a tarball before this deadline or if you think
  you'll be late, please send a mail to the release team and we'll
  find someone to roll the tarball for you!


For more information about 3.11, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.11
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule

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

Re: Fix wrong FSF's address in in source files

[Frederic Peters]

Hi Daniel,

> devhelp

I didn't find a bug report for this one, please do file one and I'll
have a look.

> jhbuild

https://bugzilla.gnome.org/show_bug.cgi?id=721532 feel free to attach
a patch and it will be quickly reviewed.


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

TARBALLS DUE: GNOME 3.11.4 due on Monday January 13th

[Frederic Peters]

Hello all,

The work towards 3.12 continues in 2014, this is the first call for
tarballs this year, happy new year!

Tarballs are due on 2014-01-13 before 23:59 UTC for the GNOME 3.11.4
unstable release, which will be delivered on Wednesday. Modules which
were proposed for inclusion should try to follow the unstable schedule
so everyone can test them.  Please make sure that your tarballs will
be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
will probably be too late to get in 3.11.4. If you are not able to
make a tarball before this deadline or if you think you'll be late,
please send a mail to the release team and we'll find someone to roll
the tarball for you!


For more information about 3.11, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.11
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule


Cheers,

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

GNOME 3.12 Schedule and 3.11.1 tarballs call

[Frederic Peters]

Hello all,

I just published our schedule for 3.11/3.12 on our wiki, it's
available at: https://wiki.gnome.org/ThreePointEleven, tarballs
for next release, the opening of the 3.11 cycle, are expected
on Monday.


Fred

[An ics file is also available:
 https://www-old.gnome.org/start/schedule-unstable.ics ]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

3.10.1 coming up!

[Frederic Peters]

Hey all,

It was not announced with the usual template but we need your tarballs
for 3.10.1, Matthias Clasen wrote:

> After catching our breath for a while, and enjoying 3.10.0, now it is time
> to put out a 3.10.1 release to fix annoyances and bugs that have come up
> since 3.10.0. I have marked a few bugs as candidates for fixes to include
> in 3.10.1 - I hesitate to call them blockers, since many of them are not
> that serious. But still, it would be nice to fix some of these before
> rolling the 3.10.1 tarballs next Monday.

So go for it, and let's make it shine.


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

Re: Opening the 3.12 cycle

[Frederic Peters]

Zeeshan Ali (Khattak) wrote:

> But apparently its the only free OS worth caring about. I think Jasper
> was asking about distros as I'm pretty sure he is well aware that
> systemd doesn't run on an archaic OSs, such as FreeBSD.

No need to be insulting.


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

Re: Opening the 3.12 cycle

[Frederic Peters]

Michael Catanzaro wrote:
> On Mon, 2013-09-23 at 09:09 -0400, Matthias Clasen wrote:
> > I think that would be a great idea - could you set up the goal wiki
> > page and link it from the gnome-software feature ?
> The goal should include that all appdata is marked for translation.

This could also come after a review of the appdata schema, for things
like screenshot translations.


Fred
___
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]

[Frederic Peters]

Jasper St. Pierre wrote:

> If you're not happy with that, we can certainly bring it up to the board
> and talk about it, but from how I see things, I don't think we'll remove
> GNOME Online Accounts integration or stop our Twitter marketing campaigns.
> So, I'm saying that if you're not happy with those directions, I think
> GNOME may not be the best place for you.

Or "we" can keep on working in GNOME, and encourage developments such
as the Owncloud support that got added to GNOME Online Accounts.


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

Re: A first look at 3.10 blockers

[Frederic Peters]

Thanks Matthias for starting this.

> Related to system status rework:
> -
> 
> 705647 gnome-shell New System Status design lost the ability to suspend
> 705733 gnome-shell Make new system status implementation respect the
> always-show-universal-access-status setting

I'd consider one of those to be a blocker:

 - 705104 / gnome-shell / new network menu has no way to select a
   wired connection

 - 705935 / gnome-control-center / make it possible to connect to
   alternate connections

Both of them probably needs designer input.


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

Re: git submodules vs translators

[Frederic Peters]

Colin Walters wrote:

> Any other thoughts?

https://bugzilla.gnome.org/show_bug.cgi?id=599066 is the request by
translators to be able to auto-commit files from damned lies, from
2009.

It would help here.


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

Re: jhbuild: better defaults

[Frederic Peters]

Thomas H.P. Andersen wrote:

> Are there non-bikeshed reasons not to do this? Are there things that
> will break so bad that the cost outweigh the benefit?

Patch welcome; but do mind this comment:

  The only slightly tricky thing about this I see is detecting the
  case where the user was actually using the default in
  defaults.jhbuildrc, in other words if you had just an empty
  .jhbuildrc and were *actually* using /opt/gnome for installs.

  -- Colin Walters 



Fred
___
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

[Frederic Peters]

Colin Walters wrote:

> The whole thing is just so horrible...Python upstream should have just
> accepted they made a different (but closely related) programming
> language and said "python" is always python2, and "python3" is 3, or
> they should have made a python2 symlink upstream for the old branch, so
> python2 users knew where to find it reliably.

This happened a bit late but http://www.python.org/dev/peps/pep-0394/
defines exactly this.

  This PEP provides a convention to ensure that Python scripts can
  continue to be portable across *nix systems, regardless of the
  default version of the Python interpreter (i.e. the version invoked
  by the python command).

   - python2 will refer to some version of Python 2.x
   - python3 will refer to some version of Python 3.x
   - python should refer to the same target as python2 but may refer to
 python3 on some bleeding edge distributions


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

Re: Requiring systemd for the gnome-settings-daemon power plugin

[Frederic Peters]

William Jon McCann wrote:

> I agree with you that we need to have a motive to change and that
> costs should be weighed carefully. We can make the case.

The objection Colin expressed was about the method; and on that
matter, frankly, we are making a good job in alienating active members
of our community, to the point our "GNOME is people" is no more but a
slogan.[1]

We have active members using Debian, Ubuntu, Gentoo, OpenBSD,
whatever, for whatever *good* reasons, and more often than not they
will have nothing to do with GNOME.

You may not want to compromise with code, I want to compromise with
people, this definitely takes longer, this takes emails, this takes
discussions, this is in my opinion important.

And this certainly doesn't mean we are not going forward.


Fred


[1] let's wait for somebody to register gnomeispeople.org and put a
big "no, it's not" on it...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Requiring systemd for the gnome-settings-daemon power plugin

[Frederic Peters]

Bastien Nocera wrote:

> > Additionally, and separately, support for ConsoleKit usage for
> > session-tracking will be removed.
> 
> This is now pushed to master for 3.7.1.

Well, this all happened a few days before the release deadline, this
is not easy matter, we have a release team meeting this week-end and
we will talk about the whole situation.

Of course this is still just 3.7.1, but anyway. I'd suggest we do
*not* ship gnome-settings-daemon 3.7.1 in GNOME 3.7.1 and wait for a
project-wide decisionon how support of ConsoleKit systems should be
(dis)continued.


Fred


[1] those kind of decisions were the subject of the release team part
our AGM in GUADEC...
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Blocker bug status

[Frederic Peters]

Germán Póo-Caamaño wrote:

> > 683354 Port to new documentation infrastructure
> 
> AFAIK, there is a fair concern on this because of the potential impact
> on translations:
> 
>  I'm tempted to just say push it, and if there's anything wrong
> I'll catch it making a release
>  but I'm a little concerned about needlessly breaking
> translations this late
>  because itstool and xml2po can produce different messages in
> some cases
>  can we check that easily?

Shaun checked that and commented in the bug report, it appeared this
would invalidate too many strings to do it now, postponed for 3.7.

  https://bugzilla.gnome.org/show_bug.cgi?id=683354#c2


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

GNOME 3.6 Blocker Report (T-16d)

[Frederic Peters]

Hello all,

We are now well frozen, it's more than time for a new blocker report;
have a look at the list below and do note the list below is not
necessarily complete.

Feedback, updates, help from packagers, developers, maintainers,
contributors, etc. is welcome. Please do speak up if some important
bugs are not listed here, or if some tickets should not be blockers.

Note: This list also includes open reports that still have a 3.4 target.


Fred


ANJUTA
==

 - Port to new documentation infrastructure
   https://bugzilla.gnome.org/show_bug.cgi?id=683308
   Last bit of the 'new doc infra' goal, patch available.


EMPATHY
===

 - Port to GStreamer 0.11/1.0
   https://bugzilla.gnome.org/show_bug.cgi?id=674179
   Empathy is now ok, bug still open to track availability of farsight
   releases and some GStreamer bugs.


EVINCE
==

 - libsecret migration
   https://bugzilla.gnome.org/show_bug.cgi?id=679855
   Rough unfinished patch available.


GNOME-BACKGROUNDS
=

 - New background "Stamps" with a stamp of Marshal Tito
   https://bugzilla.gnome.org/show_bug.cgi?id=683444


GNOME-CONTROL-CENTER


 - Wireless list - arrow button is undiscoverable and hard to activate
   https://bugzilla.gnome.org/show_bug.cgi?id=682270
   No activity here.


GNOME-DEVEL-DOCS


 - Port to new documentation infrastructure
   https://bugzilla.gnome.org/show_bug.cgi?id=683354
   Last bit of the 'new doc infra' goal, patch available.


GNOME-SESSION
=

 - gnome-session no longer starts desktop files under
   /usr/share/gdm/autostart/LoginWindow
   https://bugzilla.gnome.org/show_bug.cgi?id=663721

 - shell crashed at login and ended up in a dead end session
   https://bugzilla.gnome.org/show_bug.cgi?id=672419
   One more patch left to do. Ray?


GNOME-SETTINGS-DAEMON
=

 - Maximum 3D size limitations
   https://bugzilla.gnome.org/show_bug.cgi?id=646280
   Owen has now looked into this and Adam Jackson provided for a patch for
   gnome-session, as I understand it, it still needs some patch to gsd.

 - power: enforcing lid close
   https://bugzilla.gnome.org/show_bug.cgi?id=680689


GNOME-SHELL
===

 - restart by typing "r" in the gnome-shell run-dialog 2x in one minute
   brings up the "oops" window
   https://bugzilla.gnome.org/show_bug.cgi?id=648384

 - Be able to ask for IM account password
   https://bugzilla.gnome.org/show_bug.cgi?id=658961

 - Alt-F2 + mouse middle button paste causes freeze
   https://bugzilla.gnome.org/show_bug.cgi?id=676918
   No progress here.

 - libsecret migration
   https://bugzilla.gnome.org/show_bug.cgi?id=679851
   Rough unfinished patch available.

 - 3.5.5: Lock screen shows password for a few characters / max 1 second
   https://bugzilla.gnome.org/show_bug.cgi?id=681576

 - top left corner turns cold when message tray is displayed
   https://bugzilla.gnome.org/show_bug.cgi?id=682255

 - 3.5.90: keyring prompt can't be confirmed or cancelled
   https://bugzilla.gnome.org/show_bug.cgi?id=682830

 - Impossible to unlock screen if not using GDM
   https://bugzilla.gnome.org/show_bug.cgi?id=683060
   A patch is now available so the user at least doesn't get stuck at the
   lock screen. Lockscreen functionality is still lost for users that are
   not running GDM 3.6.

 - 3.5.90 - Nine dot application ICON drops off Dash
   https://bugzilla.gnome.org/show_bug.cgi?id=683340

 - 'tray' button doesn't work with new message tray
   https://bugzilla.gnome.org/show_bug.cgi?id=683545

 - notification does not work with new message tray
   https://bugzilla.gnome.org/show_bug.cgi?id=683546


GNOME-THEMES-STANDARD
=

 - Nautilus tabs have black background
   https://bugzilla.gnome.org/show_bug.cgi?id=682395


GSTREAMER
=

 - [0.11] pulsesrc breaks when reconfiguring
   https://bugzilla.gnome.org/show_bug.cgi?id=681247
   Blocker for Empathy.

 - v4l2src breaks after renegotiation
   https://bugzilla.gnome.org/show_bug.cgi?id=682770
   Blocker for Empathy.


GTK+


 - [regression] crash on exit
   https://bugzilla.gnome.org/show_bug.cgi?id=671939
   Patch available. Help welcome to bisect and write a test case for the
   TreeView test suite.

 - smooth scrolling could do with some optimizations
   https://bugzilla.gnome.org/show_bug.cgi?id=672091
   There has been a commit that could help, needs confirmation.

 - Commit 7603e6e4 breaks setting "background-image" from cairo pattern
   https://bugzilla.gnome.org/show_bug.cgi?id=672858

 - Code that gives me a spinner in gtk+ 3.4.4 does not in 3.5.8
   https://bugzilla.gnome.org/show_bug.cgi?id=680980


LIBSOUP
===

 - drop SoupPasswordManagerGNOME
   https://bugzilla.gnome.org/show_bug.cgi?id=679866
   Related to the libsecret migration.


MUTTER
==

 - GtkWindows (comboboxes, menus, etc.) do not show up on primary display
   https://bugzilla.gnome.org/show_bug.cgi?id=672163
   Partial fix committed.


NAUTILUS
===

Re: jhbuild update required

[Frederic Peters]

Colin Walters wrote:

> On Wed, 2012-09-05 at 15:13 -0400, Jasper St. Pierre wrote:
> > On Wed, Sep 5, 2012 at 3:10 PM, Jeremy Bicha  wrote:
> > >
> > > Could we get a new jhbuild release then? Some distributions (Debian,
> > > Ubuntu, openSUSE) have jhbuild packaged in their repositories.
> > 
> > jhbuild is not meant to be packaged. I'd highly suggest you stop
> > packaging jhbuild.
> 
> Well...there are some good and bad things about packaging jhbuild.  The
> bad thing is that there's often a large lag time before packages are
> updated.  The good thing is it's easier to install.
> 
> Craig, any thoughts on doing a release?

I just pushed a 3.5.91 tarball.

@Jasper: jhbuild packages can be quite useful to get core dependencies
installed (git, autotools, etc.), I'd encourage them.


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

String Freeze

[Frederic Peters]

Hello all,

The string freeze has set in, no string changes may be made without
confirmation from the i18n team and notification to release team,
translation team, and documentation team. From this point, developers
should concentrate on stability and bug-fixing. Translators can work
without worrying that the original English strings will change, and
documentation writers can take accurate screenshots. For the string
freezes explained, and to see which kind of changes are not covered by
freeze rules, check this page:
  http://live.gnome.org/TranslationProject/HandlingStringFreezes.

It's also important to make sure that your module's po/POTFILES.in and
po/POTFILES.skip are correct and uptodate and that no source files are
lacking from these files.

For more information about 3.5, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.5
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule


Cheers,

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

Re: Recommended office suite?

[Frederic Peters]

Mattias Eriksson wrote:

> I noticed that the Gnome Ubuntu flavor will not ship libreoffice, but
> instead only ship Abiword and Gnumeric. I was surprised by this, since I
> think libreoffice is the best office suite for linux and it has quite good
> gnome integration. The motivation for this is that they want to provide a
> pure gnome experience, and these applications are referenced in the
> gnome-app module set. However, I haven't seen any talk about Abiword and
> Gnumeric on the gnome mailinglists or on planet.gnome.org for quite a while
> (I actually was under the impression that these projects had been
> abandoned).

While I do not actively follow the development of abiword, I can
assure you gnumeric, and the goffice support library, are still under
active development, with several active commiters.

As a personal preference I use gnumeric over LibreOffice Calc and it
does have all the features, and more, that I want. Give it a try. But
I use LibreOffice Writer, it works great and fits the environment.


> I'm also under the impression that there are a lot of support
> for LibreOffice in the Gnome community, and I was told that "Documents" has
> a dependency on it (causing Documents not to be included in the Gnome
> Ubuntu flavor).

I do not know of such a dependency.


> So my question is: What is the recommended office suite for a pure gnome
> experience? What has been talked about for the up coming Gnome OS?

GNOME by itself doesn't ship an office suite. You have seen the
different projects, some are closer to GNOME, for technical or personal
reasons, but none are officialy endorsed 

If you like LibreOffice, certainly Ubuntu doesn't prevent you from
installing it, and it will work, don't worry about it, and please do
not worry about what is "pure" or not.


As for "GNOME OS", it is primarily intended as a platform for testing
and development, not the system where you'll do your daily work in
spreadsheets and text documents; there is much to resolve there before
we get to talk about an "official" office suite.


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

relative URLs for git submodules

[Frederic Peters]

Hello,

Several GNOME modules have started using git submodules, for example
there is empathy, using egg-list-box:

  [submodule "libempathy-gtk/egg-list-box"]
path = libempathy-gtk/egg-list-box
url = git://git.gnome.org/egg-list-box

This works fine, with proper calls to git submodule init and git
submodule update added to autogen.sh

Another module would now be gnome-font-viewer, it uses:

  [submodule "libgd"]
path = libgd
url = ../libgd

And this also works fine, but only if you get your clone from
git.gnome.org, if you get it from somewhere else, there is a good
chance that ../libgd won't exist. [1]

The only advantage I perceive in using a relative URL is that you get
the submodule clone over the same transport than the main module, and
this is nice if you want to also hack on the submodule (as git:// is
readonly). However it's always time to update the remote branch URL
after the fact, to use ssh://.

Are there other advantages?

If not, could we decide to always use full URLs?



Fred

[1] of course other git hosting services comes to mind, but this also
affects jhbuild ability to maintain a dvcs mirror, this is bug
682516 and this is what prompted this message.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: compiler warnings, -Werror, etc.

[Frederic Peters]

Colin Walters wrote:

> For compiler warning defaults, I think something similar what Dan
> Winship has in libsoup is what we should replicate across more GNOME
> modules:
> 
> http://git.gnome.org/browse/libsoup/tree/configure.ac?id=f5902fce98ae0314f0d9ca6e544895548c94a456#n339
> 
> It's better than the GNOME_COMPILE_WARNINGS macro in gnome-common right
> now, and *definitely* better than various modules having -Wall -Werror.

Is there some problem in fixing that macro? It would instantly fix
dozens of modules (over 50 according to a quick grep).

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

Re: libsecret migration

[Frederic Peters]

Hi Stef,

> On 06/27/2012 06:56 PM, Olav Vitters wrote:
> > On Wed, Jun 27, 2012 at 06:49:13PM +0200, Stef Walter wrote:
> >> http://people.gnome.org/~stefw/libsecret-docs/c-examples.html
> > 
> > Please have that put on http://library.gnome.org.
> 
> Yes, that's something I need to do. Do you know where I can find
> documentation for how to do that? Looked in all the obvious places.

File a bug against product: website, component: developer.gnome.org,
include a small paragraph about libsecret.


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

Re: 3.6 Feature: IBus/XKB integration

[Frederic Peters]

Tomas Frydrych wrote:

> Rather a long discussion over IBus, but it seems to more or less boil
> down to two voices and this:
> 
> Gnome developers: we want tighter IM integration and simpler UI in the
> name of better UX, and are looking at IBus as the underlying technology,
> 
> Users: IBus has poor support for CJK input and a history of not
> addressing these problems.

You may be a bit harsh on IBus, but I believe your characterisation of the
GNOME developers view point is quite correct, we do want input methods
to be integrated, we do believe this will lead to a better user
experience, and certainly this belief doesn't come out of thin air but
from discussions with actual CJK users.

This feature is called "IBus/XKB integration" but this is technospeak,
what it is really about is to get CJK input methods out of their
second-class zone, to bring their integration on the same level as the
current XKB support.

It happened discussions were engaged with IBus developers, I don't
know the history behind this; this thread questions that technical
choice, there are important voices from actual CJK users that should
not be ignored.

The voices of graphic designers are not ignored when they say it's
important to be able to configure the meanings of the buttons of their
Wacom tablet, but that happens because they are already close to the
development of GNOME, while we notoriously lack developers from Asia
(hopefully the efforts of GNOME.asia will bear fruits here).

But short of that actual experience, what can be done? Just like it
happens for other aspects of our development, did we gather relevant
art from other platforms? Would it be useful?

https://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus/InputLanguage
doesn't have any of this, perhaps it's elsewhere on the wiki but I
didn't find it.

I found the videos posted by Justin Wong very instructing, are there
moments where designers, developers, CJK users could meet to plan
things ahead, GNOME.asia happens next month but I don't think enough
of the core developers and designers are going there, but later on
there is GUADEC, will we have CJK users there?

But then waiting for GUADEC is perhaps too much, that would mean we
wouldn't get that feature for 3.6, but perhaps it's worth to wait to
make sure the target audience, CJK users, have enough occasion to
bring their feedback and to participate in the actual design.

Should we step back for now? And how will we then go ahead?



Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Frederic Peters]

Jasper St. Pierre wrote:

> We only have the development resources to ship one input method. It's
> going to need special code to integrate with Clutter and the St
> toolkit. If IBus is bad right now, we need to fix it.

Or use fcitx instead of IBus? I honestly do not know the topic, but I
read the emails from Marguerite Su and believe she brought important
points. I'd like to understand what are the plus points of IBus today.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: Lock Screen

[Frederic Peters]

Ray Strode wrote:

> On Fri, May 4, 2012 at 4:54 PM, Andre Klapper  wrote:
> > Lionel proposes to consider merging the login screen and the lock screen
> > as both are about logging in.
> > In the end Allan wrote "let's continue some place else."
> >
> > Did this conversation continue somewhere, and what were the results?
> >
> > Asking as I think that Lionel has a good point and don't see good
> > arguments against it yet either.
> It doesn't make sense to go to a new login screen because that would
> incur a VT switch, would stop your music from playing etc.  It
> something to reconsider once wayland has been integrated.  At that
> point we'll be well situated, since both are implemented with
> gnome-shell anyway.

I believe the point Lionel made was not about technicalities but about
the design by itself, e.g. why would the process of logging in be
different in the morning when you turn your computer on than in the
afternoon when you walk back to a computer with the screen locked.

As Andre wrote, "did this conversation continue somewhere, and what
were the results?"


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Zeitgeist

[Frederic Peters]

Seif Lotfy wrote:

> So I would still like to have my question answered. How is the policy
> on using Zeitgeist for non-feature and non-UX related optimization and
> maintenance distribution?

Do note this was not discussed by the release team, we'll have a
meeting soon and we can add that to the agenda if you want an official
answer, but in my opinion there is no problem if a maintainer wants to
use zeitgeist because it helps in whatever s/he is coding.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.6 Feature: IBus/XKB integration

[Frederic Peters]

Bastien Nocera wrote:

> > I don't know of a physical keyboard layout that has a Compose key.
> > So are we just deciding that one of the keys will always behave
> > differently than the printed keycap?
> > 
> > I suppose if you use a modifier key (R_Alt seems popular) then it
> > can still function as a modifier as well as Compose, though that
> > will interact poorly with sticky keys.
> 
> The usual compose key for Western European keyboards is Alt-Gr. That's
> just one more data point to add to that whole list.

On my totally standard french layout, AltGr is used to type the key
ternary character; I just checked and setting it to be the Compose key
breaks that access.


Fred (using the right Ctrl key for Compose)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: Zeitgeist

[Frederic Peters]

Shaun McCance wrote:

> Your previous email seems to indicate that the features for 3.6 are
> already a foregone conclusion, and that Zeitgeist doesn't fit into
> that. But that just can't be, because WE the GNOME community decide
> what's in the next version right here on d-d-l during the proposal
> period.

Indeed, there have been a few pages added on the wiki[1], some ported
from 3.4, but it would really help the discussion if proponents were
to send emails to this list.

Also if there are features under discussion that are not listed over
there, please add them, and bring the discussion over here.


Thanks,

Fred

[1] https://live.gnome.org/ThreePointFive/Features
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Prevent screen from going to sleep

[Frederic Peters]

Emmanuele Bassi wrote:

> On 1 March 2012 09:24, Marco  wrote:
> >> Any application which e.g. plays a movie can block the screen from
> >> turning off.
> >
> > When I  watch movies in VLC  the screen is still  switched off after
> > ten minutes. Preferences → Advanced  → “Inhibit the power management
> > daemon during  playback” is activated.  Maybe that is related  to my
> > problem.
> 
> I'd suggest you file a bug against VLC in their bug tracking system.

FWIW http://trac.videolan.org/vlc/ticket/4739


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism

[Frederic Peters]

Bastien Nocera wrote:

> And have a Provides: systemd-services in the systemd RPM. The problem
> isn't exactly insurmontable.

Of course it's not insurmontable, but this thread came to be more
about proper communication than technical solutions.

So far we had 1) the update of the portability matrix, and 2) the
acknowledgment a mail should have been sent to distributor-list@;
I believe this is satisfactory.

Ideally we'd also have earlier notifications, and a list of D-Bus API
we depend on (like we had the external dependencies page), but that's
more work, and not always feasible.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]

[Frederic Peters]

David Zeuthen wrote:

> > @David: could you confirm this? And do you have any ETA for a udisks2
> > tarball?
> 
> There is one at http://udisks.freedesktop.org/releases/

http://www.freedesktop.org/wiki/Software/udisks still points to
http://hal.freedesktop.org/releases/, could you update that page?


Thanks!
Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

udisks2 [WAS: Re: datetime: Remove datetime D-Bus mechanism]

[Frederic Peters]

Johannes Schmid wrote:

> Short note: I removed the "udisks" and "upower" rows as they don't
> follow the system of showing the part of GNOME using some technologie.
> Instead those are referred to by the "gnome-disk-utility" and
> "gnome-control-center/power" rows which is IMHO the correct way.

Speaking of udisks, gnome-disk-utility has now been switched to use
udisks2; I can only guess gvfs will follow.

@David: could you confirm this? And do you have any ETA for a udisks2
tarball?


Fred

[breaking thread on purpose]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libwacom dep

[Frederic Peters]

Hey Bastien,

> FYI, moved the git repo to be under the linuxwacom project in
> sourceforge (one of the few still there I guess, updated in ), and made
> a tarball release:
> https://sourceforge.net/projects/linuxwacom/files/libwacom/

It's (technically) required for modules that are defined as coming
from git in the jhbuild modulesets to have their tarballs published
on ftp.gnome.org; could you host a copy there?


Thanks,

Frederic
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[Frederic Peters]

Jason D. Clinton wrote:

> When did this happen? I admit I've been a bit disconnected for a few months
> but even if the Featured Apps didn't get updated, it was never intended to
> be an exhaustive list. In fact, I explicitly stated in
> the announcement (with blessing from the Release Team) that there was no
> mechanism by which to apply for "featured" status and it was to be
> construed as nothing more than what it was: purely a marketing designation.
> There were only 8 Featured Apps the 3.0 and 3.2 release (these eight
> http://www.gnome.org/applications/) *and* we still had an apps moduleset
> for both releases.

But what's the meaning of the apps moduleset? It is not about featured apps,
as you wrote earlier:

This list is not jhbuild-maintained because it is a function of
marketing, not development. The list of featured applications is
maintained on our web properties and has nothing to do with any
official module status.

-- http://git.gnome.org/browse/jhbuild/commit/?id=12a0bd91

And applications got out of release team scope in the announcement
you refer to:

Release Team continue to administer the formal new module proposal
process for Core (that is, everything which would be considered part
of "GNOME OS" and is currently in the Core moduleset)

-- 
https://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00045.html

But despite that announcement, most of the application module
maintainers continued to follow the release schedule, and were part of
releases we handled. (as evidenced by http://ftp.gnome.org/pub/GNOME/apps/)

Again, the question, what's the meaning of the apps moduleset? It's
been the place for "a serie of applications" handled by the release
team, remnants of the old modulesets, but doesn't it lack some more
formal definition?

If it's applications released by the GNOME project, shouldn't we get
back some release criteria?

If it's just to facilitate jhbuilding, what's the difference between
the -apps and the -world modulesets?


> So what has changed? I think that there's some confusion here and I'd like
> to clear it up. As far as I know, everything is just fine: Featured Apps is
> a marketing function and apps moduleset can include anything to facilitate
> jhbuilding.

Well, there was the moduleset reorg announcement, but after that we
also had 8 months of practice, and they don't quite fit, because in
some sense, what has changed? nothing, applications still wanted to be
under the GNOME shelter, and the release team kept offering that.

We put up a "feature proposal period" in place, and applications kept
being proposed, and that discrepancy is part of this thread, Vincent
wrote: "I said that I didn't feel Boxes should be tracked as a feature".


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[Frederic Peters]

Jason D. Clinton wrote:

> > Because there's a big difference between an integrated, designed,
> > polished, documented and translated GNOME app and something that happens
> > to use GTK, right?
> >
> 
> That's the distinction between Featured Apps and everything else in the
> world. Core is for, well, core OS and desktop functionality that everyone
> can't do without. The only thing requiring approval today is Platform and
> Core.
> 
> It certainly belongs in the apps moduleset where it is now so that it can
> facilitate easy jhbuilding. There's no approval required for the apps
> moduleset nor for Feature Apps (which is only a marketing distinction).

Thanks for bringing this as that was certainly the plan but (by lack
of resources in the marketing team?) it fell down and we got back to
square one with the release team "somehow" handling applications, in
this case "Boxes".

"Somehow", because we didn't redefine criterias, in terms of
documentation, schedule, all the things we had before. If people wants
the release team to handle apps, we should get back to some processes.

So I guess my questions are about roles, marketing team? release team?
and consequences.



Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes (was Re: 3.4 Features, final round)

[Frederic Peters]

Zeeshan Ali (Khattak) wrote:

> On Mon, Nov 7, 2011 at 9:00 AM, Vincent Untz  wrote:
> > Le dimanche 06 novembre 2011, à 17:06 +0100, Frederic Peters a écrit :
> >> + Boxes
> >>   https://live.gnome.org/ThreePointThree/Features/Boxes
> >>   → many commits, mclasen will push the developers to blog a progress 
> >> report
> >>     once they have something to show
> >
> > While Boxes look interesting, to me, it feels like it's "just" an
> > application, and not a feature per se. And I'm not saying that in a
> > negative way :-)
> 
>   You are correct in the sense that it is 'an' application and not 'a'
> feature. It is more like 2 essential features combined in one:
> 
> 1. Remote display: It is very common to own/having to deal with
> multiple machines these days so many users really need ability to
> easily connect to remote machines (virtual and real).

Talking about connecting to remote machines, how will Boxes coexist
with Vinagre? Do you expect its features to be available via Boxes by
3.4 time, or should both of them coexist for a while?

David, what's your take on this?


> 2. Trying out OSs: Each time we release GNOME, I really want to try it
> out and I know many people who do. Same goes for distros but people
> usually try to avoid risks and therefore most people wait till the OS
> in question is stable enough. I have even seen people avoid trying out
> an OS just because they are too scared of it doing any harm to their
> computers. Users will definitely appreciate an easy and completely
> secure way to try out OSs.

I appreciate Boxes could help here but really, trying out OSs is not a
common hobby :)




Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

3.4 Features, final round

[Frederic Peters]

Hello all,

It's about time to decide on the major features we'll track for 3.4.
Actually the release team already met yesterday and did a quick round
up of the proposed features, here's a summary (title/url) of them as
well a a quick release team note.

If you feel that something important hasn't been mentioned yet about a
proposal, or if you have questions or comments about them, go ahead
and speak now.


+ Zoom options dialog (universal access)
  https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00140.html
  → Some UI details needs to be worked out, but we want that.

+ Brightness and contrast functionality
  https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00141.html
  → Some techical details needs to be worked out, but want that.

+ Focus caret/tracking in GNOME Shell
  https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00142.html
  → Still need to be started but there is a good plan.

+ Braille Translator for Print Documents
  https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00143.html
  → Good thing, we should push dots to #gnome-design for some polish

+ Information-efficient text-entry interface, driven by natural continuous
  pointing gestures
  https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00144.html
  → We should bring dasher back to the -tested moduleset, and keep an eye on it,
making sure it builds with our platform changes.

+ Alternative input system based on low-cost webcam
  https://mail.gnome.org/archives/desktop-devel-list/2011-October/msg00145.html
  → out at the moment, the feature would need to be integrated to be
part of GNOME

+ Application menu / Actions
  https://live.gnome.org/ThreePointThree/Features/ApplicationMenu
  → desrt put out his gio menu model code on a branch, mclasen wrote
some gtk test code, mclasen needs to push walters to take a stap
at the shell side, hopes to get a prototype by end of November.

+ Blank slate helps you get started
  
https://live.gnome.org/ThreePointThree/Features/Blank%20slate%20helps%20you%20get%20started
  → it's getting implemented in gedit, seif has been blogging about
it, not sure how it would fit in other applications (we don't have
a lot of "create document" applications).

+ Boxes
  https://live.gnome.org/ThreePointThree/Features/Boxes
  → many commits, mclasen will push the developers to blog a progress report
once they have something to show

+ Help Menus
  https://live.gnome.org/ThreePointThree/Features/HelpMenus
  → Shaun has been doing good progress, and reported them recently,
still unsure about the way it will fit with app menus (this will
probably need a pass in #gnome-design once we have an app menu
prototype) but they would be used in other places, so we shouldn't
block on this.

+ IBus/XKB support
  https://live.gnome.org/ThreePointThree/Features/IBus
  → many pieces are there, but details remain to be sorted out

+ Jumplists
  https://live.gnome.org/ThreePointThree/Features/Jumplists
  → didn't heard much opinion of it from designers

+ Network zones
  https://live.gnome.org/ThreePointThree/Features/NetworkZones
  → many find the idea useful but all designers hate the idea, mclasen
will update the page to reflect that

+ Lock Screen
  https://live.gnome.org/ThreePointThree/Features/ScreenLock
  → Jon has started to put designs on the wiki

+ System Dialogs
  https://live.gnome.org/ThreePointThree/Features/SystemDialogs
  → mclasen will ask stef

+ a11y themes
  http://live.gnome.org/Accessibility/ThreePointTwo/NiceToHaves
  → the feature page needs to be written, the idea seems to be to
reuse symbolic icons where possible.

+ improvements in $foobar
  → Documents, network panel, user panel, wacom panel



Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Upgrade .jhbuilrc to gnome-apps-3.4

[Frederic Peters]

Steve Frécinaux wrote:

> On 10/26/2011 06:42 PM, Javier Jardón wrote:
> >just a reminder to note that we are already in the GNOME 3.4 release
> >cycle (3.3.1 will be released this week),
> >so do not forget to update your .jhbuildrc files to point to the 3.4 
> >modulesets.
> >
> >Normally you simply has to change this
> >
> >moduleset = 'gnome-apps-3.2'
> 
> Why not provide a gnome-apps-latest alias ? (ie a moduleset
> including the latest gnome-apps moduleset)

Actually getting the latest version (modulo the few weeks around a
major release) is what you get if you don't specify a moduleset in
your config file (and update jhbuild regularly).


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Attention anyone uploading binaries to ftp.gnome.org/pub/binaries - understand the GPL

[Frederic Peters]

Colin Walters wrote:

> Just a reminder - 2.5 weeks away now.
> 
> On Wed, 2011-09-21 at 11:10 -0400, Colin Walters wrote:
> 
> > Also, just to move things along, I plan to remove any binary which does
> > not have a corresponding SOURCES file in say one month from now.
> 
> walters@master:/ftp/pub/GNOME/binaries$ find -name SOURCES
> ./mac/frogr/0.5/SOURCES
> ./mac/frogr/0.6/SOURCES
> ./mac/frogr/0.6.1/SOURCES
> walters@master:/ftp/pub/GNOME/binaries$ 
> 
> =(

You could add /ftp/pub/GNOME/misc/ as a base directory; we do not have
the 3.2 live image on there, but while the Promo DVD has a README file
with a "Getting the Source Code" paragraph, we do not have anything
for the Fedora based live 3.0 CD.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.3 Schedule Draft

[Frederic Peters]

Shaun McCance wrote:

> The release team decides on big new features that span the desktop.
> Individual module maintainers still add features as they like. Let's
> say the Evince developers decided to add support for a new document
> format. It's not really a UI change in the sense we've traditionally
> understood, but it is a feature. And it affects the help. Absent a
> feature freeze, they could add support right up until the hard code
> freeze, a mere week before the stable release.

Of course you're right on this; with the serie of changes from "module
proposal" to "feature proposal", I failed to notice that "feature
freeze" did already exist, with a different meaning for "feature";
this should be fixed, let's have THE freeze discussed in your other
thread.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.3 Schedule Draft

[Frederic Peters]

Shaun McCance wrote:

> On Tue, 2011-09-20 at 14:42 +0200, Andre Klapper wrote:
> > A draft for the GNOME 3.3 schedule is available at
> > 
> > https://live.gnome.org/ThreePointThree#Schedule
> > 
> > Comments are welcome; Silence means compliance.
> 
> I notice there's no longer a feature freeze. I was going to propose
> a change to our UI freeze policy, but my proposal involved feature
> freeze, and it's gone. Intentional?

It's intentional, the release team decides on new features, we'll do
this early (week 6), and this cycle we will try to be more active,
getting regular status updates on the different features).

But this doesn't encompass all developments happening in GNOME, but a
set of "major user visible (and marketable) changes, typically
affecting several modules, in need of some consensus, and a person to
lead the change.". For other features we will keep on pushing for
people to publish roadmaps, but it's simply not possible to forbid
other developments happening.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

From here to apps

[Frederic Peters]

Hey,

New apps are being designed on https://live.gnome.org/Design/Apps/ and
it's really nice, we are getting Contacts and Documents on our
computers in 3.2. Those days I am wondering about apps that are in
domain spaces where we already have good applications, this is
prompted by a comment from David Nielsen on the Music page:

   The design so far looks some what like what Banshee has shipped for
   a long time for MeeGo and I would suggest using that as a start off
   point. Upstream already has a solid media management experience
   that is well deployed and tested. Adoption of GNOME3 technology is
   ongoing and the design of Banshee allows for easily experimenting
   with new UIs such as this one.

There's Music (and we also have Rhythmbox in that space), but this is
for example also the case for Photos (Shotwell?) and Boxes (Vinagre?
virt-manager?).

Speaking of Vinagre, it even has "Implement some of the ideas from
GNOME desktop sharing/virtualisation design mockups" on its roadmap
for 3.4 (see ).

So, is there anything we could do to get to the new apps faster,
accompanying existing apps to their bright future, benefiting from
their experiences?  Should we encourage specific apps authors to join
#gnome-design? What kind of place can we create for existing
applications willing to go the "GNOME App" path?



Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Splitting gnome-utils for 3.4

[Frederic Peters]

Emmanuele Bassi wrote:

> Cosimo: the only issue I can think of when splitting up the repo are the
> translations; currently, everything is translated into the same domain,
> so we'll need the i18n teams to perform some surgery. we can probably do
> it during the split (probably at the cost of the history), though.

The translations shouldn't be an issue, the .po files will be
duplicated in the new modules, with a lot of unnecessary strings, and
those will be eliminated automatically in l10n.gnome.org since they
won't be in the respective .pot file.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Switch of GNOME tarball compression format: tar.xz only

[Frederic Peters]

Vincent Untz wrote:

> Le dimanche 11 septembre 2011, à 13:41 +0200, Olav Vitters a écrit :
> > If you have concerns, I'd like to hear about it. I've set the reply-to
> > to desktop-devel-list and distributor-list.
> 
> With a few other (non-gnome) tarballs switching to xz-only, one thing I
> realized is that python doesn't support that yet:
>  http://bugs.python.org/issue6715
> 
> It means that, for my downstream activities, I'll have to update some
> scripts to work around this missing feature in python.

This is also a problem for library-web (library.gnome.org & developer.
gnome.org).


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Features-oriented releases

[Frederic Peters]

Hello Alexandre,

We will soon have 3.2 released, and it's quite time to discuss things
for 3.4, and as I said previously, while the features focused process
is something we really want, the way it happened for 3.2 was
suboptimal. Let's work on this, here are some thoughts.


My goal for features is to strenghten the position of the release
team, it shouldn't just be a list of things put on a wiki page at the
beginning of the cycle, we should demand schedules, progress reports,
status updates, during the whole cycle, and over cycles, as a feature
can span several of them.

This will be an important job and we should therefore concentrate on a
limited set of features, and here comes an important point, there is a
lot of place for features that are coordinated in an ad hoc manner,
without the assistance of the release team.

Still it is useful for features to be presented and discussed on the
desktop-devel list, as the exchanges will be signs of the directions
the GNOME project want to take; and this is on that basis that the
release team will have its own discussions, and declare support for
some of them.

What would be in it? I wrote about new requirements the release team
would have, but what are the benefits? This is unfortunately hard to
tell, ultimately module maintainers are the decision makers, what are
the steps the release team could take to help features happen?
Fortunately this shouldn't have to be about forcing patches to get in,
maintainers will express themselves in the discussion period, and will
agree with the direction of the project. (I do not foresee changes,
and hopefully maintainers are ok with the current direction).


Comments?


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Confused about the release

[Frederic Peters]

Hi again!

> Anyway we're late, and I'll ask you for two more days of patience, so
> that we have the time to meet and give you a proper answer on the
> practical questions you have; and we will make sure this gets improved
> in the future.

So we had our release team meeting yesterday evening,

Shaun wrote:
>> I noticed that we have Contacts, Documents, and Sushi in the
>> apps moduleset. If shipped, all of these are just core parts
>> of the desktop experience, so I want to document them in the
>> desktop help. But I'm wary of doing that for modules in apps.

Documents will just be a preview release, it shows the direction,
nothing more, nothing less, I don't think it's worth including it in
the desktop help for 3.2. On the other hand the features provided by
Contacts and Sushi certainly have their place in the help.

Apart of those, other new help topics could be colour management,
onscreen keyboard, and support for tablets.

I hope this answers your question, we are really sorry to provide you
this info so late in the cycle, we are still commited to keep going on
with the feature focused process, but we will improve the schedule,
and the reporting from the release team.

And really, don't hesitate to pester us whenever you feel we are
acting in a black box.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Confused about the release

[Frederic Peters]

Hi Shaun,

> The lack of module discussions overall is making it difficult
> for me to keep track of what the docs team needs to work on.
> I used to be able to send a documentation status report for
> each module before the decisions were made. Now it just seems
> like a black box.

Sorry about that, it's definitely a change in how we approach the
releases and things are far from perfect and still need to be
adjusted, for example there have been discussions (remember the
"feature proposal: backup" and how it turned in a "external gnome
control center panels" thread) but they were not systematic, and more
importantly, they were not followed by a formal decision by the
release team.

This is also because there were numerous changes in the release team,
and time had to be dedicated to get the new members to know about the
technicalities of our release processes, with less time to use on the
human/community processes :/

Anyway we're late, and I'll ask you for two more days of patience, so
that we have the time to meet and give you a proper answer on the
practical questions you have; and we will make sure this gets improved
in the future.


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: TARBALLS DUE: GNOME 3.1.90 beta release, and freezes

[Frederic Peters]

Richard Hughes wrote:

> On 28 August 2011 08:18, Frederic Peters  wrote:
> > We pushed it back to make it rock, so we count on you to deliver your
> > tarballs on time, this is before Monday 23:59 UTC. Thanks!
> 
> Monday is a bank holiday in the UK, so I have to work on my day off or
> will early morning Tuesday be acceptable? I don't mind the former if
> it's a hard requirement. :-)

It's nice to ask, so you'll be granted an exception :)


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Update GnuTLS minimum dependency to 2.12.0?

[Frederic Peters]

Hi Stef,

> In order to complete the GIO TLS Database work [1] for smart cards
> and other PKCS#11 databases (like gnome-keyring), it looks like I'll
> need to update the GnuTLS dependency [2] to 2.12.0 or later.
> 
> Any objections to doing this? Are we too late in the release cycle?

It looks really new, from a quick glance at distro websites, it's not
available in Fedora 15 nor in Ubuntu 11.10; do you have a patch for
jhbuild to build gnutls 2.12, does it work, are other packages using
gnutls working with the new version?


Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[Frederic Peters]

Jason D. Clinton wrote:

> On Wed, Jun 1, 2011 at 11:38, Johannes Schmid  wrote:
> > Pretty good list of examples. All of these projects are mostly driven by
> > Red Hat full-time employees (which isn't a bad thing in general). It
> > happens to be the same company employing big parts of the core design
> > team.
> >
> > While this doesn't mean it is a "closed group" of people, for an outside
> > developer or volunteer it pretty much feels like that even if the
> > individuals of that group are totally open to external
> > contribution/envolvement.
> 
> To *who* does it feel that way? If you're going to insinuate that
> people have tried to get involved and been rebuffed, then I think the
> responsibility here falls to you to provide an example. Please don't
> talk around the accusation by inferring that it's some kind of RH
> conspiracy. It's not.

Johannes is definitely a active member of the GNOME community, and in
my opinion the work he has been doing to make it possible for new
developers to come and use our platform is underestimated (Anjuta,
the dev doc tools hackfest, the continued work on platform demos,
etc.).

Therefore I don't think you should dismiss what he wrote, as if he had
just a vague knowledge of our community, mimicking his message as
"there's a Red Hat conspiracy".


And a second point is that it may not be easy to give examples, not
because they do not exist but because we may hesitate to bring the
involved persons in the discussion without their consent. (I don't
know if it's the case for Johannes, it's certainly my case).



Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: systemd as external dependency

[Frederic Peters]

Lennart Poettering wrote:

> I'd like to propose systemd (GPL2+,
> http://www.freedesktop.org/wiki/Software/systemd) as blessed external
> dependency for GNOME 3.2. 

There actually isn't a module proposal period anymore.  We are using
feature or design proposals now.  But the process for external
dependencies was different anyway.

Recently I was trying to categorise our 2.x external dependencies,
thinking about the way to handle this for 3.x, and came with three
levels:

** 1st level **

  Established, stable, system modules, they have been in
  place for a long time, with stable API and ABI, and they exist in
  sufficient versions in the distributions commonly used by GNOME
  hackers, even in older but still used versions (Fedora 13 for
  example).

  Examples : libxml2, libpng, dbus...

  Proposed guideline : mentioned as dependencies with a base version,
  not built by default by jhbuild.

  Rationale : we want to reduce the number of modules that need to be
  built to start developing on GNOME.


** 2nd level **

  Modules developed outside GNOME, with little attention to our
  schedule, but with an active development, and where we want to track
  recent code.

  Examples : mozilla (js-185 nowadays), poppler.

  Proposed guideline : built from tarballs, version bumps whenever a
  module need a new version.

  Rationale : we need recent code, but we do not want to arrive on a
  release days with modules failing to build because they require some
  code only available in $DVCS.


** 3rd level **

  Modules developed outside GNOME, with attention to our schedule
  (i.e. we can ask for a tarball and get it in two days).

  Examples : webkitgtk, polkit.

  Proposed guideline : treated like any other GNOME module, built from
  latest git.

  Rationale : we do not need to put extra burden on modules that are
  close to us.


At which level would you see systemd integrated, now, and in the
future?

Also you are speaking about (D-Bus) interfaces, and it is already
envisioned to have them implemented by other components, should we
talk about D-Bus interfaces that we expect to be available for GNOME,
instead of saying "systemd"?

Something else is the ability to run development GNOME, the most
common tool those days is jhbuild, which was created way before D-Bus,
and it's not always straightforward to get it working with D-Bus
services, do you believe it will be possible to have systemd built and
useful from jhbuild, or do you expect systemd will have to come from
the distribution?



Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Frederic Peters]

Shaun McCance wrote:

> I think that's the idea behind the Apps moduleset, but not Core.
> Core is the operating system. Apps are some things we think you
> might like to install on top of it.
> 
> At least, that's my understanding.

That's correct.



Fred
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list