hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ossf...@dubioso.net>
Subject TLP - the final push
Date Sat, 20 Oct 2007 20:34:46 GMT
Hi folks,

I meant to kick off the (hopefully) final TLP discussion
next weekend, but since this stuff is spinning in my head,
it's probably better to just dump it into a mail and get
some feedback instead of pondering any more on it.

The idea of joining forces with Slide failed, mainly due
to Slide not having much force left. Rather than try any
other force-joining, we should just rally what we have,
go TLP on our own, and later invite others to join.

Timeline:
There's a board meeting on December 19th. If they pass
our TLP resolution, we might get the domain and/or SVN
set up by christmas (Gregorian). I've got two weeks in
which I should have more spare time than usual just then,
so I don't want to miss that opportunity. I'd like to
send the proposal about two weeks before the board
meeting, so we can gather and - if necessary - address
early feedback from board members. Give a week or more
for voting on general@jakarta, so we should start that
vote in late November. Plenty of time for discussion...

PMCs:
In a previous discussion on going TLP, Oleg set the target
of 6 to 8 PMC members. I've checked the board minutes for
the projects that went TLP this year. 5 out of the 10 had
8 or less initial PMC members, Quetzalcoatl being the
smallest with 5. The others had 11 (POI) to 20 (Commons).
So 6 to 8 PMC members should be fine, although more would
be welcome.

Scope:
I guess that is the most important point. With just our
current activities, we're rather small as a TLP. Doesn't
mean we can't make it, but I'd prefer to allow for some
growth. At the very least, we should leave the door open
for Slide. My current ideas for the scope are as follows:
- in scope: HttpComponents as they are
- in scope: HttpClient 3.1 until obsolete
- in scope: future components in the "HTTP & related" arena
- in scope: (existing) applications in the "HTTP & related"
     arena and/or based on our components (including 3.x)
- out of scope: container stuff like Servlet API, Portlet API
     or anything else implementing container style JSRs or
     other standardized server-side monster APIs
- focus on Java

The first two items are obvious. Future components might
be a WebDAV client (from Slide), or what we used to call
http-spider (see Droids on labs.apache.org). I'd stretch
the "HTTP & related" to include Julius' nyc-ssl since
that is useful for https, which is related to http.

The application stuff is probably new in this discussion.
That thought started with the Slide server side, though
I don't expect that to be revived. Still, we should allow
it to reside with us in the event. To prevent that clause
from meaning "anything we want to do", I'd qualify it with
_existing_ applications (or projects). Existing in Apache
or outside, but no new efforts started by us directly in
the TLP. If we should get funny ideas for new projects,
we'd take them to the Incubator or the Labs or Sourceforge,
or we'd ask the board for approval.

The container stuff must be stated explicitly, to leave
no doubt that we are not going to get into the turf of
Tomcat or Jetspeed or Geronimo or whatever. We're not
doing containers, just low-level components that they
or others could use to implement a container.

Now, if we allow HTTP applications in addition to the
components, what's going to stop us from becoming a
new Jakarta... with completely separate projects on
their own mailing lists, which don't care about the
others or "the whole"? My take on this is as follows:
- one dev list for all
- one commits list for all
- separate user lists where appropriate
If people on the dev list really don't care for some
parts of the project, they can set up mail filter rules.


Name:
We do have a name, HttpComponents. I'm not concerned
about it's length anymore, it's just 2 characters
more than SpamAssassin. It will not really match with
applications, but that's a secondary thought. My primary
concern is that it is rather close to a category name.
An attempt to create a "security.apache.org" project
failed at some time in the past, the people eventually
chose a different name to go TLP. The "testing.apache.org"
idea was not too well received either in the discussion on
general@jakarta last year, mainly because of an unclear
scope and the fact that "testing" is a category.
So I would prefer to choose another name for the TLP.
I'm intentionally not suggesting anything right now,
I want to first establish a consensus on whether we
should be looking for a new name at all.
Mind you, I don't want to rename the HttpComponents. I
am talking about moving from "Jakarta HttpComponents" to
"Whatever HttpComponents". We've been de-emphasizing the
Jakarta part for several releases now, so changing that
should not be disruptive to users. And it should be no
more effort than any other domain change for us. The
new name would only gain a meaning of it's own when we
extend our activities beyond the HttpComponents.


OK, that's the brain dump... Fire away. I may not have
much occasion to answer next week, but don't let that
stop you from sharing your thoughts. I hope there will
be a lot more participants than just Oleg and me this
time around :-)

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message