Re: Patches

["M . Thielker" <balsa t-data com>]

On 2001.07.15 16:18 Carlos Morgado wrote:
> 
> you made numerous patches, most final versions of each other and needing
> each
> other. the patches must be read, tested and if not bugfixes discussed.
> that
> takes time. the better part of balsa-maintainers seems to have little time
> for
> email this last days. be patiente

Rught. But they aren't even being noticed by most.....

> 
> > 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. But if all my work does
> 
> does that mean *evolution* ?

No. It does not mean Evolution. It also does not mean Outlook, and it
doesn't mean Netscape mail. It means Balsa. I didn't choose Balsa for no
reason, of all the ones I named and a few others, it's the one I like best.
I don't want to change Balsa into something not Balsa. I don't want news,
contacts, appointments and reminders in there. I just want a rubust,
configurable, reliable yet still lightweight email client. I want
efficiency, comfort, interoperability according to Gnome standards and RFCs.
I don't want obscure scripting languages, user designable forms, Database
stuff or COM/DCOM-like things.

> imho, mutt is not pine. balsa is not evolution.

No, see above. But the features that are there should work correctly and
reliably, and a certain measure of customization must be possible, like my
toolbars. I don't intend to do the same thing for menus, that would go too
far, just to give an exable.

> > personal Balsa, patched to fit. There should be one Balsa, and I think
> it
> > can profit from my work. But if my patches are not wanted, I won't post
> them
> > anymore.
> you are blaming people for not having time to review and apply *all* your 
I'm not blaming anyone. Most of the time my recent series of patches have
not even been noticed on the list. No statements have been made about them
and I don't know how to proceed.
My patches are usually sufficiently developed for my own personal use long
before they get posted to the list. Then I add options to them, so they will
be more useful for different people and different environment.
I wouldn't have to do that if in  the end i'm the only one to use the patch
anyway. I could just hardcode my defaults and be done with it. About 5 to
30% of a patch is there to make it more general. I wouldn't have to code
those parts if the patch is not wanted. That's the reason for my post
"Patches", not blaming someone.
I have already told you, this is the first time I get involved in something
like this. I don't know how it works. I just saw that, when I first started,
patches were committed almost instantly. Then later, bigger patches were
simply ignored. No one wrote "Yes, Toolbars are useful", or "No we don't
need them". They just went by everyone without notice.

> patches. also, you seem to imply *all* your patches should go into cvs
> specially
> the ones changing UI. that, imho it's wrong. i've had stuff rejected,
> reverted
> 
> off cvs and paperbagged. that *is* natural. 

Yes, but at least one should be told. If my patches have been rejected, I
should be told, so I don't continue developing them except for personal use
and don't make them a prerequisite for future patches and bugfixes.

> speaking for myself, i'm not going to commit your patches to main the
> moment i
> get 
> them. and that goes for mostly everyone's patches (even mine at times). if
> you
> read 
> the changelog you'll notice most contributed patches are commited by
> pawel.
> that 
> means he has final word after debate. as it stands, your UI patches
> haven't
> been 
> debated and your bugfixes haven't been tested thouroughly. also, i was
> rather
> hoping
> for some input from Peter about them as most seem to be imap related.
> 
Well, Peter has just confirmed that Cyrus IMAP does indeed do this. This is
also in corpliance with rfc2060. It does not mandate header parsing, so the
client MUST be able to set the correct flags, because the server MAY do it ,
but is not encouraged to do so. As far as my tests show, cyrus is 100%
rfc2060 compliant. Soon I'll know rfc2060 by heart, anyway. I will most
likely rewrite the IMAP client code from scratch. It seems to be the thing
to do. The asynchronous, multi-connection, multi-command nature of IMAP
doesn't mix well with linear execution code as seen in libmutt. Especially
storing message scan be backgrounded and mailbox headers can be fetched in
the bacjground, too, emitting a signal when the mailbox has been read
completely. Sequence numbers can be used efficiently to simulate entries not
yet downloaded and to populate clists vene before the entire mailbox's
contents have been read. IMAP needs local shadows as well.

> having enough time, i'm planning on creating a cvs branch where all your
> patches 
> will be commited for testing. so, could you please post a list of the
> final
> final 
> versions of your patches. i must say i'm a bit lost now and can't say i'm
> tracking
> all your stuff.
> 
Well, the final ones, are:
balsa-imapflags.patch
balsa-imapcounts.patch
balsa-allbars3.patch
balsa-miscgui.patch

In balsa-miscgui.patch there is a change to the compose window that is
subject to discussion at the time.and may be left out of CVS. The wmclass
portion should be committed because otherwise it is really tedious to work
with using sawfish.

> again, *use the std balsa indentation*. your patches are *very* dificult
> to
> read 
> (at least for me) cause your indentation is wrong and clashes with
> context.
> 
Do you mean the function definitions?
They have been changed already, all I could find.

The last balsa-allbars3.patch was broken, not badly, but it included a
backup file that made it suffer from exessive bloat. With this message I'm
posting a new version with the extra file removed.

> please don't roll smaller patches into bigger ones. it just makes
> everything
> more 
> dificult. small (even interdependent) patches are easier to read and test.
> 

Well, the toolbars really are one big pack, I jumped the gun on posting the
first version (balsa-custombars.patch) while it was incomplete and buggy.
That's what started it off. In the future, I'll behave. :)

> use bugzilla. please.
> 
How? it seems terribly complicated to me.....

> and please keep in mind balsa is not a Product. it moves in it's own
> collective 
> timming.
> 
Well, Balsa is a product in the sense that people should be able to use it.
It is not a product in the sense that it's marketed or someone sets and
checks deadlines. However, of all the "products" available, Balsa shows the
most promise.

> also, despite being the most active now, i'm *not* *the* balsa guy. regard
> my
> comments as the ones from any other person on the list.
> 
Cheers, too :)

balsa-allbars3.patch.gz