----- Original Message ----- > From: "Vladimir Prus" <vladi...@codesourcery.com> > To: "Linux Tools developer discussions" <linuxtools-dev@eclipse.org> > Sent: Wednesday, November 27, 2013 7:21:34 PM > Subject: Re: [linuxtools-dev] How to use the > org.eclipse.linuxtools.perf plugin > > On 27.11.2013 19:48, Roland Grunberg wrote: > >> Dmitry, > >> Would you please clarify this? Do you mean that a patch was not reviewed > >> or > >> rejected without reasoning or that none of the current committers was > >> interested in working on this at the time? > >> > >> If nothing else Linux Tools tries to be really open so please refer to the > >> bugzilla or gerrit patch in case your contribution was rejected for the > >> publicity record. > >> We don't have endless manpower but we always try to onboard people > >> interested > >> in working on Linux Tools according to EDP and I see this as one of the > >> biggest virtues of the projects so if we failed on doing that I would like > >> to check it myself and learn where a mistake was made. > >> P.S. I made have replied or not but my memory is vague about it. > > > > I believe Dmitry is referring to > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=376043 . > > > > There was another implementation submitted that matched more closely with > > how other > > plugins' remote capabilities were being done (ie. through PTP). > > Maybe that could have been handled a bit more openly.
I would not question that, unfortunately things don't happen magically and they require both existing committers and people trying to contribute to check what others are doing. > We did remote OProfile > support, > including substantial refactoring of the code, and tried to submit it > upstream, and then, > after some back-and-forth, the final message we've got was: > > Another remote oprofile implementation was committed by existing > committers and is > part of 1.2 release. We hope that you will help us make it even better. > > It was not explained by anybody why that another implementation is better. The thing is that I can not explain whether one or the other is better. What I can point is that it was done by existing committers who has added remote capabilities to other Linux Tools plugins so at least some consistency was kept. I just double check with Rodrigo (who pushed the alternative implementation) and he was not even aware of your implementation. This points at least 2 problems which are not that easy to overcome: * existing committers don't keep an eye on the bugzilla/gerrit queues in general but on things they care for only leaving all the rest to the project leads which leads to situation like this * contributors need to be more vocal and connect to interested parties (I would bet that guys working on current remote capabilities would love to get some help). Also once the new implementation was in it would have been easier and better if deficiencies was pointed out at the time if any. > And I still > don't understand overall strategy of LinuxTools. So now that we did the same > with perf > (support for local-cross-build-and-remote-execution), it's pretty hard to > justify, > to oneself, or to my manager, the benefits of submitting it upstream - even > though we'd > like to. Strategy is big word for Linux Tools. I would say that Linux Tools strategy is to get as much as possible functionality in a consistent and supportable way. And simple things like "if someone commits first, we continue from there" are taken for given. I believe that we had only one such case and this is the case we already discuss, at least I don't remember another one. Overall, we would like to get more contributors and welcome everyone into the project. So submitting it upstream is definetely what I as project lead am looking for and also I'm looking for existing committers interested in remote capabilities to keep track with such contributions so we can get better product at the end. Alexander Kurtakov Red Hat Eclipse team > > Thanks, > > -- > Vladimir Prus > CodeSourcery / Mentor Graphics > http://www.mentor.com/embedded-software/ > _______________________________________________ > linuxtools-dev mailing list > linuxtools-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/linuxtools-dev > _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
