Re: Looking for unit tests written for GNOME 2 back in 2004

[Tristan Van Berkom via desktop-devel-list]

Hi,

On Sat, 2021-03-20 at 15:53 +0530, Tejas Sanap via desktop-devel-list wrote:
> Hi everyone,
> 
> This is going to be a weird request.
> 
> But, I'm looking for unit tests that were contributed to the gnome
> project back in 2004-2005. 
> 
> I have been trying to find them somewhere in the code repository, but I
> haven't had much luck, yet.
> 
> I would really appreciate if someone could help me by sharing links to
> the appropriate repositories (back in 2004, gnome was using CVS).
> 
> Any sort of help, would be much appreciated. If my question is too wide,
> please let me know, and I will try to share more details, that can help
> me narrow my search.

Yes this is too wide of an inquiry.

I should point out that at the time of the migration from svn to git,
the svn and CVS history was preserved, so if you are looking for
specific code dating back to 2004 in a module hosted on GNOME
infrastructure, you should still be able to find it in the
corresponding git repository.

Cheers,
-Tristan


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

Re: Can we enforce beta release for the freeze

[Tristan Van Berkom]

Hi all, and long time no see, hope everyone is doing well...

On Tue, 2021-02-23 at 08:37 -0600, Michael Catanzaro wrote:
[...]
> On Tue, Feb 23, 2021 at 1:53 pm, Emmanuele Bassi via desktop-devel-list 
>  wrote:
> > In the end, though, releases are manual labour; only the maintainer 
> > can say: "okay, this is good enough for other people to use" (where 
> > "people" defines different audiences depending on the stage of the 
> > development cycle). No amount of automation is going to solve that 
> > because if it did we would not need per-project maintainers in the 
> > first place, and we would only need people reviewing code and 
> > pressing the "Merge" green button.
> 
> We...
> 
> I think we *could* automatically tag the .alpha .beta .rc and .0 
> tarballs, since I expect these to be created at specific predetermined 
> times regardless of whether the code is "ready" or not. This would 
> solve Shaun's problem. It would require a bunch of infrastructure work, 
> though. We would lose manually-written NEWS files. But automation would 
> probably not be able to handle library versioning, like libtool C:R:A 
> or the meson equivalent, so maintainers would need to handle that 
> manually in advance.

I think this is a wonderful idea, I've been toying with something
similar for years now, I never ended up taking it to d-d-l as I did not
get much traction from within the release team yet.

>From my perspective, the main pain point that I would like to solve, is
that we are not running integrated builds of the same software we end
up releasing, if we were releasing the same thing we were running
integrated builds of, then we would obviously have much less issues at
release time.

Bringing releases inline with regular CI throughout the cycle would
also make actual integration work more meaningful (i.e. work like
testing pam setups for gnome-keyring, getting the ibus working
properly, ensuring the GOA stuff is all working, etc).

As this topic came up, I'll try to throw up a tentative outline of how
I think this could work.

  * We would need to support opting in and opting out of this.

For maintainers who want to keep manually tagging and releasing
tarballs, we would only ever build tarballs for those in the
integrated builds.

Those maintainers are responsible for updating the tarball
references in gnome-build-meta every time they release a tarball.

Some policy would need to be drawn up on what happens when
introducing an updated tarball of your platform library into the
build causes the overall GNOME build to break.

  * For maintainers who opt in to the automation (which I would think
would have to be more than 80%, ideally 95%, for this approach to
be worthwhile), we would enforce a GNOME-wide standard release tag
nomanclature.

  * Maintainers would be responsible for updating the `track` reference
in gnome-build-meta for the active release cycle.

With something like this, the release builds would just track the
latest of every maintainer chosen branch at the time of release, and
tag the modules which have changed in any way since the last release
tag - tagging the module would result in automatically also generating
a tarball and publishing it (possibly without any NEWS updates as
Micheal pointed out) - the tarballs are only generated for the
convenience of certain downstreams which still want to consume them.

> For stable releases after .0, I agree only a human can judge when a 
> release is required.

Once the first stable release is out, there are different ways we can
handle things, but I don't think that it is entirely necessary to have
the maintainer decide when to make a stable release of their modules -
if any new commits are available on the active stable branch listed in
the corresponding gnome-build-meta stable branch, they will be included
in the next stable release and a release will be made for them
automatically (tag + tarball published).

Instead, if there are critical security patches which need to go out on
a module in a stable series, the maintainer can just request that the
release team make an additional releases for that exception (if the
automation is good, this should not require effort on the part of the
release team anyway).


There are surely risks and downsides, like ensuring libtool versioning
bumps happen correctly, and ensuring good enough communication (such
that we select the correct branches for CI at the *beginning* of a new
cycle as well as when the freezes start), but in general I think this
would be a good avenue to pursue and would be happy to lend a hand
where I can to help us get there.

Cheers,
-Tristan


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

Re: Bootable GNOME images available

[Tristan Van Berkom via desktop-devel-list]

Hi Felipe,

On Thu, 2019-09-19 at 12:09 +0200, Felipe Borges wrote:
> Hi Tristan, thanks a lot for working on this. It is definitely going
> to help our development efforts both in CI and design.
> 
> On Thu, Sep 19, 2019 at 11:39 AM Tristan Van Berkom via
> desktop-devel-list  wrote:
> > Hi all,
> > 
> > It's my pleasure to announce that we are now producing bootable
> > images based on the very latest of GNOME modules as defined by the
> > gnome-build-meta[1] (which we also use to build the releases and
> > produce the GNOME flatpak runtime/sdk).
> > 
> > At this time, the image is recreated every time the gitlab pipeline
> > runs, and can be downloaded from gitlab here[2].
> 
> In GNOME Boxes we have the "Download an OS" feature that makes it
> easier to obtain and install an OS. I would love to feature the GNOME
> images there. For that, could we hotlink directly to [2]? Will this
> link change?
> 
> https://fedoramagazine.org/download-os-gnome-boxes/

I can't say for certain that this will be a permanent link.

The images weigh in at about 3.5 GB as it stands, and I'm not entirely
sure how long they are stored on gitlab and if it makes sense to keep
accumulating them on gitlab.

Of course, this mostly requires that we conspire on deciding what the
best solution is long term.

> Also, could we include spice guest tools in the image? This way Boxes
> could provide cool features such as "shared clipboard, automatic
> resolution, shared folders, sent files via drag and drop, and many
> more. My initial run of the image in Boxes showed that this adjustment
> will be necessary if we want people to run the VMs in Boxes.

I think it would be fine to include spice guest tools yes, the kernel
already has some guest specific features enabled, this sounds like a
natural extension to that.

The gnome-build-meta project already includes spice-protocol and
spice-gtk in the 'elements/core-deps' subdirectory, whatever is missing
could be added there and included in the image.

FWIW, I did try to boot the image with Boxes but indeed had some issues
(I think I was mostly hoping to have out of the box host network
sharing "just work") - I think it would be really great if the image
"just works" with boxes.

> What is the best channel for us to discuss these things I mentioned above?

As it stands, the body of work is maintained by the release team and
also the freedesktop-sdk project (as GNOME uses the latter as a shared
base, of course some coordination is required). So for example, if you
need a kernel feature enabled then the patch should go to the
freedesktop-sdk project.

For IRC, I would recommend the #release-team channel on gnome irc, and
the #freedesktop-sdk channel on freenode.

For issue tracking:

https://gitlab.gnome.org/GNOME/gnome-build-meta/
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/

Thanks for your encouraging enthusiasm !

Cheers,
-Tristan


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

Bootable GNOME images available

[Tristan Van Berkom via desktop-devel-list]

Hi all,

It's my pleasure to announce that we are now producing bootable
images based on the very latest of GNOME modules as defined by the
gnome-build-meta[1] (which we also use to build the releases and
produce the GNOME flatpak runtime/sdk).

At this time, the image is recreated every time the gitlab pipeline
runs, and can be downloaded from gitlab here[2].

The image comes with a simple launcher script for qemu, and should boot
up to the gnome-initial-setup[3] tool automatically.


Next steps
~~
The current setup still leaves much to be desired, and we're hoping
others will pitch in and help improve our CI story.

The next big task ahead of us is to boot the image in CI and perform
automated tests on it, most probably with openQA, you can follow that
issue here[4].

Of course there are many other things to accomplish:

  * Allow atomic upgrades with ostree, which requires some system
integration work and also requires that we publish the builds in a
publicly hosted ostree repository.

  * Currently we only build the image for 64bit intel, but we should
be able to boot for the 4 architectures we already support for the
GNOME Flatpak SDKs (i686, x86_64, armv7, aarch64).

  * Improve system integration in general, ensure input methods are
working, online accounts are integrated properly, keyring unlocks
with user login, etc.

  * Run installed tests as a part of the CI pipeline before wrapping
the image itself.

  * The list goes on and on :)


If you'd like to help out but need some pointers getting familiar with
the gnome-build-meta project, feel free to ask Javier or myself, and
other release team members should also be capable of pointing you in
the right direction.


Finally, thanks to everyone on the release team and also freedesktop-sdk
project contributors who have helped immensely to get us this far !

Cheers,
-Tristan


[1]: https://gitlab.gnome.org/GNOME/gnome-build-meta
[2]: 
https://gitlab.gnome.org/GNOME/gnome-build-meta/-/jobs/artifacts/master/browse/image/?job=build-gnome-core-x86_64
[3]: https://gitlab.gnome.org/GNOME/gnome-initial-setup
[4]: https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/206


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

Re: System-wide dark mode

[Tristan Van Berkom via desktop-devel-list]

I've been meaning to reply somewhere in this thread... I am a user
of the dark theme via the tweak tool.

In the GNOME 2 days, we did some effort in Glade to ensure that we were
compatible with HCI themes (high contrast invert as we called them), as
I recall we also ensured on a GNOME wide level that our icons were
compatible with HCI themes - likely many GTK+ apps ported forward from
the GNOME 2 days will already work well out of the box with a dark
theme due to previous efforts.

While I did not use the HCI themes back then, I really like the dark
theme that I have been using with GNOME 3.

On Mon, 2019-06-03 at 07:46 -0500, mcatanz...@gnome.org wrote:
> On Mon, Jun 3, 2019 at 5:40 AM, Allan Day  wrote:
> > If the size of the theme is the issue, do we know what size is 
> > acceptable?
> 
> For WebKit to be able to handle this, the required performance 
> improvement would be measured in orders of magnitude. I don't know 
> about Firefox.
> 
> Without changes in GTK to allow us to use multiple themes at once, or 
> instantaneously switch between themes, we can either give you broken 
> dark mode (the status quo in both WebKit and Firefox), or we can give 
> you light mode (my recommendation).

Are you saying that WebKitGTK interprets the system theme and CSS to
render the HTML content ? This does seem a bit unintuitive to me for
web content, but I suppose it is useful for cases where apps want to
embed HTML that they themselves control.

That said, as a dark theme user I doubt that having the web browser
(which I usually put fullscreen anyway) being in light mode is going to
stop people from using a dark theme.

Anecdotally, currently my biggest issue with the dark theme is that
receiving HTML emails is even more of an annoyance, as I get a flashy
attention grabbing white background in Evolution for any HTML email:
Even though it annoys me a lot, it's not enough for me to switch to a
light theme.

Cheers,
-Tristan

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

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

[Tristan Van Berkom via desktop-devel-list]

Hi Matthias,

I am replying to your post because I think it is masterfully written
and agree with it.

That said, the opinions expressed here are my own, I urge people to
not confuse my own arguments with Matthias's, and consider
these separately.

On Fri, 2019-04-26 at 19:11 +0200, Matthias Klumpp wrote:
> > Am Fr., 26. Apr. 2019 um 18:12 Uhr schrieb :
> > I'm a little surprised that nobody has yet mentioned the elephant in
> > the room. The definition of "git" is not very inclusive:
> > 
> > [...]
> 
> I really did not want to comment on this thread initially, but I would
> like to add a thought to this afterall:

Likewise (I also changed my mind).

I think that there are political pressures revolving around this topic
which prevent people from speaking their mind clearly, and I worry that
simply by not speaking up against this change we allow such pressures
to rise to a point where nobody feels free to speak their mind.

I think our priority at the community level has to be that we are open,
transparent and inclusive - while this proposal itself aims to improve
inclusiveness, it does not in my opinion achieve this goal.

Instead, by opening the door to censorship of words which are not
themselves inherently vulgar or foul (i.e. 'master' is not considered a
'swear word'), we are creating an atmosphere where people worry more
and more whether they can express themselves freely.

I don't want to be counted among those who stood silently by and
allowed our community to degenerate into a place that is not inclusive.

I do not want this community to entertain or endorse the notion that
people have any inherent right to not ever be offended either - a base
requirement for communications at this international level is that we
always take the context in which words are used into consideration and
always assume the best intentions: we should not allow ourselves to be
"triggered" simply by a word we do not like.

We should also not show favoritism of one set of cultural values over
another, I feel that censorship to this degree is a very western
concept which we should not lend any credit to. Ask has already pointed
out that the possible offensiveness of the word 'master' on it's own is
even more particular to the USA, I cannot speak to the veracity of this
but I do suspect that this is pandering specifically to US
sensitivities, which I also do not agree with.

As such, I clearly express my opposition to this proposal.

Best,
-Tristan

PS:

I should point out that I think the subject line here is misleading: It
purports to remove references to "master/slave" relationships in GNOME
modules (this would be a proposal I could get behind honestly).

However, the proposal goes on to propose eliminating all uses of the
word "master" (as in git master, as in the 'master copy') regardless of
whether it is used in context of being in relation to a slave
component.

Proposing that we replace references to master/slave relationships with
other terminology and proposing that we eliminate the usage of both
words entirely are two entirely different proposals, this is a proposal
of the latter which appears to be masquerading as the former.

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

Re: Retiring app menus - planning for 3.32.0

[Tristan Van Berkom via desktop-devel-list]

Been on vacation and amused with this thread...

On Fri, 2018-09-21 at 15:54 +0200, Bastien Nocera wrote:
> On Fri, 2018-09-21 at 14:26 +0100, Allan Day wrote:
> > > > On Fri, 21 Sep 2018 at 12:54,  wrote:
> > > 
> > > On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera 
> > > wrote:
> > > > It's faster to access for users, has terser explanations (no need
> > > > to
> > > > create sentences to describe actions) and it's usually better
> > > > updated
> > > > as it lives in the code, as opposed to being separate in the
> > > > docs.
> > > 
> > > It's also larger, well-designed, easier to read and use.
> > 
> > But what if the docs were similar...? This is a hypothetical future,
> > not what we have today.
> 
> Still takes you out of the application itself.

I would just like to add my 2 cents to this, and basically point out
that having a user manual is by no means an excuse to make primary
features non discoverable in the UI proper.

I consider keyboard shortcuts for a video player to definitely be a
primary feature (at the very least pause, play, fullscreen, next scene,
are things you don't want the user to have to bother with clicking
around on a regular basis).

User manuals are great for the few people who like to read them and get
the hang of the app, or for a fairly complicated app, but if your user
is reaching all the way to the manual because they are unable to figure
out how to perform a basic function, then the user is already
frustrated and the application UI has already failed.

When you buy a DVD player, a TV, a game console, a power drill; you
plug it in, look at the buttons, and expect it to just work. I think
people expect (and deserve) the same out of the basic apps that people
use on a day to day basis.

Cheers,
-Tristan

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Sorry I've been slow on this thread, it's an inopportune time as I'm
stuck in all day meetings all week...

On Wed, 2018-01-24 at 14:24 -0600, mcatanz...@gnome.org wrote:
> > On Wed, Jan 24, 2018 at 2:11 PM, Florian Müllner  
> wrote:
> > Really, the only thing I disagree with is that RT appears to actively 
> > discourage maintainers from updating JHbuild before everyone actually 
> > has the option to make the switch - sure, if updating GTK+ fails for 
> > me because harfbuzz gained a new dependency, I'll be able to figure 
> > out what that dependency is, what's its upstream is and whether it's 
> > available in reasonably current distros. But it'll be a lot easier 
> > and quicker for whoever made the change in the first place :-)
> 
> Maybe we should delay this until BuildStream can generate OS images. 
> Tristan, what do you think...?

Delay discouraging updates of JHBuild ?

The main motivation so far for keeping JHBuild on life support was for
Builder users who use the JHBuild integration features, giving Builder
some time to catch up, and I think we're talking about a fairly low
volume of backports for a fairly short time anyway so I'm not opposed.

I don't want us to start moving backwards either. Great progress has
been made and it's an ongoing effort, in the meantime there will be
growing pains and we should be attentive and make sure people are not
left behind.

Cheers,
-Tristan

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

Re: Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Hi all,

This will be a long email, so TL;DR:

   o At this time you can keep using JHBuild for these few cases where
 testing is very difficult, you can even do so indefinitely.

   o For these few modules who dont benefit directly at development
 time from the release team's official build metadata, the effort
 should be very low.

   o We will have a way for you to test core components soon, and it
 will be superior in many ways, but will inevitably lose *some*
 of the convenience which JHBuild offered.


On Mon, 2018-01-22 at 14:31 -0600, mcatanz...@gnome.org wrote:
> > On Mon, Jan 22, 2018 at 12:56 PM, Carlos Soriano  
> wrote:
> > What's the workflow for those before a proper solution is done? Or 
> > are the developers of those modules expected to maintain JHbuild on 
> > the meantime?
> 
> Thanks Carlos; this is an important question. Let me provide a bit more 
> context for our decision to stop maintaining JHBuild now, even though 
> BuildStream is not yet be usable for running some modules.
> 
[...]

   I'd like to thank Michael for chipping in here while I was enduring
a travel itenerary which takes over 20 hours all told, and recovering f
rom it's side effects.

There have been some discussion about the pain points for testing the
few, albeit very important and central components of the GNOME UX on
your own developer laptop.

First of all, to avoid blowing things out of proportion, we are talking
about the maintenance of a few configure arguments for a handful
modules here. These modules are not easily verifiable and testable on
your laptop using BuildStream, *yet*.

Yes the release team demands that you update the gnome-build-meta
repository for these for our purposes of delivering integrated builds
and releases of GNOME as a whole, and these few core modules might not
yet be benefiting from those builds as developers - but these configure
arguments don't change immensely often, and whatever work the release
team did before in terms of maintaining them (mostly this is manually
checking the status of tarball converted builds at release time), is
not benefiting your experience as a developer on these modules
anyway.

A better way to test an integrated GNOME is coming, but for the time
being:

  Please update the gnome-build-meta repository to help us ensure that
  it's building. And feel free to continue to use JHBuild modulesets
  without those modulesets being considered in the integrated releases.


With that out of the way, in the long term; yes it's also fine if you
continue to use JHBuild for your own development workflow preferences,
but I am very driven to convince you that ultimately we will have a
better way of doing things both for the release team and for all GNOME
developers, and these visions should be aligned. So, I'll try to
alleviate some of your concerns regarding the long term picture of
development.


To start, here is a general outline of how the tooling differs in their
core values, and how these tools are effectively crossed in purposes:


   On JHBuild
   ~~
   JHBuild is a tool which prioritizes developer convenience,
   attempting to build the "latest of GNOME" on top of a loosely
   defined abstract system.

   Various tricks are in place in the GNOME modulesets, for instance
   modules which we *can* build, but avoid trying if we have the chance
   to determine that a local pkg-config file is found for it.

   The result is that you can mostly test your software on your
   machine, and for the majority of high level apps, this is good
   enough for the developer to test and cover the majority of use cases
   in manual testing.


   On BuildStream
   ~~
   BuildStream is a tool which puts determinism of builds first and
   allows absolutely no room for unknown factors contaminating your
   integrated build result.

   Various safe guards are put in place to ensure that you are never
   building or testing a result that cannot be reproduced exactly on
   another laptop.

   The result is that you are never uncertain about which module
   changed from one build to the next when a bug was introduced,
   and you are never writing software against the old version of
   a changed component which happens to be lying around on your
   system, causing last minute pain at release time.

   Whether GNOME is broken or is working well, you always know that
   the integrated result of a GNOME build is exactly what you expect
   it to be.


I should also point out that from a release team perspective, our
priority has to be delivering an integrated GNOME where it's components
always work well with eachother at release time, not a hand full of
components which happened to work well in their respective maintainers
hacked distro setups.


Developers in FOSS have historically filed the integration work under
the "not my problem" category, and the result of that is a lot of back
and forth with the downstream distros which ensues 

Re: Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Hi Jens,

Hurried reply whilst getting ready to go to airport...

On Sun, 2018-01-21 at 10:16 +0100, Jens Georg wrote:
> > On Sat, 2018-01-20 at 11:06 -0600, mcatanz...@gnome.org wrote:
> 
> > Hi all,
> > 
> > This bears repeating: the release team will no longer maintain
> > JHBuild 
> > or the JHBuild modulesets. When adding or removing a dependency from 
> > your module, please now update gnome-build-meta instead.
> 
> So, following up on that and also on the libgepub thread: Which places
> do I have to modify if I were to switch the ABI and API version of
> gexiv2

gexiv2 is listed as a system dependency, which strikes me as a bit odd
seeing as it's a requirement for some GNOME modules and it's hosted in
GNOME - I'm new to the release team and will have to figure out the
reasoning behind this.

Also, your question makes me realize I need to clarify some more things
about sysdeps and how they have changed, there is a longer term plan
which involves collaboration with the newly created freedesktop-sdk
project (see: gitlab project[0] and mailing list[1]) for building a
well integrated system which I will try to blog about soon.

For now, the actual sysdeps we use to populate a base runtime to build
against are controlled by this list[2], and is basically generated from
packages in debian testing - until the freedesktop-sdk project evolves
and we start generating bootable VMs with a combination of that, and
GNOME build metadata, I should move that repo over to GNOME's gitlab
and re-enable the automation of generating the images it creates (I've
been doing this manually in order to avoid unnecessary rebuilds).

Cheers,
-Tristan


[0]: https://gitlab.com/freedesktop-sdk
[1]: https://lists.freedesktop.org/mailman/listinfo/freedesktop-sdk
[2]: 
https://gitlab.com/BuildStream/debootstrap-ostree/blob/master/data/multistrap.conf.in

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

Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom]

Hi,

The time has come, the Release Team is now maintaining the GNOME
releases in BuildStream format, which is now available at:

https://gitlab.gnome.org/GNOME/gnome-build-meta

This repo is intended to contain the build metadata required for
building the GNOME core modules only, while many applications have been
migrated to Flatpak.

In the near future, Jürg Billeter will be landing his work[0] on
finally allowing BuildStream projects to depend on eachother, this will
allow people to create projects which depend on `gnome-build-meta`,
which will be a suitable approach for building things which are not a
part of the "core" category in GNOME.

Instructions for using the gnome-build-meta BuildStream project can be
found at:

https://wiki.gnome.org/Newcomers/BuildSystemComponent


JHBuild
---
For what regards the upcomming 3.28 release and further, patches should
go to the gnome-build-meta project instead of the JHBuild modulesets -
otherwise these patches would not be considered in the releases we are
building.

As agreed upon in this previous thread[1], changes in gnome-build-meta
can be backported to the JHBuild modulesets while they remain on "life
support".


Issues
--
Whenever you encounter a problem or hinderance in your workflow, please
let us know at either of the below trackers, depending on the nature of
your issue:

GNOME Build Metadata problems:
~~
https://gitlab.gnome.org/GNOME/gnome-build-meta/issues

BuildStream problems:
~
https://gitlab.com/BuildStream/buildstream/issues


At this time, I am aware of a few problems and inconveniences and we
are working hard on improving things as the project evolves and we
learn about new issues.

The hot topics I am aware of so far include:

  o Inconvenience when pulling changes from the gnome-build-meta
repository.

As is described in the newcomers wiki page[2], BuildStream rewrites
the project when fetching the latest commits on any given branch,
making it inconvenient when you want to pull new changes in the
metadata itsef (e.g. fixes to configure flags or dependencies,
additions of modules etc.).

A solution for this is under way[3].

  o Testing of modules which need integration with your host.

Some applications want to access resources which are highly
host specific, or require access to the internet to really
try out (e.g. epiphany). This doesnt always work out of the
box in an isolated `bst shell` environment with a base runtime
that may bear no resemblance to your actual host.

For the internet, it should be enough to setup a resolv.conf,
we should be able to bake this in pretty easily, other things
like access to pulse audio prove more difficult to address
without reimplementing Flatpak and portals.

The ultimate solution for this will be generating VM images
of what is really the "latest GNOME" (or more accurately,
the "exact version" of GNOME you wanted to build).

At the same time, I am considering allowing a project to create
"shell profiles" which can make `bst shell` more useful for more
resource intensive applications (perhaps by giving some control
as to what the shell can inherit from the host in terms of
environment variables and such like).

  o Integration with Builder

Christian has raised a list of features and points[4] to ensure
a great UX (or DX) which we will be considering and allocating
resources to address.


Cheers,
-Tristan


[0]: https://gitlab.com/BuildStream/buildstream/merge_requests/160
[1]: 
https://mail.gnome.org/archives/desktop-devel-list/2017-November/msg00036.html
[2]: 
https://wiki.gnome.org/Newcomers/BuildSystemComponent#Fetching_the_latest_build_metadata
[3]: https://mail.gnome.org/archives/buildstream-list/2018-January/msg5.html
[4]: 
https://mail.gnome.org/archives/buildstream-list/2017-November/msg00046.html

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

Re: Meson feedback as a user

[Tristan Van Berkom]

On Sat, 2017-11-25 at 03:45 +, philip.chime...@gmail.com wrote:
> Is it possible to add to the guidelines to write your meson file such
> that you check dependencies as soon as possible and fail early?

I think we can do better than that.

Since unlike other build systems, meson is more of a declarative than
procedural thing; I thought meson should be able to report all of the
missing dependencies in one go (instead of the obnoxious trial and
error we are used to).

When I suggested this in #mesonbuild, I was directed to an existing bug
report which already has some merge request, unfortunately I am unable
to easily find the issue number off hand, but it seems there is already
a work in progress for this... the future is bright !

Cheers,
-Tristan

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

Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor

[Tristan Van Berkom]

Hi!

Quick handphone reply...

> On Nov 24, 2017, at 5:13 PM, Sébastien Wilmet <swil...@gnome.org> wrote:
> 
>> On Fri, Nov 24, 2017 at 03:16:09PM +0900, Tristan Van Berkom wrote:
>> Had not considered this use case yet, thanks !
>> 
>> I'm an emacs user but have never used any kind of symbol completion
>> feature myself.
>> 
>> For this, one could use `bst checkout` to get a full checkout of the
>> build outputs which your element (module) of choice depends on, and
>> then periodically delete / re-checkout your sysroot checkout when it
>> starts to get out of date (or make parallel checkouts for separate
>> projects).
>> 
>> However currently this is a slow operation which uses a lot of disk
>> space. Since it is an export of the built artifacts, we dont risk using
>> hardlinks for the checkout, because that leaves the user in a position
>> where they can accidentally corrupt their local artifact cache.
>> 
>> I have been considering adding some explicit switch like `--unsafe` to
>> the checkout command to allow users to do this "at their own risk", but
>> haven't really found a use case to justify this, maybe you just
>> provided one !
> 
> As Christian explained, the text editor plugin also needs the list of
> CFLAGS, especially the -I's.
> 
> With Meson the easiest is to read the compile_commands.json file created
> at the root of the build directory. See:
> https://clang.llvm.org/docs/JSONCompilationDatabase.html
> 
> CMake can also create a compile_commands.json file.
> 
> With the Autotools/make, the Vim plugin that I use provides a script to
> extract the CFLAGS while `make` is running:
> $ make CC='~/.vim/bin/cc_args.py gcc'
> this creates a .clang_complete file containing the list of CFLAGS.
> See:
> https://github.com/Rip-Rip/clang_complete/

In this case, most probably `bst shell --build` gets us closest, it will create 
a sandbox on the fly, containing the sources you intend to build, and fail if 
the dependencies are not yet built, but persist only for the lifetime of the 
interactive shell it spawns.

Same build environment that BuildStream will create for a build.

The functionality is all there but it sounds like we should carefully design 
the right interface for casual users and Builder users alike.

Cheers,
-Tristan

>> Philip's reply is also a possibility but I would prefer recommending
>> something via BuildStream, mostly because you want to use exactly the
>> header files that you need for your target environment, but also
>> because there is no guarantee that a flatpak SDK will even have headers
>> for the dependencies you might want to use.
> 
> Yes the Flatpak SDK doesn't contain all dependencies.
> 
>> For the moment, I've added this issue[0] to make sure we dont lose
>> sight of this, in any case it should be very easy to implement.
>> 
>> [0]: https://gitlab.com/BuildStream/buildstream/issues/162
> 
> OK, it's a good news if it's easy to implement.
> 
> --
> Sébastien
> 

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

Re: GNOME Modulesets migrating to BuildStream - clang completion in text editor

[Tristan Van Berkom]

On Thu, 2017-11-23 at 17:00 +0100, Sébastien Wilmet wrote:
> Hi,
> 
> I've tried a little BuildStream, but I think I'll hit a problem if I
> don't use jhbuild anymore: have clang completion in my preferred text
> editor, it needs all the *.h files of dependent libraries. Currently
> those *.h files are either installed by Linux distro packages, or by
> jhbuild in the jhbuild install prefix, in all cases they are available
> on the host.
> 
> With BuildStream the *.h files are inside the container, so I would need
> to run the text editor inside a bst shell to be able to access the *.h
> files and have C completion, if I understand correctly.
> 
> When you need to hack on a C/C++ project with a text editor like Vim or
> Emacs, how are you doing it with BuildStream?

Had not considered this use case yet, thanks !

I'm an emacs user but have never used any kind of symbol completion
feature myself.

For this, one could use `bst checkout` to get a full checkout of the
build outputs which your element (module) of choice depends on, and
then periodically delete / re-checkout your sysroot checkout when it
starts to get out of date (or make parallel checkouts for separate
projects).

However currently this is a slow operation which uses a lot of disk
space. Since it is an export of the built artifacts, we dont risk using
hardlinks for the checkout, because that leaves the user in a position
where they can accidentally corrupt their local artifact cache.

I have been considering adding some explicit switch like `--unsafe` to
the checkout command to allow users to do this "at their own risk", but
haven't really found a use case to justify this, maybe you just
provided one !

Philip's reply is also a possibility but I would prefer recommending
something via BuildStream, mostly because you want to use exactly the
header files that you need for your target environment, but also
because there is no guarantee that a flatpak SDK will even have headers
for the dependencies you might want to use.

For the moment, I've added this issue[0] to make sure we dont lose
sight of this, in any case it should be very easy to implement.

Cheers,
-Tristan

[0]: https://gitlab.com/BuildStream/buildstream/issues/162

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

GNOME 3.27.2 RELEASED

[Tristan Van Berkom]

Hi all,

GNOME 3.27.2, the second unstable release in the 3.28 development
cycle, is now available.

The porting of more modules to meson continues (which is great!), but
It's still causing some problems for some modules. See the build
failures below, along with a short list of other build errors.

If you want to compile GNOME 3.27.2 by yourself, use the BuildStream
project snapshot here:

 https://download.gnome.org/teams/releng/3.27.2/gnome-3.27.2.tgz

For the remainder of the 3.28 development cycle, you can continue to
use the JHBuild modulesets, they are also available here:

 https://download.gnome.org/teams/releng/3.27.1/

The lists of updated modules and changes are available here:
 core   -  https://download.gnome.org/core/3.27/3.27.2/NEWS
 apps   -  https://download.gnome.org/apps/3.27/3.27.2/NEWS

The source packages are available here:
 core   -  https://download.gnome.org/core/3.27/3.27.2/sources/
 apps   -  https://download.gnome.org/apps/3.27/3.27.2/sources/


Build Failures
--
Instead of including a skip list of failing modules, I will just note
here which modules were unable to build and for what reason, it looks
like the majority of failures are due to lack of fresh tarballs:

  o gnome-chess: Changed to use meson, need new release tarball with meson
  o gnome-documents: Changed to use meson, need a new release tarball with meson
  o gnome-boxes: Changed to use meson, new release tarball exists but lacks 
the meson.build
  o gnome-terminal:  Depends on vte 0.51.1, only 0.50.2 is available (need new 
vte tarball)

  o gnome-system-monitor: Build failure

looks like source schema xml is missing from EXTRA_DIST:

No rule to make target 'org.gnome.gnome-system-monitor.gschema.xml', needed 
by 'org.gnome.gnome-system-monitor.gschema.valid'.  Stop.

  o fwupd: Stack trace encountered in po/make-images (this seems to be
   a bug in the runtime / sysdeps, I will investigate further)

  o gnome-software: Now depends on fwupd, which did not build


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.27, the full schedule, the official module
lists and the proposed module lists, please see our 3.27 wiki page:

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

Cheers,
Tristan Van Berkom
GNOME Release Team

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

Re: GNOME Modulesets migrating to BuildStream

[Tristan Van Berkom]

On Fri, 2017-11-10 at 01:45 -0800, Christian Hergert wrote:
> On 11/10/2017 12:46 AM, Tristan Van Berkom wrote:
> > I'm sorry that out of the many things I have to juggle, I had never
> > considered Builder compatibility to be a blocker for the GNOME release
> > team to start maintaining GNOME builds in a new format, this does
> > strike me as an unreasonable requirement.
> 
> I think you've miss-interpreted my criticism about timing as suggesting 
> a blocker (I'm not). What I was trying to communicate is that I would 
> have benefited from a heads up (and maybe even a scheduled go/no-go date).
> 
> Doing so would have provided me a chance at keeping things working.

I will try to do better from here on and I truly am sorry for the
inconvenience, It was my mistake to have made any assumptions of who is
consuming the modulesets and for what purposes.

I did try to do my research on this, but going too public too fast with
this kind of change also can have it's downsides, we are out of the
muddy waters now though, and I will try to communicate things more
clearly, there is still a lot to sort out.

Also, thank you for your patience and understanding.

Cheers,
-Tristan

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

Re: GNOME Modulesets migrating to BuildStream

[Tristan Van Berkom]

Hi Christian,

When shaking the tree a bit more publicly, something was bound to fall
out, lets figure this out.

On my side, I can say that there is still a ton of work that needs to
be done which can only be delivered after a hard switch to BuildStream
for the GNOME modulesets - delaying this by a whopping additional six
months is a serious setback to the project, which currently has
momentum and as such; viability.


On Thu, 2017-11-09 at 13:44 -0800, Christian Hergert wrote:
> On 11/09/2017 03:20 AM, Tristan Van Berkom wrote:
[...]
> However, many of us plan our cycles before the cycle starts so that we 
> ensure we have time to implement features without burning out. We're 
> already two months into the 3.28 cycle and not far away from the 
> beginning of freezes. Doubly so when you take into account winter holidays.

This is a delicate dance, we made this decision with the release team
at GUADEC actually, to start using BuildStream only after the imminent
stable release was out the door.

At GUADEC, had I considered that you would want to have integration in
Builder before a switch (I clearly did not suspect this at all) I
should have notified you personally at the time.

I still dont think that the timing for a wider public announcement
would have been right at that time; things need to be near perfect
before we start encouraging JHBuild users to use BuildStream instead to
build GNOME.

> This change will undoubtedly affect those of us working on tooling, 
> newcomer documentation, and worflow. So I'm somewhat concerned that I'm 
> having, what appears to be, a large amount of work dropped on my plate 
> mid-cycle if Builder is to not degrade in usefulness for GNOME developers.
> 
> How can we ensure that this change happens without breaking Builder 
> users using the jhbuild runtime?

I'm sorry that out of the many things I have to juggle, I had never
considered Builder compatibility to be a blocker for the GNOME release
team to start maintaining GNOME builds in a new format, this does
strike me as an unreasonable requirement.

Frankly looking back, as someone who pushed a lot for the creation of
GtkBuilder - I could not afford to consider Glade support for the new
format as a blocker to a GTK+ release with GtkBuilder, this is not
_exactly_ apples for apples, but it's fairly close I think - it's not
always realistic to expect that all tooling evolves in lock step.

After some thought, here is my suggestion:

 o Discontinue usage of JHBuild modulesets in GNOME releases
   around January as planned, switch the upstream modulesets to
   BuildStream.

   Let's not jeopardize the momentum we have, lets keep the full time
   resources we actually have allocated to the project, working on
   improving things.

 o Keep the JHBuild modulesets on "life support" purely for the sake of
   Builder needs until such a time that Builder grows the features
   it needs to interact with BuildStream.

   By this I mean, that any changes effected to jhbuild modulesets
   are in fact backports of patches to the upstream BuildStream based
   GNOME project - and are done specifically for the sake of GNOME
   Builder users as a stop gap until Builder can grow the feature.

Looking at the jhbuild commit history, this looks like a relatively low
effort affair, especially if it only really needs to be done on an on
demand basis for the vector of Builder users who actually use the
JHBuild integration features. I suspect that as far as Builder using
Apps go, if they are not already using Flatpak, they are going to start
soon.

Also, if you worry about the quality of an interim life support branch
or repo to "carry you over", I would raise that with how ad-hoc JHBuild
is *currently* maintained, I cannot imagine it being worse (gvfs has
been broken for me for an entire week without anyone else even
noticing, recipes was broken with the updated meson, simply because
users are not guaranteed to actually be using the versions of
dependencies which are declared in the modulesets; it's just a mess).

[...]
> 
> Change of this magnitude is a lot of work and we all value the amount of 
> effort you're putting into this.

Thank you for the kind words.

I will in turn make an effort to give you more of a heads up on what is
coming up, because these things are coming soon, and might very well
effect Builder:

  o Starting now, I am working on deprecating the org.gnome.Sdk JSON
entirely, my hope would be to have it working almost immediately
when we do the switch in January, so that we could also release
the 3.28 GNOME SDK from the same upstream modulesets, and at least
put this problem behind us right away.

It is realistically possible that we miss that mark for some
reason though, and that the migration of the GNOME Flatpak SDK
get postponed.

  o The org.freedesktop.Sdk runtime and org.freedesktop.BaseSdk
runtimes are in the process o

GNOME Modulesets migrating to BuildStream

[Tristan Van Berkom]

Hi All !

Following my earlier proposals (long[0], shorter[1]), our
discussions with the release team in the unconference days of GUADEC,
and some followup internal release team discussion[2], I'm proud to
announce (with my spiffy new release team hat on) our intent to stop
maintaining the GNOME releases using JHBuild and start using
BuildStream[3] for builds and releasing GNOME.

Yes, this is going to be a disruptive change for many who are used to
doing everything with JHBuild, but it will be for the best; refer to my
opening mail in the above reffered thread[2] for a list of the
immediate benefits.

For the short term, we will continue to support and maintain the
JHBuild modulesets, using the automated conversion system (which I
previously outlined in my blog[4]), so you can continue to use JHBuild
to build from upstrem maintained GNOME modulesets for a short time, but
a cut off day is going to have to happen in order to unblock my work on
further improvements (like conditionally using the same modulesets to
generate the GNOME Flatpak SDKs, and creating bootable images which
developers can use to test more integrated components like gnome
session, gnome shell, GDM and gnome keyring).

This cut off wont happen in 2017, but will happen before the release of
GNOME 3.28 stable. From now on, we will be creating the development
releases using BuildStream.

You are all encouraged to try BuildStream, following the wiki page we
setup[5] which will replace the official getting started wiki page[6],
help us find and address any problems you might encounter before the
transition is complete.

In closing, we've been making a lot of promises for a year now, and I
think we've delivered on a lot of them so far, I'm happy with the
progress and it wont stop here !

Best Regards,
-Tristan


[0]: https://mail.gnome.org/archives/desktop-devel-list/2017-April/msg00071.html
[1]: https://mail.gnome.org/archives/desktop-devel-list/2017-July/msg00027.html
[2]: https://mail.gnome.org/archives/release-team/2017-October/msg00018.html
[3]: https://wiki.gnome.org/Projects/BuildStream
[4]: 
https://blogs.gnome.org/tvb/2017/06/01/continuous-bst-conversions-of-gnome-modulesets/
[5]: https://wiki.gnome.org/Newcomers/BuildSystemComponentBst
[6]: https://wiki.gnome.org/Newcomers/BuildSystemComponent

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

Re: Build and run gnome-shell in a Docker container

[Tristan Van Berkom]

Hi !

On Sun, 2017-09-24 at 16:55 +0200, Reto Kaiser wrote:
> > On Sun, Sep 24, 2017 at 3:34 PM, Sébastien Wilmet  wrote:
> > It will normally be possible to use BuildStream in the near future (or
> > does it already work?) for running gnome-shell built from git.
> > 
> > https://wiki.gnome.org/Projects/BuildStream/
> > 
> > BuildStream is the future!
> 
> Wow, very nice! Having a pre-built environment available will make
> everything much easier.
> Maybe BuildStream could also be used to create a container filesystem
> to be imported and run with docker or systemd-nspawn.
> Thanks for sharing the link, I will try it out!

So things are in a bit of a state of flux at the moment, while there is
reasonable documentation about BuildStream itself, there will need to
be a go to wiki page for a quick getting started experience for using
it to build GNOME, but we have to iron out a few kinks first.

Currently, it is possible to build a "project" which was converted from
the current jhbuild modulesets (these are converted continuously on a
cron job, but it's a bit fragile, sometimes I have to slap the server
and make sure it keeps converting :)).

That is currently available here:
   https://gnome7.codethink.co.uk/gnome-modulesets.git


In terms of running built software, it is already possible to run
simple application in a `bst shell` environment, but this is merely a
bubblewrap sandbox shell and is not really suitable for testing deeply
integrated things like the GNOME session or GDM.

Ulitmately we will have an option for generating a bootable image which
you can boot in a VM or on hardware (we've tested this before, only not
yet on the said converted modulesets above, probably there will be a
couple of kinks in the integration to make a booting system).


Regarding generation of container filesystems, you could probably put
it together now using `bst checkout` and adding any extra frills that
might be needed... but if there is something more convenient we can do
for specific technologies like Docker (such as automatically generating
any metadata that the target tech might enjoy), we will be interested
in creating plugins to help automate these things.

Cheers,
-Tristan

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

Re: Projects page on wiki

[Tristan Van Berkom]

> On Sep 22, 2017, at 9:02 AM, Sriram Ramkrishna  wrote:
> 
> 
> 
>> On Thu, Sep 21, 2017 at 5:19 PM Diane Trout  wrote:
>>> On Thu, 2017-09-21 at 22:41 +, Sriram Ramkrishna wrote:
>>> So we have this great projects page but it seems we need to clean up as a 
>>> lot of them seem inactive.  I will likely go through them and post the list 
>>> that i believe are unmaintained and then get approval.  If you want to 
>>> help, please do. :-)  I don't want people to waste their time looking at 
>>> projects that no longer exist.
>> 
>> Could the inactive ones be put off some corner as inactive instead of 
>> removed?
>> 
>> I have hopes of fixing some of empathy's bugs, and if vast amounts of time 
>> ever landed my lap, activity journal was a worthwhile idea.
>> 
>> Maybe there's others who might also want to recover dead projects?
> 
> I can put them into projects that need a maintainer?

I was thinking something similar for different reasons. I remember a time when 
we did a lot of roadmapping on the wiki and probably there is some interesting 
information somebody might want to see looking back.

Would be a shame to just lose it.

If resources are not an issue (and similar manual work needs to be done anyway) 
i think any alternative to deletion is nicer - i think we have an "attic" 
approach for bugzilla and git - without making any statement that these 
projects are desirable to revive one day.

Cheers,
-Tristan


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

BuildStream proposal - take two (shorter version)

[Tristan Van Berkom]

Hi all,

So GUADEC is upon us, and, as last time I sent this proposal out it
was overly detailed[0], I'll send out a less wordy proposal which I
hope everyone can easily digest.

We do have plans and ideas which go beyond the basic scope of the
proposal but let's take baby steps and talk about these separately.


The Short Proposal
~~
BuildStream is a new meta build system for building arbitrary stacks of
software and deploying built software in various ways. Our focus has
been on deterministic and reproducible builds, and decoupling the build
system from deployment mechanisms, while also providing a developer
friendly user experience.

BuildStream was also designed with GNOME's software building needs in
mind.

For more general information about BuildStream, see some of my previous
blog entries and documentation linked from our project page here[1].

For this proposal, our hope is to:

  o Replacing JHBuild as the developer tool for:

- Building and publishing GNOME releases
- Hacking on GNOME modules in general

  o Also use BuildStream to build and publish the GNOME Flatpak SDK and
    Runtime, using the same build metadata used for building the rest
    of GNOME.

As a first step, over a month ago I had setup a conversion process
which continuously takes the latest modulesets and creates a
BuildStream project which can be used to build the latest GNOME (3.26)
modulesets with BuildStream. See my blog post here[2] for full details
of how that works along with some instructions in case you want to try
it for yourself.

Currently I am also working on a Flatpak SDK deployment of GNOME
modules built from the same BuildStream project, this is not yet
integrated into the automated conversion scripts mentioned above yet,
though.

We hope that we can establish some consensus on this now at GUADEC, and
that we can also discuss plans to migrate our builds of GNOME and
GNOME's Flatpak SDK to be built with BuildStream using the same build
metadata (or "BuildStream project") moving forward.


Activities at GUADEC

At GUADEC on Sunday, I will give a more in depth talk about
BuildStream. In that talk I will focus more on the reasoning and
driving requirements behind the creation of this new meta build system,
and then generally how it can benefit GNOME's specific building needs.

I will not go deep into the plumbing during this talk and probably wont
have time to make more than a small demo, but will try to keep enough
time for some Q here.

Further, on Wednesday (The last day of the "Unconference" portion) we
will have a BoF and prepare a hands on workshop where we can discuss in
more detail how this all comes together and where this is going.

Of course, catch any of us (Jürg Billeter, Sam Thursfield, Jonathan
Maw, Tristan Maat or myself) in the hallway during the conference days
and we will love to talk about this too.


I feel like this proposal is missing a few more pages of real detail
(I'm naturally verbose that way), but instead of covering too much
ground at once I'll leave it to you to ask questions and I can then
fill in the blanks later :)

Best Regards,
-Tristan

[0]: https://mail.gnome.org/archives/desktop-devel-list/2017-April/msg00071.html
[1]: https://wiki.gnome.org/Projects/BuildStream
[2]: 
https://blogs.gnome.org/tvb/2017/06/01/continuous-bst-conversions-of-gnome-modulesets/

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

Re: Proposal to deploy GitLab on gnome.org

[Tristan Van Berkom]

On Wed, 2017-05-17 at 08:50 -0400, Carlos Soriano via desktop-devel-
list wrote:
[...]
> > 
> > > - git-bz attach equals to git push origin HEAD:fix2340issue, then
> > > click create merge request.
> > 
> > Does this rewrite the commit message to include the PR or bug
> > number?
> 
> No, as written in the wiki you write "Closes: $number" and it will
> handle things automatically.
> Of course some addition could be done to do the rewrite.

This is a point of interest to me.

To clarify:

  o Accepting a merge request will automatically close the merge
    request and apply the branch with (if enabled) an additional
    superficial commit saying MR ${number} was merged.

  o If the commit messages say "Closses ${number}" in them, gitlab
    will scan this and do automatic things too, iiuc it will close
    issues automatically when the merge request is accepted.

In gitlab this automation is quite configurable, so my question is;
will individual project maintainers in GNOME have the power to
configure this how they like for their own modules ?

This is a feature I personally want disabled, closing a bug report is a
manual thing in my mind, a patch itself should not be allowed to
dictate that it closes an issue, although that patch might presume to
do so, someone should stop by and close the issue.

Cheers,
    -Tristan

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

Re: Proposal to deploy GitLab on gnome.org

[Tristan Van Berkom]

On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote:
> [Written on behalf of Alberto Ruiz, Carlos Soriano, Andrea Veri,
> Emmanuele Bassi and myself.]

Hi !

I'd first like to say that I would love it that we embrace gitlab and
run our own gitlab instance to manage GNOME's gits.

There are some great features we can leverage, the ones I'm most
interested in are:

  o Pre merge CI pipelines manageable on a per-project basis, this
    is really great

  o Merge requests (need I say more ?)

  o Pages are also a great feature, if we could have that to allow
    projects to setup their own pages deployments from their
    .gitlab-ci.yml, that would be a bonus.

    However I'm not sure if that would be too much of a radical change
    from the experience we have now with developer.gnome.org and the
    wiki.

I don't share your optimism about gitlab bug tracking, nor do I share
in the mentioned frustration with bugzilla. However if I need to trade
what I believe to be a far superior bug tracking infrastructure for a
weaker one provided by gitlab, the other benefits far outweigh the
loss.

Regarding bug tracking, these are some things I think are important,
some of which gitlab already handles fine, others not so much:

  o For a relatively "stable" software, I want to keep hundreds of
    bugs open at all times, and I want to ideally view them and sort
    them, and not have to click through this annoying "pagination"

    A bug tracker holds a _lot_ of importance to me in how I like
    to manage and document the development of a project, arguably
    as much as the source itself; even if an enhancement requests
    lays dormant in bugzilla for years, It's always great to have
    a full documentation of what you could potentially be doing
    better.

  o Dependencies, I like that with bugzilla we can make one bug
    depend on another, with this we achieve interesting things,
    like graphing out the dependencies which lead to a symbolic
    milestone.

    Yes, I can track milestones on a wiki page or with another
    moving part, but then I tend to lose posterity; documenting
    as much as possible in your bug tracker helps you to track
    the whole project history in one place.

  o Real attachments, and a good view of them if possible with
    syntax highlighting is great.

    I dont like to accept bug reports which contain links out to
    external resources if and when at all possible, this makes it
    difficult to have good posterity. 

    If I want to go back in time and remember why this bug was
    reproducing last year, I need to have a real attachment (for
    example a glade file) and be sure that I'm not stuck with a
    link to a resource which may have changed since last year (i.e.
    a link to someone's git branch) or disappeared altogether.

  o Good email notifications, and hopefully some granularity on
    what events I want to listen and be notified for.

Again, gitlab does *some* of this stuff well, but I feel that it's just
good enough for the typically small jquery plugin like projects that
you tend to find hosted on github.

I could not imagine what it might be like to track all the bugs of the
linux kernel, GTK+ bug history, or mozilla, any serious project with
gitlab, the throughput seems to be much too high, while the main
benefits I can see are:

  o Automatic integration with the rest of gitlab for free (nice
    to have merge requests notify the issues automatically without
    having to reference in bug comments, etc). Of course this also
    means you have one account for both your git and your bug tracking.

  o A bootstrapy JS user interface instead of a more old fashioned UI
    (I dont think this is a reasonable argument to trade away a
    powerful bug tracker for this alone, though).

All of that said, I am already using gitlab's bug tracking (somewhat
begrudgingly) and with the small bug history I've accumulated so far it
does not seem to be a problem, and as I said above:

  If I have to trade in bugzilla in order to win the rest of the
  features we get with gitlab, then so be it, sold !


I'm sure you have all thought about much of this already, and thanks a
lot for your hard work !

Best,
    -Tristan


> Dear community,
> 
> Over the years, many of us have become increasingly frustrated about
> the state of our development infrastructure, Bugzilla in particular.
> Pretty much everyone we’ve spoken to doesn’t like it, and it’s not
> hard to see why: it is littered with usability issues, code review is
> a pain, and it is light-years behind more modern development
> platforms.
> 
> In the past, there haven’t been many other options, but we’re now in
> the fortunate position of having viable alternatives and the sysadmin
> resources to set one of them up and maintain it.
> 
> In recent months we have got together to examine the possibilities
> for GNOME’s development infrastructure. We’ve spent a lot of time on
> this, because we want the community to have 

Re: GNOME Build situation and BuildStream

[Tristan Van Berkom]

On Thu, 2017-04-27 at 14:41 +0200, Sébastien Wilmet wrote:
> Hi Tristan,
> 

[...]
> With jhbuild, when we enter into a jhbuild shell we are still in the
> same directory, usually inside the git repository. With builddir ==
> srcdir we have all the files that we can directly open with our
> preferred text editor. When we open a new terminal tab, we are in the
> same directory where we are able to 1) do git commands 2) building
> (with
> recursive make) 3) launching executables 4) editing files, etc.
> 
> With BuildStream, will it be similar?

Hi Sébastien,

Good question :)

There are some things which will inevitably be different. I think the
most disruptive thing is that you will not have the experience of
having a single, persistent filesystem tree where the things you've
built "are".

This is because BuildStream does not have a serial build model but
rather will parallelize builds where possible; every build result is
stored in a separate "artifact", and sandboxed environments are created
on demand.

So, first of all to talk about VMs, launching a full VM is the
preferred way to:

  o Test how some software interacts in a full GNOME environment,
usually the bleeding edge of development.

  o Work on modules like GNOME Shell, GDM, GNOME Session etc which
is very difficult to isolate and work on in your host environment.


That said, today BuildStream has a `bst shell` option to stage a given
module's dependencies in a sandbox and run shell on demand.

There are two semantics for this, first of all let's assume that you
have a checkout of the GNOME build metadata (or "modulesets"), your
current working directory is at the root of that checkout, and the
module you want to hack on is called "foo".


  bst shell --scope build foo.bst
  ~~~
  Stage all of the build time dependencies for the module `foo.bst`,
  and also stage the sources for building `foo.bst`, and drop you
  into a shell in the build directory.

  Useful for debugging failed builds (however, when a build fails
  you will be presented an option to shell into the actual failed
  build sandbox anyway).


  bst shell --scope run foo.bst
  ~
  Stage all of the runtime dependencies for the module `foo.bst`,
  including the built `foo.bst` module itself, and drop you
  into a shell in that sandboxed environment.

  Useful for debugging applications to a certain degree, can
  run gdb and strace and similar things in here.

  This shell differs from the actual build sandbox because it allows
  some pass through of the host environment variables. This makes
  it possible to launch graphical applications like say, gedit.

  This will _only_ work well on systems which have a somewhat
  conforming environment, i.e. your host should be running dbus
  and you should have DBUS_SESSION_BUS_ADDRESS set in your environment,
  similarly you want to have DISPLAY in your environment.

  So essentially, launching graphical applications inside
  `bst shell --scope run foo.bst` should work only for the cases that
  it would have worked when using jhbuild, so no loss there really.


Now that part is already working, and dont worry about speed; even if
hundreds of "artifacts" need to be staged into a directory, this is
lightning fast and uses hardlinks to get it done.


But what you will be more interested in is your edit/compile/debug
cycles, for that we have a hard blocker before BuildStream can be
really efficient for the type of workflow you want; we're calling this
"Workspaces"[0].

With workspaces, you will be able to use a directory of your choosing
to build a specific module from (and you can have more than one "active
workspace" at a time, so you might open a workspace to hack on glib,
and another one to hack on GTK+, and have your local trees for both be
effective for any builds).

This is not done yet but here's an approximate mock shell of what I
think the UX would look like:

  # First get a local copy of the modulesets
  host$ git clone 
  host$ cd gnome-modulesets

  # Now lets create some workspaces
  host$ bst init-workspace glib.bst ~/glib
  host$ bst init-workspace gtk+.bst ~/gtk+

  # Open your favorite text editor, and edit
  # files directly in ~/glib and/or ~/gtk+
  #
  # Now build something, maybe we want to just test with gtk3-demo
  host$ bst build gtk+.bst

  # Lets test it
  host$ bst shell --scope run gtk+.bst

  # We're in the sandbox now
  sandbox$ gtk3-demo

  # Hmmm, why did it crash ?
  sandbox$ gdb gtk3-demo
  
  # Ah, I see what I did there...
  sandbox$ exit

  # Edit some files in ~/glib and/or ~/gtk+ and try again
  #
  host$ bst build gtk+.bst
  host$ bst shell --scope run gtk+.bst
  sandbox$ gtk3-demo
  sandbox$ exit

  # Ok that worked !
  host$ cd ~/gtk+
  host$ git commit -a -m "Its a patch !"

  # Do appropriate thing, maybe you push, maybe you
  # do `git format-patch` and post some patch
  #
  # At this point you may want to continuously leave
  # the 

Re: GNOME Build situation and BuildStream

[Tristan Van Berkom]

Hi Matthias,

I realize now that this was too much information at once (even for the
involved reader as opposed to a fly-by reader).

So I'd like to thank you for your mind share.

On Wed, 2017-04-26 at 16:39 -0400, Matthias Clasen wrote:
> Tristan,
> 
> again, it is impossible to reply to an email of this length. I can
> only give a few general comments, beyond that, we really need to sit
> down face-to-face and discuss this. I hope you are going to be at
> Guadec ?

I will certainly be around all week at GUADEC to meet with you and
anyone who wants to discuss :)

I am preparing a talk on this subject, but perhaps I should also try to
organize something more hands on, maybe a BoF or such would be good.

> My general comments:
> 
> What you are describing here (and in your previous communications)
> looks like a big, all-encompassing system, with lots of its own
> terminology and a complete worldview of how things should be built. I
> prefer a system that starts small and solves one problem initially,
> and then maybe grows over time.

I can see how it can come across this way, we are trying to break the
trend of having a build system as something that is tied to any
particular deployment/use case.

As such, I needed to give consideration to a lot of use cases to be
sure that this is something that fits, and is also an improvement over
what exists. These considerations will be reflected in my
communications and I can see how one might think this appears to be
some kind of huge monolith which does everything.

However this is exactly the opposite of what I'm trying to achieve,
instead we are striving to "do one thing well" and are making an effort
to ensure we're doing it the right way, for any use case.

So, the core codebase itself should remain small over time, with really
the sole purpose of being:

   "A format and engine for modeling and executing pipelines of 
    elements which perform mutations on filesystem data within an
    isolated sandboxed environment"

In time, I expect that an ecosystem of plugins and projects will grow
around this, and use cases I had not even foreseen will come to light.
This has already started to happen in some ways, as Jochen Breuer's
commented on my blog here:

   https://blogs.gnome.org/tvb/2017/02/06/introducing-buildstream-2/

And as a result has started to work on a plugin which would allow
importing distro packages and building on top of those bases:

   https://gitlab.com/BuildStream/buildstream/issues/10

> The system you describe seems to be all about centralization, and
> about introducing a new language to describe what we build. That is
> by-and-large what we already have in various incarnations that you
> describe: jhbuild modulesets, the continuous manifest, flatpak
> runtimes. I can get behind the idea of unifying these into a single
> way of describing a multi-module build.
> 
> But I've also seen things mentioned like 'conversion scripts for
> flatpak'. And I think that is exactly the opposite of what we need
> for application building.

I may be mistaken, but I have a feeling you are getting the same
impression which Christian had last month, which I tried to explain in
this email:

   https://mail.gnome.org/archives/desktop-devel-list/2017-March/msg3.html

> If we want to convince 3rd party applications to use flatpak, we
> can't treat it as an intermediate format that we generate from some
> other source, and just use somewhere in a centralized build process.
> We need to embrace it ourselves and use it, just like we expect 3rd
> party applications to use it.

So at the risk of being repetitive, I am completely behind application
authors maintaining their own build metadata themselves, building
flatpaks themselves and/or submitting build metadata to a "flathub" to
have them built and published to users.

Of course this makes sense, because the application authors themselves
are usually best situated to know what should be in their bundling
build metadata.

So let me try to break down how I would see this work (I realize,
already a long email):


  GNOME core modules and services (excluding Flatpak apps)
  
  These can be expressed in a single format/repository for all the
  interesting purposes:

    o Performing CI
    o Creating bootable GNOME images on top of some base system,
      mostly for developers
    o Release modulesets
    o Producing the GNOME Flatpak runtime and SDK

  This is of course, one centralization.


  Flatpak Applications
  
  Considering the benefits which the GNOME core modules and services
  get by representing build metadata for multiple purposes, a given
  application developer team may also benefit in similar ways.

  This is without centralizing everything into one big build blob, or
  using intermediate formats or anything like this.

  Now, this may be more of a personal goal, a bit more ambitious,
  maybe best punted to later on, but 

Re: GNOME Build situation and BuildStream

[Tristan Van Berkom]

Hi Sasa,

On Tue, 2017-04-25 at 17:45 +, Sasa Ostrouska wrote:
> Woow, long one really. Ok, I think the idea is really good. Of course
> a lot of work. I as a maintainer of a gnome desktop version for
> Slackware would like to ask how this would handle the distros which
> do not use systemd ?

I did not expect this question, but I'm glad you asked it :)

Firstly, I can say that a new build tool is not going to magically make
GNOME work better on all distros, however it *can* help us to
understand the problem better and raise awareness, both for GNOME
developers and for distro developers/integrators.

Here's how I think we can greatly improve the integrator's experience:

> >   For CI
> >   ~~
[...]
> >   Further than this, I should mention there is some movement to implement
> >   Source plugins to represent distro packaging sources, e.g. the dpkg
> >   source plugin[4]. With this plugin in place, I suspect it will be
> >   very easy to run tests of building and running GNOME against various
> >   third party distributions and versions of those. Imagine we could have
> >   a board somewhere which displays which distributions GNOME builds on
> >   without failing tests (we could always know when GNOME master is failing
> >   against debian sid, or latest fedora, etc).

So, my vision of how we can improve communication and collaboration
between GNOME and it's consuming distros works something like this:

  o We would have a dedicated CI system which would build and hopefully
    run GNOME on a series of "subscribed" distros.

  o An interested party (distro representative/contibutor) would have
    to ensure that BuildStream have a 'Source' plugin which handles
    importing of distro packages in the package format which that
    distro uses.

    The requirements to meet for implementing a Source plugin are
    outlined in the comments of the 'dpkg source' issue[4].

  o The interested party then subscribes to the CI, by providing
    a simple patch to some YAML which says:

      - This is variant 'slackware'
      - This is how you obtain the 'slackware' base to build on
        (using the appropriate Source plugin to do the work).

    and then adding 'slackware' to a list of variants that the
    CI server should try building.

  o For every distro that passes some CI, a bootable image could
    be downloadable too, so one could easily try out the latest GNOME
    on a variety of bleeding edge versions of distros and compare the
    experience (this could be fun pretty quickly :))

I think it would be great if this CI was centralized and hosted by
GNOME in some way, even though I'm sure that most distros have their
own forms of CI, this would provide a venue for GNOME developers to
collaborate with distros directly and have a better understanding of
what kind of changes break distros in what ways.

Now of course in such a utopian future, it would be important to
understand that GNOME running CI against a variety of distros, does not
equate to GNOME making a promise to never break distros.

If a CI fails in this context then it could be for any of the following
reasons:

  o It is a legitimate integration bug in the distro
  o It is a legitimate bug somewhere in GNOME
  o The distro did not provide what GNOME requires
  o GNOME failed to communicate it's requirements clearly enough

So in closing, no this would not magically make GNOME easier to work
with when integrating on non-systemd distributions, at least not at
first.

However, it could help everyone understand the details and problems
surrounding integrating GNOME on any distro better, which would
contribute to a better experience for distro integrators in general
over time.

That is aside from the most obvious advantage, that building the
bleeding edge of GNOME against the bleeding edge of 'foo distro'
continuously will of course help everyone to catch integration bugs
earlier in the cycle.

Cheers,
    -Tristan

[4]: https://gitlab.com/BuildStream/buildstream/issues/10

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

Re: GNOME Build situation and BuildStream

[Tristan Van Berkom]

Hi Christian,

On Tue, 2017-04-25 at 10:07 -0700, Christian Hergert wrote:
> On 04/25/2017 09:38 AM, Tristan Van Berkom wrote:
> > 
> > Any questions about what we have created so far and how it works ?
> > Please
> > reply and ask about these !
> 
> I don't think this was mentioned, apologies if I missed it.

No worries, apparently it was a very long email :)

> One thing we want in Builder is a simulator. Being able to take a
> BuildStream bootable image and overlay the project is a very
> desirable
> feature. It could be a patched gnome-shell, glib, or an application.
> It
> would be great If your "workspace" feature can allow us to do this on
> the developer host rather quickly (so we don't wait minutes to launch
> the simulator).

Reducing the image creation routine from minutes to seconds is a bit
difficult, for that purpose you might try reusing an already made image
across multiple sessions.

The way this would normally work (without customization):

  o The user downloads or builds artifacts for all modules which go
    into the image (where 'artifact' is the output of a traditional
    `make DESTDIR=${artifact-root} install`).

    A build is only performed in the case that an artifact does not
    already exist.

  o The user can now build a "workspace" module on pre-built
    dependencies

  o The user can now create an image using their "workspace" artifact

  o The image is then created using all the required artifacts, this
    is an I/O bound task which takes time, proportional to the size of
    the image

The user story for the above should just only be a matter of:

  o Creating a workspace (something like `bst workspace `)
  o Edit sources in the workspace
  o Running `bst build gnome-system-image.bst` would now take the
    active workspace into account

But this would take minutes...

So instead, for a really nifty Builder simulator feature, you might
prefer to work with the content of the image and have it cooperate with
Builder's simulator use case; which may mean either Builder has a fork
of upstream release modulesets (with only few changes), or that the
upstream modulesets have some kind of support for this built in.

There are probably a few ways to get this to be lightning fast once you
have some cooperation from the already created image, here is one idea:

  o You have the image created with a kernel with virtualization
    features, specifically you will want the 9p 'virtfs' filesys.

  o You have the initramfs `init` script check for the presence
    of the 9p device and mount it if it's there (this is where you
    will have the build output "prefix" of only the modules you want
    overridden, which are already staged on the host filesys).

  o You ensure that the system ld.so.conf is configured in such
    a way that the mounted virtfs 'libdir' location takes precedence,
    and probably run ldconfig (not sure that's needed).

    This would ensure that a rebuilt 'glib' is the effective glib
    for the whole system's boot sequence

  o Something similar needs to be done for core system applications
    like gnome-control-center or the like, to ensure the execs in the
    thing you've mounted take precedence over the copies in the image.

    Probably you dont want to care about gdm, gnome-keyring and system
    services, from a Builder perspective.

Something along those lines would allow you to reuse the same image
across multiple Builder user sessions and always be able to rebuild
something against existing pre-built dependencies, and boot an image
immediately after the build completes.

> For the application case, we certainly just want to inject the
> Flatpak'd
> build of the app from Builder rather than a traditional build.
> 
> As you can imagine, it would be hell if we had users downloading full
> bootable images regularly. Do you anticipate a way to publicly expose
> the OStree even for bootable images? Would it be reasonable for
> Builder
> to use that to keep things in sync?

From the BuildStream maintenance perspective I much prefer to keep the
artifact caching implementation details a "black box" (I want to keep
the door open for later supporting other OSes than only Linux).

However it should be easy enough to have BuildStream download it for
you and check it out to a local directory, which would have the same
benefits.

Makes sense ?

Cheers,
    -Tristan


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

GNOME Build situation and BuildStream

[Tristan Van Berkom]

TL;DR: We are working to improve build tooling for GNOME software development, 
and
   are very interested in GNOME developer community feedback on the 
BuildStream
   approach we are taking, and how to achieve a successful transition.


Hi all,

By now many participants of this list are already aware of our efforts on
the BuildStream tooling from reading my blog posts ([0] and [1]), which we 
aspire
to use in GNOME to improve GNOME's developer experience as well as improving the
process around maintaining GNOME releases.

At this time I would like to start a more open conversation about our plans,
ensure that we are all aligned on what the best approach should be for building
GNOME and also look at how we can implement a better build story for GNOME,
hopefully over the following months.

There is a lot to say here as it's a big topic, so to structure this a bit,
I'll talk about:

  o What are the existing use cases of building GNOME ?
o What are the pain points related to these use cases ?
  o How do we plan to address these pain points using BuildStream ?
  o How would we implement BuildStream in GNOME with a smooth transition ?


What are the existing use cases of building GNOME ?
~~~

  o A developer uses JHBuild to build and hack on parts of
GNOME on their local laptop or desktop machine, which
can be any linux distro.

Pain Points:

* Non deterministic set of dependencies cause builds to fail in
  random unpredictable ways, which can be off putting for newcomers
  and also an annoyance to seasoned developers who want to fix some
  specific bug, but get caught up fixing other bugs instead.

* It's difficult to debug core components such as the interactions
  of gnome-keyring, Linux-PAM, GDM, GNOME Session, GNOME Shell.

  Manual tinkering is needed, you either need a separate machine or
  a VM you've setup manually to recreate login scenarios and
  gnome-initial-setup scenarios, ensuring a seamless handoff to the
  initial user with their online accounts setup and all of this.

  o The release team needs to build and publish GNOME releases

Pain Points:

* Non deterministic dependencies again make things unclear as to
  what exactly we are releasing.

  E.g., we might know that this vector of GNOME module versions
  work well on some specific distro it has been tried with, but
  we can't know for sure that the result of a JHBuild of GNOME
  will behave the same on any person's distro.

  By the same logic, it becomes difficult as time passes to
  build older releases of GNOME in the future on more modern
  dependency sets.

* Current tooling does not allow for any distinction from
  a specific version of something (be it a commit sha in a git
  repository or a specific tarball), and a symbolic branch name.

  With JHBuild (or flatpak-builder for that matter), you must
  either specify a symbolic branch, or a specific commit.

  To advertise a specific release involves a lot of tedious
  editing of build metadata to communicate new versions of a stable
  or development release set manually.

  o The Flatpak maintainers currently maintain their own set
of build metadata to build the GNOME SDK and runtime.

Pain Points:

* Arguably the flatpak maintainership should not be accountable
  for maintaining the GNOME Runtime and SDK builds. I think we
  mostly agree by now that it would be great to have the GNOME
  release team have control of their own flatpak builds.

  There is however a large overlap of libraries and tooling
  which must appear in the GNOME Runtimes/SDKs and must also
  appear on an operating system running GNOME (libraries and
  services to support the display manager, the shell,
  the session, control center, etc.).

  Maintaining these sets of build metadata in separate formats
  and separate repositories is both burdensome and error prone:
  releases are not communicated atomically and nothing guarantees
  that GNOME 3.24 moduleset versions and GNOME 3.24 flatpak runtime
  versions coincide at all times.

  o Application module maintainers need to either build Flatpaks
of their module or at least provide some flatpak-builder json
for a third party to build it on your behalf.

Pain Points:

* Here there is not much in terms of pain points for the author
  of a Flatpak application. As long as the only bundled format
  your application wants to support is Flatpak, you'll only
  need to maintain one set of build metadata.

  o The CI story of building GNOME on automated build machines.

Pain Points:

* Here again the problem of maintaining multiple sets of
  build metadata in various formats comes up for the release team.

  We should ideally be using the same build metadata for building
  

Re: Improving the way we build nightly apps

[Tristan Van Berkom]

On Wed, 2017-03-01 at 18:13 +, Sriram Ramkrishna wrote:
> 
> 
> On Wed, Mar 1, 2017 at 5:16 AM Michael Catanzaro  g> wrote:
> > On Tue, 2017-02-28 at 15:50 -0800, Christian Hergert wrote:
> > > You make it sound like there is already unanimous support for
> > this 
> > > (considering I've seen no discussion on the topic, I find that
> > hard
> > > to 
> > > take at face value)?
> > 
> > 
> > release team is dealing with right now. Currently, we only maintain
> > the
> > JHBuild modulesets, and that's not great because it's not what
> > users
> > actually use.
> > 
> 
> Users aren't using Jhbuild?  What are they using?  I'm asking because
> in our newcomer documentation we are asking them to use JHBuild.  So
> I'm trying to understand why there is a dichotomy.

I think what Michael is saying (correct me if I'm wrong) is that
developers (newcomers or otherwise) are using JHBuild. Users in general
use what distro packagers put together, which was not assembled with
JHBuild. Users are also going to be using Flatpaks as it becomes
available in the next/current wave of distro.

The JHBuild modulesets, besides being handy to actually build stuff, is
also the GNOME release team's method of blessing what vector of
specific package versions that are appropriate to assemble as a whole,
and I would not be surprised that distros use this metadata at least as
a guideline to build and distribute GNOME.

Cheers,
    -Tristan

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

Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)

[Tristan Van Berkom]

On Mon, 2016-10-10 at 08:39 -0500, Michael Catanzaro wrote:
> On Mon, 2016-10-10 at 10:04 +0100, Philip Withnall wrote:
> > 
> > I don’t think we’ve ported enough modules as testbeds yet. Meson is
> > too new
> > to jump into encouraging everyone to port GNOME modules en-masse.
> > 
> > Maybe the goal could be proposed in 6 months once Meson has matured
> > a
> > bit
> > more and more modules have dogfooded it?
> 
> Yeah. I've been looking at Meson recently and it looks really nice,
> but
> right now not much is using it in JHBuild, just GStreamer and, as of
> yesterday, libhttpseverywhere. Let's port a couple more modules and
> give it some months before we decide to recommend it project-wide.
> This
> also gives Meson some more time to mature.

I'm not familiar with Meson myself but have had to go through numerous
headaches dealing with CMake ported projects which tended to build well
on the maintainers computer but not on mine, or not withstand to a
cross compile properly. CMake (and it's userbase) is/are starting to be
mature and these problems are fewer and further between.

I would caution against using only JHBuild as a metric for Meson's
maturity. Rather I would recommend starting at the lower end of the
stack, say try to port glib/GTK+ over to use Meson in a wip branch, and
then see how that withstands a cross compile to arm in a wip branch
against Yocto poky master.

If that works well I would say it's pretty much ready.

Cheers,
    -Tristan

> 
> At any rate, I have experience with working on CMake for WebKitGTK+,
> and my initial impression of meson relative to CMake is highly
> positive.
> 
> Michael
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: [ Revised Proposal ] Continuous Builds in GNOME

[Tristan Van Berkom]

On Sat, 2016-06-18 at 08:15 +0100, Emmanuele Bassi wrote:
[...]
> Tristan: I understand you don't give a crap about GNOME as a holistic
> project; you've made it *painfully* clear over the years. I'd like to
> point out that without GNOME working as a single unit nothing we do,
> or did up until now, really matters in the grand scheme of things.
> The
> *only* successful thing out of GNOME is the GNOME desktop environment
> and its whole stack of technologies; everything else has been a
> failure, mostly caused by this inane obsession of considering the
> GNOME platform as a bag of loosely coupled projects that somebody has
> to work hard into identifying and keep working together, granting the
> position of gatekeeper to a bunch of middle men. This position is
> ignorant of the history of the project, especially of its failures;
> it's insulting of the work of hundreds of people who want to keep
> this
> thing working and keep it approachable to newcomers; and completely
> invalidated by the reality of what happens every day in the
> commercial
> space. I also don't understand your opposition to keeping the only
> integration branch we have, the 'master' branch, building constantly,
> considering this is a basic engineering practice, but at this point I
> can barely muster the strength to even care. In any case, as I said
> to
> Milan, I'll gladly consider any project you maintain at the same
> level
> as an external dependency, and thus just tag it. Feel free to go
> through the Continuous manifest and Jhbuild moduleset and point out
> which modules you still maintain.


Emmanuele,

Thank you for sharing this. You make the perfect example.

You will note, that my "astronauting" is in fact a sincere attempt to
reconcile both of these views with some plausible technical approach,
so while your goals are clearly not the same as mine; I am being
sensitive to your goals, in fact I want some team within GNOME to be
successful at integrating all of these projects into some coherent user
experience - I only want that team to accept that the components they
intend to integrate have bigger plans than *just* being a part of this
integrated whole.

You on the other hand seem threatened by my views and consequently act
intolerant towards the existing diversity of goals of projects within
GNOME - I don't think this intolerance is an attitude we should have to
deal with, we should be instead looking for creative ways to reconcile
both views.

Yes, the GNOME Desktop Environment as a unified thing has never been a
personal goal for me to work towards, rather the most important to me
is to build a solid and stable platform with good development tools,
and I want it to be the platform of choice in the FOSS world - if the
GNOME Desktop Environment turns out to be the only consumer of the work
I've done over the years, this will be the biggest failure of all in my
eyes.

You may have accepted defeat but as long as I spend any energy in GNOME
at all, I simply can not.

Regards,
    -Tristan

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

Re: [ Revised Proposal ] Continuous Builds in GNOME

[Tristan Van Berkom]

First,
  I've been on vacation this week and have been able to put time into
this, with the hope that next week I will be able to focus on $dayjob
without regretting too much not being able to take part in this
important debate. I hope we are going somewhere. Also, in closing in
this mail, I will just highlight my motivations for bringing up this
proposal in the first place.

Sri,
  Please just gloss over the technical stuff and read the end, I think
you are in a position to effect change and this is written with you in
mind (from the "Why do I think..." heading).

On Fri, 2016-06-17 at 15:17 +0200, Milan Crha wrote:
> On Fri, 2016-06-17 at 17:11 +0900, Tristan Van Berkom wrote:
> > 
> > I dont believe you have any such functionality in jhbuild.
> > 
> > At best, you can specify the sha1 of the commit you want to build
> > of
> > a given module, this would not let you single out one commit,
> > omitting it from history in integration and at least attempt to
> > apply
> > subsequent commits without that one included, re-including that
> > commit in the correct place in history only when CI infrastructure
> > would find integration unbroken.
>   Hi,
> I never thought of a single commit removal from a set of commits. To
> be
> honest, that sounds even more crazy (not 'crazy' like 'insane'). :)
> We are talking about master, the development version of the software.
> If you'd like to tell me that you are at commit X and feature which I
> added at commit X-3 does not work for you, then trying to figure out
> why exactly you do not see that feature is a real nightmare and waste
> of time for both the reporter and the developer, especially when you
> want to remove only single commit from a history. Not talking that
> following commit can "build on top of the previous commit", which is
> quite usual.
> 
> > 
> > The thing is, either way; your work flow will not be interrupted at
> > all with this approach, ...
> See above.

Milan,
    I think that if your commit broke integration with the wider GNOME
ecosystem, that will matter to you and you will be quite aware of which
commit in master broke it and why until it is fixed. I think we have to
ensure that people take integration breaking commits seriously and
ultimately, an integration breaking commit would block any stable
release.

That said, in your above scenario; a disparity between master and
integration is a serious issue, but consider the alternative:

If a new comer wants to get involved in GNOME, they probably have a
specific itch to scratch, say with Evolution or EDS; they will either
be able to build everything up to EDS & Evolution easily; have an easy
experience, and be able to submit a patch to bugzilla, or, they will
fail to build and get side tracked because the bleeding edge of master
for all GNOME modules doesn't build.

In other words (and this has absolutely nothing to do with using
jhbuild or not) when you build everything from master and it breaks
before you are even able to work on the issue you wanted to work on,
this is discouraging; this means that we are offloading our technical
debts to newcomers, forcing them to deal with our bugs before being
able to even submit a patch they wanted to contribute.

Would you prefer that a potential EDS contributor be able to submit a
patch to bugzilla, even if it does not match up *exactly* against
master ? Or would you prefer that your potential contributor get
discouraged while trying to build EDS against the latest gcr,
libsecret, libgdata or such, or just get bogged down trying to fix an
EDS bug to adjust to some API churn in a dependent GNOME library ?

I think receiving a patch for what the contributor wanted to work on is
preferable, even if you happen to fall on a patch that doesn't apply
exactly against master, in the 1% of the time that EDS integration is
broken and lagging behind.

[...]
> I said earlier in the thread that the current situation works for me
> the best. There is clearly stated what the continuous builds from, at
> which exact commit it "stopped updating" certain module, because of
> some breakage, and everything references the real master branch. That
> the continuous uses jhbuild might be just a coincidence, even it
> sounds
> like the moduleset is targeted for the Continuous builds, when it can
> influence an environment for any developer using the jhbuild (I do
> not
> use it, this is how I understood how it works in the jhbuild world).

I'll just note again this is not about jhbuild particularly, jhbuild in
master tries to build everything from master, sometimes it breaks and I
think that's natural in the present state of affairs.

gnome-continuous does *not* build jhbuild modulesets, it uses it's own
json format for, also building everything from master:

https://

Re: [ Revised Proposal ] Continuous Builds in GNOME

[Tristan Van Berkom]

On Wed, 2016-06-15 at 17:49 +, Sriram Ramkrishna wrote:
[...]
> I think with a couple of iteration we can work out an agreement.  :)

Hi Sri,

I can see you read through this diagonally, so I'll try a TL;DR version
below...

> So to wit, let me summarize your points:
> 
> * Master is unstable and can be in unbuildable state until we apply a
> tag making it stable.

Basically what it is today, mostly always buildable modulo transitional
periods in times of API churn, and modulo some mistakes which may take
time to fix for maintainers in different timezones with dayjobs.

> * We have a 'integration' branch or something like that which is
> always in buildable state but lags behind master by some undetermined
> number of commits.

The integration branch as proposed does not lag behind except by
commits which break integration, in all other respects it is always
exactly master.

> I'm a little unclear what a maintainer's workflow is, and how can we
> ascertain that they push to this integration branch when there is no
> social policy in place to do so.  I mean some maintainers can
> completely ignore that if they wanted to.

Nobody ever pushes to 'integration' (at least not developers and
maintainers), and this is why I want some strict git hooks in place to
ensure that any pushes to the integration branch are immediately
rejected ('git push origin integration' shows you an error).

TL;DR version is basically:

  o Yes, this is going to take some actual work to implement, technical
work, but not an astronomical amount, maybe a few weeks.

  o The integration branch of every module is continuously
reconstructed based on that module's master branch.

This must be an automated process, which runs perhaps every 10 min
or so, updating integration branches of all modules whenever new
commits are available on master.

At first it wont be completely automated, it will require some
human intervention to assist in maintaining the blacklist of
broken commits (we have a problem to solve which is deciding
which commits to blacklist in the cases of API churn).

Ideally though, the buildbots should be able to reconstruct
integration by performing many variants and deciding on the
blacklist with least changes omitted.

  o Notifications are delivered, perhaps bugs filed, against commits
in master which dont integrate properly into 'integration'

No need for a grace period, when your commit to master breaks
integration, it is omitted from integration and you get a bug
report.

  o Default for jhbuild is 'integration' of everything, which is
    almost always buildable (in fact it could be made to be literally
    always buildable with a bit more effort, assuming some tries
    are performed by the build bots before constructing the integration
    branches).

    In terms of workflow this would mean people would always work
    against the integration branch, except that developers/maintainers
    of a given specific module would checkout a few modules as master.

    Commits only ever enter the history via regular master or stable
    branches.


Basic gist of the idea is like this.

Cheers,
-Tristan

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

[ Revised Proposal ] Continuous Builds in GNOME

[Tristan Van Berkom]

On Tue, 2016-06-07 at 22:24 +0200, Sébastien Wilmet wrote:
[...]
> > This of course, requires real thought and engineering, but I wanted
> > to
> > at least offer some technical input, some starting point that could
> > be
> > explored - this wont be solved without real engineering, trial and
> > error.
> It's similar to the "master/master-stable-next/master-stable"
> branches
> concept that I thought about in this previous sub-thread. See those
> two
> mails:
> https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg2
> .html
> https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg8
> .html
> 
> It doesn't look like rocket science to me, and it would get us closer
> to
> continuous delivery.

Honestly I hadn't put a huge amount of thought to this, but I did
figure in that once there is API churn, there will be multiple
variations/combinations that are desirable to build - one might want to
build a certain app which has not yet adapted to an API change, in
which case they need an amalgamation of branches which gets them their
app building without the API change in a lower level library/service.
On the other hand someone who wants bleeding edge of the given
library/service will want it with the API change included... but I
admit these considerations are possibly not worthwhile for our basic
goals: improve CI for development cycles and help have a more friendly
starting point for onboarding newcomers.

I also woke up this morning to an interesting conversation on #gnome-
hackers, which I missed due to timezone skew, but made me think of
something cheaper also more inline with what you suggest with master-
stable, master-stable-next etc.

So here it goes, after reading the interesting conversation I think
that we are close to something that is a step forward which will not
cost very much at all, I think that the main point we disagree on is
reverts in *master*, and the idea that *master* is something that can
be forced to be always stable.

For some of us, Milan and I at least, I think we disagree most
particularly on dirtying master, this creates work especially if we
have to pick up the pieces after some API change or such, and it
dirties the mainline development history which is a bad thing in
general, it makes bisections dirty and history tracking dirty, we've
come to have some discipline over the years to even avoid any
whitespace in commits because we value the history that much, we want
to know that every commit in mainline is relevant.

Simply put, if master is broken, it needs to be fixed the correct way,
and a maintainer has never advertised master as being stable until we
tag it as stable, we want to keep this.

So what I thought up after reading that IRC conversation, is that there
is no reason at all why all of this has to be done in master, and no
justification to want this behavior on master either - we just want to
be able to provide a closest-to-master as possible build that always
builds, and we want that to be the "easy way" that we advertise to
newcomers - more mature developers when they grow up might want to
build master anyway and see the actual breakages in real time.

Sorry I dont have time to spend hours reducing this huge text and being
all concise, but I want to contribute to this, so here goes:

Cheap proposal for a build-bot/release-team/build-sherif owned
integration branch
~~
So what I would propose here is a setup with some automation, similar
to the proposed master-stable but I would call it 'integration' and
with a few changes.

Starting with our current workflow, all our projects/modules use the
master branch as mainline development, feature branches are merged into
master and eventually come release time, master is tagged and branched
as stable and we release tarballs for each release tag.

 [ feature ]   |
 \ |
  \
  [ master ]
   |
   |
   [ release tag ]
\
   |  \
 [ feature ]   |\
           \   |  \
            \  |\
             \ |  [ release branch ]
  \|   |
   |   |
   [ bugfix ] ---> |
   |   |
   |  [ bugfix release ]

I dont think the above should change at all; patch flow for production
continues to flow in this traditional way that we have come to work
with very well. Master remains mainline.

What I would suggest, in addition to our setup, is that there is
a new 'integration' branch for every module in the moduleset, this
integration branch is automatically managed.

Workflow for contributors can look more like this:
[ integration ]   [ master ] [ bugzilla patches ]
   |   |/
   |   |  /  patches possibly
   |   |/made against
   |   |  /  

Re: Continuous Builds in GNOME

[Tristan Van Berkom]

On Fri, 2016-06-03 at 01:53 +, Sriram Ramkrishna wrote:
> I found this discussion really fascinating and so I wanted to
> continue it, separately from Emmanuele's thread so that issue is
> resolved without bifurcating the discussion.
> 
> My thoughts are that we really shouldn't be looking at something and
> say 'well, we can't do it we don't have the resources' especially
> when there is a clear return on investment.  I think this would be an
> interesting challenge and we should find a way to figure out how we
> can attract the talent, machines and money to do this.  After all, we
> have a foundation dedicated to supporting the development of GNOME.

Hi Sri,

I am not happy with how the previous discussion evolved. I think I
raised some technically valid points and historical insight, e.g. [0]
and [1] and I get the impression that those who are pushing this agenda
are not willing to digest the facts and converse constructively, but
lets re-examine this.

I am certainly not against continuous integration, but I think we need
to recognize first that we are in an extremely different position from
companies, organizations and projects which perform CI successfully -
this is not a solved problem that we can simply apply to GNOME as a
wider umbrella of various interconnected projects.

CI works very well where development is done in silo, all developers
are instantly reachable or replaceable, and all components are designed
to work in harmony for a very singular purpose. None of these
ingredients are present in the wider GNOME project.

So how can we improve things ? What technical approach can we take to
better leverage CI for the purpose of furthering the collective goals
of projects in GNOME ? Before we can even answer that question, we have
to ask also, what are the goals we want to achieve with CI, what do we
want to improve ?

I think this falls under 2 distinct categories:

  A.) Finding actual bugs and integration breakages early enough in the
      cycle to have a stable build come release time.

  B.) Making it easier for new comers to build and contribute to
      projects in GNOME.

I think first, we need to dispel the belief that the bleeding edge of
every module is going to build at all times - especially to new comers
who have the idea that they can build all of GNOME and it just doesn't
pan out, they get a bad experience because we advertise jhbuild of
master as something that should just work. We need to be more honest
here.

What we have currently with gnome-continous is already helpful for (A),
but can be improved. For (B) we don't have a solution right now, but
there may be some technical approaches to help solve (B).

One approach might be a setup where we have an RC branch opened for
integration of changes from master at the beginning of each cycle -
this could be a sort of "soft master" that builds but might not be
bleeding edge in every way, it could benefit new comers as they could
still submit patches against the RC branch and it should at least
successfully build all projects from scratch. Also it could benefit the
release team inasmuch as we could have constant awareness of exactly
how much of the bleeding edge currently integrates at a given time.

I strongly disagree with holding project maintainers responsible for
creating feature branches and burdening them with the duty of updating
other modules not under their control, especially for reasons already
outlined in [0], however perhaps a uniform 'integration' CI branch
could be automated to a certain extent, as gnome-continuous currently
blacklists not-building modules, it could instead be made to guess what
changes break a build and recreate the integration branch without the
said failing patch, performing tries with merges from master until
something builds and integration can again include the new changes.

This of course, requires real thought and engineering, but I wanted to
at least offer some technical input, some starting point that could be
explored - this wont be solved without real engineering, trial and
error.


One line of thinking I think we really need to distance ourselves from,
is the idea that the "social problem" of projects in GNOME is one that
needs itself to be fixed. Yes it is a problem, but rather a riddle or
puzzle to be solved. Lets embrace the community as it is and find a
technical solution that works *for* the community, not try to teach the
community that their goals should be more in line with what some
particular participants think.

I say this, because I sense there is some impatience coming from
participants who seem to hold the belief that a uniform and beautiful
desktop experience is the singular goal of all projects participating
in GNOME, while on the other hand, projects who have been solving real
problems and are targeting a much wider audience than just this suffer.
The result is that we begin to alienate smart and diligent developers
who have been long standing dedicated contributors, 

Re: Installed tests - parallel installability

[Tristan Van Berkom]

On Sun, 2016-03-13 at 15:33 +0100, Sébastien Wilmet wrote:
> Hi,
> 
> Currently the installed tests [1] of libraries are not parallel
> installable.
> 

Hi Sébastien,

  A.) The change that you propose for GTK+-3's install path for
      installed tests is harmless as far as I can see, no
      reason to object.

  B.) Claiming that they are not parallel installable is a bit
      dramatic.

      When GTK+-4 is released, it should install it's tests in a
      separate path in order to be parallel installable with GTK+3,
      there is no reason why the current install path is a real
      problem looking forward.
      (they could continue to be installed in ...installed-tests/gtk+
      while GTK+-4 tests be installed in another directory).

Cheers,
    -Tristan

> For example the GTK+ tests are installed in:
> .../installed-tests/gtk+/
> 
> When GTK+ 4 will be released, it would be nice to still run the GTK+
> 3
> tests. Especially because GTK+ 3 will be advertised as more stable.
> But
> I guess this is true for any library (except when security holes are
> not
> fixed in old versions).
> 
> So for GTK+ 3, the tests should probably be installed in:
> .../installed-tests/gtk+-3.0/
> 
> No?
> 
> Sébastien
> 
> [1] https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: Build sheriffs for GNOME

[Tristan Van Berkom]

On Sun, 2016-01-24 at 05:18 +0100, Vamp898 wrote:
> Hi, 
> 

Hi Shirakawa,

I see you replied off list, I am returning this to the list because it
is a good question to answer and it's rather wasteful to compose a full
reply to this and not have the benefit of it being recorded in the
archives for posterity. Also if we shake the tree on the list, maybe
something interesting will fall out :)

> I hope this mail doesn't sound too stupid (I'm not that into the
> GNOME build system). 
> 
> Jhbuild checks out the git repository and builds them. 
> 
> I personally would say that even master should be buildable,
> otherwise it's not of much use, or is it? 

No it does not sound stupid at all, without a deeper understanding of
how the projects inside GNOME function when they are under active
development combined with some understanding of the history of how
things were done before we had jhbuild, it is perfectly understandable
that you might think that is what jhbuild is for.

In fact, it is even possible that some people within GNOME have
presented jhbuild to you as if it were a tool you could use to always
build and "obtain" the latest master of everything, and that it should
always work, that if it did not build it was in fact a problem that
some module could be blamed for. Things are a bit more complex than
just this, though.

I would in fact argue that jhbuild is exactly the opposite of this, one
of the great benefits of jhbuild is that we find incompatibilities and
breakages early on in the cycle rather than in the last few weeks
before release time.

> I rather have an old eds than none (and if master is broken due to
> changes in eds, it's like having nothing). 

There is one thing to take in context here: GNOME has never had a
policy which mandates ABI or even API stability for ALL projects which
participate in GNOME. API stability is only a hard requirement for core
platform modules who have opted in and advertised this, understandably
because these platform components are relevant also to the real world
outside of GNOME. Historically we have a competitive platform, and lets
hope that with work and discipline our platform will again be a viable
and top choice for mobile, IVI and other embedded sectors (but I am
digressing...).

The point is, for any project in GNOME which does not advertise API
stability, these projects are entirely free to change the API contract
during the course of a release cycle. Of course when this happens,
there are periods where other projects in GNOME depending on these will
be broken, and this is not incorrect or undesired. This does not happen
that frequently, but it's reasonable to expect that some applications
wont build with "everything master" for periods of weeks at a time.

We could mandate that every project which provides an API be always API
stable and extend this rule beyond core platform components, but this
would generate a lot more work for some not funded volunteer driven
projects, and it's an entirely different discussion.

> I'd say touching git (in terms of reverting commits) is the worst
> idea. 
> 
> Jhbuild should take care of that. Jhbuild should find ( with the help
> of tags in git?) what is the latest thing that still builds in
> combination and check out that. 

It's not possible for jhbuild or continuous to distinguish at this
time:
  a.) When an application is broken
  b.) When a library broke that application
  c.) When a library changed their API contract and the application
  is rightfully broken in a transitional period

Further, it would not be desirable for jhbuild to automatically do what
you suggest, because then we would not see the breakage, exposing that
breakage as early as possible is one of the primary values jhbuild has
given us.

In order to shed some light, I want to share a little bit of history of
how things were done before we had jhbuild, because I will argue that
jhbuild is not a delivery system of latest GNOME, but that does not
decrease the value of jhbuild, it has really, really been a great step
forward in our development cycles.

So, before jhbuild, most developers of GNOME projects had their own way
of building their project against bleeding edge versions of other
components. Everyone had a different OS with different third party
dependency versions installed, and everyone did everything by hand.

What that means, is usually I would have a few lines of environment
script I would use to build:

  PREFIX=/opt/devel
  PATH=${PREFIX}/bin:$PATH
  LD_LIBRARY_PATH=${PREFIX}/lib:${LD_LIBRARY_PATH}
  PKG_CONFIG_PATH=${PREFIX}/lib/pkgconfig:${PKG_CONFIG_PATH}
  ACLOCAL_FLAGS="-I ${PREFIX}/share/aclocal"

  export PATH LD_LIBRARY_PATH PKG_CONFIG_PATH ACLOCAL_FLAGS

Personally I would mostly be building Glade, so to do that, usually I
would have to get the latest version of GTK+, so usually I would have
to update atk, cairo, pango, gdk-pixbuf and gtk+, and I would have to
do so in that order specifically.

I would source my 

Re: Build sheriffs for GNOME

[Tristan Van Berkom]

On Fri, 2016-01-22 at 11:40 -0600, Michael Catanzaro wrote:
> On Fri, 2016-01-22 at 09:25 -0800, Jasper St. Pierre wrote:
> > It's more frequent than you might think.
> > 
> > In the past week, alone, we've had to tag glib, gnome-calculator,
> > e-d-s, gstreamer, and more, all because of broken builds. Take a
> > look
> > at how busy gnome-continuous is as a project:
> > https://git.gnome.org/browse/gnome-continuous/log/
> 
> Absolutely. I should be more clear: it doesn't happen so often for
> any
> PARTICULAR module, so the git history of any particular module is not
> likely to get polluted by many revert commits. (And even if it does
> --
> so what if your history doesn't look quite as nice as you'd like.)
> But
> it happens a LOT for GNOME as a whole, and it's a big problem, which
> is
> why I'm so supportive of Emmanuele's plan.

I am still a bit baffled by this, as I expect a higher standard of
quality from GNOME contributors than I would for your regular corporate
r lab.

So let me reiterate what I mentioned in my first email, I am not
against this proposal for the stable branches, and, for master: I think
Emmanuele's proposal needs clarification.

To clarify what I mean by that, is it should be clear what a sheriff
has, and has not the right to revert. If I committed a spelling error
which obviously broke the build of my own module, *doh*, of course,
it's a single commit, a stupid one, and I really couldnt care less if
it were to be reverted by someone else who caught the error. Jasper
seems to indicate that this kind of thing actually happens more than I
would expect, this is indeed sloppy and should be addressed.

I do not support the vague notion that a "sheriff" can come along and
revert an entire branch I've just landed which changes the API contract
early enough in the release cycle for depending modules to catch on and
adapt to.

As I have elaborated enough in my reply to Shaun, this kind of thing
happens, frequently enough, and there are transitional periods where
building all of GNOME and expecting everything to build is just not
rational, responsible maintainers will be careful to introduce churn as
early as possible in the cycle.

Best Regards,
    -Tristan

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

Re: Build sheriffs for GNOME

[Tristan Van Berkom]

On Fri, 2016-01-22 at 12:12 -0500, Shaun McCance wrote:
> On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote:
> > On Thu, 2016-01-21 at 14:54 +, Emmanuele Bassi wrote:
> > [...]
> > > This is not enough, and it does not raise the bar in keeping
> > > GNOME
> > > in
> > > a buildable state. It actually lowers it a fair , to the
> > > effective
> > > point that *nobody* cares about Continuous builds.
> > > 
> > > I want this to change. I want to be able to revert failing
> > > commits
> > > on
> > > the offending modules, if they are hosted on GNOME
> > > infrastructure,
> > > if
> > > they fail for more than N hours, and *then* open a bug about it.
> > 
> > Hi Emmanuele,
> > 
> > In GNOME, we have got along well for many years with many projects
> > sharing the same infrastructure mostly because we find that in
> > practice, people are generally respectful enough of eachothers work
> > to
> > recognize a module maintainer's word as scripture. As such we do
> > not
> > commit changes to others modules without expressed permission
> > unless
> > it
> > is for a minor change that we are absolutely sure about.
> 
> It has always been my understanding that master (née trunk née HEAD)
> is
> supposed to be buildable in GNOME, and that the release team has the
> power to make commits to ensure it is.

And it has always been my understanding that it is simply not the case,
notably because of said cross module API changes.

It annoys me that in recent years, notably after the introduction of
jhbuild, which has saved us a lot of trouble of setting up local
environment scripts and building everything by hand, that this
expectation has somehow arisen, this expectation is just causing
friction, it simply cannot be expected within reason.

> I am sympathetic to the difficulty of synchronizing cross-module API
> changes. But is there any reason those changes can't all be done in
> development branches in each module, with all of them merged to
> master
> at the same time when they're ready?

Yes.

Here is one example:

Michael Catanzaro writes in this very thread:
> Milan, you have full commit access to every repo on git.gnome.org.
> Any breakage that could register on Continuous is fully within your 
> ability to fix.

I find this statement very disconcerting, and it relates and is a good
example.

Milan maintains EDS, and EDS is a relatively *huge* and complex source
base, I personally know Milan to be considerate about API breakages and
stability in general and I trust that if he has to change the API
contract, it is in the interest of long term maintainability of this
very complex project which has gone though a *lot* of churn over the
last decade.

Milan does not maintain libfolks, and he does not maintain gnome-
contacts, if he is going to spend weeks refactoring EDS and Evolution,
I am not going to tell him that his word is not the law, his word on
the EDS contract *is* law, and I'm confident that he will announce it,
and that maintainers of related modules will have a heads up with
enough time to adjust for the next stable GNOME release.

I am not going to tell Milan that hey, I know you spent weeks or months
of your life refactoring and making EDS better, but I will not accept
that you land your work in your own module unless you spend another
week modifying libfolks and/or gnome-contacts.

Changes like this need to be introduced as soon as they are ready in
master, which is the unstable development branch until the next stable
release is made. It cannot be delayed until the maintainer of libfolks
returns from vacation and wraps his head around the new changes, then
we lose time and we cause friction with other patches landing in
master, accumulating conflicts and generating more work - this work is
not necessary, because nobody every guaranteed that "all of GNOME
master" would build harmoniously together at a given time.

Here is another example, Benjemin Otte one week or two ago landed some
huge refactoring in GTK+ related to drawing - as a result, Glade is
entirely unusable. It's entirely possible that I may have had an
installable unit test in Glade to raise a flag on this.

Are you, really, going to go and revert the landing of his branch
because the unit test flagged GTK+ as broken ?

Sure, for a single project which builds regularly against a stable
platform, the expectation is always that master builds. But this
analogy of a single project cannot not carry on to GNOME, which is an
assembly of distinctly separately run projects which are developed
under the same infrastructure, integration issues will obviously arise
and the best that we can hope for is introducing those issues as early
as possible in the cycle and try our best

Re: Build sheriffs for GNOME

[Tristan Van Berkom]

On Fri, 2016-01-22 at 10:37 -0600, Michael Catanzaro wrote:
[...]
> I really don't think it's a big deal to have a few reverts in the git
> history. And anyway, reverts should be relatively rare, because build
> breakage should be relatively rare.
> 
> The master branch may be unstable, but that doesn't mean build
> breakage
> is ever acceptable. If your code is not buildable at all times in
> Continuous, keep it on a *side branch* -- otherwise, tag your module
> in
> Continuous, branch it in jhbuild, and do whatever you want in master.
> But as long as you have an official GNOME module, if it's not
> branched
> and tagged, master needs to build. This isn't the wild west.

Of course, when you commit something and your *own* code does not
compile, this is a very, very rare thing, rare enough to not be worth
discussion I think, it that's happening, it's a problem.

But it's common enough with many moving parts that the breakage is
indeed intentional, in which case screwing with the history is only
intrusive.

> 
> > My interpretation of your proposal is that you would want to
> > revert
> >     this api break or behavioral change if it were found to break
> > the
> >     build (or the tests) of another module, during this unstable
> >     development period.
> > 
> > This would obviously be wrong and would just be an obstacle to
> > progress in the cases where breakage is intentional and the
> > only
> >     correct solution is to have applications adapt to the new API
> > or
> >     behavior before the next stable release.
> 
> It's a big problem that some modules break for days or weeks at a
> time
> during API transitions; this makes it very difficult for new
> contributors to build and run GNOME, and it's inconvenient for
> experienced contributors as well.

This kind of breakage is just a fact of life, you cannot sweep it under
the rug and pretend it does not exist.

Sure, it's a barrier of entry for newcomers and an annoyance for
experienced developers who realize the facts of life. But that's just
the way it is, there is no reason to complain about it.

Software development is difficult, integration is difficult when you
have many moving parts that are in a development stage before being
release ready.

[...]
> To be clear: if you've branched and tagged your module, then you do
> whatever you want in master without hurting anyone else. But
> otherwise,
> master needs to be buildable.

And to be doubly clear: the master branch is *not* what is advertised
by upstream maintainers as stable, it is the bleeding edge, it can have
churn, it may not always match up to other modules perfectly, other
modules may have not yet adapted to the churn. Building master may be
asking for trouble, again, this is just a fact of life if you are
trying to integrate with all bleeding edge component in the middle of
their development cycle, instead of what maintainers have published as
stable.

If you want something that you are sure will build, take the stable
release tag and build that.

Best,
    -Tristan

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

Re: Build sheriffs for GNOME

[Tristan Van Berkom]

On Thu, 2016-01-21 at 14:54 +, Emmanuele Bassi wrote:
[...]
> This is not enough, and it does not raise the bar in keeping GNOME in
> a buildable state. It actually lowers it a fair , to the effective
> point that *nobody* cares about Continuous builds.
> 
> I want this to change. I want to be able to revert failing commits on
> the offending modules, if they are hosted on GNOME infrastructure, if
> they fail for more than N hours, and *then* open a bug about it.

Hi Emmanuele,

In GNOME, we have got along well for many years with many projects
sharing the same infrastructure mostly because we find that in
practice, people are generally respectful enough of eachothers work to
recognize a module maintainer's word as scripture. As such we do not
commit changes to others modules without expressed permission unless it
is for a minor change that we are absolutely sure about. There is/was a
page describing this policy to those who receive commit access
explaining the responsibility that comes with being a committer, it has
either gone missing or I cannot currently find the text.

In that context, I admit that I first interpreted your proposal as
hostile, at least in it's current form, because it violates this policy
which has allowed our projects to exist in harmony for so many years
under the GNOME umbrella, by awarding some kind of revert power to an
arbitrary group of individuals. I can see much opportunity here for
unnecessary dispute, if special care is not taken, we may risk
incentivizing maintainers to host their projects elsewhere.

On the other hand, it is desirable to have things building regularly,
of course the master branch is inherently unstable - that's what it's
for, but I would however support your proposal without hesitation were
it to be applied to stable branches only.

Were we to apply your proposed policy to master, I think we need
further thought and clarification before carrying that out:

  o We are a volunteer driven project with contributors distributed
    across timezones, who have dayjobs, it is ridiculous to expect that
    maintainers can be reachable within a 3 hour turnaround period.

This leads me to believe that you fully expect to cause friction by
    reverting commits before said maintainers have the time to even
    respond, and doing so on the unstable master branch.

The master branch should ideally not be littered with reverts and
    reverts of reverts, it is the main history of project development
and adding such noise to master should be avoided as much as
    possible for the purpose of preserving the integrity and value of
    the history.

I think this is unfriendly at best and I would prescribe a one week
period for master. We should really wait for the maintainers word
before intruding and reverting commits which introduce breakages
    which may have even been intentional.


  o Not all libraries advertize API/ABI stability, especially when it
    comes to libraries whos only consumers are GNOME applications, we
    allow ourselves much more leniency here than with platform
    libraries which are also relevant outside of the GNOME ecosystem.

During the course of unstable development, it is entirely common
for a library to introduce a new API and then to later change it,
even more than once before it is ready for a stable release.
For instance, EDS's backend facing APIs are not stable, and there
have been regular issues in the vala API it exposes and libfolks
consumes.

    There are periods where it must be accepted that things are just
    broken in a transitional phase.

My interpretation of your proposal is that you would want to revert
    this api break or behavioral change if it were found to break the
    build (or the tests) of another module, during this unstable
    development period.

This would obviously be wrong and would just be an obstacle to
progress in the cases where breakage is intentional and the only
    correct solution is to have applications adapt to the new API or
    behavior before the next stable release.

In summary, I am not opposed to applying your proposal as is to the
stable builds, there is no justification *ever* for breakage in stable
branches.

For master, I only think this needs to be detailed properly, perhaps it
would be enough to ensure we had policy ensuring that intentional
breakage is announced (on this list ?) and that "sheriffs" are
responsible for following this list and not reverting commits which
break things intentionally in a transitional period.

Regards,
    -Tristan

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

Re: Killing off UNCONFIRMED in Bugzilla

[Tristan Van Berkom]

On Sat, 2015-02-14 at 22:12 +0100, Andre Klapper wrote:
 On Sat, 2015-02-14 at 21:27 +0100, Sébastien Wilmet wrote:
  A bug triager only needs to look at UNCONFIRMED bugs.
 
 I strongly disagree with that statement.
 Triage takes place across the full life cycle of a report [1].
 
  A contributor willing to fix a bug has more chances to find a real bug
  with the NEW status.
 
 A new contributor willing to fix a bug might be better off picking a
 gnome-love bug. There's a query for them on the product browse page,
 sorted by latest update so rotting bug reports are listed last.
 
 IMO, more chances to find a real bug only applies in a well-gardened
 bug repository where constant triage takes place so all tickets are in
 good and up-to-date shape.

Just wanted to point out that most projects which use gnome bugzilla
are relatively small and have bug counts in the mere hundreds, with
the exception of a few central products like GTK+.

To be frank, with bug counts numbering 3 or 4 hundred, I have only
ever had use for UNCONFIRMED and RESOLVED.

However I could see that with a product like mozilla or libreoffice,
it totally makes sense to have triaging and confirmed status and the
like.

That said, I honestly dont care if NEW becomes the new UNCONFIRMED so
long as little to no damage is caused by this.

It certainly wont magickly cause maintainers of said modules to have
more time to deal with bugs - if some people feel that UNCONFIRMED is
a rude way to express the NOT RESOLVED status, and would prefer to
call it NEW, then that, in itself doesnt bother me at all :)

Best,
-Tristan

 
  It's even more important for feature requests. If a contributor provides
  a patch for an unconfirmed feature request and then the bug is closed as
  wontfix, I think the contributor won't come back ;-)
 
 So triage incoming bug reports and set proper expectations by setting
 status RESOLVED WONTFIX for such tickets right away, instead of spending
 the approx. same amount of time for changing status UNCONF to NEW?
 
  The UNCONFIRMED status can be kept around to not break URLs, but would
  be hidden by default, no?
 
 Your bookmarked query for open tickets which searches for statuses
 UNCONFIRMED, NEW, ASSIGNED, REOPEN will not magically include those open
 tickets with a newly introduced new status (e.g. CONFIRMED)...
 
 Cheers,
 andre
 
 [1] See e.g. section Question Time on page 6 of
 http://thomas-zimmermann.com/publications/files/breu-cscw-2010.pdf
 


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

Re: Unreviewed patches - is the boat sinking?

[Tristan Van Berkom]

On Sun, 2014-04-13 at 09:34 +0200, Joanna Larsen wrote:
 Hello.
 
 I'm new to Gnome. Some time ago I started looking into the inner
 workings of it. Reading the source code, learning from it. Coming up
 with a few ideas. So I jumped on Bugzilla eager to fix bugs and
 contribute features.
 
 Until I found this [1]. No it's not the list of open bug reports, it's
 the list of unreviewed patches. As of now that's 6138 in total.

Many have already replied useful things to this, just wanted to add yet
another reason the number 6138 is flawed.

As a general rule, there are two or three useful bug statuses,
UNCONFIRMED, RESOLVED and in some cases, if it really makes you feel
good to use a fancy bug status, you might mark it as NEEDINFO.

The same goes for patch statuses, which are much more of an annoyance
than useful, except for the rare cases where you have 6 patches on the
same bug and it becomes interesting to track the status of each
individual patch.

My guess is that a large portion of this 6138 are actually reviewed but
still unresolved, where the review is done completely in the bug
comments and the reviewer thought better than to waste a precious 20
extra seconds on clicking through extra pages in order to mark the bug
status as reviewed.

Cheers,
-Tristan

 Hundreds or thousands of people have taken the time to create a patch,
 submit it and then heard absolutely nothing back. Any free software
 project would crave for even this many contributions alone.
 
 I'm sure it's possible to contribute to Gnome. But this number tells
 newcomers very clearly that there's no point in submitting patches,
 they won't be reviewed.
 
 How do we solve this?
 
 [1]
 https://bugzilla.gnome.org/page.cgi?id=patchreport.htmlpatch-status=none
 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/desktop-devel-list


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

Re: Travel assistance applications to attend to GUADEC

[Tristan Van Berkom]

On Tue, May 28, 2013 at 8:23 AM, Germán Póo-Caamaño g...@gnome.org wrote:
 On Mon, 2013-05-27 at 14:47 -0700, Germán Póo-Caamaño wrote:
 The GNOME Foundation provides travel sponsorships to individuals
 that want to attend GUADEC and need financial assistance.

 We are happy to announce that the Travel Committee is ready to
 receive applications for sponsorships to attend to GUADEC 2013.

 The instructions are detailed at http://live.gnome.org/Travel
 Please read them carefully.

 Deadline: May 31, 2013, 19:00 UTC.  You can start sending
 your applications now!

 After further consideration the new deadline is: June 3, 2013, 19:00
 UTC.

Hi !

I'm a little confused, or perhaps just unfamiliar with this process.

How can the deadline to request sponsorship be on June 3rd
when the deadline for speakers to confirm their attendance is
already June 2nd ?

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

Re: New GnomeGoal proposal: InstalledTests

[Tristan Van Berkom]

On Fri, Apr 26, 2013 at 9:46 PM, Matthias Clasen
matthias.cla...@gmail.comwrote:

 On Thu, Apr 25, 2013 at 10:45 AM, Colin Walters walt...@verbum.org
 wrote:

 
  Do we have (makefile) infrastructure to allow GTests to run both
  uninstalled (during make *check) and installed?
 
  Not at this time; that'd be nice, but I think the jhbuild model
  mostly obviates the need for uninstalled tests, because jhbuild by
  nature is a sandboxed environment independent from the underlying
  system.


 You are not going to get me to buy eagerly into a new installed tests
 scheme for glib if it means that I have to give up make check.


I just wanted to jump in and mention that, I'd really really like to see
better all around relocatability of modules.

Ideally, I'd like to see the following things:
  o Ability to run installed tests, encapsulated in the jhbuild prefix
  o Ability to use the same test cases that I use in-tree as installed
 tests, hopefully by simply installing my in-tree tests somewhere
 (perhaps they would run without some of the custom env vars
 that I would use in-tree, but still re-use all the same test suites
 when installed)
  o Overall relocated D-Bus and settings environment

This last one is a really big deal, there are some really annoying
things right now, for instance I can in *no way* test GTK+ apps
in a jhbuild shell and use the theme installed in the jhbuild prefix.
It seems natural that when typing 'jhbuild shell', any processes
that run should be accessing the settings persisted somewhere
in /opt/devel... instead I would have to slave my whole system
just to see what an app looks like with the theme installed in /opt/devel.

GTestDBus has brought us at least part of the way there when
it comes to D-Bus, but if we run installed tests we'll want to disable
the relocation of services done by GTestDBus (so that some apps
and services can interact with other services installed into the
build prefix, instead of running in complete isolation which is
more appropriate for 'make check'). Perhaps this can be done
by hardwiring some features directly into GTestDBus, of course
in this case we still would want to run a separate session bus for
the jhbuild environment, so that the whole relocated installed
test suite does not interfere with a real active session.

Some few tests, I realize will always depend on how the system
is setup, perhaps require a specific compositor, or even wayland,
but surely 90% or more of the stack is software that is not system
dependant. It would be interesting to have a separate class of installed
tests which *absolutely* cannot run in a relocated environment, but
those would really be a corner minimum case.

I also realize this is a lot of work, but frankly better relocatability is
something that benefits our workflow (I would be able to actually
run Evolution Mail in jhbuild without interfering with my mail account,
I would be able to see what GTK+ apps look like to those select
few who are actually running the bleeding edge of GNOME on a
device)... i.e. it would not only beneficial for installed tests, but
it would help with installed tests too.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New GnomeGoal proposal: InstalledTests

[Tristan Van Berkom]

On Sat, Apr 27, 2013 at 1:56 AM, Colin Walters walt...@verbum.org wrote:

 On Fri, 2013-04-26 at 18:49 +0200, Emilio Pozuelo Monfort wrote:
  Hi,
 
  On 04/26/2013 05:01 PM, Colin Walters wrote:
   On Fri, 2013-04-26 at 10:32 -0400, Dan Winship wrote:
   I want make distcheck to still run all of my tests, to guarantee
 that
   everything works correctly when built from a tarball, not just when
   built from git.
  
   That's going to be a high bar to jump; but I suppose it makes sense to
   have both during the transition and give downstreams time to teach
 their
   build systems about revision control.
 
  I'm not sure I follow here. Are you implying that you want to stop making
  tarballs eventually?

 Yes.

 https://mail.gnome.org/archives/release-team/2013-April/msg00038.html


We're not all on that mailing list (I would venture to say only a select few
people who are part of the release-team are on that list).

Frankly I think it's a really bad idea to expect people to build from git,
prepackaged tarballs are much easier to build.

What is the point of configure.ac without a tarball ? with no tarball
you unconditionally require that the m4s for every dependency,
even a soft dependency be present (because the m4s for soft
dependencies are required to actually build the configure script).

Not to mention, build mechanisms generally use tarballs and prefer
them (eg. buildroot, sure you can configure packages to download
from git, etc, but it's generally an overhead vs. downloading a nice
standard tarball which you know will build as you expect it to,
every time).

If you want to remove our shell accounts, please provide us with
an alternative way of publishing our tarballs (and do give us a heads
up on d-d-l before hand, so we can collect anything which we might
be keeping in our $(HOME) and $(HOME)/public_html).

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

Re: Porting GNOME to Wayland

[Tristan Van Berkom]

On Sat, Mar 16, 2013 at 3:32 AM, Matthias Clasen
matthias.cla...@gmail.com wrote:
 Spring is in the air - things change, people are looking for things to
 try and new goals. I propose that we set ourselves a new goal: port
 GNOME to Wayland

 Wayland has reached the 1.0 milestone recently and it has already had
 some good success in the embedded space. Many of us have silently
 assumed that Wayland is the future display system on Linux, and that
 we will get to using it eventually. But to reach its full potential,
 it needs the push of a full desktop porting project. I think GNOME is
 the right project for this and now is the right time for us to embrace
 Wayland.

 I am confident that the Wayland and X communities will be able to help
 us in reaching this goal.

 Initially, the main work in this effort will be to give gnome-shell
 the ability to work as a Wayland compositor - something that has
 already been demonstrated at last years Guadec in La Coruna. Then we
 need to port functionality for which we've so far relied on the X
 server, such as display configuration or keyboard accessibility
 features. Lastly, the GTK+ Wayland backend needs some love to reach
 parity with the X backend. We will retain the ability to run X
 applications in a compatibility mode, so there is no need to rush and
 port all the worlds applications to Wayland. Porting of applications
 can happen independently and at its own pace.

I'm asking this out of my own curiosity... what kind of porting work
would be required for an 'application' to be ported to wayland ?

Shouldn't that be transparent for most applications by virtue
of linking against the new default wayland GDK backend ?

i.e. usage of the gtk+-3.0.pc would imply wayland anyway
in the bright future where GTK+ is installed on a wayland
capable system, right ?

Will applications need to update configure.ac to specify
a specific GDK backend ? (for systems which might
offer both GTK+ backends, x11 and wayland ?)

And... basically I suppose we're mostly talking about applications
which explicitly #include gdk/gdkx.h that might need any
porting, if any applications do need porting ?

Cheers,
   -Tristan


 As far as a roadmap is concerned, I am fairly optimistic that we can
 have gnome-shell work as a Wayland compositor within 6 months. That
 will allow us to have optional Wayland support in GNOME 3.10, while
 still using X by default. Reaching this milestone by 3.10 will enable
 experimentation with Wayland, and should help us to take the next step
 for GNOME 3.12: a fully converted desktop, with no regressions. If we
 realize during 3.12 development that we won't be able to close all
 feature gaps in time for 3.12, it should be possible to keep
 gnome-shell on X for one more cycle without affecting the rest of the
 desktop too much.

 This proposal is mine, but it has been discussed with the release
 team, as well as with gnome-shell, GTK+ and Wayland maintainers.

 For more details about Wayland see: http://wayland.freedesktop.org
 For more details about this proposal, see http://live.gnome.org/Wayland


 Let me know what you think,

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

Re: jhbuild continuous integration testing: status and plans

[Tristan Van Berkom]

On Fri, Mar 8, 2013 at 12:48 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello fellow GNOMErs,

 after the first round of discussions a month ago[1] about the jhbuild
 CI building/testing [2] I'd like to give some status update.

Along the same topic, I wanted to bring to light something that
was recently raised in EDS bugzilla [0].

Vadim filed this bug, and apparently copied the makefile
from another module... I was wondering if standardizing
this would be interesting for the Continuous Integration
servers... the html output it creates is certainly interesting
to have, an example of the output can be found here [1].

My thoughts were mostly that in that proposed patch, the
included Makefile is a bit crack and hacked out, I would
be interested in standardizing that a bit.

My thoughts were:

  a.) Create an m4 macro implementing the gtester rules
   which could be included in gnome-common and easy
   to integrate into various GNOME modules

  b.) Perhaps extend the .doap format (who defines the
   .doap format anyway ?).. so that the build server
   (or jhbuild directly perhaps) could introspect whether
   a module supports the 'make gtester-report' target.

   In that way, the CI server could automatically collect
   these reports only for modules which support them.

Is it interesting for more modules to implement the more fine grained report ?

Did I miss some important information (i.e. is this already done somewhere
at least partially and I'm not aware of it) ?

Any additional thoughts on this ?

Cheers,
-Tristan

[0]: https://bugzilla.gnome.org/show_bug.cgi?id=695688
[1]: http://dl.dropbox.com/u/8686253/test-report.html


 Since then, Jean-Baptiste has worked quite a bit on the scripts:
 Updating git checkouts as well as building modules are now
 parallelized (building still respects the dependency tree), so that we
 can now rebuild all the 160 modules in something like 15 minutes now.
 This brings us much closer to useful commit-level testing. It now also
 uses jhbuild sysdeps and a much smaller hardcoded list of extra
 build dependencies (which are not exposed by the module lists).
 If a build or test fails it now uses jhbuild's -C option to restart
 with a clean checkout, to avoid tripping over build system cruft from
 autotools file changes.  I spent some time chasing down long-standing
 failures in some modules, as well as filing bugs for newly identified
 regressions.

 Since the announcement, the system has stabilized a lot, and the set
 of test failures is now quite stable.

 The thing that hurts most currently is that the machine is behind a
 proxy.  This causes quite a lot of test failures (like libgdata's
 youtube test), as well as spurious build failures like [3]. We do plan
 to move this machine into the DMZ soon, so that it has unrestricted
 network access. I'd like to postpone sending out notifications until
 that happens, as otherwise we'll spam people too much about irrelevant
 issues.

 Once that happens, we'll set up email notifications for state changes
 (e. g. pass → fails to build, or test fail → pass) and send them
 to Jean-Baptiste and myself first, to give this some more real-world
 testing. If that has a low enough noise ratio, we were planning to
 mail the maintainers of the affected modules (if the module has a
 .doap file), with some hint to notify us if they want to opt out of
 notifications.

 Then we can investigate for some time how this works, and debate if
 filing bugs would be better or not.

 Does that sound like an acceptable plan?

 Thanks,

 Martin

 [1] 
 https://mail.gnome.org/archives/desktop-devel-list/2013-February/msg00025.html
 [2] https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/
 [3] 
 https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/job/jhbuild-amd64-libgee/92/artifact/libgee.log
 --
 Martin Pitt| http://www.piware.de
 Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

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

Re: -Werror considered harmful

[Tristan Van Berkom]

Hi Behdad.

I'll be the first to agree that -Werror is evil stuff, we even fell
into this catch 22 only
around a year ago where one group thought it was a good idea to infect
our builds
with -Werror, while another group thought it was a good idea to add
deprecation warnings,
... I'm not even sure we're out of the woods from that tangled mess yet.
(and I'll side with the latter, deprecation warnings are a good thing,
warnings are a
good thing in general).

That being said, does glib not use the gnome-common macros,
which include the --disable-fatal-warnings configure option ?

I've found this configure option to be helpful, not sure if glib still
needs it to be added...

Cheers,
 -Tristan

On Tue, Feb 26, 2013 at 10:39 AM, Behdad Esfahbod beh...@behdad.org wrote:
 [I think I'm not on d-d-l, CC is appreciated.]

 rant

 Hi,

 I'm sending this email instead of filing a bug because I think I need to say
 this as widely as I can: modules adding -Werror (or -Werror=... variants
 thereof) are harmful

 Background:

 A few years ago Javier opened this bug against gnome-common:

   https://bugzilla.gnome.org/show_bug.cgi?id=608953

 which references my blogpost:

   http://mces.blogspot.ca/2008/12/year-end-cleaning-ie-on-warning-options.html

 The bug title is Add some more compiler warning options.  Something that I
 thinks is good hygiene.  However, in the course of that happening, things like
 these ended up going in:

 dnl These compiler flags typically indicate very broken or suspicious
 dnl code.  Some of them such as implicit-function-declaration are
 dnl just not default because gcc compiles a lot of legacy code.
 dnl We choose to make this set into explicit errors.
 base_error_flags= \
 -Werror=missing-prototypes \
 -Werror=implicit-function-declaration \
 -Werror=pointer-arith \
 -Werror=init-self \
 -Werror=format-security \
 -Werror=format=2 \
 -Werror=missing-include-dirs \
 

 which then made it into glib as part of bug 687385.

 Now, can you spot the problem?  Hint: the comment above says *typically*
 indicate very broken.  I translate: typically this is fine, in other
 situations we are breaking people's build, but that's fine.

 Indeed, the email that went out with the change [1] acknowledged the problem:

 This gets to the next problem, which is that -Wall includes
 -Wmaybe-uninitialized and other heuristics like -Wstrict-aliasing.  Then
 combine that with the fact that some people have got it in their head
 that -Wall -Werror is the Right Thing, what actually ends up happening
 is your code only compiles on a *particular version* of gcc.  That just
 doesn't work in a distributed project like GNOME, where various bits get
 reused by different projects and products on different schedules etc.

 but goes on to conclude:

 So I think what Dan has is more the Right Thing - make the compiler
 warnings that you should *never* hit into explicit errors.

 Interesting.  So some omniscient hacker decided that compilers compiling GNOME
 shall never ever see code that generates a missing-prototypes warning, err,
 error.  Not in the cryptic system headers of whatever weird cross compiler I
 may be using.  I want your crystal ball seized!

 Here I am, trying to cross-compile glib using mingw32, so I can cross-compile
 pango, so I can fix a pangowin32 bug, and was stopped getting this:

 behdad:libcharset 2$ make V=1
 /bin/sh ../../libtool  --tag=CC   --mode=compile i586-mingw32msvc-gcc
 -DHAVE_CONFIG_H -I. -I../../../glib/libcharset -I../..
 -DLIBDIR=\/home/behdad/.local/i586-mingw32msvc/lib\ -I../..
 -I/home/behdad/.local/i586-mingw32msvc/include   -g -O2 -mms-bitfields  -Wall
 -Wstrict-prototypes -Werror=declaration-after-statement
 -Werror=missing-prototypes -Werror=implicit-function-declaration
 -Werror=pointer-arith -Werror=init-self -Werror=format=2
 -Werror=missing-include-dirs -MT localcharset.lo -MD -MP -MF
 .deps/localcharset.Tpo -c -o localcharset.lo
 ../../../glib/libcharset/localcharset.c
 libtool: compile:  i586-mingw32msvc-gcc -DHAVE_CONFIG_H -I.
 -I../../../glib/libcharset -I../..
 -DLIBDIR=\/home/behdad/.local/i586-mingw32msvc/lib\ -I../..
 -I/home/behdad/.local/i586-mingw32msvc/include -g -O2 -mms-bitfields -Wall
 -Wstrict-prototypes -Werror=declaration-after-statement
 -Werror=missing-prototypes -Werror=implicit-function-declaration
 -Werror=pointer-arith -Werror=init-self -Werror=format=2
 -Werror=missing-include-dirs -MT localcharset.lo -MD -MP -MF
 .deps/localcharset.Tpo -c ../../../glib/libcharset/localcharset.c
 -DDLL_EXPORT -DPIC -o .libs/localcharset.o
 In file included from ../../../glib/libcharset/localcharset.c:28:
 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/stdio.h:372:
 error: no previous prototype for 'getc'
 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/include/stdio.h:379:
 error: no previous prototype for 'putc'
 

Re: Announcement/RFC: jhbuild continuous integration testing -- mystery of recent flood of failures solved

[Tristan Van Berkom]

On Tue, Feb 19, 2013 at 10:13 PM, Simon McVittie
simon.mcvit...@collabora.co.uk wrote:
 On 18/02/13 22:34, Martin Pitt wrote:
 Please note that there is no system D-BUS and no default session D-BUS
 running. If you need those, then the tests should start dbus-launch or
 use GTestDBus.

 dbus-launch is not particularly suitable for regression tests: if you
 use it, you have to kill the resulting dbus-daemon yourself when you're
 finished with it. If not using GTestDBus, please use with-session-bus.sh
 from telepathy-glib, or review
 https://bugs.freedesktop.org/show_bug.cgi?id=39196 so I can add
 dbus-run-session(1) to dbus.

This is a very interesting topic (and brings to mind Colin's ideas about
installed tests).

Here's some ideas worth consideration IMHO...

  o Unit Tests with GTestDBus

 GTestDBus is IMO ideal for regression testing (or in-tree unit tests),
 I made a short write-up on this not long ago in my blog[0].

 The idea here is that you want to be absolutely sure that you
 are testing isolated modules and services that are still in-tree,
 you want to test ideally your services alone without clouding
 your results with installed services. If your service relies on
 system installed services, you would ideally want to control
 which specific installed services get to run in your controlled
 D-Bus environment sandbox.

 I.e. if you have services in /usr/share/dbus-1, you dont want those
 mixed in to your sandboxed build path, colliding with services in
 /opt/devel/share/dbus-1/.

 You also probably want to control cases where fallbacks can be
 implemented, if your service/client can run without a complimentary
 service... you want to test a case where your client has access to
 an installed service vs. a case where a fallback is used instead.

 o Now that we are talking about a build server and building 'all-of-gnome'
it becomes interesting to know if a service installed by some dependency
effects any modules which depend on that service in a negative way.

For this case (why I thought about Colin's ideas on installed tests), it
suddenly becomes interesting to have tests which do not use GTestDBus
in a controlled environment, but instead to test the system as a whole,
running only services from ${build_prefix}/share/dbus-1 but certainly
avoiding anything from /usr/share/dbus-1/ (or at least properly prioritizing
the build prefix services over the system installed ones, if we can't avoid
using those).

 o If we have these two theories of testing D-Bus services and clients which
depend on them, we probably want to reuse the unit testing code as much
as possible.

Perhaps some additional features added to GTestDBus could allow us
to run the same tests in both contexts (i.e. the installed test context
with a full gnome environment vs. the isolated in-tree context).

Cheers,
  -Tristan

[0]: 
http://blogs.gnome.org/tvb/2012/12/20/isolated-unit-testing-of-d-bus-services/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcement/RFC: jhbuild continuous integration testing

[Tristan Van Berkom]

On Thu, Feb 14, 2013 at 3:12 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello Tristan,

 Tristan Van Berkom [2013-02-14  6:42 +0900]:
 Upon reading this particular part (and I noticed before you are
 using mostly jhbuild mechanics), it leads me to wonder, how
 granular exactly are these rebuilds ?


Hi !

Thanks for answering in detail (and Colin and Emmanuele too, very
interesting stuff).

 Right now, every 15 minutes. Sometimes longer, when the previous run
 is still running.

 I think ideally it would be great if builds could be triggered by
 commit. In other words, commits are serialized chronologically and
 each and every commit should trigger an entire rebuild, each rebuild
 should build everything in the moduleset up to the latest commit...
 separately, one after the other.

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

 Once we solve both, and we dramatically reduce the time of one run
 from several hours (which is currently needed if e. g. a glib change
 happens, which rebuilds pretty much everything) to  15 minutes.

 The way I imagine this works now (and this is a big assumption,
 correct me if I'm wrong), is that a commit in a given module triggers
 a jhbuild build, which would mean that:

a.) Several commits could have been made in a given module
 by the time jhbuild actually runs... meaning we dont know
 which of the given commits in that lapse of time actually
 caused the fault.

 That's right. It's massively better to know that one commit in these
 15 minutes triggered it than something in the past week, but still
 not perfect as you say.

b.) Module foo triggers a rebuild... and while jhbuild builds,
 it also pulls in new changes from module bar, in this
 case it's possible that a recent commit in module bar
 caused another module baz to be effected,  but in the
 end it's module foo who is blamed (since module foo
 essentially /triggered a rebuild/)

 That's a trickier thing. For most commits, one should actually be able
 to build them independently, but sometimes those in between breaks
 are inevitable. Say, you make an API change in a library and then
 update your application to the new API, then in between you will get a
 build failure. The next iteration should fix it again.
 We have that problem independently of the frequency we build stuff of
 course, as we can always hit a bad time.

As someone mentioned/proposed earlier in this thread, this kind of temporary
error could probably be ruled out with a timeout (perhaps not a real timeout,
but a measurement in elapsed time between commits).

In other words, no need to alert people if a breakage was almost immediately
addressed and fixed.

I'm sure with some more time and development we'll find the right approach
and refine things further (may include some kind of graph theory, trying some
builds with different modules' changes applied in different orders and
eliminating
false breakages this way).

Anyway, very exciting work, thank you for doing this :)

Cheers,
-Tristan


PS: One of the fun things this will allow is... to hand out build breaker
awards (something we used to do in a company I worked at, was to
hand out an award to the committer which introduced the most
build breaks this month, mostly just for giggles).
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Announcement/RFC: jhbuild continuous integration testing

[Tristan Van Berkom]

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

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

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

Fixing that bottleneck also sounds like one of the first steps towards
setting up a patch queue approach, i.e. set up a local mirror of all
remote git repos which is periodically updated... and fixup jhbuild
to optionally update from those local mirror instead of accessing
remote ones all the time.

Of course, making jhbuild parallelize the actual module builds is
a bit more complex (probably just a bit of python scripting ? not sure).

Another thought, if this gets integrated in a 'mostly a feature of jhbuild'
fashion, this can have some really interesting additional benefits.

Many projects that use the gnome platform libs already do create
their own modulesets, and can then easily set this up on their own
build server for their own project (improving the gnome developer
story in a big/real way), first thing that comes to mind is the osx
builds of Clutter and GTK+ (which are mostly just customized jhbuild
modulesets), not sure about win32... do we use jhbuild inside MSYS
I can't remember ?

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

Re: Announcement/RFC: jhbuild continuous integration testing

[Tristan Van Berkom]

First, this sounds like really interesting stuff, great news.

On Tue, Feb 12, 2013 at 3:43 PM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello fellow GNOME developers,

 this already came up as a side issue recently[1], but now we are at a
 point where have reasonably stabilized our GNOME jhbuild continuous
 builds/integration test server to become actually useful:

   https://jenkins.qa.ubuntu.com/view/Raring/view/JHBuild%20Gnome/

 This is building gnome-suites-core-3.8.modules, which currently
 consists of 160 modules. Builds are updated every 15 minutes, and
 triggered whenever there was a new commit in a module or any of its
 dependencies. This mostly uses the smarts of jhbuild, we just have
 some extra scripts around to pick the results apart for Jenkins and
 drive the whole thing [2]. You can click through all the modules, all
 their builds, and get their build logs.

 Right now there are 151 successes (blue), 5 modules fail to build
 (red), and 4 modules build but fail in make check (yellow). It's
 been like that for a week or two now, so I'd say we are doing
 reasonably well for now. Some details:

 Build failures:
  - colord: recently started depending on libsystemd-login, which we
don't have yet; that's a fault on the Ubuntu side
  - e-d-s: calls an undeclared g_cond_timed_wait(), not sure what this
is about
  - folks: this started failing very recently, and thus is a perfect
example why this is useful (unqualified ambiguous usage of
HashTable)
  - gst-plugins-bad: unknown type GStaticRecMutex; this might be due to
recent changes in streamer? That smells like a case of broken by
change in dependency, needs updating to new API
  - mutter: worked until Jan 7, now failing on unknown XIBarrierEvent;
that might be a fault in Ubuntu's X.org packages or upstream, I
haven't investigated this yet

 Test failures:
  - gst-plugins-good, empathy: one test failure, the other tests work
  - realmd: This looks like the test suite is making some assumptions
about the environment which aren't true in a headless server?
  - webkit: I don't actually see an error in the log; we'll investigate
this closer on our side

 This was set up by Jean-Baptiste Lallement, I mostly help out with
 reviewing the daily status and cleaning up after some build/test
 failures which are due to broken checkouts, stale files, new missing
 build dependencies, and so on. It's reasonably maintenance intensive,
 but that's something which the two of us are willing to do if this
 actually gets used.

 The main difference to Colin's ostree builds is that this also runs
 make check, which is one of the main points of this: We want to know
 as soon as possible if e. g. a new commit in glib breaks something in
 gvfs or evolution-data-server. Where soon is measured in minutes
 instead of days/weeks, so that the knowledge what got changed and why
 is still fresh in the developer's head. That's also why I recently
 started to add integration tests to e. g. gvfs or
 gnome-settings-daemon, so that over time we can cover more and more
 functionality tests in these.

 To make this really useful, we can't rely on developers checking this
 every hour or every day, of course; instead we need push notifications
 as soon as a module starts failing. That's the bit which needs broader
 discussion and consent.

 I see some obvious options here what to do when the status of a module
 (OK/fails tests/fails build) changes:

  (1) mail the individual maintainers, as in the DOAP files
(1a) do it for everyone, and let people who don't want this filter
them out on a particular mail header (like X-GNOME-QA:)
(1b) do this as opt-in

This most often reaches the people who can do something about the
failure. Of course there are cases where it's not the module's fault, but a
dependency changed/got broken. There is no way we can automatically
determine whether it was e. g. a deliberate API break which modules
need to adjust to, or indeed a bug in the depending library, so we
might actually need to mail both the maintainers of the module that
triggered the rebuild, and the maintainers of the module which now
broke.

Upon reading this particular part (and I noticed before you are
using mostly jhbuild mechanics), it leads me to wonder, how
granular exactly are these rebuilds ?

I think ideally it would be great if builds could be triggered by
commit. In other words, commits are serialized chronologically and
each and every commit should trigger an entire rebuild, each rebuild
should build everything in the moduleset up to the latest commit...
separately, one after the other.

I know, it sounds like some CPU will be melting quickly
at the rate gnome-wide commits are made... but it would be
simply awesome, if we could automatically pull out the exact
commit which introduced exactly which failed build report in
which module (and then as you mentioned, we probably need
to notify both the 

Re: Privacy/Security Friends of GNOME campaign?

[Tristan Van Berkom]

On Wed, Dec 19, 2012 at 12:35 AM, Federico Mena Quintero
feder...@gnome.org wrote:
 On Wed, 2012-12-12 at 23:19 -0500, Karen Sandler wrote:

 The marketing team agreed that this time a privacy/security campaign would
 be great for a friends of GNOME drive. After Jacob Applebaum's talk at
 GUADEC, we heard a lot of people discussing how important these issues are
 and how we'd like to do more at GNOME.

 Are there areas of GNOME that you think could be improved from this
 perspective?

 Jacob mentioned that Pidgin/libpurple badly needs a security audit (and
 since Empathy's machinery is in libpurple, this would have a direct
 benefit for Gnome).  Maybe we could fundraise with that in mind.

 Some random ideas:

 * What would it take to have a Tor-ified session right from GDM?

 * Should we have a desktop-wide incognito mode?

While we're throwing wild ideas around that might actually make a
difference in the world, let me share a half-backed idea that came
to mind last night (coincidence I'm reading this thread the following
morning !)... bear with me, the idea is a bit vague and I don't see
the crystal clear path to implementing it, but I'm sure it's quite
doable (and much less complex than implementing Tor).

Simply put the idea is Identity Sharing.

What if I had multiple identities when I logged into my desktop
which I would use for different purposes ?

The key point here is that I envision some infrastructure that
allows one to tie all access to internet services with a given
identity which can then in turn be shared (and when I thought
of this, I was thinking that GNOME Online Accounts was a
great place to start out on this sort of thing)

For instance, I would log in to hack on GNOME stuff and I would
use some kind of official appearance identity... using my
Tristan Van Berkom pseudonym. Then I would not share this
particular identity because I may risk sharing GNOME private
stuff (like GNOME commit access)... But I may at other times
rather to use a shared identity.

Sharing an identity would mean that others would have access
to all the facebook/google/youtube/skype/whatever services which
were subscribed to by the original creator of that identity.

The idea is to counteract malicious attempts to tie an
identity to a single person and then profile, track
and spy on them.

This would work better of course when coupled with
something like Tor.

I recall in Jacob's talk on Tor at GUADEC he mentioned
some obvious pitfalls where Tor could not always protect
your anonymity online... i.e. when you log into a site with
your user information... like Skype for instance... they might
not know your location and IP, but your data is being pushed
through their site and is also attached to the personal information
you used to create that Skype account in the first place,
which means that they can still spy on you and associate your
conversations with your identity (even without an IP).

Identity Sharing, by way of lessening/removing the overall
value of an internet identity, by way of dissociating the
identity with the person; seems to me to be a small
but significant step towards protecting users from spyware.

Anyway... a friends of GNOME campaign might not be
the right time and place for such a venture, but I thought
it was worth while to share the idea while on the topic
of security.

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

Re: make --silent

[tristan . van . berkom]

On 2012-09-09, at 2:35 AM, Lanoxx lan...@gmx.net wrote:

 Hi Colin,
 
 can you give me a concrete example of some output where the silent switch is 
 actually problematic? For every occasion where I have used it so far, it only 
 removed lines which look like
 
 make[2]: Leaving directory `/home/user/Documents/Code/tilda'
 


This is generally useful to pinpoint the directory where something went wrong 
in the case that you are searching in a verbose make output.

When for example, you build the whole platform from scratch... It's a long 
process... Maybe one build fails because 3 packages ago a package was badly 
configured.

When something goes wrong you need all the output... what if you need to know 
that the correct flags are given to the linker? What if you are pulling the 
pkg-config from /usr/bin instead of from your cross compiling environment ?

Many things can go wrong when building entire stacks, so all output is needed. 
when you build one package as a developer, you are one of the use cases of 
build scripts which (sometimes) require less output... Of course if something 
goes dramatically wrong even you will end up enabling the complete output...

Cheers


 and I don't understand how that can lhelp people who run build servers? On 
 the other hand, how many people (e.g. developers) need to compile some code 
 by hand and how many people are there running build servers? I could be wrong 
 of course, but wouldn't it be easier to set the silent option as default and 
 then let the people with build servers export some variable such that the 
 silent option is ignored? Im not very familiar with autotools but it should 
 be possible to do something like this:
 
 if not environment.SILENT_MAKE_FLAG then;
  MAKEFLAGS = -s
 fi
 
 and then everyone who runs a build server can just export SILENT_MAKE_FLAG. 
 Or is that a stupid idea for some reason?
 
 On 08/09/12 19:12, Colin Walters wrote:
 On Sat, 2012-09-08 at 19:06 +0200, Lanoxx wrote:
 
 I tried to ask in #gtk+ why they are using the SILENT_RULES makro, but
 are not using the silent make flag, and someone tried to explain to me,
 that this also silences warnings, but as can be seen below, it does not.
 I also dont see a real benefit in these make output which only seems to
 output which folders make is entering.
 Because people running build servers want the complete verbose logs in
 order to debug problems.
 
 It's easy enough to filter the output; we should really patch jhbuild to
 do so.  It's just hard to do in the curent code.
 
 
 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: jhbuild update required

[Tristan Van Berkom]

On Thu, Sep 6, 2012 at 5:23 AM, Jeremy Bicha jbi...@ubuntu.com wrote:
 On 5 September 2012 15:13, Jasper St. Pierre jstpie...@mecheye.net wrote:
 jhbuild is not meant to be packaged. I'd highly suggest you stop
 packaging jhbuild.

 Yes, you're not the only one to say that. But, I thought a big part of
 what jhbuild offers is that it makes it relatively easy to try out the
 bleeding edge of GNOME without having to mess with learning how to
 ./configure, make, make install (and of course ./configure doesn't
 work on GNOME packages without running autogen.sh first but how's a
 beginner to know that?). Requiring a beginner to manually build
 jhbuild from source defeats that advantage.

I think initiatives along the lines of build servers generating live CDs
or usb mountable images are more what you're looking for.

Whether you get past actually installing jhbuild on your system
or not, by the package manager or via a git clone, there's no way
you will be able to build highlevel modules on the bleeding edge
without a little know-how.

In other words, the build will fail and you will have to fix it, either by
upgrading python, installing some unspoken dependency or by
actually meddling in source code during the build and forcing it
to build.

This is not the case for *some* jhbuild setups, for instance stable
release module sets typically have less problems and the jhbuild
scripts targeting quartz builds (on OSX) are typically error free.

But that's only because those build scripts target very specific
module versions for each checkout (or resort to downloading
release tarballs directly)... if you build master, you will have
problems and you should know how to fix them.

You cannot blame jhbuild scripts for this issue, the quality of
the jhbuild scripts will not avoid the simple fact that there will
always be some disconnection between modules in master
between release cycles, those are bugs in the effected
modules and are generally fixed during the unstable dev
cycle (for instance, you cant expect gedit developers to
update all of their dependencies between every single commit
that they make, although I'm sure they are pretty good at
updating things frequently enough).

This does not mean jhbuild is not useful, by far.

For some perspective, how I used to build gnome modules
before jhbuild existed was an exercise consisting of listing
by hand all of my inter-module dependencies and
updating/building them by hand in the right order.

Like many others I would use a custom environment script which
consisted mostly of:

PATH=/opt/devel/bin:$(PATH)
LD_LIBRARY_PATH=/opt/devel/lib
PKG_CONFIG_PATH=/opt/devel/lib/pkgconfig
ACLOCAL_FLAGS=-I /opt/devel/share/aclocal
(and I probably forgot something else here...)

This manual building is a real problem that jhbuild does solve.

Cheers,
-Tristan


 Also, there's the whole problem of users needing to periodically
 update their jhbuild manually. Why not let distros handle that like
 they do every other package?

 I've always ran jhbuild from the distro package. As long as jhbuild
 gets regular releases, those releases get packaged, and I use the
 default network modulesets, I don't see a problem.

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

Re: RFC: Securing maintainer uploads to master.gnome.org

[Tristan Van Berkom]

On Fri, Nov 11, 2011 at 4:50 AM, Olav Vitters o...@vitters.nl wrote:
 On Thu, Nov 10, 2011 at 07:47:26PM -0500, Tristan Van Berkom wrote:
    I think it's nice that currently we can upload win32 and osx builds of 
 gnome
 modules/apps and have them available on gnome servers, if we take away
 shell access then perhaps the install-module/ftpadmin script should be
 enhanced to allow this (afaik the only way currently is to manually place
 a file somewhere on master.gnome.org).

 Any pointers on what you need? It should be enhanced, yes. Ftpadmin
 takes a file and then based on the filename it figures out where to
 store it. For binary stuff, I think we should agree on the way the files
 are named. This so ftpadmin can figure out where to store it on
 'ftp.gnome.org'.

That sounds like it would work perfectly to me, we might have
some standard platform suffixes after the module name and before the
version suffix, like: module-win32-1.0.0.tar.bz2, (win64, osx...)

If there are multiple ways of distributing packages on the same
platforms, it might make sense to have separate names for those.

Windows unfortunately I think is more tricky than osx as specially
since people want to download libraries pre-built and use them in thier
packages (i.e. people dont want to build GTK+ on win32) you might really
want to know that you are downloading something that's linked with
cygwin, was built with MSYS/mingw, or was compiled with some
particular version of MSVC

I don't know, perhaps it's better to allow the publishing maintainer to specify
the name of the 'platform' suffix directory name... and avoid bike shedding
what all these directory names might be...


 If possible, I want to first get rid of the majority of the shell
 accounts and still allow the old way. Then whomever complains gets a
 shell, but then I'll work to remove the shell again ;)

 Other than that I think the only interaction I ever needed with 
 master.gnome.org
 was to hook the autogeneration of glade.gnome.org website to a git commit
 hook or such (and it probably shouldn't have been me doing that anyway...).

 This I don't get. Master.gnome.org is just to release tarballs. If you
 need a post-commit git rule, just file a bug with
 https://bugzilla.gnome.org/browse.cgi?product=sysadmin. If
 glade.gnome.org is on a gnome server, then it should be pretty easy to
 setup (already have post-commit scripts in place; only need to run git
 config on git.gnome.org).

Right, it was a couple years ago I guess, but I have in my bash history
some references to the directory:
   /usr/local/www/gnomeweb/hooks/glade-web

The site still updates properly... but the directory does not exist anymore
on master.gnome.org ;-)

This was really just a corner case where we were copying the functionality
of the pygtk site... and ideally only a sysadmin should be able to touch
those things anyway.

Cheers,
 -Tristan

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

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

Re: RFC: Securing maintainer uploads to master.gnome.org

[Tristan Van Berkom]

   I think it's nice that currently we can upload win32 and osx builds of gnome
modules/apps and have them available on gnome servers, if we take away
shell access then perhaps the install-module/ftpadmin script should be
enhanced to allow this (afaik the only way currently is to manually place
a file somewhere on master.gnome.org).

Other than that I think the only interaction I ever needed with master.gnome.org
was to hook the autogeneration of glade.gnome.org website to a git commit
hook or such (and it probably shouldn't have been me doing that anyway...).

Cheers,
  -Tristan

On Thu, Nov 10, 2011 at 10:36 AM, Olav Vitters o...@vitters.nl wrote:
 On Thu, Nov 10, 2011 at 03:19:07PM +, Maciej Marcin Piechotka wrote:
 On Thu, 2011-11-10 at 12:47 +0100, Olav Vitters wrote:
  My thoughts to secure this is:
  1. Get rid of shell for ideally everyone (maintainers, release team,
  etc)
  2. Uploads are done using:
     a. rsync over ssh using rrsync; this restricts what you can upload
     b. something like: ssh master.gnome.org install-module
     c. the install-module command looks at what you uploaded and then
     calls ftpadmin on it
     Problem:
     a. rsync might be annoying / unreliable
     b. don't think you can delete easily with rsync
     c. more annoying than e.g. sftp or scp
     Benefit:
     a. rsync over ssh is easy to secure

 I may be wrong but IIRC ssh can be configured to allow only scp
 connections. Maybe solution would be (instead of rsync):

  - Allow scp
  - Allow install-module as default (and only) login shell

 scp is shell commands, only sftp has a bit more of a protocol. But I
 don't want people to be able to modify anything than uploading a
 tarball (e.g. ~/.bash*). Intention is just allowing exactly what is
 needed.

  3. Access is determined using doap files

 Hmm. Isn't access to git open to everyone who have key? The malicious
 attacker who compromise account one of 350+ user may alter the doap file
 (I guess it would be much easier to miss then say unexpected release
 which is followed by public e-mail).

 ftpadmin informs all existing maintainers when a tarball is uploaded.
 I'm intending to inform all existing + new maintainers on any changes
 to the doap file. I could (but don't want) to restrict doap file updates
 solely to people already marked in the doap file.

 If master.gnome.org is compromised, the attacker could pretend
 everything is fine. If it instead follows the process I think is secure
 enough, then it just is our policy that is wrong.

 Reason I choose for lax is same reason any gnome git account can modify
 any repository: eases development imo.
 --
 Regards,
 Olav
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: Use of maintainer mode in GNOME modules

[Tristan Van Berkom]

2011/9/12 Murray Cumming murr...@murrayc.com:
 On Fri, 2011-09-09 at 13:09 +0100, Javier Jardón wrote:
 Hi all,

 As you can read in the Ryan blog post [1], the use of the
 AM_MAINTAINER_MODE macro is only correct when used in this way:

 AM_MAINTAINER_MODE([enable])

 As ryan said in the blog post, fredp made a report page for packages
 using AM_MAINTAINER_MODE.

 green  - no “AM_MAINTAINER_MODE” at all (good)
 yellow - “AM_MAINTAINER_MODE([enable])”  (fine)
 orange - means that your package is currently broken and needs to be fixed.

 So if Its not already fixed in your module, we are going to proced to
 fix all the GNOME modules that appear
 in orange and convert it to yellow, ie

 AM_MAINTAINER_MODE - AM_MAINTAINER_MODE([enable])

 Thanks for you collaboration.

 [1] http://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/
 [2] http://people.gnome.org/~fpeters/reports/maintainer-mode.html

 We don't really want this change in the gtkmm (and friends) modules.
 Chaning AM_MAINTAINER_MODE to AM_MAINTAINER_MODE([enable]) will change
 the default behaviour in tarball builds.

 We currently ship generated C++ files and HTML documentation files in
 our tarballs. Distro packagers generally don't want to regenerate those
 files because a) It's unnecessary and b) It requires extra build tools.

Hi guys,
   After reading the blog post and this thread yesterday I did not think
much of it... but can we clarify this point ?

If I have AM_MAINTAINER_MODE([enable]) then what happens by
default ?
   a.) docs and user manual are not included in the tarball ?
   b.) docs are built and distributed in the tarball but typing 'make'
causes them to be rebuilt ?

Actually I accepted a patch to modernize Glade's configure script (which
adds the '([enable])' bit to AM_MAINTAINER_MODE) and it's possible that
I have just not noticed the pain which I've caused anyone downloading
our tarballs
(since I obviously happen to always have all the tools I need to build GNOME
from git).

We've always been very clear about this, to build from a git checkout
you need a whole lot of gnome stuff, but when you build from the tarball
you really only need a basic gnu toolchain and the GTK+ development files
and dependencies.

If users are forced to have unnecessary tools on their system to download
and test Glade tarballs, this is definitely a problem for us and we will
probably be inclined to revert to just AM_MAINTAINER_MODE.

But, perhaps this is just a misunderstanding, does this change really
push complications onto the innocent downloaders of our tarballs ?

Best regards,
 -Tristan


 We don't want distro packagers to regenerate the files because there is
 a risk that the output will not be the same if they have slightly
 different versions of the dependencies, including newer versions. It can
 even risk breaking ABI. Distro packagers don't want that either.

 If, for some reason, distro packagers do want to turn this off, they
 already can with the configure option.

 So, for *mm modules, it doesn't seem to be a change that would actually
 help anybody in the real world, though it risks causing real problems.


 Theoretically we might not be doing things in the right way, but then it
 would be up to someone to fix things properly instead of just breaking
 our modules.


 We have seen you make this change at least once without asking the
 maintainer:
 http://git.gnome.org/browse/gdlmm/commit/?id=3272c0aa3008654e54b6fd68af8c324db3ee72f8
 even though this has not apparently been approved yet as a gnome-wide
 goal.

 --
 murr...@murrayc.com
 www.murrayc.com
 www.openismus.com

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

Re: Archiving 120 Git modules with no commit in 3 or more years

[Tristan Van Berkom]

On Tue, Apr 5, 2011 at 9:17 AM, Olav Vitters o...@vitters.nl wrote:
 Checking the last commits of the modules on git.gnome.org, I noticed we
 have 120 modules which haven't received a commit in the last 3 years.

 I'll archive the modules somewhere this week (modules can easily be
 moved out of the archive).

 I've archived modules before when I was really sure that nobody would
 use it... but 120 is a bit much to check. Posting this list so if anyone
 has an objection, I'll not archive the git module.

 The intention is to ensure that http://git.gnome.org/browse/ is readable
 (old stuff in archive).

You might move the old glade module (its now called glade_legacy ?) into
the archive too as I did not see it in the list.

Just out of curiosity, are they just going to be in another directory ?

http://git.gnome.org/archives/browse/ or such ?

Cheers,
-Tristan



 List of modules:

 Following give an error. I'll check them manually.

 accroc.git      error
 bin.git error
 buildbot-web.git        error
 dbus-hook.git   error
 gconf-dconf-bridge.git  error
 gnome-art-tool.git      error
 gstreamermm-plugins-good.git    error
 just-my-testuser-repos.git      error
 libtruthiness.git       error
 lock-service.git        error
 network-manager-openswan.git    error

 Modules which did not receive a commit in the last 3 years:

 web-mirror.git  1999-05-25 21:49:45 +       12 years ago
 web-gtkorg.git  2001-11-26 02:27:24 +       9 years ago
 ludwig.git      2002-09-22 20:47:37 +       9 years ago
 assetmlweb.git  2003-09-25 21:28:15 +       8 years ago
 gle.git 2004-02-03 18:08:05 +       7 years ago
 gtkvts.git      2004-07-02 10:36:10 +       7 years ago
 evolution-monoembed.git 2004-07-06 17:13:51 +       7 years ago
 denzil.git      2004-08-08 14:11:11 +       7 years ago
 CWordHelper.git 2004-12-31 01:26:15 +       6 years ago
 wiki-web.git    2005-01-16 17:06:35 +       6 years ago
 kanjipad.git    2005-03-07 22:23:22 +       6 years ago
 bugmasters.git  2005-03-20 01:07:13 +       6 years ago
 evolution-xmltv.git     2005-05-11 09:52:30 +       6 years ago
 mozilla-bonobo.git      2005-07-09 17:34:27 +       6 years ago
 bookworm.git    2005-07-13 05:00:13 +       6 years ago
 siobhan.git     2005-07-18 04:43:17 +       6 years ago
 libgnomeservice.git     2005-07-25 16:29:24 +       6 years ago
 gnome-smproxy.git       2005-08-09 16:20:55 +       6 years ago
 Mocca.git       2005-08-12 13:43:41 +       6 years ago
 gio.git 2005-08-14 17:37:04 +       6 years ago
 microtinder.git 2005-08-17 22:11:53 +       6 years ago
 yarrr.git       2005-08-25 15:56:14 +       6 years ago
 gnome-db-web.git        2005-08-27 14:48:32 +       6 years ago
 camtrack.git    2005-09-01 14:23:59 +       6 years ago
 sarma.git       2005-09-02 16:12:14 +       6 years ago
 search-party.git        2005-09-04 16:48:13 +       6 years ago
 pygnome-hello.git       2005-09-07 18:12:11 +       6 years ago
 livecd-project.git      2005-09-08 16:26:54 +       6 years ago
 giulia.git      2005-09-27 12:26:12 +       6 years ago
 gnome-startup-profiling.git     2005-10-09 15:53:06 +       5 years ago
 gnome-session-manager.git       2005-10-11 21:15:16 +       5 years ago
 silky-www.git   2005-10-12 14:46:03 +       5 years ago
 gshrooms.git    2005-10-15 12:53:42 +       5 years ago
 tepache.git     2005-10-28 14:17:26 +       5 years ago
 gnome-panel-extensions.git      2005-11-18 01:14:55 +       5 years ago
 pango-profile.git       2005-11-25 16:41:54 +       5 years ago
 libinotify.git  2005-12-01 19:11:01 +       5 years ago
 im-canna.git    2005-12-02 09:11:36 +       5 years ago
 dia-web.git     2005-12-29 14:23:12 +       5 years ago
 gppthtml.git    2006-01-06 09:35:09 +       5 years ago
 gopersist.git   2006-01-10 14:49:59 +       5 years ago
 gegl-web.git    2006-01-18 00:29:05 +       5 years ago
 gnome-printer-add.git   2006-01-19 20:28:04 +       5 years ago
 perl-GStreamer-GConf.git        2006-01-29 21:02:29 +       5 years ago
 perl-Gtk2-SourceView.git        2006-01-30 08:44:31 +       5 years ago
 nautilus-revisioning.git        2006-01-31 01:08:19 +       5 years ago
 eazel-tools.git 2006-02-01 05:06:36 +       5 years ago
 gtkmozembedmm.git       2006-02-27 16:10:39 +       5 years ago
 muine-shell.git 2006-03-05 20:56:58 +       5 years ago
 evo-conversation.git    2006-04-02 04:24:51 +       5 years ago
 gtkmm-root.git  2006-04-03 11:09:21 +       5 years ago
 snark.git       2006-04-22 05:27:50 +       4 years, 12 months ago
 jhfarmer.git    2006-04-29 05:22:20 +       4 years, 11 months ago
 blogs-web.git   2006-06-05 19:17:18 +       4 years, 10 months ago
 halloween.git   2006-07-05 19:31:39 +       4 years, 9 months ago
 perl-Gtk2-Recent.git    2006-07-20 09:32:50 +       4 years, 

Re: Modulesets Reorganization

[Tristan Van Berkom]

On Wed, Jun 2, 2010 at 3:14 PM, Murray Cumming murr...@murrayc.com wrote:
 On Wed, 2010-06-02 at 07:52 -0400, Matthias Clasen wrote:
 ...total nightmare...
 ...crush all these efforts...

 I understand that change is uncomfortable and incites fear, but can we
 please lay off the melodramatic voice here ?

 There's three basic facts that lead us to this proposal:

 1. We have an ever-growing set of modules and a constantly expanding
 set of external dependencies.

Sorry to jump in the middle here, I did read the 60 some emails.

Generally I share the feeling of dismay about losing some important
order that we have in GNOME. Also I feel like this coming year might
really be the year for gnome devtools...

The success of the potential features I have in mind for Glade/GTK+
(and hopefully Anjuta) are going to depend vitally on how tightly we can
integrate our developer tools together as a unified chain.

Regardless of my bias in this matter as one who advocated the devtools
suite in the past, I can definitely feel Matthias's pain expressed here
that we are just running low on resources to manage it and as such
maybe the overly large desktop suite is becoming unmanageable.

So, if there are too many apps in the desktop suite (or in other suites)
could we just try to clean it up somehow ?

The process could be something like:
- Release team decides what modules to thow away for GNOME 3.0
- Gruesome exciting technical battles occur on d-d-l as the over-all
  3.0 module inclusion discussion heats up
- Release team and the community would have to help to defend
  the relevance of older modules inclusion in GNOME 3.0 (for modules
  who's maintainers can not be contacted).
- Accepted modules would at least have to build against the new
  stack as a minimum bar for passing (i.e. fully GSEALed GTK+ and
  only apis available in the new platform).

I'm sure that 3.0 is a great time to throw away alot of stuff that
may have become irrelevant over the years. This route would also
hopefully offload a significant part of the work to the community
(each maintainer would have to re-defend their module's significance
in the new GNOME)... allowing the release-team to focus on other
things while the community dukes it out...

This could even be a process with an undefined timeline, 3.0
could just start with an empty applications suite and we could
go on in the usual way [re]adding new applications every 6 months.

Thoughts ?

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

Re: Versioned symbols for 3.0?

[Tristan Van Berkom]

On Tue, May 18, 2010 at 12:30 PM, Patryk Zawadzki pat...@pld-linux.org wrote:
 On Tue, May 18, 2010 at 6:25 PM, Behdad Esfahbod
 behdad.esfah...@gmail.com wrote:
 On 05/18/2010 12:12 PM, Patryk Zawadzki wrote:
 And neither are there plans to start using versioned symbols.
 Good news then.
 Did you misread what Matthias said maybe?

 I assumed it was because of the possible ABI break so I pointed that
 was not the case.

 As for not wanting to use versioned symbols, could you provide more
 information why such a decision was made?

Patryk,
   It looks to me like your script is going to need somebody
to maintain it in the long term (like one of those annoying
extra files you want to shoot the GTK+ build system for, i.e.
gtk.symbols or such).

Do you have a full proposal of how the script's generation
will be automated ?

I'm also not sure I understand from your mail what problem
this patch would address. GTK+ has its own ways of ensuring
ABI/API stability across releases.

Is there anything about versioned symbols that will reduce
the workload of the GTK+ team to ensure binary compatibility
across releases (hopefully without adding yet stricter requirements
to the GTK+ ABI spec) ?

Just some thoughts, ofcourse I also cannot speak for Matthias ;-)

Cheers,
  -Tristan



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

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

Re: Backup

[Tristan Van Berkom]

On Wed, Nov 18, 2009 at 9:30 PM, Michael Terry m...@mterry.name wrote:
 Is GNOME interested in shipping an official backup program?  I (as a
 long-time lurker) haven't ever noticed discussion about it.

 I feel the backup market currently has a lot of almost-there UIs and
 lots of duplicated effort.  That might either mean it's a good time
 for GNOME to step in and polish one, or that it's a good time for
 GNOME to wait for one to 'win'.  I'm not even sure that GNOME cares
 particularly, but it seems like a hole in the market.

Usually what is best is for you to make an official proposal and
explain why you think your module should be included in GNOME
releases - personally I think if we dont have any backup mechanism
I would probably give it a thumbs up.

There is a wiki page I found for you which explains how
we go about including modules in the releases:
   http://live.gnome.org/ReleasePlanning/ModuleProposing

Cheers,
-Tristan



 For full disclosure, I am notably biased in any such discussion as the
 maintainer of one of those almost-there duplicated efforts (an app
 called deja-dup).  But I'd like to think that I'm more interested in a
 good user experience than my own ego.

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

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

Re: Backup

[Tristan Van Berkom]

On Wed, Nov 18, 2009 at 9:47 PM, Michael Terry m...@mterry.name wrote:
 2009/11/18 Tristan Van Berkom t...@gnome.org:
 Usually what is best is for you to make an official proposal and
 explain why you think your module should be included in GNOME
 releases - personally I think if we dont have any backup mechanism
 I would probably give it a thumbs up.

 Fair enough, and I would be willing to go through that process for my
 own pet project, but I was interested in taking the temperature.  My
 own project may not necessarily be the best fit (though of course I
 think it's the best thing since sliced bread).

 I wanted to make a 'fill-in-the-blank backup module proposal'.  Unless
 such a discussion would best take place in the context of a concrete
 module proposal?


Personally I think that would be more effective; your proposal could
very well (as it often does) inspire other proposals - but as its a volunteer
project we really need your input as maintainers, we also cant assume
that maintainers of said modules want to follow the GNOME release cycles.

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

Re: Forcing button icons (Re: Appearance properties)

[Tristan Van Berkom]

On Mon, Nov 16, 2009 at 11:13 AM, Andre Osku Schmidt
andre.osku.schm...@osku.de wrote:
 On Tue, 2009-11-10 at 10:56 +, Bastien Nocera wrote:
 The reasons behind the move have been documented, and explanations given
 on how to get the icons back.

 i remember there was also a hint about the application now needing to
 force an icon on a button. (but cant seem to find the mail)

 could someone point me to this/any document/info/example ?

 im trying to do a play/pause button in glade3 (gtkbuilder), and i just
 cant get any icons shown in a button any more... (nope, didn't get any
 answer on this at glade mailing list)

Are you sure ? that sounds a little ridiculous.

I would just let this whole desktop icons discussion pass without
comment... but something smells wrong...

Just to be sure.. are you declaring your button as a stock
button with stock ids for the play pause buttons ?

... or are you using a button with GtkImage set explicitly
from Glade ?

If it were the former, I can understand - what GTK+ creates
as a stock play button for your application is completely
up to GTK+, if it doesnt come with an icon because of a setting,
that can still be perceived as expectable behaviour.

Please clarify because if it were the latter, it would mean that
the GtkBuilder spec is just invalid for desktops who have this
no icons setting enabled.

FWIW, I really dont care so much about this setting default
being changed in the desktop UI without any announcement,
actually I think this is what we have UI freezes for.

But you cant go break the GtkBuilder spec because you disagree
with a said application author about explicitly placing an image
somewhere in their interface, be it in a button, or wherever.

Sigh, anyway please let me know if this is the case, hopefully
I'm jumping to some conclusion here, and GTK+ only hides
icons that GTK+ created in stock buttons, or some expectable
behavior, that can easily be worked around when customizing
your applications look and feel.

Otherwise my god what a mess we have to deal with...

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

Re: Forcing button icons (Re: Appearance properties)

[Tristan Van Berkom]

On Mon, Nov 16, 2009 at 3:35 PM, Andre Osku Schmidt
andre.osku.schm...@osku.de wrote:
 On Mon, 2009-11-16 at 13:02 -0200, Tristan Van Berkom wrote:
 Just to be sure.. are you declaring your button as a stock
 button with stock ids for the play pause buttons ?

 ... or are you using a button with GtkImage set explicitly
 from Glade ?

 screenshot1(+b).png is with label with optional image
 screenshot2.png is with stock button (this used to work)

 in both cases there is no icon displayed.

 ok, it seems custom button content (hups, didn't notice this option
 before, sorry) seems to work. is this the recommended way ?


I would really rather not, Custom button content should really be for
cases where you need to customize - Originally I put that option
there because there was no way to assign a custom label/image
in a button (Glade-2 did something similar, only it exposed the
option and saved the file with an added GtkHBox/GtkAlignment
to position the label and image properly).

This activity of setting up an HBox/Alignment manually for your
button involves trying to mimic the spacing/alignment of a GtkButton which
could even change in the future, leaving your application looking awkward
with custom buttons grouped along with normal ones.

Well, after reading this:
   http://library.gnome.org/devel/gtk/stable/GtkButton.html#gtk-button-set-image

It seems like the image property of a GtkButton is ignored in the case
of gtk-button-images = FALSE

It seems that I've been happily unaware of this feature in GTK+ for some
years, since I have never encountered a desktop with this setting set
to FALSE, and it seems nobody else ever has either - or I would expect
to have received bug reports in Glade about this confusion by now.

Anyway, I have to say I'm a bit peeved about this policy of stomping on
the _explicitly_user_assigned_ GtkButton:image-widget property for the sake of
some desktop setting, returning a stock button with or without an
image based on
that criteria might have been more acceptable, since the definition of what a
stock button is, is left up to GTK+.

Actually I was really happy to see the addition of the image-widget
and image-position properties, but it seems that that is all just dead-code,
if the image-position/image-widget cant be used with the obscure setting
set to FALSE, and now with the setting default to FALSE, its just useless :(
(what a shame that I even spent time to expose those properties in a nice
way from the Glade GUI).

What am I expected to do, if Im expected to do anything about it at all;
just put some kind of big fat warning in Glade telling the user that image
and image-position properties are only useful on some remaining systems
that dont muck about with this gtk-button-images setting ?

Man the way information flows around here... we are obviously not... a team.

Cheers to a new graveyard in gtkbutton.c...

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

Re: Danger: older bugs are getting squashed with NEEDINFO

[Tristan Van Berkom]

On Fri, Sep 18, 2009 at 8:42 PM, Danielle Madeley
danielle.made...@collabora.co.uk wrote:
 On Fri, 2009-09-18 at 14:28 -0400, Owen Taylor wrote:

 I think for most modules, confirming bugs has usually seemed like a
 waste of of the maintainer's time. Confirming bugs assumes that the
 maintainer isn't looking at bugs until they are confirmed. Once the
 maintainer is already looking at a bug, what's the point of confirming
 it?

 So, while it is indeed an extra click or two to confirm a bug as NEW, is
 it really that much extra time?


Yes,
   I do receive bugmail almost every day on average myself, and if I have any
reason to close the bug, if its invalid or misguided, I will go all the way
to bugzilla.gnome.org and close or correct the bug, which generally represents
at least one bug a week I have to close.

I have been taking care of Glade for ~5 years now; does it represent alot
of time for me to mark one bug as confirmed every day for the next 5 years ?

Yes in fact it can take a big slice out of your own life.

Cheers,
   -Tristan

 Surely most of your time was spent in reading the bug, thinking about
 it, establishing that it was not a duplicate, and then commenting on it
 that confirming it is only one extra mouse click.

 It seems that an UNCONFIRMED bug is likely to move into one of three
 states: NEW, DUPLICATE or NEEDINFO. Sometimes if the fix is easy, you
 might fix it immediately and move it to RESOLVED, but in this case the
 1yr rule clearly does not apply.

 Marking bugs also seems to me to be a polite way of telling the reporter
 that you're aware of her issue and that it does seem to be a legitimate
 bug (especially in the case of GTK+ or another library, this means that
 maybe the reporter will stop trying to work out if it's a bug in her
 code).

 I know that sometimes you can't be sure about a bug immediately, so you
 leave it alone. Maybe we need a system that finds all UNCONFIRMED bugs
 that are 6 months old, or 11 months old and emails a reminder summary to
 the maintainer. That gives the maintainer an opportunity to confirm the
 bugs she now knows/suspects to be real.

 --danni

 --
 Danielle Madeley

 Collabora Ltd., Melbourne, Australia
 http://www.collabora.co.uk/


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

Branching Glade 3.6 line

[Tristan Van Berkom]

Created a stable branch for Glade 3.6 today, the branch is called 'glade-3-6'

I hope to make releases off the 3.6 branch for a while and only use master
for some patches that are not release ready just yet, or patches which may break
string/ui freezes.


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

Glade re-branched stable as gnome-2-28

[Tristan Van Berkom]

After a moments pause, I decided this year was a good time to go
with the GNOME branching scheme.

It will make more sense if Glade does not see a major point release
for quite some time to just branch with the gnome version numbers
(will be easier for me to handle patches which break freezes etc.).

So sorry for the confusion there, the good branch for releasable
Glade with no unexpected freeze breaks for GNOME 2.28 is the
'gnome-2-28' branch.

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

Re: Danger: older bugs are getting squashed with NEEDINFO

[Tristan Van Berkom]

On Fri, Sep 18, 2009 at 7:44 AM, Andre Klapper ak...@gmx.net wrote:
 Am Donnerstag, den 17.09.2009, 15:26 -0400 schrieb Tristan Van Berkom:
 So the bottom line is basically this: if you feel this should
 be the minimum standard of attention that a maintainer must
 absolutely pay to his buglist, then so be it, but I think you are
 being unfair to ask this of me.

 Yes, I expect maintainers should be able to take a look at the incoming
 bug reports at least once in 12 months.
 That is all what this policy is about.
 Nothing else.

I am seriously and sadly insulted now.

Lets recap:
  - There was no effort made at all to contact me about this policy change
  - The policy change you are making directly involves me doing lots
of work now:
   going over hundreds of entries in the buglist one by one, waiting for
   bugzilla.gnome.org to resolve, and manually claim bugs that I
am interested
   in keeping.
  - It also means that receiving bugmail is not good enough, I must from now on
always visit bugzilla.gnome.org and resolve the page to claim the bug, after
having coffee and reading my morning bugmail, and just before I
hurry out the door.

And if this weren't enough, now you are telling me that this policy is all about
me not doing enough work for GNOME, Nothing else.

This is the attitude I expect from people outside of GNOME, people
reporting bugs
whom dont completely understand what it is we go through to deliver GNOME.

To tell you the truth its gotten so bad this year that sometimes I just dont
want to look at the bugmail, for fear of another user telling me:
   how dare you release 3.6 at all if its not perfect, you must fix it for
me immediately or I will declare your work a waste of time.

I need to know that we are together in GNOME, we are supposed to be a team;
please dont tell me that my work is not welcome.

Regards,
   - A tired maintainer.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Danger: older bugs are getting squashed with NEEDINFO

[Tristan Van Berkom]

On Fri, Sep 18, 2009 at 3:20 PM, Andre Klapper ak...@gmx.net wrote:
[...]

 So to summarize, the question boils down to:
 Are you able to take a look at the latest glade3 bug reports once a
 year? If not, glade3 probably has to be excluded from the policy.

I receive bugmail for all bugs and I am quite aware of the state of
the buglist at all times.

Glade will not see another major point release without running through
the buglist (in Glade 3.0, 3.2 and 3.4, we were able to use the list to chose
reasonable blocker bugs and release something more stable, this time
I simply could not do it), basically I need the buglist to be intact whenever
initiative picks up in the future, when Juan and I and hopefully some fresh
blood have motivation and time to run through the blockers.

To answer briefly, no I cannot afford to make any promise to remember
to claim bugs on the list by marking them NEW, rather I need the untended
to list to stay in tact for when we need it.

Please exclude Glade from this policy.

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

Re: Danger: older bugs are getting squashed with NEEDINFO

[Tristan Van Berkom]

On Thu, Sep 17, 2009 at 11:32 AM, C de-Avillez hgg...@ubuntu.com wrote:
[...]
 All,

 We had a chat a few ago on #bugs, and we agree this was rather too
 inclusive: as Tristan points out, and others commented, a confirmed
 (i.e., status NEW) bug is no longer under the care of the bugsquad.

 We have just revised the policy to refer exclusively to:

  * UNCONFIRMED bugs with *no* action in the last year

 We appreciate the feedback, and we would like to keep on having
 more ;-). We invite any interested party to either email us at the
 gnome-bugsquad or to drop by #bugs, voicing their concerns and
 suggestions.

Really, I dont think this is good enough for me.

As for Glade, a bug has always either been UNCONFIRMED or RESOLVED...

Let me put it this way, I have been contributing sporadically
over the last 5 years, the last time I gave the buglist a short
runthrough was in December before releasing Glade 3.6, since then
the buglist has seen alot of activity and I have religiously only
dealt with crasher bugs, it happens often enough that I dont touch
Glade at all for 6 months at a time.

I really dont have time to run after the crasher bugs that I do
run after this year, but I do it cause I wanted to promise at
least something usable that doesnt crash.

Now its like you are telling me that if I dont go through my
whole buglist myself and explicitly mark every unconfirmed
bug as new, that I will lose all the older bugs.

I also feel threatened that if I dont pay attention promptly
to bugmail that bugs will be lost on the long term.

So the bottom line is basically this: if you feel this should
be the minimum standard of attention that a maintainer must
absolutely pay to his buglist, then so be it, but I think you are
being unfair to ask this of me.

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

Danger: older bugs are getting squashed with NEEDINFO

[Tristan Van Berkom]

Guys,
   Im sorry I missed the memo if there was one, I woke up this
morning to a full page of bugmail, deleting valid bugs from the
buglist and throwing them into a NEEDINFO state.

Javier pointed me to a blog post[0] which describes a new policy
to mark bugs as NEEDINFO after one year. I'm raising the flag here
on d-d-l because it concerns us all and I think every maintainer
needs to know this policy is currently in effect.

I know the guys mean well, and I cannot express my gratitude
enough for the efficiency that the bugsquad has for closing
some crash bugs that really do need info.

Suffice it to say; I really need to know this policy is going to stop,
or at least not effect Glade bugs.

Thank you,
 -Tristan

[0]http://blogs.gnome.org/aklapper/2009/08/10/gnome-bugsquad-policy-changes/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Trying a new toolbar style

[Tristan Van Berkom]

On Wed, Jul 29, 2009 at 12:13 PM, Calum Bensoncalum.ben...@sun.com wrote:
[...]
 IIRC Glade's toolbar editor never used to allow developers to set either of
 these properties for any given toolbar button, which didn't help.  I don't
 know if that's changed in the past six months or so -- if not, it would be
 good to make it a priority (assuming it's technically possible), especially
 if we go ahead with the proposed change.

The toolbar style is accessible in the toolbar properties, as optional (with
a checkmark, default unset), its there incase the toolbar widget in question
is not the main application's toolbar and needs to be setup in a custom way.

The is-important property was not available in the customized toolbar editor
before 3.6, but now all the general properties are there for all
items instead
of a few cherry picked properties.

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

Glade: big plans with no hands

[Tristan Van Berkom]

Hello Desktop Hackers,
   Since as usual I was not available to be barking insanities at
palm trees at GUADEC this year, and also since Javier Jardón made
the amazing contribution of redoing glade.gnome.org[0] for us
in a much more simple and modern way, I was motivated draw out a
roadmap[1] to a very achievable future of Glade.

So, why am I writing to you ?
   I felt it was my responsibility to share with you what is really
bearly in our grasp, but I cannot do for GNOME by my self this year.

To tell you the truth, I think we can provide a development environment
for GNOME that really beats other platforms, I think we can achieve the
level of object class integration available in other modern designer tools
I've seen recently (tools with rigid and restricted platforms such as Xcode's
ObjC or Flash Creator's Action Script), except in our case, we can bundle up
any GObject based UI toolkit and custom widget type in a generic way
using our new introspection framework, most of which is already
cross-platform portable code; and on top of it you can use the language
of your choice (am I missing something here or doesnt that beat
everyone ? I'll let someone else figure out why it costs  40MB to install
Glade on OSX, Im sure thats just sillyness though).

So, if you are just curious and want to know what kind of nonsense I would
be blabbering to the palm trees this year had I been at GUADEC, give 'er a
read for the hell of it, if it interests you please comment, if there
is interest
in this kind of thing we can try to organize it and make these items happen,
its not all that hard work in the end, personally I have to step back and
work on bugs and regular features unless others step in.

Thanks all for your attention ;-)

Cheers,
 -Tristan

[0] Many thanks as well to the Nemiver team for letting us use the design,
and Rafael (pachi) Villar Burke for helping us translate it into python.

[1] Ive split the attached document into items on a hypothetical
roadmap for Glade: http://live.gnome.org/Glade/Roadmap


roadmap
Description: Binary data
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[Tristan Van Berkom]

Morning folks ;-)

On Thu, Jul 23, 2009 at 7:08 AM, Andre Klapperak...@gmx.net wrote:
 Am Mittwoch, den 22.07.2009, 14:21 -0400 schrieb Tristan Van Berkom:
 On the other hand, its possible we could do better tracking this stuff,
 is there a l.g.o. page that I can visit that shows me what are the blocker
 bugs in the platform for any given supported system ?

 bugzilla.gnome.org provides a portability keyword and you can set the
 severity of a bug. I don't think that a wikipage is needed.
 If people use these bugzilla options is another question though...

Maybe a query into the GNOME bugzilla database will give
me the impression that GNOME is taking care of my issues
on my system foo, Maybe the same bugzilla query could be
useful to me as a developer`s roadmap to addressing problems
on system foo, but I doubt it.

On the other hand people do file these bugs, so there is
evidence that people do care about the bugs - and somebody
might even be interested in volunteering to track them; so
that we could have a report of the status of the platform on a
given system, it might even be useful for us maintainers to
have a clearer picture of what is going on with our code when
distributed in the real world.

Usually in the past Ive had time to go over the buglist before
release time and nail all the blockers I can, this hasnt been the
case this year, and really as far as I am concerned as a maintainer,
its really pretty and nice to set patch status and stuff like that,
but a bug is unconfirmed until its resolved - thats the summit
of interaction with bugzilla I can realistically afford.

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

Re: GNOME and non-linux platforms (release team please stand up)

[Tristan Van Berkom]

On Wed, Jul 22, 2009 at 7:50 AM, Christian Fredrik Kalager
Schallerura...@gnome.org wrote:
 So I would like to ask the GNOME release team to please come forward
 and clearly state that the future of GNOME is to be a linux desktop
 system as opposed to a desktop system for any Unix-like system.

I dont think anyone wants to do that, as Matthias says we need to
pave the way for a better future, and of course you cant do that without
breaking a few eggs.

On the other hand, its possible we could do better tracking this stuff,
is there a l.g.o. page that I can visit that shows me what are the blocker
bugs in the platform for any given supported system ?

Considering that many people test out the GNOME platform on various
systems already, I wonder how much effort it would cost us to instate
a team responsible for tracking system specific bugs and then publishing
these on a wiki page, pretty much the same way we have translation
teams (a system could possibly only be supported when its blockers
are closed ?, while work is done supporting that system ?)

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

Glade: big plans with no hands

[Tristan Van Berkom]

Hello Desktop Hackers,
  Since as usual I was not available to be barking insanities at
palm trees at GUADEC this year, and also since Javier Jardón made
the amazing contribution of redoing glade.gnome.org[0] for us
in a much more simple and modern way, I was motivated draw out a
roadmap[1] to a very achievable future of Glade.

So, why am I writing to you ?
  I felt it was my responsibility to share with you what is really
bearly in our grasp, but I cannot do for GNOME by my self this year.

To tell you the truth, I think we can provide a development environment
for GNOME that really beats other platforms, I think we can achieve the
level of object class integration available in other modern designer tools
I've seen recently (tools with rigid and restricted platforms such as Xcode's
ObjC or Flash Creator's Action Script), except in our case, we can bundle up
any GObject based UI toolkit and custom widget type in a generic way
using our new introspection framework, most of which is already
cross-platform portable code; and on top of it you can use the language
of your choice (am I missing something here or doesnt that beat
everyone ? I'll let someone else figure out why it costs  40MB to install
Glade on OSX, Im sure thats just sillyness though).

So, if you are just curious and want to know what kind of nonsense I would
be blabbering to the palm trees this year had I been at GUADEC, give 'er a
read for the hell of it, if it interests you please comment, if there
is interest
in this kind of thing we can try to organize it and make these items happen,
its not all that hard work in the end, personally I have to step back and
work on bugs and regular features unless others step in.

Thanks all for your attention ;-)

Cheers,
-Tristan

Note, this might come up as a double-post; classic email/ML mismatch sorry.

[0] Many thanks as well to the Nemiver team for letting us use the design,
and Rafael (pachi) Villar Burke for helping us translate it into python.

[1] Ive split the attached document into items on a hypothetical
roadmap for Glade: http://live.gnome.org/Glade/Roadmap
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Glade: big plans with no hands

[Tristan Van Berkom]

On Tue, Jul 21, 2009 at 4:27 PM, Tristan Van Berkomt...@gnome.org wrote:
 Hello Desktop Hackers,
  Since as usual I was not available to be barking insanities at
 palm trees at GUADEC this year, and also since Javier Jardón made
 the amazing contribution of redoing glade.gnome.org[0] for us
 in a much more simple and modern way, I was motivated draw out a
 roadmap[1] to a very achievable future of Glade.

And ofcourse the attached document is...


roadmap
Description: Binary data
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Glade: big plans with no hands

[Tristan Van Berkom]

On Tue, Jul 21, 2009 at 4:36 PM, Tristan Van Berkomt...@gnome.org wrote:
 On Tue, Jul 21, 2009 at 4:27 PM, Tristan Van Berkomt...@gnome.org wrote:
 Hello Desktop Hackers,
  Since as usual I was not available to be barking insanities at
 palm trees at GUADEC this year, and also since Javier Jardón made
 the amazing contribution of redoing glade.gnome.org[0] for us
 in a much more simple and modern way, I was motivated draw out a
 roadmap[1] to a very achievable future of Glade.

 And ofcourse the attached document is...


Ok with no shame, I present you the same file with a fancy cute .txt
extension
because mail readers can be garbage at most times.

That will be all :)

Cheers,
   -Tristan
1.0 In depth support for custom widgets
===

1.0 Rationale:
==

Currently Glade supports custom widgets by way of letting the user 
introduce a catalog and optional plugin for their custom widgets, 
this has been great to allow integration of customized portions of 
the UI, easing things like integration of a GstVideoSink or MozView 
widget into your application directly, or integration of GTK+ based 
toolkits to be run on a kiosk or a hand held device.

After recently being hired to do some work that happened to involve 
using IDEs I realized that today that just doesnt cut it. 
Simply put: its not important or a challange anymore to integrate a 
mozilla or gstreamer widget into the Glade catalog, people want to 
derive widget classes from thier interface directly and easily, 
not because they want to use an exotic widget... but just because 
they can write more encapsulated and reusable code, presumably better 
code than when using the currently popular technique of connecting 
to signals and playing god with every single element of the UI from 
a main application logic object or workspace.

1.1 Implementation (Glade Catalog Updater using GObject Introspection)
==
The Glade catalog describes a set of GObject types that are to be 
mentioned in the Glade palette, up to date this catalog has always 
been written by hand and updated by hand - now that we have releases 
of gobject-introspection; not only do we have the opportunity of 
automating things like updating targettable versions of newly introduced 
properties and signals and deprecation data (every GTK+ release I have 
to go over the list by hand and mark the deprecated and since data), 
we also have the possibility of generating usable catalog completely 
from GIRs with the restriction that we have usable editors for object 
classes found in the GIR (object classes that do not derive from GtkWidget, 
can only have thier properties and signals setup but not appear in 
the workspace currently).

The Catalog updater should respect a simple api such as:

GladeCatalog *glade_catalog_new_from_gir (const gchar *gir_path,
  GError **error);

and also to update catalogs:

void glade_catalog_update_from_gir (GladeCatalog *catalog,
const gchar *gir_path,
GError **error);

Then we can either compile a program against the core library or just add 
command line options to Glade to create new catalogs or update existing 
catalogs with introspection data.

1.2 Features

Now assuming we have the frameworks layed out discussed in the previous 
section, we can move on to implement fancy features, what we are going 
to want to add, we could go about it a few ways with a few UIs, this is what 
I have in mind right now:

* There will be a clean separation between catalogs loaded at init 
  time by Glade (installed catalogs or catalogs loaded via the 
  GLADE_CATALOG_PATH environment variable).
* When the user edits a project, every object gets a new attribute in 
  the property editor, the Implementing Class field.
* User Implemented classes will be shown in a special portion of the 
  palette and will be a part of the project data.
* A User Implemented class can also optionally be attributed a 
  gir by the User
* If a User Implemented class has introspection data available (i.e. 
  it has a valid gir with the implementing class name listed and 
  parented by the correct ancestor type); then the user can also edit 
  any added properties or signals that were found for that class in the 
GIR. 

1.3 GtkBuilder
==
The way GtkBuilder works we should be able to just work around it, 
although it would be nice to tell GtkBuilder that an Implemented Class 
is assumed to exist and doesnt need to have its catalog version asserted. 


2.0 Splitting out the GTK+ dependency
=

2.1 Rationale
=
Currently we are seeing some interesting toolkits emerging around 
GObject and GNOME, Clutter being the obvious first in 

Re: A not about GtkBuilder conversion

[Tristan Van Berkom]

On Fri, Jul 17, 2009 at 4:40 PM, Matthias
Clasenmatthias.cla...@gmail.com wrote:
 On Fri, Jul 17, 2009 at 4:31 PM, Christian Perschc...@gnome.org wrote:


 Is there any special reason that gtk-builder-convert is unsuitable as a
 build-time tool? If it has bugs, they should simply be fixed.

 Send patches, then. I'd personally rather drop it and force people to
 use glade if it turns out that its existence is used as an excuse for
 this kind of setup...

FWIW, there are a few reasons why I would also rather GTK+ dropped
the script all together, one of them being that I would rather see bugs
reported against Glade for bad conversions than bugs reported against
a convenience script provided by GTK+ when Glade was not ready.

just because Im selfish and I think those bugs belong to me :)

Another, more real reason is that the convert script generates those
UIManager things, and the more the people use the scripts, the more
there will be uimanagers in the world... I'll never hear the end of it ;-)

Anyway, have a nice day ! :)

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

Re: Libglade officially deprecated in favor of GtkBuilder.

[Tristan Van Berkom]

On Mon, May 11, 2009 at 7:33 AM, Xavier Claessens xclae...@gmail.com wrote:
[...]

 Also, when there are GtkMenu defined in a glade file, the
 gtk-builder-convert script will generate a GtkUIManager, but if I open
 that generated file with glade-3, and save again, the ui manager is
 gone... Files saved with glade-3 contains GtkMenuItem widgets but
 loading that file generate GtkAction objects instead...

 Is there a bug open for that?

In Glade you can have menus, and you can have GtkActions;
I used to think it was important but now I dont have a plan to
support GtkUIManager go-betweens from Glade.

From my POV, its a lot less work to support mergability in GTK+ either
as a GtkMergable container interface or a secret lore of GtkBuilder,
than to go ahead and support the dual standard of widget builders
in GTK+ in the long run. (I think this is probably as true for GTK+
maintenance as it is for Glade maintenance).

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

Re: Platform

[Tristan Van Berkom]

On Tue, May 5, 2009 at 3:05 PM, Shaun McCance sha...@gnome.org wrote:
 Hey folks,
[...]
 I would like to get people's opinions on what technologies
 we should be pushing.  I'm interested both in the here and
 now and in what people think the Gnome 3 message should be.


Hi,
   Great time to brain-storm what we have...

I think we should put some emphasis on the devtools suite in
general, a basic we have tools message is called for.

Personally, I always compile gnome relocated by hand, I tried
jhbuild years ago and found it clunky then, Im trying MacPorts
now and find it works awesome, where are we with jhbuild ?
theres also another one out there iirc, cant remember the name...

I would be interested to know, what do we all generally recommend
in terms of a tool/setup to compile gnome ?

... anyway, that should also be part of this message, we have tools
and we can make it easy for you to build...

[...]

 GConf -- Configuration system.  There is talk of a new
 system (see below).  But I think it's obvious that we need
 to be pushing something here.  So as long as GConf is what
 we have, it's what we push.

ditto GConf as dbus below, settings, setting observations and
messaging to into a need-to-have bundle IMO

[...]
 D-Bus -- Inter-process messaging system.  Lots of stuff is
 built on it.  How much do we want to push it directly?

I think we want to push this alot, applications need IPCs,
I would expect a book about developing with GNOME
technologies to include a chapter on IPC/settings and
an observer model (something like GConf I guess, we
have GConf over dbus ? or GSettings now ? sorry for
not knowing all the details ...).

From what I gather... which is a little vague... using some
language bindings you can observe the state of an object
even if its in another process, GObject mapping over dbus
is something I heard of... does that really exist ? if so,
its something people need to hear about..

Anyway IMO we need to have an IPC to use in the platform.

[...]

 libxml2/libxslt -- We put these into the external deps
 a couple release cycles back.  Do we want to continue
 pushing them as part of our platform?


I think its important to have an xml library, what is here
to replace libxml2 ? (maybe I'm missing something...)


[...]

 Libchamplain -- Wicked cool mapping library.  This is
 not something I would have thought of as something we
 need to offer.  But now that it's here, it's a really
 compelling technology with a lot of potential.

+1 for the ooh-aah factor heh

 Clutter -- Are we actively embracing Clutter, or is it
 just something we're OK with people using?  The message
 is unclear.

I am privately embracing Clutter myself, I think its wrong
to consider it as a drop in replacement for GTK+,
right now I would probably recommend Clutter or another
leading canvas like hippo-canvas, to do anything really
fancy in a UI...

 WebKit -- More and more applications are finding uses
 for an embedded HTML rendering widget.  I think we need
 to provide one with a solid API.  WebKit seems to be the
 direction people are heading in.

just pointing out that the next generation mozilla (xulrunner)
will also sport a portable embeddable GTK+ widget... although I
dont really have an opinion about what we should push in
this regard...


Anyway I should get back to work... thanks for starting this
thread, Im also interested to hear what people have to say ;-)

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

Re: On autogenerated ChangeLog

[Tristan Van Berkom]

On Mon, Apr 20, 2009 at 10:20 PM, Cody Russell brats...@gnome.org wrote:
[]
 Yeah, but the thing that sucks about versioned ChangeLogs is
 merging/rebasing your code.  Typically you always leave writing a
 ChangeLog last for this reason, but it just makes so much more sense to
 be able to write your entry when you do your commit.

 If you're posting a branch for review or something, people can read your
 commit logs as well as the code.. but if you post patches for review,
 you probably don't post the ChangeLog with it because it'll get
 clobbered when you have to merge it into the tree.


You always post ChangeLogs diffs with large patches, large patches
generally come to the maintainer in the form of a patch, with a single
changelog entry, the maintainer reviewing a branch doesnt want to
see the revision history of what happened on the branch, or why
you reverted that peice of code thats not actually in the patch
(and never made it into the baseline/trunk).

Now if I can demand that a patch submitter provide the base minimum:
  - A patch that applies to trunk
  - A rich ChangeLog entry that describes what happens in the change

Then why would I waste my time flipping through individual commit
logs ?

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

Re: On autogenerated ChangeLog

[Tristan Van Berkom]

On Tue, Apr 21, 2009 at 12:19 PM, Zeeshan Ali (Khattak)
zee...@gmail.com wrote:
[...]

  Dude, we have moved to git and you are still talking of versioned
 ChangeLog and favoring large patches?

With a tool like git, you should be at least able to generate a single
reviewable patch, large or small, and thats reviewable, yes.

Versioned ChangeLog is a matter of trust, Id personally rather
take care of it and revision it by hand, I didnt ask other people
to do so, this is what I will do though (also, merging changes
in a ChangeLog cannot be difficlult, definitly not more difficult
than merging sources).

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

Re: On autogenerated ChangeLog

[Tristan Van Berkom]

On Tue, Apr 21, 2009 at 4:23 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote:
[...]
  Reminds me of my friend who insists that evolution is nothing more
 than hoax and when I try to educate him, he doesn't want to discuss
 it. :) There are simply two facts to be kept in mind here:

 1. All information in the ChangeLog is redundant.
 2.  Maintaining a ChangeLog only and only realizes otherwise
 inexistent conflicts.

   It is as simple as that.

Sure,
   on the other hand projects with ChangeLogs that are hand-tended
to are, in my personal experience richer than logs of arbitrary commits,
if only by the simple virtue of forcing you to spend time caring for it.

Anyway, lets see what some experiments yield ;-)

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

Re: On autogenerated ChangeLog

[Tristan Van Berkom]

On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote:
[...]
 So, actually, what exactly IS the use case of ChangeLog if there is git
 history on one end and NEWS on the other? Who are the people who need
 more information than NEWS gives, but who would not want to actually
 check out the source tree, and what information, exactly, do they need?

Generally its the tarball that is published and trusted, not the git repository.

The ChangeLog comes with the published tarball like an exported history,
for the use of anyone who receives the tarball (the NEWS is just a quick
resume of what happened in a release).

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

Re: On autogenerated ChangeLog

[Tristan Van Berkom]

On Mon, Apr 20, 2009 at 11:35 AM, Ruben Vermeersch ru...@savanne.be wrote:
 On Mon, 2009-04-20 at 11:20 -0400, Tristan Van Berkom wrote:
 On Mon, Apr 20, 2009 at 10:58 AM, Dan Winship d...@gnome.org wrote:
 [...]
  So, actually, what exactly IS the use case of ChangeLog if there is git
  history on one end and NEWS on the other? Who are the people who need
  more information than NEWS gives, but who would not want to actually
  check out the source tree, and what information, exactly, do they need?

 Generally its the tarball that is published and trusted, not the git 
 repository.

 Given that tags can be signed in Git, shouldn't it be about time that we
 move to a more modern way of trust, one that maintains a 1:1 mapping
 between changelog and changes?


For someone that maintains a module, how you manage your
ChangeLog and how much you trust your current revisioning system
to do what you expect is your business, I personally feel safer
populating my revision history with ChangeLog entries and not
the other way around, but thats my perogative and besides the point here.

On the other hand, for someone who receives your release, i.e.
your tarball, they dont want to know how you manage your ChangeLog
or your revision history, without forcing them to understand git,
or understand branching schemes in GNOME, they still deserve
an exported ChangeLog (which is why I answer to Dan, this is
why we do at least need a ChangeLog, generated or otherwise).

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

Re: On autogenerated ChangeLog

[Tristan Van Berkom]

On Sat, Apr 18, 2009 at 9:54 PM, Behdad Esfahbod beh...@behdad.org wrote:
 Hey,

 I first wrote Makefile.am magic for Pango to generate ChangeLog from git on
 demand.  Those macros have been modified and gathered in
 http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for make
 dist.  I wonder what people actually want to have, so I can work on
 canonical macros to copy across projects (and eventually find a better way
 to distribute).  Pros and cons:


Personally, I prefer maintaining an actual revisioned ChangeLog file, simply
because I like having the ChangeLog as a part of the project data, revisioning
tools come and go, projects get exported and imported, but the ChangeLog
always remains in the repository or published tarball.

... I'd be tempted though to somehow preset the commit message
of a changeset to be the current diffs against the ChangeLog (i.e.
when prompted with the editor), that would save me a step of getting
the information from ChangeLog into the commit message...

Cheers,
 -Tristan

 Pros for generating ChangeLog proper:

  - No need to have a placeholder ChangeLog, nor need to pass foreign to
 automake

  - You can make ChangeLog and inspect it before it goes into the tarball

 Cons:

  - Have to modify autogen.sh to create an empty ChangeLog, or pass the
 foreign flag to automake


 Humm, no idea about pros and cons of the other approach.  So, what do people
 think?

 Cheers,
 behdad

 PS.  If you need any autotools hacking, related to git or not, feel free to
 ping me.  I'd always be happy to help.
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list

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

Re: quo vadis, docs

[Tristan Van Berkom]

On Mon, Feb 9, 2009 at 10:36 AM, Luis Villa l...@tieguy.org wrote:
[...]
 Dan Winship wrote:
 Dave Neary wrote:
 - Should we just ditch the docs and declare the UI self-explanatory ?
 Definitely not.

 Why not?

 Because (a) the docs are pretty good, merely outdated,

 That statement just can't be true. Outdated docs not only don't help
 users, they *actively confuse* users. If they don't help users, and
 actively confuse, they are not 'pretty good' in any meaningful sense
 of the word, since one measures good docs by whether or not they help
 users, not by whether they helped users c. GNOME 2.2, or by how
 comprehensive the confusing coverage is.

What an interesting debate, I will have to drop my 2 cents in the direction
of just letting people know where the docs are useless and confusing and
hope people will not distribute those outdated docs.

Yeah, *some* GNOME projects might have been gifted at one point by
the interest of some corporation writing docs for them - I seriously doubt
that most projects received that attention - from my perspective:
- Glade user docs were ported from Glade 2, and to this day are still in
  a prototype state.
- I dont have time to update the website (it was written in raw html,
  and a real pain to update the news just for a trivial release), I already
  made damn sure there was good API reference documentation for
  the libgladeui core - theres no way I'll find time to write cute user
  docs with screen shots.
- There is no way I could realistically say that one day someone
will write docs
  for Glade - its a promise we simply cant make.

 and (b) it would
 send a terrible message about the priorities of the project.

 Depends on how you did it. The message could be 'our software is so
 easy to use it doesn't need docs', which is a pretty damn good
 priority. Or the message could be 'we know our limits.' Or it could be
 'we don't want to insult our users by pretending the docs, in their
 current state, are useful.'

a.) first of all have to agree that pushing outdated user docs as official is
sending a painfully bad message about our internal management (if the docs
are so out of date, why wouldnt all my 'stable' apps crash ?)

and more importantly b.) We cannot allow ourselves to make decisions about
our infrastructure based on what message it sends - at the end of the day we
should only be concerned with what message is sent by GNOME 2.26

Anyway, I'm sure we have great people in our doc team, and if those people
had time, or 10 more people then things would be great - in the meantime
maybe we can at least mark all the outdated documentation as old and obsolete
and at least start an initiative to write user docs for GNOME
applications and the
desktop.

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

Re: quo vadis, docs

[Tristan Van Berkom]

On Mon, Feb 9, 2009 at 11:52 AM, Luis Villa l...@tieguy.org wrote:
[...]

 Amen. I've often felt developers should be required to document their
 own UI changes :) Heck, simply asking 'what does this dialog mean'
 would be useful a lot of the time...[1]

Luis do you write software ?

Not that its important that you do, but just to clarify the issue;
simply asking what does this dialog mean in the long run usually means:
   - Take a screen shot of the dialog
   - Open the html or whatever the docs are written in
   - take time to format the docs/text/images in a readable way
   - take time to properly describe your feature or functionality
   - take time to write a healthy ChangeLog entry for your
 docs commit.

I am going to generalize here and guess that if you are not GTK+,
and you are not epiphany or gimp - then its pretty much safe to
say you are a one man team plus the occasional extra guy, or
a few randomly submitted patches (which often generate more work
for the maintainer than bugs fixed or features implemented) - you can hardly
find time to update the website when you make a release, much less
spend time writing user docs.

Sorry I'm starting to run my trap here, I tend to take it to heart
when time and time again I find our manpower is seriously overestimated
(which must also be a good thing, if the mere handful of dudes we are
hacking code managed to accomplish so much and seem like
such a big team).

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

Re: 2.26 will use GTK+ 2.16

[Tristan Van Berkom]

On Mon, Dec 22, 2008 at 2:17 PM, Diego Escalante Urrelo
die...@gnome.org wrote:
 On 12/22/08, Frederic Peters fpet...@gnome.org wrote:
 Hello beloved hackers!

  The GTK+ team decided for a short 2.16 cycle, so it can already be
  used for GNOME 2.26; this is great news and something many developers
  wanted, as there are already interesting features:

   - new status icon api
   - using threads for page rendering when printing
   - the new invisible char handling


 Also:
  - GtkEntry can show progress (think olpc's or safari's url bar)
  - GtkEntry can now show icons, think libsexy's widget


Dont forget natively buildable menus, pretty much closing any
remaining blockers on supporting builder format (GtkBuilder), also
the ability to parse pango attributes on GtkLabel directly (allowing
translatable strings without markup to have fancy pango sugar).

Nice, I'm going to do my best to pump out some nice editing magic
for the new GtkEntry features from Glade, and I'll see if I cant squeeze in
some pango attribute support on other widgets than just label
(I guess we can set attributes on entries too... not sure what else...)

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

Glade 3.5.3 released

[Tristan Van Berkom]

Hi,
  this is a follow up release to the last big release a few days ago with
a few cleanups for the gnome development release, please refer to the
last releases news[1] for the real juice.

I also thought I'd cc d-d-l in this case since we have alot alot
of new stuff and havent seen a release in over 6 months...


What is Glade ?
===
Glade is a RAD tool to enable quick  easy development of user interfaces
for the Gtk+ toolkit and the GNOME desktop environment.
The user interfaces designed in Glade are stored in XML format,
enabling easy integration with external tools.
In particular libglade and GTK+'s new GtkBuilder can load the XML files and
create the interfaces at runtime. The DTD for the XML files is available at
http://glade.gnome.org/glade-2.0.dtd.

===
Glade 3.5.4
===
- Added short readable versions of new enum/flag values
- Fixed a crasher in the store editor
- Focus always stays in the store editor when editing cells get 
cancelled
- Better resizing in editors (property names/warnings expand, inputs 
dont)
- Cleaned up gtk+ includes (Maxim Ermilov - bug 561260)
- Some code now available under LGPL


Where can I get it ?

 http://download.gnome.org/sources/glade3/3.5/

For more information consult our home page at http://glade.gnome.org/

Enjoy,
   - The Glade team

[1]http://ftp.gnome.org/pub/GNOME/sources/glade3/3.5/glade3-3.5.3.news
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Glade 3.5.4 released

[Tristan Van Berkom]

[ reposting to lists I am not a member of with my other email address :-/ ]

Hi,
 this is a follow up release to the last big release a few days ago with
a few cleanups for the gnome development release, please refer to the
last releases news[1] for the real juice.

I also thought I'd cc d-d-l in this case since we have alot alot
of new stuff and havent seen a release in over 6 months...


What is Glade ?
===
Glade is a RAD tool to enable quick  easy development of user interfaces
for the Gtk+ toolkit and the GNOME desktop environment.
The user interfaces designed in Glade are stored in XML format,
enabling easy integration with external tools.
In particular libglade and GTK+'s new GtkBuilder can load the XML files and
create the interfaces at runtime. The DTD for the XML files is available at
http://glade.gnome.org/glade-2.0.dtd.

===
Glade 3.5.4
===
   - Added short readable versions of new enum/flag values
   - Fixed a crasher in the store editor
   - Focus always stays in the store editor when editing cells get cancelled
   - Better resizing in editors (property names/warnings expand,
inputs dont)
   - Cleaned up gtk+ includes (Maxim Ermilov - bug 561260)
   - Some code now available under LGPL


Where can I get it ?

 http://download.gnome.org/sources/glade3/3.5/

For more information consult our home page at http://glade.gnome.org/

Enjoy,
  - The Glade team

[1]http://ftp.gnome.org/pub/GNOME/sources/glade3/3.5/glade3-3.5.3.news
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Reduced Bugzilla functionality for 6+ months -- acceptable?

[Tristan Van Berkom]

On Thu, Dec 4, 2008 at 11:00 AM, Olav Vitters [EMAIL PROTECTED] wrote:
 The GNOME Bugzilla is still using 2.20. Current stable upstream is at
 3.2. The stable version has several benefits, but overall:
  * no crappy table locking, while still allowing full text indexing
   (table locking causes many performance problems)

GNOME bugzilla takes a heavy load on its shoulders, and is often slow,
I imagine reduced or eliminated locking of DB tables will improve that
significantly,
enough to sell me on the whole thing.

Do we lose patch review status info temporarily with the attachment table
layout modifications ? or is that just a cosmetic/usability issue ?

Granted we have everything we need to work and are only
temporarily discomforted, you deffinitly have +1 from me.

Cheers,
-Tristan

  * Upstream supported XMLRPC (not perfect, but various things can be
   done, see WebService stuff at http://www.bugzilla.org/docs/3.2/en/html/api/)
  * Supported by upstream (security bugs)
  * bla bla see
   http://www.bugzilla.org/releases/3.2/new-features.html
   http://www.bugzilla.org/releases/3.0/new-features.html
   http://www.bugzilla.org/releases/2.22/new-features.html

 There is a proposal to upgrade the GNOME Bugzilla by:
  * having an external party do it (not me)
  * deliver the functionality in multiple stages (hard requirement)
   -- Means that not all the current functionality will be available!

 For that the proposal is that the following is not part of the initial
 upgraded bgo:
  * The points system
  * index.cgi UI mods
  * Making a new favicon
  * The infomessages on show_bug.cgi
  * Layout modifications for attachment table and the login box
  * duplicates.cgi modifications
  * Fixing the comment headers
  * Patch and keyword emblems
  * delete-keyword.pl, mass-reassign-bugs.pl, and year-end-stats.pl
  * describeuser.cgi

 Possibly even:

  * Canned responses (this would be a priority immediately after
 the upgrade)
   (the javascript stuff to say things are a dupe etc)
  * show_bug.cgi UI re-ordering  float-right box
  * simple-bug-guide.cgi
  * Grouping products in a dl by classification when displayed
  * Asking people if they've provided the NEEDINFO info.
  * Boogle enhancements to QuickSearch (or maybe just implement
 the most important ones first and theno implement the rest later?)
   -- this is the GNOME specific 'simple search'


 Is above acceptable?


 IMO I find the following very important:
  * attachment table
  * describeuser.cgi
  * canned responses
  * Boogle

 but please focus on what you use: Is the reduced functionality trade-off
 acceptable if in the end we get a newer Bugzilla and the feature back?
 Note that likely some things will work in different ways etc.

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

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

Re: Cleanup tasks

[Tristan Van Berkom]

On Mon, Nov 3, 2008 at 12:26 PM, Matthias Clasen
[EMAIL PROTECTED] wrote:
 During a recent release team meeting, the idea was brought up that we
 should put forward some non-mandatory cleanup tasks that we'd like
 to see some progress on during this development cycle. Because,
 everybody loves to clean up, right ?!

 Completing these cleanup tasks for 2.26 will make the move to GTK+ 3
 at some point in the future much easier, and it will give us a leaner,
 cleaner codebase.

Its a somewhat related topic, people have been asking me what widgets
they should be using and which ones they should stay away from because
they are planning libglade -- GtkBuilder migrations.

The answer on my part has been easy until they asked me, what will
I use instead of GnomeCanvas ?

afaik there is no blessed canvas for gtk+ as of yet, and I think that
GnomeCanvas functionality extends beyond GtkDrawingArea, so are we
looking at an immediate future of people using GnomeCanvas as
GtkBuildable ?

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

Re: Preserve glade files when switching from libglade to gtkbuilder format

[Tristan Van Berkom]

On Tue, Oct 14, 2008 at 7:06 AM, Fernando Herrera [EMAIL PROTECTED] wrote:
 Hi,

 On Tue, Oct 14, 2008 at 12:54 PM, Christian Persch [EMAIL PROTECTED] wrote:

 However, glade-3 is still not working on all features in the gtkbuilder
 format (e.g. nautilus' and gnome-terminal's .ui files break badly when
 edited with glade-3).

Ok,
  I know we're due for a devel snapshot, I promise you one as soon
as I get liststore stable (liststores are a base requirement as
they are needed to convert combo boxes).

As of about 2 weeks ago I'm confindant that we have everything save
GtkMenus in gtk-builder-convert replicated in glade's conversion routine.
So any case specific bug reports on glade-3 edited ui files are really
appriciated at this time...

Menus:
  I have these patches[1] against gtk+ that are pretty straight
forward and solve the problem of loading natively built GtkMenu
hierarchies, they need a final tweak to solve the
accelerator--toplevel window problem and a resubmission, needless
to say I just havent found or taken the time yet - this also
means we cant use native menus until the next major gtk+ release.

GtkUIManagers:
  These could be very straight forward to write, we wouldnt have
the uimanagers build the menus and toolbars in runtime, only in
a possible future demo window, I'd say it represents about a
week of work including the learning curve (2 or 3 real nights hacking
for myself).


 What about using gazpacho?


Does that work out of the box ? then be my guest, but I have
to say this time around it pains me a little to see so many
people struggling with this conversion script problem, it looks
like alot of energy spent... when all I really need is for one or
two of you to really bleed with me on the hackfield for a week,
and case closed.

Cheers,
  -Tristan

[1] http://bugzilla.gnome.org/show_bug.cgi?id=527672
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Glade is late

[Tristan Van Berkom]

Hello fellow hackers,
Simply put, this is a call for aid. Normally I obviously wouldnt
try to explicitly solicit help this way (and I've never been good with
project PR anyway) but in light of GTK+'s progress over recent times
I feel its my responsibility here to make a statement because Glade is
bigger than my own personal interest and hobby, its a part of GNOME
and all our interests.

First let me explain my vision - I believe that Glade can and should
play a major role in all the porting work that may be done in the near
future in light of the new GtkBuilder api, and now, work on GTK+3.0
(since 3.0 is announced to be api compatible with GTK+2.0 minus deprecations
we can probably expect to see people to be writing 3.0 savy code from now on).
What we plan to offer is a tool that will allow you to load  save your
Glade file in either format and also chose what major and minor GTK+
version you are targeting, so that you know that every widget, property
and signal is available in that version and even know if its deprecated.
(ofcourse we also want fancy treeview editors and lots of powerful new
features, but thats already obvious ;-)).

That vision may seem far fetched, but the few of you who have Glade trunk
know that we already have those features ! its running smoothly but there
are still bugs, tedious detail bugs, plus we dont have normal menus loading
in GTK+ yet using GtkBuilder - nor do we have a tedious little GtkUIManager
object editor - so no menus in the new format yet.

I don't have my head wrapped around all the blockers right now but suffice
it to say were not going to have Glade 3.6 ready for GNOME 2.24, for this,
we are sorry. We're just a team of 2 occasional developers (typically we
go on binges every once and a while and get things done that way).

So with that, I think the bottom line is: I think this is a critical
time for Glade
in GNOME, because I think the afore mentioned features can significantly
help encourage developers to use new GTK+, and help ease the pain of porting
GTK+ apps all around. If you agree - then you are invited to help us
make it happen.

Thank you all for your attention.

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

Re: Translator credits (to maintainers)

[Tristan Van Berkom]

On Thu, Jul 17, 2008 at 3:09 PM, Jonh Wendell [EMAIL PROTECTED] wrote:
 Hi, folks.

 This is just a warning about translator names in NEWS file:

 You should get the translator name from the Last Translator field in
 the .po file, not from po/Changelog. Sometimes the translator is not the
 same person as who commits the file.

Hi, first my apologies, I've always pulled translator names from
po/Changelog ;-)

 There is even a script to help us on this job:
 http://svn.gnome.org/viewcvs/releng/trunk/single_module/tools/list_translators.sh?view=markup

Thats really cool and I wish I knew about it before, hey I wonder if -
it would make any
difference to maintainers (I think it might for me), if this script
were available in the
gnome-common module sitting beside gnome-autogen.sh
(gnome-translator-credits.sh ?)

Frankly, I rebuild my gnome sandbox from scratch often enough, and reinstall my
OS probably once each gnome release cycle - I dont see how I could possibly
remember the location of that script.

Just a suggestion, I may be the only one .. and I'll be happy to just
copy the script
into my own module and be on my way ;-)

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

Re: Recommended way to cleanup your own gobject types in a desktop app (finalize and/or dispose)

[Tristan Van Berkom]

On Sun, Mar 23, 2008 at 8:00 AM, Ali Sabil [EMAIL PROTECTED] wrote:
 Hello,

  iirc, the GObject documentation states that dispose may be called
  multiple times,
  and the object must still be usable even after dispose is called, so
  freeing memory
  in dispose is wrong, even with locks.

  Actually both dispose and finalize are needed if your object hold
  references to other
  objects, and has allocated memory during its init. The dispose will be 
 called as
  many times as necessary to remove the references to other object (and thus 
 break
  possible cycles), and when the object's ref count drop to 0, the
  finalize is called to
  completely free any resource held by the object.

Not to contradict, because you DID just outline the proper way of
freeing up your GObject.

Just pointing out that, in all my personal experience Ive never had
to write a dispose handler to break cyclic references, usually if your
app is well structured and you have a good concept of ownership,
these cyclic situations should remain a myth (in the few cases
I have actually written one, it was only because the source was
open and to set a better example for those who might read the code).

Im sure, deep in the complexities of gtk+, and the possible ways
people can use/misuse it, dispose handlers are needed.

I would actually be interested if someone would show me an example
of where its precisely needed in gtk+ ;-)

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