On Sat, 2007-10-20 at 22:34 +0200, Roland Weber 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. >
+1 to all said above. > 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. > > +1 > 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. > Roland, We tried to come up with a new fancy name and that led us nowhere. I wish we had chosen a better name from the start or were allowed to be http4j or some such. Good names are very difficult to come up with. HttpComponents may be dull and ugly but it does reflect the purpose of the project rather well. > > 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 :-) > I am tired of discussions that lead nowhere. If no one else participates we should just go ahead and put a proposal on vote and be done with it. This whole mess has been taking too much of our time and energy away from writing code and cutting releases. Cheers Oleg > cheers, > Roland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
