harmony-dev mailing list archives

BTW, I'm more than happy if you just do a quick sketch of what you're
thinking, and we resume the convo from there.
I just wanted to clear up some confusion I had.
geir
Geir Magnusson Jr. wrote:
>
>
> Etienne Gagnon wrote:
>> Geir Magnusson Jr. wrote:
>>>> The "communication" aspect of 2 can be quite helpful when doing
>>>> system-wide changes. Just think about the effect of simply doing a
>>>> system-wide reindentation of source code; this is a nightmare when
>>>> developing using branches, as diff/merge tools are line-based, not
>>>> syntax-based. So, if your new indenter moves things across lines,
>>>> you're in hell.
>>>>
>>> So here's where I'm starting to believe I'm missing something
>>> important :
>>>
>>> Can you give me an example of the "communication" that you imagine
>>> taking place here? That's the part I'm just not grokking here.
>>
>> How about: j2se5 developers, seeing that his planned modification to
>> some code will lead to utterly broken nearby j2se6 (commented) code
>> fragments, steps on this mailing list and asks j2se6 developers to help
>> him find the most harmless way to do the change (or, at least,warn them
>> about the problem)?
>
> Ok - we do that now. I thought you were saying that your tool added
> somehow to communications.
>
>>
>>>> I am not saying that using the tool should replace using branches for
>>>> all situations, but there are situations where it would be more
>>>> effective not to use branches when the code is mostly identical.
>>> I want to avoid branches at all costs.
>>
>> [somewhat off-topic] I think that we should consider tools/approaches
>> on their merit. Sometimes, branches are the right solution... You
>> wouldn't want to use syntax-processing instead of branches for managing
>> sandboxes. ;-)
>
> I'm trying to figure out the merit here.
>
>>
>>> Clearly there's some confusion here. My goal is to
>>>
>>> 1) Avoid branches at all costs so we can share as much code, and get as
>>> much benefit for collaboration between different versions, and different
>>> platforms, if that happens.
>>
>> Agreed.
>>
>>> 2) make it simple to work in either the 'master' code, or the 'target'
>>> code through tooling, including standard IDE activities like debugging
>>
>> Agreed.
>>
>>> 3) make it easy for users to report bugs based on 'target' code,
>>> including patches and line numbers
>>
>>
>> Ah! That's something to add to my requirements. Fine! I hadn't
>> included the "patches" thing into account. It doesn't break what I've
>> exposed so far; it simply adds to it.
>
> It has to be the case - we'll do snapshots and distributions of
> "src.jar" and when a developer goes into the debugger, they need to see
> normal Java SE 5 code.
>
>>
>>> What I've suggested is :
>>>
>>> forward(X, platform) -> Y
>>>
>>> reverse(X, platform, Y') -> X'
>>
>> OK. I see this in *addition* to:
>>
>> forward(X, devtarget) -> Y
>> reverse(Y') -> X'
>
> I believe that
>
> reverse(X, palatform, Y') -> X'
>
> is the same as
>
> reverse(Y') -> X'
>
> as you need to know at least what platform Y' is, and what it came from.
> You could always embed as metadata in the code itself in a comment, I
> suppose. I was just being explicit.
>
>
>>
>> So, to simplify the discussion, let's rewrite your proposal as:
>>
>> forward(X, releasetarget) -> Y
>> reverse(Y',X,releasetarget) ~~> X' (possibly reporting
>> conflicts/problems)
>>
>> That's neat. I like it. Yet, we would encourage developers to work and
>> submit patches using devtarget code, instead of releasetarget code.
>
> I don't know this terminology. I was using "master" being the code in
> SVN, and "target", being the code Y, so the map is :
>
> master == devtarget
> target == releasetarget
>
> right? Ok.
>
> I want to work in the master code w/ an IDE plugin that lets me think
> I'm in target (and lets me flip back to master). No preprocessing of
> the tree is required to develop.
>
> However, end-users - people who take our JDK and work with it, will
> report bugs with stacktraces and line numbers that are from
> target/releasetarget code.
>
> So what to do with a patch?
>
> I can either
>
> patch -p0 << reverse(patch.file)
>
> on the main code or use patching facilities in an IDE to patch the
> transform view
>
> Man, this tooling is going to be fancy! :/
>
>
>>
>> In other words, here's how I see the distribution(s):
>>
>> - Binary j2se5 Harmony release: includes j2se5release src.jar for
>> end-developers using debuggers to step through API code.
>>
>> - Source j2se5 Harmony release: API are in j2se5dev form. The build
>> process uses the processing tool to generate j2se5release src.jar.
>>
>> - Binary j2se6 Harmony release: includes j2se6release src.jar for
>> end-developers using debuggers to step through API code.
>>
>> - Source j2se5 Harmony release: API are in j2se6dev form. The build
>> process uses the processing tool to generate j2se6release src.jar.
>
> Yes.
>
>>
>> Why? Because reverse works much better with devtarget than
>> releasetarget code, and the communications benefit of devtarget that are
>> lost in releasetarget code (because of stream code erasure). In
>> addition, using smart IDEs, there wouldn't be much difference for
>> developers between the "visible" formats of dev vs release code when
>> working on it.
>
> I don't think it matters, as I think that most people interested in
> working on the code will just check out of SVN.
>
>>
>>> for X being a single class. To produce a complete target source base,
>>> walk the single source tree as defined by a 'platform descriptor' :
>>
>> I don't really understand the "platform descriptor" thing, yet I think
>> that it is, somehow, an orthogonal issue to the discussion above.
>> [Remember my long message describing 2 levels of processing:
>> file/directory-level and source-level.] My first prototype tool would
>> attack source-level processing (discussed above), to validate the
>> approach.
>
> Right - the "platform descriptor" is the data that the
> file/directory-level thing uses.
>
>>
>> Maybe you could try rephrasing your file/directory-level (right?)
>> proposal? How does it differ from Tim's proposal?
>
> I get lost in who's proposal is who's. I thought we were working
> towards one collectively owned solution. can you describe what you
> think Tim's, your's and mine are?
>
> geir
>
>