+1 to all this. I think HttpComponents has been operating as a TLP anyway except for the PMC vote on releases.
On 10/21/07, Roland Weber <[EMAIL PROTECTED]> wrote: > 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 [EMAIL PROTECTED], 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 > [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- dIon Gillard Rule #131 of Acquisition: Information is Profit. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
