[Gtranslator-devel] Re: [gtranslator patch] Email for Romanian team

[Ross Golder <ross golder org>]

On àà., 2004-01-11 at 15:42 +0200, Dan Damian wrote: 
> Hi Ross,
> 
> On Du, 2004-01-11 at 03:13, Ross Golder wrote:
> > Sure. Read the HACKING file. It says 'OK to commit as long as you do a
> > ChangeLog entry too'.
> 
> Thanks for accepting my other patches. 
> 
> I read the HACKING file, but as it was written by Fatih and you're the
> current maintainer, I wasn't sure that it had your blessing :) For small
> patches, I'll just go ahead and commit.

That's the idea. Small fixes/changes - just go ahead and commit. If
you've got any earth-shattering changes, a bugzilla report and/or
gtranslator-devel notice would be more appropriate.

> However, I'm not sure how well this liberal commit policy would work for
> large patches. For example, I'd really like to improve undo suport by
> upgrading GtkTextView widgets to GtkSourceView (thus adding a new
> dependency, gtksourceview). It's quite an important decision to take,
> and I think it should be approvted by someone with better understanding
> of gtranslator's code/design.

That would need some consideration on the mailing list. I'd be for it, but I'd like to see what other users think first.

> So there are basically three things I can do when I'm finished writing
> the patch:
> 
>   a) open a bugzilla bug and attach the patch
>   b) send it to the gtranslator-devel list for review
>   c) just commit it and see what happens
> 

I wouldn't worry about a) too much, unless it's a major patch. Same for b). Just do c) in most cases will be fine.

> Now if there aren't any more problems with the mailing lists on
> sourceforge (they were inaccesible two days ago), I'd go with b). And I
> would strongly suggest anyone in my position to follow that path, as
> gtranslator's code matures and significant changes made by new
> contributors are likely to break things.
> 

I shouldn't worry too much there. We've got a stable-ish 2.4 branch, so all code in HEAD should now be aimed at 2.6+. Changing widgets and GUI/API-related updates are welcome, but as you said, changes involving dependencies should be considered first.

Thanks for all your work, by the way. Fatih and I (and the users) certainly appreciate the help.

Regards,

--
Ross