[Glade-devel] state of the project

[pborelli katamail com (Paolo Borelli)]

Il giorno gio, 07-10-2004 alle 15:03 -0400, Tristan Van Berkom ha
scritto:
> > This comes down to how you prefer to work: since glade3 has still big
> > chunks of functionality missing, until now we preferred keep the
> > discussion/patches going on the mailing list. We listed the "still to
> > implement" stuff in the TODO and  use bugzilla for real bugs and for
> > stuff reported by others.
>
> That sounds good to me, can we get a consensus on this ?
>
> For now I've sent a couple of patches to this list, should my
> patches in the future go to bugzilla instead ?

I should probably let you guys sort this out yourself since you are the
ones doing the work, but since I'm into this thread I'll give you my
opinion :)

I'd suggest to keep discussion on the ML so that it's easier for
everybody to follow and reply.
At the same time I suggest to put all the patches in bugzilla so that
thy do not get lost, especially considering the fact that the lack of a
clear maintainer may mean that they are not applied immediately to the
tree.

Patches should be created with "cvs diff -up" to make reviewing easier
and should not be split up by file; new files should be attached
separately. Please do not gzip them: gzip patches are just a pain.

> I have to admit that this is a little clunky for me, ATM I'm working
> full time on glade3 and I seem to be the only one here without a
> cvs account, Is there a formal request I have to make somewhere for
> that ?

I can understand your pain... usually the procedure to get cvs write
access is to contribute patches and when the maintainer feels he can
trust your changes he will "sponsor" your request. Lack of a maintainer
clearly makes this procedure more difficult.

Some possible solutions that comes to my mind are to try to maintain a
patchset against upstream or try setup an "arch" repository for
glade3... I never used arch, but I know there are other projects on
cvs.gnome.org that switched to it (Rhythmbox, MLView,...).

Since you for now you have to keep a patchset against upstream, I
suggest you to only make strictly needed changes leaving out coding
style changes and other noise.

That brings me to  coding style (which you raise in the other email)...
once again, I know coding style is a personal preference and I know I'm
not the one doing the work, but I'd suggest to adopt the current coding
style since consistency is the most important thing. Preferred coding
style is described in the HACKING file and, to answer your specific
question, we decided to put braces on their own line:

if (a == b)
{
        c = d;
}

some parts of the codebase predate this decision and have the opening
brace on the same line.

With regard to long lines, I find really looooong lines annoying too,
but at the same time things like

function_name
        (arg, arg)

are IMHO just plain ugly and I find that solution way worse than the
long line itself. After all it's 2004 and we can well expect people to
use an editor/terminal which is not limited to 80 cols ;-)


ciao
        paolo