xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Helder Magalhães <helder.magalh...@gmail.com>
Subject Long: Next TODOs and debate on existing ones (was "Re: Welcome to Helder Magalhães as a committer")
Date Sun, 21 Feb 2010 12:11:04 GMT
Hi everyone,

(Note that I've renamed the thread and redirected to batik-dev only,
as this is basically stuff which shouldn't really interest users much

There has been a (somehow longer than I expected) delay in starting up
the engines. I'm still entering the project and been overwhelmed with
other stuff lately. Oh well, that's just how things are... :-)

>> 1. Reduce the patch queue, looking into committing (at least) the set
>>    of trivial patches currently available;
>    Please make sure that for any contribution of size the contributor
> has a CLA on file.

That's also something I currently have doubts with. I haven't found
clear information anywhere on when asking for a CLA should be required
from a patch contributor. Is the distinguish made ad-hoc (mental
heuristics using number or lines, code impact, etc.) or am I missing
something? For example, I don't really have a clue on regarding the
patch on bug 48771 [1]...

>> 3. Try to improve the regression tool, regard.
>>    (There was already some debate [3] on this, so I'll probably create
>>     a bug to track progress on this as Cameron suggested.)
>     Sounds good.

Great! :-) I've been gathering thoughts/feedback on this and will soon
report a couple bugs to track this down.

>> 4. Cleanup Sun proprietary stuff and/or improve GNU ClassPath
>> compatibility
>>    (See bugs 38183 [4] and 46513 [5].)
>     This is fine, I never finished the switch over to Java Image IO as I
> didn't have the time to ensure forward compatibility in all the corner
> cases.
> Perhaps it doesn't matter anymore and we should make Java Image I/O the
> default and let people use the original encoders/decoders by switching the
> SPI file.

I'm voting on that as well. I'm doing a few experiments around this
but I need to get my Regard infrastructure up and running to do more
"scientific" experiments. I'll be posting updates in bug 46513. ;-)

>> 5. Improve the JSVGCanvas applet demo in order to provide a
>> cross-browser, high quality environment for SVG development/deployment
>>   (Maybe through resurrecting what seemed to be an official applet,
>> dropped back in 2001 [6]... Can anybody recall why?)

I'd still like to receive some feedback on this before attempting to
put effort on such task: my slowly improving Java/Batik foo will
probably require some guidance so, if no one else thinks this is a
good idea, I'd better leave it in the shelf for a while... Basically,
I still haven't quite well understood if silence (generally) means
positive approval or just OK in the sense of "I'm not against it". :-)

[Trying to follow numbering from the previous message to ease replies]

6. I'm (also) still trying to set a strategy on making commits: I have
lots of small changes in my working copy and, although most changes
are tiny, I did want to try separating unrelated commits. I guess one
would prefer me taking longer and separate things (read: "unrelated
commits") to ease reviewing right? Or would it be better to "just
commit it!"...? ;-)

7. I'm thinking in committing trivial stuff directly but, for more
elaborated stuff, I guess that creating a bug and/or posting a patch
into the dev mailing list would be better, so that it can bake for a
while/allow reviewing prior to commit. Are there any
preferences/guidelines for this?

8. I've noticed (taking a look at the commit logs) that apparently
there wasn't a fixed "template" for the commit message. So, in my
previous couple of commits, I've used a format which I have been
starting to get fond with:
Bug fix:
  Bug 1 summary
    (details, impact, contributed by, URL, ...);
  Bug N summary
    (details, impact, contributed by, URL, ...).

  Feature 1 summary
    (details, impact, contributed by, URL, ...);
  Feature N summary
    (details, impact, contributed by, URL, ...).

  General 1 summary
    (details, impact, contributed by, URL, ...);
  General N summary
    (details, impact, contributed by, URL, ...).
Bug fix and feature subsets are self-explaining, general is mean for
stuff like typos, whitespace fixes, SVN property changes. etc. Does
this sound attractive as template or am I missing any general

9. I've noticed that there are many files missing SVN properties
(namely svn:keywords for substitution). I already am ongoing to fix it
but, in the meantime, it also occurred to two related things:
 9.1. Should we start using SVN 1.2+ fixed length keywords [2]? That
will look much better in XML files. Subversion is currently at version
1.6 and, specially now that it was incubated into ASF, I guess it
would nice. Could I be missing something which would stop use from
using this?
 9.2. Can we get rid of ".cvsignore" and other CVS metadata or is it
there for a purpose? Yeah, I'm aware that it probably won't hurt
leaving as-is but, given that the switch from CVS to SVN was already a
while ago, removing this cruft would be better in the long run, IMO.

10. @Thomas: Were you ever known as "l449433" [3] (maybe an internal
company user name, old nickname or something)? I've noticed it spread
over a few files and am assuming either that or a broken find&replace.
Would it be better to fix this, right? Please clarify! ;-)


[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=48771
[2] http://svnbook.red-bean.com/nightly/en/svn.advanced.props.special.keywords.html
(search for "Subversion 1.2 introduced a new variant of the keyword
[3] http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/sources/org/apache/batik/util/CleanerThread.java?view=annotate#l32

To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org

View raw message