Long: Next TODOs and debate on existing ones (was "Re: Welcome to Helder Magalhães as a committer")

[Helder Magalhães <he...@gmail.com>]

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
IMO.)


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... :-)


[me]
>> 1. Reduce the patch queue, looking into committing (at least) the set
>>    of trivial patches currently available;
[Thomas]
>    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]...


[me]
>> 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.)
[Thomas]
>     Sounds good.

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


[me]
>> 4. Cleanup Sun proprietary stuff and/or improve GNU ClassPath
>> compatibility
>>    (See bugs 38183 [4] and 46513 [5].)
[Thomas]
>     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. ;-)


[me]
>> 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:
<snippet>
Bug fix:
  Bug 1 summary
    (details, impact, contributed by, URL, ...);
  Bug N summary
    (details, impact, contributed by, URL, ...).

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

General:
  General 1 summary
    (details, impact, contributed by, URL, ...);
  General N summary
    (details, impact, contributed by, URL, ...).
</snippet>
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
guidelines?


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! ;-)


Cheers,
 Helder


[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
syntax")
[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

Re: Long: Next TODOs and debate on existing ones (was "Re: Welcome to Helder Magalhães as a committer")

[Simon Pepping <sp...@leverkruid.eu>]

On Sun, Feb 21, 2010 at 12:11:04PM +0000, Helder Magalhães wrote:
> [Thomas]
> >    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]...

Any contribution that is considerable enough to be considered as
intellectual property. Usually that is measured by size: a
contribution of say 50 lines applies. But it can also be measured by
intellectual content: a function of say 25 lines that implements an
algorithm applies. In the end it is decided by good judgement of the
committer who commits the contribution.

Regards, Simon

-- 
Simon Pepping
home page: http://www.leverkruid.eu

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