RE: [gnome-love] My proposals for Gnome

["Tom Musgrove" <TomM pentstar com>]

Hi Malcolm,

thanks for your comments, I'll respond inline.

> I have a few comments on the practicaltilty of one of the ideas Tom
> raised. Having written this and looked over it, I hate myself. This is
> really "the voice of negativity" speaking. :(

Nonsense, perhaps it is the voice of reason (or the voice of
misunderstanding <grin>)

[snip]


> (1) The "pretty printer" idea: different projects have different
> indentation styles. There is no one true layout method and to try and
> insist on one will simply generate a few megabytes of email and no
> consensus. For example, the GNU coding guidelines have been out for
> years and some projects follow them. Others (even major Gnome
> components) modify them slightly and still have readable code. Some big
> project (e.g. linux kernel) throw them out entirely and still have
> readable code. A lot of people know what the true and correct
> indentation style is, the problem is that they all know it to be
> something different from all the other people. The rest of us just
> adjust to the different styles in different modules; it's not that hard.

I believe that you misunderstood.  I meant consistency within the style(s).

Although styles may differ, running a pretty printer on the same piece of
code with different style definitions, if the code changes dramatically
under multiple definitions (i.e. the white space is not consistent with any
particular style given the syntax) then most likely there was a syntax
error.

For example

if (a=b)
        a = c;
        b = d;
else c +=1;

Now from the white space, it is clear that the author meant to enclose the
two statements with braces.  There is no coding style for which the
alignment of the white space is correct.  Thus, an error would be generated.

> Even were somebody to try and mandate that we will all use indentation
> style X, it would be a travesty to go through CVS and reindent or
> otherwise alter the existing code. You would screw up CVS's knowledge of
> who last edited that line. This is part of the reason why people are
> encouraged to stick with whatever coding style already exists in a
> project, rather than doing mass reformattings -- it is *very* useful to
> be able to see when a line was last changed and generally retain the
> history of pertinent alterations.

I don't want to reformat with the pretty printer, just check for
consistency, no change would be made to the code, just a flag sent to the
bug tracker/code submitter.  If they flag a 'won't fix' than it will no
longer generate a bug report for that formatting inconsistency.


> (2) Automatic compiling: please remember that it is not a requirement
> (and should not, in general, be one) that everything in CVS must compile
> and run. For many (most?) Gnome modules, the contributors are spread
> around the world. The main way they have to communicate their coding
> changes to each other is through CVS, so sometimes code will be
> committed simply for the purpose of sharing it with the other
> developers. Especially between point releases the code on the various
> CVS branches may well be broken and that is not a bad thing.

That is a good point, I was thinking of the Debian set up of frozen, slushy,
and unstable.  Permissions on how 'breakable' a tree is can be set up.

> Some people may argue that if code is going to break the compile, then
> it should go on its own branch. That's not an unreasonable attitude. But
> then the tinderbox maintainers have to keep track of which branches are
> "stable" ones (e.g. the GNOME_1_4 branch in gnome-core) and which are
> temporary development ones. Secondly, I am a believer that the
> maintainers of the module should be the ones to determine if their main
> branch must always compile. People who arbitrarily insist that CVS code
> from times between releases must always compile and run correctly are,
> in my opinion, contributing only negatively the project -- they remove
> the ability to experiment in consultation with other developers. For
> that matter, even point releases in unstable branches can have known
> problems.

I agree, the tree maintainer should have the ability to define what tests
they want ran on their code, and what branches they want it ran under.

> Because of these points, any sort of automatic setup needs a way for
> maintainers to add or remove their module from the process (during
> periods when they are aiming at a release or developing madly,
> respectively). Otherwise you are going to have truckloads of spurious
> bug reports and email spam about expected bugs and people will just
> ignore them as "yet another thing we sort of expected".

Yep absolutely, good point.

> (3) Giving garbage input is HARD at the moment. Most gnome applications
> are based around some sort of GUI. It is possible to set up tests on a
> case-by-case basis sometimes, but to do it for all apps, automatically
> at the moment is an enormous undertaking.

> Consider the work that must be done:
>       (a) somebody has to write a tool that will automatically poke at
>       buttons and know about entry widgets and stuff.

I don't think this is difficult, it can ignore the interface, and poke
buttons at the handler level.

>       (b) Each project must then have some sort of file that describes
>       to this tool what it's GUI is like (I can't imagine how this
>       would work, but it's required). This file must be kept up to
>       date and since it's really a duplicate of work in the project's
>       code and since it probably can't be automatically generated, it
>       will often slip out of sync.

I don't believe you are correct, as stated above, the button poking can be
generated automatically, the testing just sends input to the handler.
Unless you have a highly customized widget, I don't see how this would be a
problem.  (and if you have a highly customized widget, it should define what
it is expecting, and what it is derived from, so it should also be
automagically generatable).

>       (c) The application that does all this random poking about must
>       be run in a very high-walled sandbox. For example, imagine
>       you're testing a file manager via this method. Somewhere in
>       there is the ability to delete files. You aren't going to run
>       that in $HOME are you? :-)

Good point.  But we can run it on a virtual linux box so that shouldn't
really be a problem.

> Now, none of these problems are impossible to overcome. Late last year I
> wrote down what a tool like that in (a) would look like and do (then the
> problems in (b) and (c) became clear and I got depressed about it). The
> Palm Pilot emulation stuff has a program called Gremlins, which randomly
> pokes about at your application and if it crashes, records where it was
> up to. This is all done via software emulation of the Palm (so it
> effects the sandbox idea). Since sandboxing is a bit fiddly (because you
> need to sandbox an entire Gnome setup to be accurate), I was also
> thinking about scripting tests (as can be done with some tools on
> Microsoft's systems). I got further here (there's a spec somewhere on my
> backup disks if people care), but it's still not bullet-proof: for
> example, the script says to click on the first button on the left, the
> author recently changed that to make it the "delete" button and ... oh,
> dear!

Hand generating the code is a bad idea, the tests need to be automagically
generated from the interface file.


> I'm a bit confused as to what advanatages this has over mailing lists
> (since even the realtime reponse of IRC is not considered necessary).
>
> It sounds to me like a lot of what you are talking about here could be
> accomplished by turning archives of gnome-list and gnome-hackers into
> more searchable FAQ lists. But I'm probably missing something in your
> proposal because I haven't really thought about this as much as the
> above points.

Malcolm, did you read the attachments?  Those outlined the majority of 'The
Ultimate help system'.  The gist is, is finding what normal/ 'naive' users
ask, and mapping their questions to the correct answer.  Right now most non
powerusers don't use help (on any OS) because they can never find what they
want in a timely manner.  Thus they come and ask me (you, help desk,
whatever), and then we look it up in the help system in about 2 seconds.
This would leverage our collective lookup ability, so that the normal user
would find help useful and accurate, and quit interrupting our Quake
games/web surfing/programming every ten minutes <grin>.  The real time
response of IRC (or any instant messaging system) is preferable and vastly
superior to a non-real time response because it will help that user right
then, but not absolutely necessary.  Even if the individual doesn't get
their response in real time, it will be answered, and added to the help
system for future users.

Thanks for your comments,

Tom M.
TomM Pentstar com
LetterRip