Commons is TLP

Hi everyone,

The new Commons TLP was established today, with Torsten Curdt as Vice President.

Mvgr,
Martin

Re: Commons is TLP

On 21.06.2007, at 00:57, Martin van den Bemt wrote:

> Hi everyone,
>
> The new Commons TLP was established today, with Torsten Curdt as
> Vice President.

....so where do we start with the TLP move is the question :)

cheers
--
Torsten

Re: Commons is TLP

The commons one is probably less straight forward, although could be a lot easier. Since there was a
commons in the past, it could well be that you don't need to do a lot (website, mailinglists, etc
already there), besides setting up the karma for the people, moving over the website, etc,etc.. So
probably best to figure out on infrastructure how to approach this specific situation.

Mvgr,
Martin

Torsten Curdt wrote:
>
> On 21.06.2007, at 00:57, Martin van den Bemt wrote:
>
>> Hi everyone,
>>
>> The new Commons TLP was established today, with Torsten Curdt as Vice
>> President.
>
> ...so where do we start with the TLP move is the question :)
>
> cheers
> --
> Torsten
>
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>

Re: Commons is TLP

There is a Velocity JIRA Issue with a lot of subtasks that basically has
everything that is needed/can be done for a new TLP. Scott cloned it for
Turbine, so it is TRB-44 and INFRA-1249. These might be good starting
points.

Best regards
Henning

Torsten Curdt schrieb:
>
> On 21.06.2007, at 00:57, Martin van den Bemt wrote:
>
>> Hi everyone,
>>
>> The new Commons TLP was established today, with Torsten Curdt as Vice
>> President.
>
> ...so where do we start with the TLP move is the question :)
>
> cheers
> --
> Torsten
>
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>

--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
Open Source Consulting, Development, Design | Velocity - Turbine

"Save the cheerleader. Save the world."

Re: Commons is TLP

Martin van den Bemt wrote:
> The commons one is probably less straight forward, although could be a lot easier. Since there was a
> commons in the past, it could well be that you don't need to do a lot (website, mailinglists, etc
> already there), besides setting up the karma for the people, moving over the website, etc,etc.. So
> probably best to figure out on infrastructure how to approach this specific situation.

This also raises the question how the HttpClient 3.x code
should be managed. Path-wise it is part of commons in SVN:
/jakarta/commons/proper/httpclient
but it is maintained by HttpComponents which doesn't move
to the Commons TLP. If it isn't too much effort for infra,
I would suggest to keep that part of the tree under Jakarta
karma control. Either in place, or by moving it to the
HttpComponents part of the repository, for example as
/jakarta/httpcomponents/oachttpclient
or
/jakarta/httpcomponents/httpclient3x

cheers,
Roland

Re: Commons is TLP

+1 to keep httpclient and move it to httpcomponents.

Mvgr,
Martin

Roland Weber wrote:
> Martin van den Bemt wrote:
>> The commons one is probably less straight forward, although could be a lot easier. Since there was a
>> commons in the past, it could well be that you don't need to do a lot (website, mailinglists, etc
>> already there), besides setting up the karma for the people, moving over the website, etc,etc.. So
>> probably best to figure out on infrastructure how to approach this specific situation.
>
> This also raises the question how the HttpClient 3.x code
> should be managed. Path-wise it is part of commons in SVN:
> /jakarta/commons/proper/httpclient
> but it is maintained by HttpComponents which doesn't move
> to the Commons TLP. If it isn't too much effort for infra,
> I would suggest to keep that part of the tree under Jakarta
> karma control. Either in place, or by moving it to the
> HttpComponents part of the repository, for example as
> /jakarta/httpcomponents/oachttpclient
> or
> /jakarta/httpcomponents/httpclient3x
>
> cheers,
> Roland
>
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
>

Re: Commons is TLP

Don't go the subtask route. Keep it all on the one issue as TLP Admin
and Joe'll take care of things.

Hen

On 6/22/07, Henning Schmiedehausen wrote:
> There is a Velocity JIRA Issue with a lot of subtasks that basically has
> everything that is needed/can be done for a new TLP. Scott cloned it for
> Turbine, so it is TRB-44 and INFRA-1249. These might be good starting
> points.
>
> Best regards
> Henning
>
> Torsten Curdt schrieb:
> >
> > On 21.06.2007, at 00:57, Martin van den Bemt wrote:
> >
> >> Hi everyone,
> >>
> >> The new Commons TLP was established today, with Torsten Curdt as Vice
> >> President.
> >
> > ...so where do we start with the TLP move is the question :)
> >
> > cheers
> > --
> > Torsten
> >
> >
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
>
> --
> Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux
> 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
> Open Source Consulting, Development, Design | Velocity - Turbine
>
> "Save the cheerleader. Save the world."
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: Commons is TLP

Yes, but it *still* has a check list of all things to do (as subtasks).
You don't need to clone it but you get an idea what a TLP can
potentially have (e.g. a lot of TLPs did not know about the Solaris
zones).

Best regards
Henning



On Sat, 2007-06-23 at 23:33 -0700, Henri Yandell wrote:
> Don't go the subtask route. Keep it all on the one issue as TLP Admin
> and Joe'll take care of things.
>
> Hen
>
> On 6/22/07, Henning Schmiedehausen wrote:
> > There is a Velocity JIRA Issue with a lot of subtasks that basically has
> > everything that is needed/can be done for a new TLP. Scott cloned it for
> > Turbine, so it is TRB-44 and INFRA-1249. These might be good starting
> > points.
> >
> > Best regards
> > Henning
> >
> > Torsten Curdt schrieb:
> > >
> > > On 21.06.2007, at 00:57, Martin van den Bemt wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> The new Commons TLP was established today, with Torsten Curdt as Vice
> > >> President.
> > >
> > > ...so where do we start with the TLP move is the question :)
> > >
> > > cheers
> > > --
> > > Torsten
> > >
> > >
> > >
> > > ------------------------------------------------------------ ---------
> > > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: general-help@jakarta.apache.org
> > >
> >
> > --
> > Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux
> > 91054 Buckenhof, Germany -- +49 9131 506540 | Apache person
> > Open Source Consulting, Development, Design | Velocity - Turbine
> >
> > "Save the cheerleader. Save the world."
> >
> > ------------------------------------------------------------ ---------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
--
Henning P. Schmiedehausen -- hps@intermeta.de | J2EE, Linux, |gls
91054 Buckenhof, Germany -- +49 9131 506540 | Apache person |eau
Open Source Consulting, Development, Design | Velocity - Turbine guy |rwc
|m k
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350 |a s
Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen |n

What about HttpClient? (was: Commons is TLP)

Martin van den Bemt wrote:
> +1 to keep httpclient and move it to httpcomponents.

I've taken a first look at things. Moving the tree in
Subversion should be painless. Then we have to update
the SVN links on the website. Changing them in xdocs
is easy, but it will take some careful review to make
sure that the site generated from the new tree location
is still OK. I haven't stumbled across relative links
to outside resources yet, so maybe we're not going to
run into problems from that side.

The commons list of subprojects is hard-coded, so the
missing httpclient subtree in SVN should not affect it.
We will have a problem when the commons website moves
though. I see several options:

1. Keep the httpclient site with the rest of commons
and move it to the new TLP domain. We'll have to update
the httpclient build with the new location and redeploy.
(Anything I've forgotten?)

2. Move the httpclient site to httpcomponents. Since
httpcomponents is unlikely to remain in Jakarta
indefinitely, that means the site would move again
later this year. Two moves within a few months is a
bit too disruptive to users for my liking.

3. Keep the httpclient site at it's current location
in Jakarta when the rest of the commons site moves.
Move it only once to httpcomponents when those leave
Jakarta.

Please share your thoughts on this. My preferred option
is 3, but I don't know how much trouble that will cause
when setting up redirects to the new commons site.

I don't have a Maven 1 environment set up to play around
right now, but I'll give it a try next week-end if time
permits. Oleg will be busy with the upcoming releases.

cheers,
Roland

Re: What about HttpClient? (was: Commons is TLP)

On 6/24/07, Roland Weber wrote:

> 1. Keep the httpclient site with the rest of commons
> and move it to the new TLP domain. We'll have to update
> the httpclient build with the new location and redeploy.
> (Anything I've forgotten?)
>
> 2. Move the httpclient site to httpcomponents. Since
> httpcomponents is unlikely to remain in Jakarta
> indefinitely, that means the site would move again
> later this year. Two moves within a few months is a
> bit too disruptive to users for my liking.
>
> 3. Keep the httpclient site at it's current location
> in Jakarta when the rest of the commons site moves.
> Move it only once to httpcomponents when those leave
> Jakarta.
>
> Please share your thoughts on this. My preferred option
> is 3, but I don't know how much trouble that will cause
> when setting up redirects to the new commons site.

Probably some. Plus the svn move will be painful.

Either 1 or 2 seem fine to me and whatever those committing to
HttpComponent/HttpClient want to do is fine by me. 3 seems painful to
do.

Hen

Re: What about HttpClient?

Hi Henri,

Henri Yandell wrote:
> On 6/24/07, Roland Weber wrote:
>
>> [...]
>> 3. Keep the httpclient site at it's current location
>> in Jakarta when the rest of the commons site moves.
>> Move it only once to httpcomponents when those leave
>> Jakarta.
>>
>> Please share your thoughts on this. My preferred option
>> is 3, but I don't know how much trouble that will cause
>> when setting up redirects to the new commons site.
>
> Probably some. Plus the svn move will be painful.

I'd like to give the svn move a try rather sooner than
later. What kind of problems do you expect? My idea is
to copy the current trunk plus old tags/branches to the
new location, followed by an update of the SVN locations
in the site xdocs. Anything I forgot? If I am not mistaken,
the HttpClient build is independent of the commons build.

> Either 1 or 2 seem fine to me and whatever those committing to
> HttpComponent/HttpClient want to do is fine by me. 3 seems painful to
> do.

Ok.

cheers,
Roland

Re: What about HttpClient?

Roland Weber wrote:
>
> Henri Yandell wrote:
>> Plus the svn move will be painful.
>
> I'd like to give the svn move a try rather sooner than
> later. What kind of problems do you expect?

I am beginning to understand. Quite a few links spread
across the site, mainly to code examples. I even found
one link still pointing to cvs :-)
Nightly Builds.
Gump.

cheers,
Roland

Re: What about HttpClient?

Roland Weber wrote:
> 1. Keep the httpclient site with the rest of commons
> and move it to the new TLP domain. We'll have to update
> the httpclient build with the new location and redeploy.
> (Anything I've forgotten?)
>
> 2. Move the httpclient site to httpcomponents. Since
> httpcomponents is unlikely to remain in Jakarta
> indefinitely, that means the site would move again
> later this year. Two moves within a few months is a
> bit too disruptive to users for my liking.
>
> 3. Keep the httpclient site at it's current location
> in Jakarta when the rest of the commons site moves.
> Move it only once to httpcomponents when those leave
> Jakarta.

The question is really whether the Commons TLP owns the HttpClient
codebase. I don't believe its terribly sensible for it to do so. All
active committers and knowledge are focussed in the HttpComonents group.

Thus I would suggest #3 as the best option, followed by #2.

Stephen

Re: What about HttpClient?

On Fri, 2007-06-29 at 21:26 +0100, Stephen Colebourne wrote:
> Roland Weber wrote:
> > 1. Keep the httpclient site with the rest of commons
> > and move it to the new TLP domain. We'll have to update
> > the httpclient build with the new location and redeploy.
> > (Anything I've forgotten?)
> >
> > 2. Move the httpclient site to httpcomponents. Since
> > httpcomponents is unlikely to remain in Jakarta
> > indefinitely, that means the site would move again
> > later this year. Two moves within a few months is a
> > bit too disruptive to users for my liking.
> >
> > 3. Keep the httpclient site at it's current location
> > in Jakarta when the rest of the commons site moves.
> > Move it only once to httpcomponents when those leave
> > Jakarta.
>
> The question is really whether the Commons TLP owns the HttpClient
> codebase.

Stephen et al

Based on the project's charter approved by the Jakarta PMC on Oct 31st,
2005 the HttpComponents project is meant to have the ownership of the
Commons HttpClient codebase

http://svn.apache.org/repos/asf/jakarta/httpcomponents/proje ct/project-charter.txt

It all did not matter much while we were still one (more or less) happy
family.

My preference is to not not move stuff around (option 1). I am planning
to cut HttpClient 3.1 final release shortly after HttpClient 4.0 alpha1.
3.1 is very likely to be the last release of the HttpClient 3.x codebase
unless some serious security or legal problems are found. There is no
point in investing a lot of efforts into a codeline, which is going to
become dormant very soon.

Oleg

> I don't believe its terribly sensible for it to do so. All
> active committers and knowledge are focussed in the HttpComonents group.
>
> Thus I would suggest #3 as the best option, followed by #2.
>
> Stephen
>
> ------------------------------------------------------------ ---------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>

Re: What about HttpClient?

Oleg Kalnichevski wrote:
>> The question is really whether the Commons TLP owns the HttpClient
>> codebase.
> Based on the project's charter approved by the Jakarta PMC on Oct 31st,
> 2005 the HttpComponents project is meant to have the ownership of the
> Commons HttpClient codebase
Thats great! Thanks for the link.


> My preference is to not not move stuff around (option 1).

But option 1 does move stuff around. It moves it to commons.apache.org
which is misleading to both the commons and jakarta groups. And is why I
suggested option 3, where HttpClient retains the same URL as now.

Stephen