Re: GNOME goal candidates

2017-04-14 Thread Sébastien Wilmet 
On Wed, Mar 01, 2017 at 10:31:24AM +, Philip Withnall wrote:
> On Tue, 2017-02-28 at 17:12 -0600, Michael Catanzaro wrote:
> > GtkBuilder validation looks like more gook to add to our Automake
> > files, when we really want less gook there. Even if it's only a small
> > amount of code, I'd rather it be implemented as an autoconf archive
> > macro and re-proposed. I'm not sure if it's really necessary anymore
> > anyway, since GTK+ almost always warns about XML problems at runtime,
> > right?
> 
> Who cares how much ‘gook’ we have in the build system? What we care
> about is how useful it is. The value of adding validation for files at
> build time is that it catches errors *at build time*, not at runtime if
> a certain code path is taken. For GtkBuilder files, the usefulness of
> this depends entirely on the project — if the project uses a single
> massive .ui file, any errors in that are going to be caught when the
> program is started. But if a project uses a separate .ui file for each
> dialogue, you have to test every dialogue in the program at runtime
> before you know all the .ui files are valid.
> 
> This is a textbook example of the tradeoff between build time and
> runtime testing.
> 
> The example rules given on the goal page are not the tidiest. There is
> a simpler way to do this:
> 
> https://git.gnome.org/browse/hitori/tree/Makefile.am#n95 (four lines)
> https://git.gnome.org/browse/hitori/tree/configure.ac#n51 (two lines)
> 
> I don’t think that needs to be shipped out to an autoconf-archive macro
> — including such a macro in a project would be two lines at the least,
> so it would save a total of four lines. This one is better off being
> cargo-culted.

So the general consensus was to approve this GNOME goal:
https://wiki.gnome.org/Initiatives/GnomeGoals/ValidateGtkBuilderFiles

provided that someone updates the instructions and the list of modules.

For the instructions, hitori currently does this: (with more
future-proof links):
https://git.gnome.org/browse/hitori/tree/Makefile.am?h=3.22.2#n95
https://git.gnome.org/browse/hitori/tree/configure.ac?h=3.22.2#n51

There is now also the gtk-builder-tool utility program (or
gtk4-builder-tool for GTK+ 4), which can also validate GtkBuilder files.
With gtk-builder-tool I wonder if xmllint is still necessary.

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

Re: GNOME goal candidates

2017-03-02 Thread Sébastien Wilmet 
On Thu, Mar 02, 2017 at 08:58:26AM -0600, Michael Catanzaro wrote:
> On Thu, 2017-03-02 at 12:36 +0100, Sébastien Wilmet wrote:
> > I can take ownership of:
> > https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage
> > 
> > I will update the description.
> 
> OK. Go ahead and move it to the approved list goals list once you've
> updated the list of modules, since it's been discussed at length now on
> the list. We obviously don't have a super formal process for this, at
> least not that I'm aware of.

Done! One less goal in the candidates category.

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

Re: GNOME goal candidates

2017-03-02 Thread Michael Catanzaro 
On Thu, 2017-03-02 at 12:36 +0100, Sébastien Wilmet wrote:
> I can take ownership of:
> https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage
> 
> I will update the description.

OK. Go ahead and move it to the approved list goals list once you've
updated the list of modules, since it's been discussed at length now on
the list. We obviously don't have a super formal process for this, at
least not that I'm aware of.

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

Re: GNOME goal candidates

2017-03-02 Thread Sébastien Wilmet 
On Wed, Mar 01, 2017 at 03:12:17PM -0600, Michael Catanzaro wrote:
> On Wed, 2017-03-01 at 14:22 -0500, Carlos Soriano via desktop-devel-
> list wrote:
> > I think installed test etc it's not going to happen or be maintained
> > if we don't enable coverage with it too. I think that's the actual
> > trick that will keep us up with the initiative.
> > 
> > So I would go with both since the start, and together.
> 
> OK then. Does anybody want to take ownership of this? It'd require
> updating the goal pages to match the new best practices, maybe merging
> them together, and updating the list of affected modules.

I can take ownership of:
https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage

I will update the description.

For the list of modules, I can merge the current list with the list
from:
https://wiki.gnome.org/Initiatives/GnomeGoals/Template

I'll not actively see if more modules can be marked as done, nor file
bugs for every module, that's a task for each individual module
maintainer.

I'm not sure it is a good idea to merge the two goals (installed tests +
code coverage). When filing a bug in bugzilla, it should cover only one
task. The installed tests make sense only if it'll actually be used, for
example by GNOME Continuous. I don't know if all modules listed in the
Template page are built by GNOME Continuous.

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

Re: GNOME goal candidates

2017-03-01 Thread Michael Catanzaro 
On Wed, 2017-03-01 at 14:22 -0500, Carlos Soriano via desktop-devel-
list wrote:
> I think installed test etc it's not going to happen or be maintained
> if we don't enable coverage with it too. I think that's the actual
> trick that will keep us up with the initiative.
> 
> So I would go with both since the start, and together.
> 
> Best regards,
> Carlos Soriano

OK then. Does anybody want to take ownership of this? It'd require
updating the goal pages to match the new best practices, maybe merging
them together, and updating the list of affected modules.

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

Re: GNOME goal candidates

2017-03-01 Thread Carlos Soriano via desktop-devel-list 
I think installed test etc it's not going to happen or be maintained if we 
don't enable coverage with it too. I think that's the actual trick that will 
keep us up with the initiative.

So I would go with both since the start, and together.



Best regards,
Carlos Soriano
 Original Message 

Subject: Re: GNOME goal candidates
Local Time: March 1, 2017 8:05 PM
UTC Time: March 1, 2017 7:05 PM
From: swil...@gnome.org
To: desktop-devel-list@gnome.org

On Wed, Mar 01, 2017 at 08:31:24AM -0600, Michael Catanzaro wrote:
> OK, you all have changed my mind. I guess installed tests should be a
> goal.
>
> Do we want to do this for coverage as well...?

https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage

The page needs to be updated for AX_CODE_COVERAGE. But I would keep it,
at least to have a list of best-practices as Emmanuele said.

--
Sébastien
___
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: GNOME goal candidates

2017-03-01 Thread Sébastien Wilmet 
On Wed, Mar 01, 2017 at 08:31:24AM -0600, Michael Catanzaro wrote:
> OK, you all have changed my mind. I guess installed tests should be a
> goal.
> 
> Do we want to do this for coverage as well...?

https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage

The page needs to be updated for AX_CODE_COVERAGE. But I would keep it,
at least to have a list of best-practices as Emmanuele said.

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

Re: GNOME goal candidates

2017-03-01 Thread Michael Catanzaro 
OK, you all have changed my mind. I guess installed tests should be a
goal.

Do we want to do this for coverage as well...?
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal candidates

2017-03-01 Thread Sébastien Wilmet 
On Wed, Mar 01, 2017 at 07:26:19AM -0600, Michael Catanzaro wrote:
> This is the other thing. The goals should be achievable, something we
> can look at in a year or two and say "all apps meet the goal" and close
> it, not a longstanding epic that stays open forever. The installed
> tests and coverage goals do not really qualify. Even though more tests
> are definitely desirable, I don't think it's reasonable to use the
> GNOME Goals project for this, even if it would be nice to see as many
> projects as possible adopting it.
> 
> Maybe I am being too negative here. It does seem odd to say that doing
> something desirable should not be a goal. But a longstanding pie-in-
> the-sky project is very different from existing goals. Switching to
> g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks that
> all apps should be able to accomplish easily. Adding a comprehensive
> testsuite, not so much. And adding just one or two installed tests,
> while a good starting point, is not very useful on its own.

Replacing a menubar + toolbar to a GtkHeaderBar can be a major
undertaking for large applications (for example for IDEs, Evolution,
etc). It's not always a "quick task", especially if the application
needs to move away from GtkUIManager/GtkAction.

The GNOME goals about unit tests don't require to write a comprehensive
test suite. If there is just one small unit test, it's already valuable,
because the module will have the infrastructure to write unit tests, so
chances are that more unit tests will be written in the future. And with
code coverage support, it gives more motivation to write more unit
tests.

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

Re: GNOME goal candidates

2017-03-01 Thread Philip Withnall 
On Wed, 2017-03-01 at 13:40 +, Emmanuele Bassi wrote:
> On 1 March 2017 at 13:26, Michael Catanzaro 
> wrote:
> > It sounds like most everyone else supports installed tests. OK,
> > then.
> > 
> > On Wed, 2017-03-01 at 10:22 +, Philip Withnall wrote:
> > > I agree that developers need to be engaged with adding more unit
> > > tests
> > > and code coverage if such a goal is to be useful. I wonder if
> > > making
> > > it
> > > a goal would kick-start some people to do that? I don’t think we
> > > can
> > > ever expect the majority of maintainers to care about (or have
> > > enough
> > > time to care about) code coverage and unit testing — but GNOME
> > > goals
> > > have been useful catalysts in the past. I guess a suitably well
> > > publicised and tutorialised blog post would work just as well
> > > though.
> > > 
> > 
> > This is the other thing. The goals should be achievable, something
> > we
> > can look at in a year or two and say "all apps meet the goal" and
> > close
> > it, not a longstanding epic that stays open forever. The installed
> > tests and coverage goals do not really qualify. Even though more
> > tests
> > are definitely desirable, I don't think it's reasonable to use the
> > GNOME Goals project for this, even if it would be nice to see as
> > many
> > projects as possible adopting it.
> > 
> > Maybe I am being too negative here. It does seem odd to say that
> > doing
> > something desirable should not be a goal. But a longstanding pie-
> > in-
> > the-sky project is very different from existing goals. Switching to
> > g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks
> > that
> > all apps should be able to accomplish easily. Adding a
> > comprehensive
> > testsuite, not so much. And adding just one or two installed tests,
> > while a good starting point, is not very useful on its own.
> 
> At some point, Gnome Goals become "best practices for GNOME projects"
> — especially because new projects should conform to these goals by
> default.
> 
> I'm all for taking all the present and past GNOME Goals pages on the
> wiki and turning them into "Best Practices for GNOME projects" —
> where
> applicable. Additionally, every cycle we can evaluate where we are on
> the completion of every goal, and if the completion rate passes a
> certain threshold we simply close the goal and move the page to the
> "best practices" section.

+1, although I think such documentation should go in gnome-devel-docs,
rather than on the wiki. Cross-referencing it and finding it is a lot
easier in gnome-devel-docs.

Philip

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal candidates

2017-03-01 Thread Emmanuele Bassi 
On 1 March 2017 at 13:26, Michael Catanzaro  wrote:
> It sounds like most everyone else supports installed tests. OK, then.
>
> On Wed, 2017-03-01 at 10:22 +, Philip Withnall wrote:
>> I agree that developers need to be engaged with adding more unit
>> tests
>> and code coverage if such a goal is to be useful. I wonder if making
>> it
>> a goal would kick-start some people to do that? I don’t think we can
>> ever expect the majority of maintainers to care about (or have enough
>> time to care about) code coverage and unit testing — but GNOME goals
>> have been useful catalysts in the past. I guess a suitably well
>> publicised and tutorialised blog post would work just as well though.
>>
>
> This is the other thing. The goals should be achievable, something we
> can look at in a year or two and say "all apps meet the goal" and close
> it, not a longstanding epic that stays open forever. The installed
> tests and coverage goals do not really qualify. Even though more tests
> are definitely desirable, I don't think it's reasonable to use the
> GNOME Goals project for this, even if it would be nice to see as many
> projects as possible adopting it.
>
> Maybe I am being too negative here. It does seem odd to say that doing
> something desirable should not be a goal. But a longstanding pie-in-
> the-sky project is very different from existing goals. Switching to
> g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks that
> all apps should be able to accomplish easily. Adding a comprehensive
> testsuite, not so much. And adding just one or two installed tests,
> while a good starting point, is not very useful on its own.

At some point, Gnome Goals become "best practices for GNOME projects"
— especially because new projects should conform to these goals by
default.

I'm all for taking all the present and past GNOME Goals pages on the
wiki and turning them into "Best Practices for GNOME projects" — where
applicable. Additionally, every cycle we can evaluate where we are on
the completion of every goal, and if the completion rate passes a
certain threshold we simply close the goal and move the page to the
"best practices" section.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal candidates

2017-03-01 Thread Philip Withnall 
On Wed, 2017-03-01 at 07:26 -0600, Michael Catanzaro wrote:
> It sounds like most everyone else supports installed tests. OK, then.
> 
> On Wed, 2017-03-01 at 10:22 +, Philip Withnall wrote:
> > I agree that developers need to be engaged with adding more unit
> > tests
> > and code coverage if such a goal is to be useful. I wonder if
> > making
> > it
> > a goal would kick-start some people to do that? I don’t think we
> > can
> > ever expect the majority of maintainers to care about (or have
> > enough
> > time to care about) code coverage and unit testing — but GNOME
> > goals
> > have been useful catalysts in the past. I guess a suitably well
> > publicised and tutorialised blog post would work just as well
> > though.
> > 
> 
> This is the other thing. The goals should be achievable, something we
> can look at in a year or two and say "all apps meet the goal" and
> close
> it, not a longstanding epic that stays open forever. The installed
> tests and coverage goals do not really qualify. Even though more
> tests
> are definitely desirable, I don't think it's reasonable to use the
> GNOME Goals project for this, even if it would be nice to see as many
> projects as possible adopting it.
> 
> Maybe I am being too negative here. It does seem odd to say that
> doing
> something desirable should not be a goal. But a longstanding pie-in-
> the-sky project is very different from existing goals. Switching to
> g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks that
> all apps should be able to accomplish easily. Adding a comprehensive
> testsuite, not so much. And adding just one or two installed tests,
> while a good starting point, is not very useful on its own.

Porting a module to installed-tests is a fairly quick job. I’m not
suggesting the goal includes “write more tests” in its description. If
a module doesn’t have any tests already, then it doesn’t need porting
to the installed-tests infrastructure (instead, the infrastructure
should be added when tests *are* added to that module in future). The
advantage of porting everything to the infrastructure now is that all
new tests are then installed-tests by default, and hence appear in
Continuous, etc.

Philip

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal candidates

2017-03-01 Thread Michael Catanzaro 
It sounds like most everyone else supports installed tests. OK, then.

On Wed, 2017-03-01 at 10:22 +, Philip Withnall wrote:
> I agree that developers need to be engaged with adding more unit
> tests
> and code coverage if such a goal is to be useful. I wonder if making
> it
> a goal would kick-start some people to do that? I don’t think we can
> ever expect the majority of maintainers to care about (or have enough
> time to care about) code coverage and unit testing — but GNOME goals
> have been useful catalysts in the past. I guess a suitably well
> publicised and tutorialised blog post would work just as well though.
> 

This is the other thing. The goals should be achievable, something we
can look at in a year or two and say "all apps meet the goal" and close
it, not a longstanding epic that stays open forever. The installed
tests and coverage goals do not really qualify. Even though more tests
are definitely desirable, I don't think it's reasonable to use the
GNOME Goals project for this, even if it would be nice to see as many
projects as possible adopting it.

Maybe I am being too negative here. It does seem odd to say that doing
something desirable should not be a goal. But a longstanding pie-in-
the-sky project is very different from existing goals. Switching to
g_timeout_add_seconds() or adding a GtkHeaderBar are quick tasks that
all apps should be able to accomplish easily. Adding a comprehensive
testsuite, not so much. And adding just one or two installed tests,
while a good starting point, is not very useful on its own.

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

Re: GNOME goal candidates

2017-03-01 Thread Michael Catanzaro 
On Wed, 2017-03-01 at 09:08 +, Allan Day wrote:
> I don't think this one is particularly needed any more.

OK, I'll drop it then. I agree, it no longer seems relevant.

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

Re: GNOME goal candidates

2017-03-01 Thread Emmanuele Bassi 
Hi;

On 1 March 2017 at 02:44,   wrote:

> properly. Therefore I'd love to see the installed tests run automatically in
> Continuous or something like that, which is more the intended environment
> for running them in.

They already do: that's what the "integration test" phase is.

Sadly, there has been an outage and some changes in the machine broke
various testing services (that's why you don't get a screenshot any
more), and nobody has had the time to sit down and fix them.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal candidates

2017-03-01 Thread Simon McVittie 
On Wed, 01 Mar 2017 at 10:22:56 +, Philip Withnall wrote:
>  • installed-tests allows reverse-dependency testing: find test
> failures from new versions of libraries your project depends on,
> without having to rebuild your project (useful in a CI environment)

This is particularly interesting because if one of your rdeps has
unintentionally broken ABI, rebuilding your project would hide that error.
GNOME mostly dodges this bullet because it's mostly C and what is ABI in
C is relatively well-understood, but it matters a lot for C++.

>  • Allows for integration tests as well as just unit tests

I think this is quite a key thing too - some tests (integration tests and
those that must run with root privileges or specific third-party bits)
only make sense as installed-tests, some tests (unit tests that exercise
internals) only make sense as build-time tests, and many tests (black-box
unit tests that only use public APIs) can work fine both ways.

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

Re: GNOME goal candidates

2017-03-01 Thread Philip Withnall 
Hi,

On Tue, 2017-02-28 at 17:12 -0600, Michael Catanzaro wrote:
> Hi,

*snip*

> GtkBuilder validation looks like more gook to add to our Automake
> files, when we really want less gook there. Even if it's only a small
> amount of code, I'd rather it be implemented as an autoconf archive
> macro and re-proposed. I'm not sure if it's really necessary anymore
> anyway, since GTK+ almost always warns about XML problems at runtime,
> right?

Who cares how much ‘gook’ we have in the build system? What we care
about is how useful it is. The value of adding validation for files at
build time is that it catches errors *at build time*, not at runtime if
a certain code path is taken. For GtkBuilder files, the usefulness of
this depends entirely on the project — if the project uses a single
massive .ui file, any errors in that are going to be caught when the
program is started. But if a project uses a separate .ui file for each
dialogue, you have to test every dialogue in the program at runtime
before you know all the .ui files are valid.

This is a textbook example of the tradeoff between build time and
runtime testing.

The example rules given on the goal page are not the tidiest. There is
a simpler way to do this:

https://git.gnome.org/browse/hitori/tree/Makefile.am#n95 (four lines)
https://git.gnome.org/browse/hitori/tree/configure.ac#n51 (two lines)

I don’t think that needs to be shipped out to an autoconf-archive macro
— including such a macro in a project would be two lines at the least,
so it would save a total of four lines. This one is better off being
cargo-culted.

Philip

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal candidates

2017-03-01 Thread Philip Withnall 
On Tue, 2017-02-28 at 18:05 -0600, Michael Catanzaro wrote:
> Ah yeah, don't cancel your plans for nautilus.
> 
> Regarding coverage. Most of our modules are core modules; we have a
> lot
> of them. I don't think we have the resources right now to write tests
> and obtain high coverage for more than a couple of these modules,
> unfortunately. I'd like to keep the GNOME goals manageable and
> achievable. You should still go ahead and add coverage support to
> nautilus, though. It's an excellent way to improve quality.

I agree that developers need to be engaged with adding more unit tests
and code coverage if such a goal is to be useful. I wonder if making it
a goal would kick-start some people to do that? I don’t think we can
ever expect the majority of maintainers to care about (or have enough
time to care about) code coverage and unit testing — but GNOME goals
have been useful catalysts in the past. I guess a suitably well
publicised and tutorialised blog post would work just as well though.

> Regarding installed tests. The benefits of installed tests versus
> make
> check tests are not very clear to me. I don't think it should be
> necessary to install the tests in order to be able to run and test
> applications. That indicates a failure somewhere in the test
> infrastructure.

The comparison of installed-tests and `make check` is given on the goal
page:

https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests#Issues_wit
h_.22make_check.22

Briefly:
 • installed-tests give a more consistent test environment, eliminating
spurious test passes or failures due to differences in developers’
laptop configurations
 • installed-tests allows reverse-dependency testing: find test
failures from new versions of libraries your project depends on,
without having to rebuild your project (useful in a CI environment)
 • Much easier to integrate into a system like gnome-continuous
 • Allows for integration tests as well as just unit tests

Importantly, there seems to be a misconception that it’s “installed-
tests *or* `make check`”. That’s not true. Adding support for
installed-tests to a module doesn’t mean `make check` goes away or
becomes less useful.

I’m strongly in favour of adding installed-tests to our modules. With
the glib-tap.mk helper file, it’s pretty trivial. Before accepting it
as a goal, though, the wiki page should be updated to give a howto on
adding installed-tests support to a module.

This is the commit I did for libgdata a while ago. It’s probably not
perfect, but it’s an indication of what needs to be done:

https://git.gnome.org/browse/libgdata/commit/?id=802fad78

Note that installed-tests also fits in nicely with distribution testing
efforts like Debian’s autopkgtest:

http://packaging.ubuntu.com/html/auto-pkg-test.html

i.e. It’s a case of adding the following two files to a package:

https://git.apertis.org/cgit/rhosydd.git/tree/debian/tests/control
https://git.apertis.org/cgit/rhosydd.git/tree/debian/tests/gnome-deskto
p-testing

Philip

signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal candidates

2017-02-28 Thread Christian Hergert 

On 02/28/2017 04:05 PM, Michael Catanzaro wrote:

Regarding installed tests. The benefits of installed tests versus make
check tests are not very clear to me. I don't think it should be
necessary to install the tests in order to be able to run and test
applications. That indicates a failure somewhere in the test
infrastructure.


In-tree tests are beneficial to application developers.

Installed tests are beneficial to distributions, systems implementer, 
automated QA, etc.



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

Re: GNOME goal candidates

2017-02-28 Thread Michael Catanzaro 
Ah yeah, don't cancel your plans for nautilus.

Regarding coverage. Most of our modules are core modules; we have a lot
of them. I don't think we have the resources right now to write tests
and obtain high coverage for more than a couple of these modules,
unfortunately. I'd like to keep the GNOME goals manageable and
achievable. You should still go ahead and add coverage support to
nautilus, though. It's an excellent way to improve quality.

Regarding installed tests. The benefits of installed tests versus make
check tests are not very clear to me. I don't think it should be
necessary to install the tests in order to be able to run and test
applications. That indicates a failure somewhere in the test
infrastructure.

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

Re: GNOME goal candidates

2017-02-28 Thread Carlos Soriano via desktop-devel-list 
Hey,

Good initiative, I agree with the approvals and rejections, except:
For installed tests an coverage... I think we should aim to provide some 
minimum quality, and continuous integration and installed tests is something 
that really help with this and it's pretty common now for every project. You 
are right when you commented about coverage that this highly depends on the 
project, so maybe the goal should apply just to the core modules and apps?

FWIW Nautilus has an internship that is going to be precisely this, installed 
tests and coverage. IMHO we should aim for this in the core, where we are 
really present and the quality of the project is reflected.

Also adding tests is a good newcomers task, so it doesn't necessarily mean a 
lot of work for the maintainer, it can be a good entry point for getting new 
contributors for the module.



Best regards,
Carlos Soriano


 Original Message 
Subject: GNOME goal candidates
Local Time: March 1, 2017 12:12 AM
UTC Time: February 28, 2017 11:12 PM
From: mcatanz...@gnome.org
To: desktop-devel-list@gnome.org

Hi,

One of my action items from the release team meeting at GUADEC was to
go through the GNOME goals page to deal with the backlog of unapproved
goals. (I never said *when* I would do it. ;) Please review this list
and complain if you don't agree with my choices.

It's worth mentioning that some of these goals are VERY old.

I want to immediately approve the following three goals, provided that
their sponsors are willing to update the (now very stale) lists of
affected modules:

https://wiki.gnome.org/Initiatives/GnomeGoals/UseTimeoutAddSeconds
(Javier Jardon)
https://wiki.gnome.org/Initiatives/GnomeGoals/HeaderBars (Allan Day)
https://wiki.gnome.org/Initiatives/GnomeGoals/DBusActivatable (Matthias
Clasen)

I want to punt on the following goals and keep them in the unapproved
candidate list for now:

https://wiki.gnome.org/Initiatives/GnomeGoals/DistCheck
https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests

I want to reject the following goals:

https://wiki.gnome.org/Initiatives/GnomeGoals/UpdateInfoFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/NicerBuilds
https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage
https://wiki.gnome.org/Initiatives/GnomeGoals/ValidateGtkBuilderFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/CorrectIconNames

In order:

Passing distcheck is obviously good, but not useful to spend time on
this now if we wind up creating a Meson goal, which seems likely. We
have enough goals right now as it is. Moreover, this is really
something to be expected of module maintainers rather than a project-
wide goal where everyone would be encouraged to help with different
modules. And our maintainers are not stupid; if they're releasing
modules that don't pass distcheck (vte <_<), something is very
seriously wrong.

The ModernAutotools goal needs to be updated, because best practices
have changed since it was written. We'll need to look this one over
closely before approving it. Additionally, it's not useful to approve
it if we wind up creating a Meson goal instead.

As for the installed test goal, I'm really not convinced that tests
should be installed. The QA team that was enthusiastic about installed
tests seems to have disappeared, so nobody is driving this anymore. I'd
like to see further discussion on this before approving or rejecting
it. Also, I'd like to see if people are still interested in . I kinda
think that traditional make check style testing is still the way to
go

UpdateInfoFiles includes some weirdness like updating FSF address in
all source files, and changing all applications to not use ranges to
indicate copyright years. This is not related to updating info files
and needs to be split out at the very least. But I'm also not sure this
is an appropriate goal candidate anyway. We can update all our README
files now, but they're just going to become stale again in a few years,
and we don't want to re-run this goal every couple of years. That's not
to say we shouldn't update our info files anyway -- of course we
should! -- but that I'm not convinced this should be a project-wide
GNOME goal. (P.S. This goal turns 10 at the end of the March! We should
probably handle goals a bit sooner in the future. ;)

NicerBuilds is just using silent rules. That's already complete for all
GNOME modules, so there's zero reason to approve it as a new goal.

Code coverage would be wonderful, but there is no point in adding
coverage to modules unless the modules' maintainers plan to work on
adding new tests to raise the coverage. We just don't have enough
developers to do this project-wide. Accordingly, coverage should be
pursued on a per-module rather than project-wide basis.

GtkBuilder validation looks like more gook to add to our Automake
files, when we really want less gook there. Even if it's only a small
amount of code, I'd

GNOME goal candidates

2017-02-28 Thread Michael Catanzaro 
Hi,

One of my action items from the release team meeting at GUADEC was to
go through the GNOME goals page to deal with the backlog of unapproved
goals. (I never said *when* I would do it. ;) Please review this list
and complain if you don't agree with my choices.

It's worth mentioning that some of these goals are VERY old.

I want to immediately approve the following three goals, provided that
their sponsors are willing to update the (now very stale) lists of
affected modules:

https://wiki.gnome.org/Initiatives/GnomeGoals/UseTimeoutAddSeconds
(Javier Jardon)
https://wiki.gnome.org/Initiatives/GnomeGoals/HeaderBars (Allan Day)
https://wiki.gnome.org/Initiatives/GnomeGoals/DBusActivatable (Matthias
Clasen)

I want to punt on the following goals and keep them in the unapproved
candidate list for now:

https://wiki.gnome.org/Initiatives/GnomeGoals/DistCheck
https://wiki.gnome.org/Initiatives/GnomeGoals/ModernAutotools
https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests

I want to reject the following goals:

https://wiki.gnome.org/Initiatives/GnomeGoals/UpdateInfoFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/NicerBuilds
https://wiki.gnome.org/Initiatives/GnomeGoals/AddCodeCoverage
https://wiki.gnome.org/Initiatives/GnomeGoals/ValidateGtkBuilderFiles
https://wiki.gnome.org/Initiatives/GnomeGoals/CorrectIconNames

In order:

Passing distcheck is obviously good, but not useful to spend time on
this now if we wind up creating a Meson goal, which seems likely. We
have enough goals right now as it is. Moreover, this is really
something to be expected of module maintainers rather than a project-
wide goal where everyone would be encouraged to help with different
modules. And our maintainers are not stupid; if they're releasing
modules that don't pass distcheck (vte <_<), something is very
seriously wrong.

The ModernAutotools goal needs to be updated, because best practices
have changed since it was written. We'll need to look this one over
closely before approving it. Additionally, it's not useful to approve
it if we wind up creating a Meson goal instead.

As for the installed test goal, I'm really not convinced that tests
should be installed. The QA team that was enthusiastic about installed
tests seems to have disappeared, so nobody is driving this anymore. I'd
like to see further discussion on this before approving or rejecting
it. Also, I'd like to see if people are still interested in . I kinda
think that traditional make check style testing is still the way to
go

UpdateInfoFiles includes some weirdness like updating FSF address in
all source files, and changing all applications to not use ranges to
indicate copyright years. This is not related to updating info files
and needs to be split out at the very least. But I'm also not sure this
is an appropriate goal candidate anyway. We can update all our README
files now, but they're just going to become stale again in a few years,
and we don't want to re-run this goal every couple of years. That's not
to say we shouldn't update our info files anyway -- of course we
should! -- but that I'm not convinced this should be a project-wide
GNOME goal. (P.S. This goal turns 10 at the end of the March! We should
probably handle goals a bit sooner in the future. ;)

NicerBuilds is just using silent rules. That's already complete for all
GNOME modules, so there's zero reason to approve it as a new goal.

Code coverage would be wonderful, but there is no point in adding
coverage to modules unless the modules' maintainers plan to work on
adding new tests to raise the coverage. We just don't have enough
developers to do this project-wide. Accordingly, coverage should be
pursued on a per-module rather than project-wide basis.

GtkBuilder validation looks like more gook to add to our Automake
files, when we really want less gook there. Even if it's only a small
amount of code, I'd rather it be implemented as an autoconf archive
macro and re-proposed. I'm not sure if it's really necessary anymore
anyway, since GTK+ almost always warns about XML problems at runtime,
right?

I'm not sure about the status of CorrectIconNames, but its description
is clearly very obsolete. So at the very least, that's going to need to
be revisited and proposed again.

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