On 03/26/2012 09:59 AM, Andrew Overholt wrote:
* sami wagiaalla [2012-03-26 09:55]:
If you don't want to sign for something being an API please move it to
org.eclipse.linuxtools.internal. packages.
I have done this for o.e.l.rpm*. I'll start pushing the patches one
at a time shortly.
* sami wagiaalla [2012-03-26 09:55]:
>
>
> >If you don't want to sign for something being an API please move it to
> >org.eclipse.linuxtools.internal. packages.
>
> I have done this for o.e.l.rpm*. I'll start pushing the patches one
> at a time shortly.
There are consumers of that API (Fedor
Sami,
Have you seen my changes? Please do not push things that can break
fedorapackager functionality.
Alex
On Mar 26, 2012 9:55 AM, "sami wagiaalla" wrote:
>
>
> If you don't want to sign for something being an API please move it to
>> org.eclipse.linuxtools.**internal. packages.
>>
>
> I hav
If you don't want to sign for something being an API please move it to
org.eclipse.linuxtools.internal. packages.
I have done this for o.e.l.rpm*. I'll start pushing the patches one at a
time shortly.
___
linuxtools-dev mailing list
linuxtools-d
Aleksandar Kurtakov wrote on 03/22/2012 03:22:54 PM:
> I fully support the all-internal approach and after doing that to
> the man-page and rpmstubby projects they have two exported classes
> each. In the rpmstubby case it even led to simplifying/unifying the
codebase.
> But I think that we sho
other things.
Clean subprojects from that point of view are: gcov, gprof, man, rpmstubby,
rpm, perf, valgrind
Alex
- Original Message -
> From: "Aleksandar Kurtakov"
> To: "Linux Tools developer discussions"
> Sent: Thursday, March 22, 2012 9:22:
- Original Message -
> From: "John Arthorne"
> To: "Andrew Overholt" , "Linux Tools developer
> discussions"
> Sent: Thursday, March 22, 2012 8:48:33 PM
> Subject: Re: [linuxtools-dev] API for 1.0
>
>
> Andrew Overholt wrote on
Andrew Overholt wrote on 03/21/2012 02:25:42 PM:
> Please take a look at the Javadocs for our nightly build:
>
> https://hudson.eclipse.org/hudson/job/linuxtools-master/javadoc/
>
> There is still a *lot* of API exposed. If that's intention, great, but
> if not, we need to fix it ASAP.
>From
Hi,
> I've opened a bunch of bugs to deal with the exposed API. Being able to
> see things in the javadocs of the nightly builds is a quick way to see
> how we're doing :)
Please take a look at the Javadocs for our nightly build:
https://hudson.eclipse.org/hudson/job/linuxtools-master/javadoc
Hi,
> In preparation for our 1.0 release we finally come to a state where we
> have to care about an API.
Thanks for sending this and for getting the build fixed up!
> [...] have to keep this API for the whole Juno timeframe.
Actually, until we go to 2.0 (we could theoretically do 1.1, 1.2, etc
Hi everyone,
One more boring email:)
In preparation for our 1.0 release we finally come to a state where we have to
care about an API. Something we have never done before in this project so there
will be hard issues to fix I'm sure.
First of all we should follow Eclipse Naming Conventions
(h
11 matches
Mail list logo