dpp-devel Mailing List for Saros - Distributed Party Programming (Page 2)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2123/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2122/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2121/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2120/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2119/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2118/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2117/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2116/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2115/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2114/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2113/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2112/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2111/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2110/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2109/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2108/>

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2107/>

On 05.05.2017 15:55, Tobias Bouschen wrote:
> @Stefan: It was not clear to me that your intention was to only re-write
> the resource implementation.
> My biggest problem in the whole situation was the lack of communication
> as I did not know what your plans were or rather how you want to proceed.
>
>> I did not create an "alternative implementation". I already told Tobias
>> that those Bound/Unbound approach
>> is not needed if the "delegating" object is an IPATH and not a
>> VIRTUALFILE. So I just dropped the Unbound classes and dropped some
>> code that is not needed but is currently present in IntelliJ because it
>> it present in the interfaces (just because IntelliJ needs it .... )
> Yes, you told me that the splitting was unnecessary, to which I replied
> that I see my error during the design of the new resource implementation
> but that the current design works as well and a redesign would not be
> worth the effort. 
Of course it works, but just saying that another refactoring is not
worth the effort...
Maybe it is not worth when it comes to your changes and overhaul, yes,
i.e. you would have to spend
even more time on something that does not have any impact on the current
logic.

But for the future it might complicate things when you have to work on
unbound/bound resources.
It might be not so clear for new developers why we have to distinguish
here although we only want to work
on VirtualFiles in the end at all.
> That was the full extend of the conversation. I did
> not know that this was still an issue for you, otherwise I would have
> been happy to discuss it with you and do the re-design myself
> (admittedly with a few weeks of delay as I do not have the time right
> now). And even if you wanted to do it yourself, it would have been nice
> to talk about it with me beforehand.
That is normally the issue with big patches. Some conversation parts are
getting lost.
>> I already told Tobias just to continue his stuff. You can then integrate
>> this stuff.
> We discussed that I can just add further patches to the 'big patch'.
> This did address my concern on how to work while the integration of the
> big patch is still ongoing (which probably won't be an issue any more),
> but I was still not sure how the rest of the integration was going to
> proceed. Your actions and comments left me under the impression that you
> were going to integrate (and adjust) the entire patch yourself.
>
> My main concerns with this issue are how we are going to proceed and how
> we can improve our communication to avoid something like this in the future.
Commit early, commit often is the simple answer (this applies to all
developers in the team and not just you).

What I have seen during the past years is sometimes the exact opposite.
Some students (sometimes not even updating their thesis side) just present
a big patch (or a bunch of patch sets) after a few month (sometimes
based on a HEAD that is old as ...).

While it is not obvious it is really frustrating to review such code. It
is even more frustrating to tell them sometimes that they
just have written garbage.

You can also publish drafts and add reviewers to discuss code regarding
functionality and design choices etc.
> Am 05/05/2017 um 15:12 schrieb Zieris, Franz:
>> Franz wrote:
>>
>>> OK, Stefan, here's is your chance: What do you propose?
>>> Please share your conception on how to proceed in this manner.
>> Stefan wrote:
>>
>>> I already told Tobias just to continue his stuff. You can then integrate
>>> this stuff. Take this V2 versions as a "polished" version
>>> of this overhaul.
>>
>> I'm sorry, but I have no clue what this means.
>> @Tobias: Do you know how to "just continue your stuff"?
>>
>> "You can then integrate this stuff" --
>>   who is "you",
>>   what does "integrate" mean here (usually it's: 'push a patch,
>>   work on your reviewer's comments, eventually submit the patch'),
>>   and what precisely is "this stuff"?
>>
>>
>> Stefan wrote:
>>
>>> Tobias patch can be reviewed since 19th April. You do
>>> not have written a single comment since then regarding his patch.
>> That is not helpful.
>> I don't see how this line of argument brings us any closer to finding
>> a way to clean up the filesystem "stuff".
>> (For what's it worth: I do not review patches that do not pass the CI,
>>  unless I have a good reason to do so, e.g. being directly asked by
>>  the patch author.)
>> After all: This is a communication issue between you and Tobias.
>>
>>
>> Stefan wrote:
>>
>>> I do not get your point. I have no grudge against you.
>> I was referring to this quote of yours:
>>
>>> Well, just look at the patches (the abandoned one) containing my name.
>>> Sometimes Franz already revert some of my features. It is
>>> frustrating but you have to deal with it.
>> As frustration is counterproductive, I wanted to know what's going here.
>>
>>
>> Stefan wrote:
>>
>>> just look how many LOCS I have thrown away by
>>> myself a.k.a just because I have written a bunch of code does not mean
>>> it was a good approach etc. to do it that way.
>> True.
>> But it's a completely different type of frustration to throw away one's
>> own work compared to waking up and seeing one's work being invalidated or
>> at least being put into a position where the next steps are less than clear
>> -- and that's how I understood Tobias's position
>> ("this patch has somewhat put me in an awkward position").
>>
>> He explained his concerns, you caused this situation and so far,
>> you did very little to address his concerns.
>> (@Tobias: Stop me if I'm wrong on this one.)
>>
>> So, to move forward:
>> Please share your thoughts on how the filesystem should be reworked.
>> Not only in terms of the desired outcome product-wise, but also
>> regarding the process how to get there:
>> Which parts (existing classes/packages, patches-under-review, ...) are
>> to be worked on by whom and in which order?
>>
>> We need a common understanding of this -- to the very least, you and
>> Tobias.
>>
>> Franz
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> DPP-Devel mailing list
>> DPP...@li...
>> https://lists.sourceforge.net/lists/listinfo/dpp-devel
>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> DPP-Devel mailing list
> DPP...@li...
> https://lists.sourceforge.net/lists/listinfo/dpp-devel

@Stefan: It was not clear to me that your intention was to only re-write
the resource implementation.
My biggest problem in the whole situation was the lack of communication
as I did not know what your plans were or rather how you want to proceed.

> I did not create an "alternative implementation". I already told Tobias
> that those Bound/Unbound approach
> is not needed if the "delegating" object is an IPATH and not a
> VIRTUALFILE. So I just dropped the Unbound classes and dropped some
> code that is not needed but is currently present in IntelliJ because it
> it present in the interfaces (just because IntelliJ needs it .... )

Yes, you told me that the splitting was unnecessary, to which I replied
that I see my error during the design of the new resource implementation
but that the current design works as well and a redesign would not be
worth the effort. That was the full extend of the conversation. I did
not know that this was still an issue for you, otherwise I would have
been happy to discuss it with you and do the re-design myself
(admittedly with a few weeks of delay as I do not have the time right
now). And even if you wanted to do it yourself, it would have been nice
to talk about it with me beforehand.

> I already told Tobias just to continue his stuff. You can then integrate
> this stuff.

We discussed that I can just add further patches to the 'big patch'.
This did address my concern on how to work while the integration of the
big patch is still ongoing (which probably won't be an issue any more),
but I was still not sure how the rest of the integration was going to
proceed. Your actions and comments left me under the impression that you
were going to integrate (and adjust) the entire patch yourself.

My main concerns with this issue are how we are going to proceed and how
we can improve our communication to avoid something like this in the future.

Am 05/05/2017 um 15:12 schrieb Zieris, Franz:
> Franz wrote:
> 
>> OK, Stefan, here's is your chance: What do you propose?
>> Please share your conception on how to proceed in this manner.
> 
> Stefan wrote:
> 
>> I already told Tobias just to continue his stuff. You can then integrate
>> this stuff. Take this V2 versions as a "polished" version
>> of this overhaul.
> 
> 
> I'm sorry, but I have no clue what this means.
> @Tobias: Do you know how to "just continue your stuff"?
> 
> "You can then integrate this stuff" --
>   who is "you",
>   what does "integrate" mean here (usually it's: 'push a patch,
>   work on your reviewer's comments, eventually submit the patch'),
>   and what precisely is "this stuff"?
> 
> 
> Stefan wrote:
> 
>> Tobias patch can be reviewed since 19th April. You do
>> not have written a single comment since then regarding his patch.
> 
> That is not helpful.
> I don't see how this line of argument brings us any closer to finding
> a way to clean up the filesystem "stuff".
> (For what's it worth: I do not review patches that do not pass the CI,
>  unless I have a good reason to do so, e.g. being directly asked by
>  the patch author.)
> After all: This is a communication issue between you and Tobias.
> 
> 
> Stefan wrote:
> 
>> I do not get your point. I have no grudge against you.
> 
> I was referring to this quote of yours:
> 
>> Well, just look at the patches (the abandoned one) containing my name.
>> Sometimes Franz already revert some of my features. It is
>> frustrating but you have to deal with it.
> 
> As frustration is counterproductive, I wanted to know what's going here.
> 
> 
> Stefan wrote:
> 
>> just look how many LOCS I have thrown away by
>> myself a.k.a just because I have written a bunch of code does not mean
>> it was a good approach etc. to do it that way.
> 
> True.
> But it's a completely different type of frustration to throw away one's
> own work compared to waking up and seeing one's work being invalidated or
> at least being put into a position where the next steps are less than clear
> -- and that's how I understood Tobias's position
> ("this patch has somewhat put me in an awkward position").
> 
> He explained his concerns, you caused this situation and so far,
> you did very little to address his concerns.
> (@Tobias: Stop me if I'm wrong on this one.)
> 
> So, to move forward:
> Please share your thoughts on how the filesystem should be reworked.
> Not only in terms of the desired outcome product-wise, but also
> regarding the process how to get there:
> Which parts (existing classes/packages, patches-under-review, ...) are
> to be worked on by whom and in which order?
> 
> We need a common understanding of this -- to the very least, you and
> Tobias.
> 
> Franz
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> DPP-Devel mailing list
> DPP...@li...
> https://lists.sourceforge.net/lists/listinfo/dpp-devel
> 

On 05.05.2017 15:12, Zieris, Franz wrote:
> Franz wrote:
>
>> OK, Stefan, here's is your chance: What do you propose?
>> Please share your conception on how to proceed in this manner.
> Stefan wrote:
>
>> I already told Tobias just to continue his stuff. You can then integrate
>> this stuff. Take this V2 versions as a "polished" version
>> of this overhaul.
>
> I'm sorry, but I have no clue what this means.
His version: bound/unbound IResources, my modification of his current
work = no need to distinguish between unbound/bound resources.

So switching from his overhaul to the polished overhaul (which is not
even finished yet) is just a a renaming. Of course he does not need to
do that. I can do that.

To say it again, these V2 version are not my versions. It is basically
the work of Tobias with just a small modifications.
> @Tobias: Do you know how to "just continue your stuff"?
>
> "You can then integrate this stuff" --
>   who is "you",
>   what does "integrate" mean here (usually it's: 'push a patch,
>   work on your reviewer's comments, eventually submit the patch'),
>   and what precisely is "this stuff"?
>
It is the integration of this patch:
http://saros-build.imp.fu-berlin.de/gerrit/#/c/3310/3
Feel free to give an good advice on how to split it, or: if you do not
have any concerns we can just commit this big patch.

> Stefan wrote:
>
>> Tobias patch can be reviewed since 19th April. You do
>> not have written a single comment since then regarding his patch.
> That is not helpful.
> I don't see how this line of argument brings us any closer to finding
> a way to clean up the filesystem "stuff".
> (For what's it worth: I do not review patches that do not pass the CI,
>  unless I have a good reason to do so, e.g. being directly asked by
>  the patch author.)
> After all: This is a communication issue between you and Tobias.
Tobias already mentioned that he has problems to fix the test cases. The
patch itself compiles.

So my idea is (with anything said above).

Add IResource/IFile/IFolder (bound and  unbound). Add anything else
which should be mainly the resource handling stuff in the
SharedResourceManager, FilesystemChangeListener.

The modifications need to setup the module stuff (e.g selecting them for
sharing on the host side and creating / selecting them on the receiving
side).

But I have my doubts that this patch can be split in a good way because
the whole new implementation of Tobias replaces the old filesystem and
therefore the modifications of other parts (SharedResourceManager etc.)
have to be present as well.

Again the V2 versions are just the cleanup. They still rely on the
complete overhaul and cannot be integrated anyway until the overhaul is
committed (unless I enjoy debugging things twice which I do not).

TLDR: just ignore the V2 versions, focus on Tobias modifications.
>
> Stefan wrote:
>
>> I do not get your point. I have no grudge against you.
> I was referring to this quote of yours:
>
>> Well, just look at the patches (the abandoned one) containing my name.
>> Sometimes Franz already revert some of my features. It is
>> frustrating but you have to deal with it.
> As frustration is counterproductive, I wanted to know what's going here.
>
>
> Stefan wrote:
>
>> just look how many LOCS I have thrown away by
>> myself a.k.a just because I have written a bunch of code does not mean
>> it was a good approach etc. to do it that way.
> True.
> But it's a completely different type of frustration to throw away one's
> own work compared to waking up and seeing one's work being invalidated or
> at least being put into a position where the next steps are less than clear
> -- and that's how I understood Tobias's position
> ("this patch has somewhat put me in an awkward position").
>
> He explained his concerns, you caused this situation and so far,
> you did very little to address his concerns.
> (@Tobias: Stop me if I'm wrong on this one.)
>
> So, to move forward:
> Please share your thoughts on how the filesystem should be reworked.
> Not only in terms of the desired outcome product-wise, but also
> regarding the process how to get there:
> Which parts (existing classes/packages, patches-under-review, ...) are
> to be worked on by whom and in which order?
>
> We need a common understanding of this -- to the very least, you and
> Tobias.
>
> Franz
>

Franz wrote:

> OK, Stefan, here's is your chance: What do you propose?
> Please share your conception on how to proceed in this manner.

Stefan wrote:

> I already told Tobias just to continue his stuff. You can then integrate
> this stuff. Take this V2 versions as a "polished" version
> of this overhaul.

I'm sorry, but I have no clue what this means.
@Tobias: Do you know how to "just continue your stuff"?

"You can then integrate this stuff" --
  who is "you",
  what does "integrate" mean here (usually it's: 'push a patch,
  work on your reviewer's comments, eventually submit the patch'),
  and what precisely is "this stuff"?

Stefan wrote:

> Tobias patch can be reviewed since 19th April. You do
> not have written a single comment since then regarding his patch.

That is not helpful.
I don't see how this line of argument brings us any closer to finding
a way to clean up the filesystem "stuff".
(For what's it worth: I do not review patches that do not pass the CI,
 unless I have a good reason to do so, e.g. being directly asked by
 the patch author.)
After all: This is a communication issue between you and Tobias.

Stefan wrote:

> I do not get your point. I have no grudge against you.

I was referring to this quote of yours:

> Well, just look at the patches (the abandoned one) containing my name.
> Sometimes Franz already revert some of my features. It is
> frustrating but you have to deal with it.

As frustration is counterproductive, I wanted to know what's going here.

Stefan wrote:

> just look how many LOCS I have thrown away by
> myself a.k.a just because I have written a bunch of code does not mean
> it was a good approach etc. to do it that way.

True.
But it's a completely different type of frustration to throw away one's
own work compared to waking up and seeing one's work being invalidated or
at least being put into a position where the next steps are less than clear
-- and that's how I understood Tobias's position
("this patch has somewhat put me in an awkward position").

He explained his concerns, you caused this situation and so far,
you did very little to address his concerns.
(@Tobias: Stop me if I'm wrong on this one.)

So, to move forward:
Please share your thoughts on how the filesystem should be reworked.
Not only in terms of the desired outcome product-wise, but also
regarding the process how to get there:
Which parts (existing classes/packages, patches-under-review, ...) are
to be worked on by whom and in which order?

We need a common understanding of this -- to the very least, you and
Tobias.

Franz

See below

On 05.05.2017 14:20, Zieris, Franz wrote:
> Franz asked:
>
>> Sounds like something bigger (?) that should have been discussed on the
>> mailing list.
>>
>> @Stefan, @Tobias: Could you spare a few words on this?
> Stefan (forgetting to include dpp-devel in CC) answered:
>
>> http://saros-build.imp.fu-berlin.de/gerrit/#/c/3314/
>
> For further reference, I copy the discussion from there:
> (new content follows below the ===== line)
>
> Stefan wrote:
>
>> Just FYI. I am starting to integrate some parts of your big patch.
>> It is not the original code. As I already stated, we do not need
>> Unbound stuff if we are working with paths instead of virtual file
>> objects.
> Tobias wrote:
>
>> I don't want to sound ungrateful (as I currently am somewhat low on
>> time and therefore appreciate your efforts to integrate my patch),
>> but this patch has somewhat put me in an awkward position.
>>
>> Firstly, it is kind of harsh to work on something for multiple weeks
>> and then only see a tiny sliver of it make it into your integration
>> (I am aware that this is a very streamlined version throwing out all
>> the unneeded code written for future expandability; these were
>> written before the prototype nature of the current implementation
>> was made clear to me). I know this is more of a personal problem,
>> but I hope you can see where I am coming from.
>>
>> Secondly (and more importantly), this somewhat complicates my further
>> work as I am still set on fixing the functionality concerning the
>> change of the session scope (SharedResorucesManger and
>> FileSystemChangeListener).
>> What am I supposed to base these fixes on? I have no frame of
>> reference how long the integration is going to take and when it
>> will be at a testable point.
>> Should I just base it on my original big patch? And how am I
>> supposed to push it in that case?
>>
>> Furthermore, I would like to do the integration work myself in the
>> future as it is part of the work (and learning) experience and I am
>> the one who is going to work with it afterwards, which is much
>> easier if I have written and integrated the code myself.
>>
>> As I already said, I appreciate your work, especially since the
>> scope of the patch got way out of hand and I am running low on
>> time. I hope that all of this will work more smoothly in the future.
>>
>> I also don't know how I should proceed with the big patch. Should
>> I still push the last patchset with the small changes I already noted?
>> Should I complete the classes written in this patch? What was your
>> thinking on how this is supposed to proceed? Are you going to do the
>> entire integration and re-re-implementation yourself?
> Stefan wrote: 
>
>> Well, just look at the patches (the abandoned one) containing my name.
>> Sometimes Franz already revert some of my features. It is
>> frustrating but you have to deal with it.
>>
>> But I already told you that you do not need Unbound resources if
>> you are working with paths instead of virtual files.
>>
>> Just because someone writes a big bunch of code does not give
>> him/her the rights to insist that the code gets committed.
>>
>> As for the bug fixing stuff, just do it in your big patch.
>>
>> The splitting after you are finished shouldn't be that hard,
>> believe me. It is basically a just renaming stuff after the V2
>> files are ready.
> =====================================================================
>
> Here is what I take from this:
>  * Tobias worked on the IntelliJ filesystem quite some time, discussing
>    his patches with Stefan.
>  * Stefan created an alternative implementation without discussing it with
>    Tobias, and without proposing a procedure on how to integrate the efforts.
I did not create an "alternative implementation". I already told Tobias
that those Bound/Unbound approach
is not needed if the "delegating" object is an IPATH and not a
VIRTUALFILE. So I just dropped the Unbound classes and dropped some
code that is not needed but is currently present in IntelliJ because it
it present in the interfaces (just because IntelliJ needs it .... )
>  * Tobias complained about this, asking on how to proceed.
>  * Stefan did not answer with a proposal on how to proceed, but seems to have
>    something in mind ("after the V2 files are ready")
>
> OK, Stefan, here's is your chance: What do you propose?
> Please share your conception on how to proceed in this manner.
I already told Tobias just to continue his stuff. You can then integrate
this stuff. Take this V2 versions as a "polished" version
of this overhaul. Tobias patch can be reviewed since 19th April. You do
not have written a single comment since then regarding his patch.
> On a different note: It sounds like you, Stefan, are in for "egoless
> programming", but at the same time, you seem to hold some grudge against
> me for "reverting some of your features".
> I honestly have no idea what you're referring to.
> The last time I git-reverted one of your commits was in 2012 [1,2].
> In terms of Gerrit patches [3], I stopped looking when I reached 2014:
I do not get your point. I have no grudge against you. Maybe I was a
little bit p**** for several hours, that's all.
> I did not abandon any of your patches.
I never said that. I said: just look how many LOCS I have thrown away by
myself a.k.a just because I have written a bunch of code does not mean
it was a good approach etc. to do it that way.
> So: What's the matter here?
>
> Franz
>
> [1] git log --author=zieris --grep=Revert"
> [2] https://github.com/saros-project/saros/commit/a6ae0ef3567f
> [3] http://saros-build.imp.fu-berlin.de/gerrit/#/q/owner:srossbach%2540arcor.de+status:abandoned

Franz asked:

> Sounds like something bigger (?) that should have been discussed on the
> mailing list.
>
> @Stefan, @Tobias: Could you spare a few words on this?

Stefan (forgetting to include dpp-devel in CC) answered:

> http://saros-build.imp.fu-berlin.de/gerrit/#/c/3314/

For further reference, I copy the discussion from there:
(new content follows below the ===== line)

Stefan wrote:

> Just FYI. I am starting to integrate some parts of your big patch.
> It is not the original code. As I already stated, we do not need
> Unbound stuff if we are working with paths instead of virtual file
> objects.

Tobias wrote:

> I don't want to sound ungrateful (as I currently am somewhat low on
> time and therefore appreciate your efforts to integrate my patch),
> but this patch has somewhat put me in an awkward position.
>
> Firstly, it is kind of harsh to work on something for multiple weeks
> and then only see a tiny sliver of it make it into your integration
> (I am aware that this is a very streamlined version throwing out all
> the unneeded code written for future expandability; these were
> written before the prototype nature of the current implementation
> was made clear to me). I know this is more of a personal problem,
> but I hope you can see where I am coming from.
>
> Secondly (and more importantly), this somewhat complicates my further
> work as I am still set on fixing the functionality concerning the
> change of the session scope (SharedResorucesManger and
> FileSystemChangeListener).
> What am I supposed to base these fixes on? I have no frame of
> reference how long the integration is going to take and when it
> will be at a testable point.
> Should I just base it on my original big patch? And how am I
> supposed to push it in that case?
>
> Furthermore, I would like to do the integration work myself in the
> future as it is part of the work (and learning) experience and I am
> the one who is going to work with it afterwards, which is much
> easier if I have written and integrated the code myself.
>
> As I already said, I appreciate your work, especially since the
> scope of the patch got way out of hand and I am running low on
> time. I hope that all of this will work more smoothly in the future.
>
> I also don't know how I should proceed with the big patch. Should
> I still push the last patchset with the small changes I already noted?
> Should I complete the classes written in this patch? What was your
> thinking on how this is supposed to proceed? Are you going to do the
> entire integration and re-re-implementation yourself?

Stefan wrote: 

> Well, just look at the patches (the abandoned one) containing my name.
> Sometimes Franz already revert some of my features. It is
> frustrating but you have to deal with it.
>
> But I already told you that you do not need Unbound resources if
> you are working with paths instead of virtual files.
>
> Just because someone writes a big bunch of code does not give
> him/her the rights to insist that the code gets committed.
>
> As for the bug fixing stuff, just do it in your big patch.
>
> The splitting after you are finished shouldn't be that hard,
> believe me. It is basically a just renaming stuff after the V2
> files are ready.

=====================================================================

Here is what I take from this:
 * Tobias worked on the IntelliJ filesystem quite some time, discussing
   his patches with Stefan.
 * Stefan created an alternative implementation without discussing it with
   Tobias, and without proposing a procedure on how to integrate the efforts.
 * Tobias complained about this, asking on how to proceed.
 * Stefan did not answer with a proposal on how to proceed, but seems to have
   something in mind ("after the V2 files are ready")

OK, Stefan, here's is your chance: What do you propose?
Please share your conception on how to proceed in this manner.

On a different note: It sounds like you, Stefan, are in for "egoless
programming", but at the same time, you seem to hold some grudge against
me for "reverting some of your features".
I honestly have no idea what you're referring to.
The last time I git-reverted one of your commits was in 2012 [1,2].
In terms of Gerrit patches [3], I stopped looking when I reached 2014:
I did not abandon any of your patches.
So: What's the matter here?

Franz

[1] git log --author=zieris --grep=Revert"
[2] https://github.com/saros-project/saros/commit/a6ae0ef3567f
[3] http://saros-build.imp.fu-berlin.de/gerrit/#/q/owner:srossbach%2540arcor.de+status:abandoned

Hi there,

we currently have not automated mirroring from Gerrit to GitHub and SourceForge,
and whenever I remember this, I will push the most recent changes manually.
That's way the dpp-robot commit e-mails tend come in batches.

A particularly large batch was due on Wednesday (13 commits, +1009 lines, [1]).
I just had the time to look at it:

----
 create mode 100644 de.fu_berlin.inf.dpp.intellij/src/de/fu_berlin/inf/dpp/intellij/filesystem/Filesystem.java
 create mode 100644 de.fu_berlin.inf.dpp.intellij/src/de/fu_berlin/inf/dpp/intellij/filesystem/IntelliJFileImplV2.java
 create mode 100644 de.fu_berlin.inf.dpp.intellij/src/de/fu_berlin/inf/dpp/intellij/filesystem/IntelliJFolderImplV2.java
 create mode 100644 de.fu_berlin.inf.dpp.intellij/src/de/fu_berlin/inf/dpp/intellij/filesystem/IntelliJProjectImplV2.java
 create mode 100644 de.fu_berlin.inf.dpp.intellij/src/de/fu_berlin/inf/dpp/intellij/filesystem/IntelliJResourceImplV2.java
----

Sounds like something bigger (?) that should have been discussed on the mailing list.

@Stefan, @Tobias: Could you spare a few words on this?

Thanks,
Franz

[1] https://sourceforge.net/p/dpp/mailman/message/35820223/

See <http://saros-build-old.imp.fu-berlin.de/jenkins/job/Saros-Eclipse-STF-Nightly/2106/>

2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (2)	Nov	Dec
2009	Jan (1)	Feb	Mar	Apr	May	Jun (4)	Jul (1)	Aug	Sep	Oct (61)	Nov (88)	Dec (27)
2010	Jan (55)	Feb (93)	Mar (133)	Apr (148)	May (92)	Jun (56)	Jul (110)	Aug (28)	Sep (229)	Oct (93)	Nov (137)	Dec (91)
2011	Jan (62)	Feb (207)	Mar (157)	Apr (59)	May (122)	Jun (56)	Jul (105)	Aug (154)	Sep (64)	Oct (232)	Nov (224)	Dec (60)
2012	Jan (93)	Feb (251)	Mar (571)	Apr (205)	May (82)	Jun (48)	Jul (49)	Aug (34)	Sep (69)	Oct (22)	Nov (85)	Dec (41)
2013	Jan (30)	Feb (50)	Mar (66)	Apr (37)	May (11)	Jun (36)	Jul (40)	Aug (20)	Sep (9)	Oct (9)	Nov (28)	Dec (38)
2014	Jan (19)	Feb (20)	Mar (11)	Apr (5)	May (16)	Jun (26)	Jul (50)	Aug (60)	Sep (75)	Oct (49)	Nov (37)	Dec (9)
2015	Jan (20)	Feb (51)	Mar (72)	Apr (33)	May (22)	Jun (35)	Jul (38)	Aug (47)	Sep (48)	Oct (21)	Nov (47)	Dec (31)
2016	Jan (57)	Feb (42)	Mar (23)	Apr (21)	May (27)	Jun (9)	Jul (10)	Aug (43)	Sep (69)	Oct (30)	Nov (27)	Dec (34)
2017	Jan (34)	Feb (38)	Mar (35)	Apr (35)	May (40)	Jun (10)	Jul (6)	Aug	Sep	Oct	Nov	Dec

dpp-devel Mailing List for Saros - Distributed Party Programming (Page 2)

dpp-devel — [THIS LIST HAS BEEN MOVED TO GOOGLE GROUPS - "https://groups.google.com/forum/#!forum/saros-devel"] Developer List for Saros