Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 98950 invoked from network); 29 Oct 2007 18:22:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Oct 2007 18:22:54 -0000 Received: (qmail 44595 invoked by uid 500); 29 Oct 2007 18:22:41 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 44551 invoked by uid 500); 29 Oct 2007 18:22:41 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 44540 invoked by uid 99); 29 Oct 2007 18:22:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 11:22:41 -0700 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 64.233.162.239 as permitted sender) Received: from [64.233.162.239] (HELO nz-out-0506.google.com) (64.233.162.239) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 29 Oct 2007 18:22:42 +0000 Received: by nz-out-0506.google.com with SMTP id o1so1149655nzf for ; Mon, 29 Oct 2007 11:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=CTFhE2NK0HN4xDMmpmFnI4J7kBFn2iiH+JIi9HPzZXk=; b=mPse4vVFstFTkliRpkJMleSrJcFsmLodFuJzaRLfSZZXwF4ydzFCDj5Uw7Ws2sa9lpLYOzMzqjbUiy4Yr8duWTRzQpxajxnhWFif9tAavHkbhPTv3HbfNWzOolRFIgFKWHG6JyDjMhLb8vc58/ERh3Q0+b33Go5mNOJ/RbEPqX4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=IwsIiMjDEhK77xoKO+1ZNVmS4MqSfnsQUqfOXgBJJ9jRk0O/pDTz0nHuAQefAdlClSsp+Z7eKlTMJ3xprO8nzsv1Ev4I5yv2qSi0A97ZrMMqo/7zgzo8LDyN+nh3/sOorXZiSlIvmDC9oBHQfWCi10THKItisguuBu/0P/l75Ag= Received: by 10.114.166.1 with SMTP id o1mr7313790wae.1193682140827; Mon, 29 Oct 2007 11:22:20 -0700 (PDT) Received: by 10.115.18.12 with HTTP; Mon, 29 Oct 2007 11:22:20 -0700 (PDT) Message-ID: Date: Mon, 29 Oct 2007 14:22:20 -0400 From: "Alex Karasulu" Sender: akarasulu@gmail.com To: "Apache Directory Developers List" Subject: [VOTE] [ApacheDS] [BigBang] Should we check point what we have? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4283_13351967.1193682140826" X-Google-Sender-Auth: fff5d45e31977f03 X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_4283_13351967.1193682140826 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I think we can say we're finished with Phase I of the the big bang plan [0]. Emmanuel planted the seed in my head that we might consider replacing the current trunk with a copy of the big bang branch before moving forward on Phase II. He made some excellent points: o this gives developers a chance to see the changes o allows for an interim release if the team wants to release 1.5.2 o gives the team a chance to start documenting some changes o prevents stalling somewhat as this refactoring is underway These are all good points. Personally I'm strapped on time trying to work on various things such as Triplesec, the refactoring in bigbang, and my day job. So I may not have enough time for helping out in a release but I'm fully supportive of one. Copying big bang over to trunk check points the refactoring at a community level: heck svn automatically checkpoints for us and we can tag things as they are now too. But the point is it checkpoints the current state and sends a clear message about where we are and what we can do before we do much with more in the bigbang. Who knows Phase II might become a big mess and/or we might not like where we get to. We may decide to keep things as they are after Phase I. Should we replace trunk now with the bigbang? [ ] +1 - replace trunk with big bang in present state [ ] +/-0 - don't care [ ] -1 - no not now Thanks, Alex --------------------- [0] - http://www.nabble.com/-ApacheDS---BigBang--Status-Report-tf4585474.html#a13089517 ------=_Part_4283_13351967.1193682140826 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I think we can say we're finished with Phase I of the the big bang plan [0]. 

Emmanuel planted the seed in my head that we might consider replacing the
current trunk with a copy of the big bang branch before moving forward on
Phase II.  He made some excellent points:

  o this gives developers a chance to see the changes
  o allows for an interim release if the team wants to release 1.5.2
  o gives the team a chance to start documenting some changes
  o prevents stalling somewhat as this refactoring is underway

These are all good points.  Personally I'm strapped on time trying to work on
various things such as Triplesec, the refactoring in bigbang, and my day job. 
So I may not have enough time for helping out in a release but I'm fully supportive
of one.

Copying big bang over to trunk check points the refactoring at a community level:
heck svn automatically checkpoints for us and we can tag things as they are now
too.  But the point is it checkpoints the current state and sends a clear message
about where we are and what we can do before we do much with more in the bigbang. 
Who knows Phase II might become a big mess and/or we might not like where we
get to.  We may decide to keep things as they are after Phase I. 

Should we replace trunk now with the bigbang?

[  ] +1 - replace trunk with big bang in present state
[  ] +/-0 - don't care
[  ] -1 - no not now

Thanks,
Alex

---------------------

[0] - http://www.nabble.com/-ApacheDS---BigBang--Status-Report-tf4585474.html#a13089517
------=_Part_4283_13351967.1193682140826--