Patches and CVS accounts (was Re: Patches)

[Pawel Salek <pawsa theochem kth se>]

On 2001.07.15 03:06 M . Thielker wrote:
>  there is a question I'd like to ask:
> While I have made numerous patches in those past few days, none of them
> have made it into CVS. I get the impression that all the patches I make
that
> change the UI aren't even considered for inclusion.

Your impression is wrong, at least from my point of view. However,
commiting a patch to the CVS respository takes more than executing two
commands. (I should stress I am speaking for myself only). I tend to look
closer at every non-trivial patch to make sure it will not turn out to be a
problem in the future. Getting four versions of same patch within 24h gives
me a hint that the patch is not obvious or incomplete. As an example, I got
following patches:

Subject:       PATCH: Complete custom toolbars package (partially
               rewritten)
Date:          2001.07.13 22:06

Subject:       PATCH: final version of toolbar patch, corrected for current
               CVS
Date:          2001.07.14 00:59

Subject:       PATCH: FIXED: custom toolbars
Date:          2001.07.14 02:41

Subject:       PATCH: Toolbars finally done
Date:          2001.07.14 20:51


This functionality would get commited much faster in CVS if I got only one
of them, not four. From the way they are submitted, I get an impression
that none of them is really ready. I find it difficult to treat it
seriously. I have got a job and I don't have time for checking the same
patch four time a day. I would be happier if you respected that.



> I am seriously starting to wonder if I should continue making them or
> just save myself the worry and disappointment by keeping them to myself.

If the patches are good, you don't have to worry, they will get in.

> It is my goal to make Balsa into a full featured email program, that can
> be used in day-to-day work by just about anyone.

Good! It means we have very similar goals! (They only question is what do
you mean by "just about anyone".)

> But if all my work does not
> even have a chance to get into the project, I might just as well make all
> the patches I need for myself and keep them to myself, too.
> It has never been a GoodThing to have too many patches floating around,
> maybe even patches that are incompatible to each other, it's a sure way
> to kill a project. I don't want that.

If you don't want that, please don't submit four patches. Submit one but
final instead. It has been little annoying when you submitted four versions
of one patch because I had to:
a. apply first patch and start testing.
b. I got a patch from another person that collided with your corrections so
I had to remove collision manually.
c. then I got another version of your patch, could not remove automatically
patch b and a. because of collisions so had to do it by hand; then apply
patch c and reapply b.
d. when I got your third patch, I got discouraged and decided to wait until
the patch finally stabilises.

I hope you can see now that it is plainly counter-productive.

I should mention the CVS account issue. The GNOME policy is that if you
want to get the CVS account with write privileges, you have to come with a
new project or - if you want to join another project - one of the project
developers has to vouch for you. Balsa has now three active developers:

        Matthew Guenther        <mguenthe@attcanada.ca>
        Pawel Salek             <pawsa@theochem.kth.se>
        Carlos Morgado          <chbm@chbm.nu>

My personal rules for vouching for other person are:
1. the person in question must be good programmer (I have impression you
are one, so this in not a question).
2. he/she must intend to work on balsa for a period longer than 2-3 months.
3. she/he must be willing to work in team. That includes also bug fixing
(bugzilla.gnome.org).

Of course, other developers may follow other rules. The goal of my rules is
to provide a framework for long-standing development of balsa. The
developer should know how to program well within GNOME/GTK framework so the
code is optimal, non-redundant and clean. The developer should take the
responsibility for the written code for reasonable period of time, so if
some bugs are discovered, they will get fixed. Finally, balsa is not a
single-man project and the ability to communicate with other developers
gives a crucial foundation for fruitful collaboration. The development
should not be done in vacuum and quick response on reported problem is
important element of writing a program for "just about anyone".

If you have more questions I will be happy to answer them.

My regards,

Pawel

-- 
Pawel Salek, pawsa@theochem.kth.se