harmony-dev mailing list archives

Tim Ellison wrote:
> 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.
>
> I believe that there will still be a role for branches, both for
> sandboxes to experiment as Etienne said, and for the maintenance streams
> of our releases.
Of course we aren't going to ban branches. The context is branching for
mainline code. Lets stay focused...
>
>>>> 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.
>
> Agreed -- our src.jar will be 'normal' Java code without multi-target
> mark-ups.
>
> <snip>
>
>>> 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.
>
> There are multiple 'devtarget's -- each contains all the source code
> marked-up for every target being developed, but each is distinct by
> having different targets uncommented. Since each devtarget contains the
> entire source code it is possible to accurately transform from any one
> devtarget to any other devtarget. One of the devtargets is actually
> stored in svn, and that is the canonical form of the devtarget code.
So that's 'master'. and everythign else is a transformed master, right?
>
>> 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.
>
> Screech -- the releasetarget, by definition, does not contain the source
> for all possible targets so that it is consumable by end-users.
That is correct.
The only code that contains all code is master.
>
>> So what to do with a patch?
>>
>> I can either
>>
>> patch -p0 << reverse(patch.file)
>
> I don't understand how you will ensure there is enough information in
> patch.file to make the reverse() function exact? I proposed that our
> releasetarget code contains tie-points where it is out of sync with the
> closest devtarget by some number of lines.
I don't understand why you'd bother. If you know that patch P creates
Y' from a given Y, and you can always create Y as you know everything to
do the xform from master source and the platform name, everything is known.
>
>> 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?
>
> It's all one proposal. Etienne's principal idea with a few others
> meddling on the side :-)
>
> Regards,
> Tim
>