Re: Making Website Update Part of Release Process

[Stack]

On Mon, Sep 14, 2015 at 10:14 PM, Stack  wrote:

> They are up now looking at latest mirror:
> http://mirrors.gigenet.com/apache/incubator/htrace/
>
> Doc on how to release is coming.
>
>
A start on RM doc can be found here:
http://htrace.incubator.apache.org/building.html



> On how to update the website, currently best doc is in HTRACE-19. I can
> update in morning unless you beat me to it.
>
>
Here is how to update website:
http://htrace.incubator.apache.org/building.html#Publishing_htraceincubatorapacheorg_website

St.Ack



> Thanks Lewis,
> St.Ack
>
>
>
>
>
> On Mon, Sep 14, 2015 at 9:41 PM, Lewis John Mcgibbney <
> lewis.mcgibb...@gmail.com> wrote:
>
>> Hi Folks,
>> Excellent work on getting recent 4.0.0-incubating release out the door.
>> I wonder if there is documentation available for a release manager? If so
>> does it currently contain advice on how to update the HTrace website with
>> the info for the release?
>> Right now I don't even see the HTrace artifacts available
>> http://www.apache.org/dyn/closer.cgi/incubator/htrace/
>> I am assuming they are not available for public consumption yet.
>> Is this the case?
>> Thanks
>> Lewis
>>
>> --
>> *Lewis*
>>
>
>

Build failed in Jenkins: HTrace-Master #79

[Apache Jenkins Server]

See 

Changes:

[iwasakims] HTRACE-246. HTrace WebApp not properly defined and therefore not 
packaged into .war (Lewis John McGibbney via iwasakims)

[stack] HTRACE-250 Fix the markdown in index.md

--
[...truncated 719 lines...]
Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Build failed in Jenkins: HTrace-Master #78

[Apache Jenkins Server]

See 

Changes:

[stack] HTRACE-249 Script and doc on how to publish website

[stack] HTRACE-249 Script and doc on how to publish website

--
[...truncated 722 lines...]
Building tree for all the packages and classes...
Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Re: htrace-core compatibility policy for htrace 4.x

[Masatake Iwasaki]

I agree with the policy.


> Major releases should change the namespace of htrace-core classes so that
> both a 4.x and a 5.x jar can reside on the same CLASSPATH

Should we have a namespace convention for this?
We moved classes from org.apache.htrace to org.apache.htrace.core on 4.0
but need new word other than "core" for 5.0.
Simple way for this would be containing version number in package name
like "org.apache.htrace.5".


> Let's focus on just compatibility rules for htrace-core right now,
> since that's where our integration issues are. The other subprojects
> of htrace generally don't have the same integration issues.

I thinks it is reasonable.
Any version of receiver with the same major version keeps working
as far as htrace-core keeps compatibility.


Thanks,
Masatake Iwasaki


On 9/15/15 09:13, Colin McCabe wrote:

Hi all,

In the recent 4.0 release, we changed the htrace-core API. The API
that programs use to create traces, annotations, etc. (aka the "Java
client API") went through some changes. This was necessary to clean up
some core architectural issues (such as the use of overly short 64 bit
IDs that will collide in a real-world deployment, or the overuse of
globals.)

Since we want to make it easy for projects to integrate with HTrace, I
think we should have some compatibility rules for htrace-core for the
future.

Specifically, I think that we should include only backwards-compatible
changes to the htrace-core API in HTrace 4.x So, for example, adding a
new function is OK. Deleting an existing function or altering it in an
incompatible way is not. It is OK to add a new function to a public
abstract base class (provided you also add a default implementation in
the base), but not to add a new function to a public interface, since
that would break compilation.

We should save incompatible changes for HTrace 5.x. In general, each
"major release" such as 4.x or 5.x should contain only compatible
changes to htrace-core. There should be no guarantees between 4.x and
5.x, or between any major releases-- this is the time to address
architectural debt that can't be resolved any other way. Major
releases should change the namespace of htrace-core classes so that
both a 4.x and a 5.x jar can reside on the same CLASSPATH, similar to
how we did with 3.x and 4.x. This is important because it will require
some time for downstream projects to upgrade from 4.x to 5.x, and in
the meantime we must avoid CLASSPATH conflict issues. There is no
requirement that tracing work when the major version of the client and
the span receivers are different. However, the programs themselves
should function.

Let's focus on just compatibility rules for htrace-core right now,
since that's where our integration issues are. The other subprojects
of htrace generally don't have the same integration issues. For
example, it is easy for an admin to standardize on a single version of
htrace-hbase or htrace-htraced across the entire cluster. They simply
install the jars for the version they want. It is not easy for that
same admin to standardize htrace-core, since they might have Hadoop
pulling in 4.1 and HBase pulling in 4.0. The different subprojects are
also at different levels of maturity. For example, htrace-flume is
still very immature, whereas htrace-htraced is starting to get more
mature. So I think the subprojects should come up with their own
compatibility policies rather than trying to be one-size-fits-all.

This policy should only apply to publicly visible symbols in
htrace-core, not to private or package-private symbols.  Test
functions should also not be covered, since they don't appear in the
final htrace-core jar.

I think having a compatibility policy for htrace-core will be very
nice for the users of our core APIs. Let me know what you think.

best,
Colin

Build failed in Jenkins: HTrace-Master #77

[Apache Jenkins Server]

See 

Changes:

[cmccabe] HTRACE-241. Add docker image for HTrace (Jake Farrell via Colin P.  
McCabe)

--
[...truncated 4178 lines...]
Building tree for all the packages and classes...
Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Re: incubator result tally

[Colin P. McCabe]

Thanks, Billie.  Next time I will list the names of the voters.

best,
Colin

On Tue, Sep 15, 2015 at 6:48 AM, Billie Rinaldi  wrote:
> On Sat, 12 Sep 2015 at 17:50, Colin P. McCabe  wrote:
>> With 5 +1s, the vote passes.
>> Thanks, all.
>>
>> cheers,
>> Colin
>
> Hey Colin,
>
> It's customary to state the incubator vote result in terms of the number of
> IPMC member (binding) votes and the number of non-binding votes, since 3
> IPMC +1s are required for a podling release.  Often people list the names
> of the voters so it's easier to verify them.  Fortunately we have 3 IPMC
> members voting in this case.  :-)
>
> Billie

incubator result tally

[Billie Rinaldi]

On Sat, 12 Sep 2015 at 17:50, Colin P. McCabe  wrote:
> With 5 +1s, the vote passes.
> Thanks, all.
>
> cheers,
> Colin

Hey Colin,

It's customary to state the incubator vote result in terms of the number of
IPMC member (binding) votes and the number of non-binding votes, since 3
IPMC +1s are required for a podling release.  Often people list the names
of the voters so it's easier to verify them.  Fortunately we have 3 IPMC
members voting in this case.  :-)

Billie