Re: Trunk instability
On 1/29/11 10:20 PM, Alex Karasulu wrote: Hi y'all, This trunk situation is just horrible. I don't know how I fell into working this heavily in the trunk. We all usually branch and work isolated. I in fact, I started refactoring in a branch. I don't know how this shifted into the trunk. It matters not though, so long as this never happens again. I sure am stressed over it and the time others are loosing. It started with some good intentions : - all the changes were supposed to be automatically impacting studio, the API and ADS - they were not supposed to be so heavy - it was suppose to be done fast - merging when many directories change is just a PITA to manage with SVN That being said, the initial changes leaded to some more changes, then some others etc. It was an attempt to catch many birds with one stone. IMO, and I don't want to blame anyone on that, some really important rules about development on a complex project have also been forgotten : - trunk must build. Always. - before starting to add new features, the previous one must be done - when some task takes longer than expected, then usually we won't be able to finish it in time before being hit but our human physical limits - big refactoring should start in a branch... On the bright side, we've got some great decoupling going on that will make life much easier, and the codec clearer, especially for use by those who will have to extend it for their own controls and extended operations. I prepared some hand written materials to share on these topics but we've been scrambling, trying to get this done fast. I'd like to prepare these materials formally after we stabilize. The decoupling is a major step forward. If we had only focused on it, we would have been done earlier. OTOH, using generics, creating a mechanism to allow codec injection, could have been done once the initial decoupling has been terminated. Working using 'Sprints', or whatever we name them, is simply better than any other options we have when it's not an initial work. These changes are an important step even if we don't achieve full pluggability by M1 because it helps us clearly see what MUST be expose to users of the codec (API) and people extending the codec (SPI). We ain't gonna get fancy with OSGi either right now. Floating ideas on the ML is cool but right now we need this M1 out the door. My primary motive was to get the API roughly demarcated. This way huge shifts in the API between milestones don't have to happen. We don't want to freak users out. Our milestone contract gives us some liberty but maybe we should still try to be conservative with API changes. So that's why NOW is the best time to get this done fast before the M1. The rest of the milestone series should not have such massive API changes. Totally agree. So let's just not panic about a day or two. (I say this because I am panicing) I will dedicate my time to get this done ASAP. We even talked about backing out etc with Emmanuel. But I think it would be an incredible loss at this point. We're going to have to do this at some point. Why not now and be done with it? Emmanuel the codec master is also equally involved. It takes a lot to change when things have settled over the past 6 years in this shared area. But do realize, we have lots of tests, and most of the changes are not fundamental to the way the software works. The changes are high level structural changes. We have not changed the way we encode and decode, we've simply shifted exposed APIs. The new incongruities introduced will disappear fast and things will align again. We need to be confident in that. What worked before will work again. I would say that : if tomorrow evening we don't get trunk back on rail, compiling and tests passing, then I'll suggest to revert to something which at least compile. I'm not even sure if we should not revert tomorrow morning, create a branch, and finish what we are doing in the branch (the cost of branching, reverting, and merging should be around 2 hours for one person.) Let's see what tomorrow brings, and then we decide what to do. Thanks for the heads up, Alex -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: svn commit: r1063987 - in /directory: apacheds/trunk/core-api/src/main/java/org/apache/directory/server/core/interceptor/context/ apacheds/trunk/core-jndi/src/main/java/org/apache/directory/server
On Thu, Jan 27, 2011 at 5:50 AM, wrote:
> Author: akarasulu
> Date: Thu Jan 27 04:50:03 2011
> New Revision: 1063987
>
> URL: http://svn.apache.org/viewvc?rev=1063987&view=rev
> Log:
> cleaned up control codec classes after changes in ManageDsaIT control classes
...
> -public class ManageDsaIT extends BasicControlImpl
> +public interface ManageDsaIT extends Control
> {
> /** This control OID */
> - public static final String OID = "2.16.840.1.113730.3.4.2";
> + String OID = "2.16.840.1.113730.3.4.2";
>
> /** An instance of this constant control which never changes */
> - public static final ManageDsaIT INSTANCE = new ManageDsaIT();
> -
> -
> - /**
> - * Default constructor
> - */
> - private ManageDsaIT()
> - {
> - super( OID );
> - }
> -
> -
> - public void setValue( byte [] value )
> - {
> - }
> + ManageDsaIT INSTANCE = new SimpleManageDsaIT();
>
>
> - public boolean hasValue()
> + class SimpleManageDsaIT extends BasicControlImpl implements ManageDsaIT
> {
> - return false;
> + /**
> + * Default constructor.
> + */
> + public SimpleManageDsaIT()
> + {
> + super( OID );
> + }
> +
> +
> + public void setValue( byte [] value )
> + {
> + }
> +
> +
> + public boolean hasValue()
> + {
> + return false;
> + }
It doesn't make sense - and it's also dangerous - to have a static
instance of a control. It is possible to alter the criticality of a
control which may cause issues when using the singleton in a
multi-threaded environment.
Kind Regards,
Stefan
Re: Trunk instability
Hi y'all, This trunk situation is just horrible. I don't know how I fell into working this heavily in the trunk. We all usually branch and work isolated. I in fact, I started refactoring in a branch. I don't know how this shifted into the trunk. It matters not though, so long as this never happens again. I sure am stressed over it and the time others are loosing. On the bright side, we've got some great decoupling going on that will make life much easier, and the codec clearer, especially for use by those who will have to extend it for their own controls and extended operations. I prepared some hand written materials to share on these topics but we've been scrambling, trying to get this done fast. I'd like to prepare these materials formally after we stabilize. These changes are an important step even if we don't achieve full pluggability by M1 because it helps us clearly see what MUST be expose to users of the codec (API) and people extending the codec (SPI). We ain't gonna get fancy with OSGi either right now. Floating ideas on the ML is cool but right now we need this M1 out the door. My primary motive was to get the API roughly demarcated. This way huge shifts in the API between milestones don't have to happen. We don't want to freak users out. Our milestone contract gives us some liberty but maybe we should still try to be conservative with API changes. So that's why NOW is the best time to get this done fast before the M1. The rest of the milestone series should not have such massive API changes. So let's just not panic about a day or two. (I say this because I am panicing) I will dedicate my time to get this done ASAP. We even talked about backing out etc with Emmanuel. But I think it would be an incredible loss at this point. We're going to have to do this at some point. Why not now and be done with it? Emmanuel the codec master is also equally involved. It takes a lot to change when things have settled over the past 6 years in this shared area. But do realize, we have lots of tests, and most of the changes are not fundamental to the way the software works. The changes are high level structural changes. We have not changed the way we encode and decode, we've simply shifted exposed APIs. The new incongruities introduced will disappear fast and things will align again. We need to be confident in that. What worked before will work again. Thanks for your patience. Best, -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: svn commit: r1065085 - /directory/shared/trunk/ldap-client-api/src/main/java/org/apache/directory/ldap/client/api/LdapNetworkConnection.java
On Sat, Jan 29, 2011 at 6:48 PM, wrote: > Author: akarasulu > Date: Sat Jan 29 17:48:52 2011 > New Revision: 1065085 > > URL: http://svn.apache.org/viewvc?rev=1065085&view=rev > Log: > shared at least is building now without the DSML modules Not really: Tests run: 2148, Failures: 18, Errors: 85, Skipped: 2 http://vmbuild.apache.org/continuum/buildResult.action?buildId=2924&projectGroupId=6&projectId=207&projectName=Apache+Directory+Shared May I suggest to - copy the current trunk to a branch where you can continue the refactoring - revert trunk to r1064845 ? Kind Regards, Stefan
Re: Trunk instability
On 1/29/11 3:31 PM, Stefan Seelmann wrote: Hi devs, In the last days it happened that the trunk didn't build. Last night and right now shared even doesn't compile. I really appreciate the activities that happen to restructure the code. I also understand that working on trunk is easier than branch and merge, I fully support that. But for less-active people like me it is annoying, e.g. when I want to spend two hours to work on the M3 build. So my question is how long it will take till the trunk becomes more stable again? Isn't it possible to ensure that the trunk compiles at least? Yeah, sorry, there is no excuse for that. Trunk was pretty much stable (well, it was compiling at least) those last days, but yesterday we made a mistake thinking that we would have enough energy to fix it in the evening. That was a bad move, thank for pointing it. We are now busting our back to get trunk building again... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Trunk instability
Yes you are 100% right. We made a wrong call going against our gut to work in a branch. We both (Emmanuel and I) are on it to cleanup and stabilize. This hopefully will be the last time we do anything like this. Sorry about the inconvenience. Alex On Sat, Jan 29, 2011 at 4:31 PM, Stefan Seelmann wrote: > Hi devs, > > In the last days it happened that the trunk didn't build. Last night > and right now shared even doesn't compile. I really appreciate the > activities that happen to restructure the code. I also understand that > working on trunk is easier than branch and merge, I fully support > that. But for less-active people like me it is annoying, e.g. when I > want to spend two hours to work on the M3 build. So my question is how > long it will take till the trunk becomes more stable again? Isn't it > possible to ensure that the trunk compiles at least? > > Kind Regards, > Stefan > -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Trunk instability
Hi devs, In the last days it happened that the trunk didn't build. Last night and right now shared even doesn't compile. I really appreciate the activities that happen to restructure the code. I also understand that working on trunk is easier than branch and merge, I fully support that. But for less-active people like me it is annoying, e.g. when I want to spend two hours to work on the M3 build. So my question is how long it will take till the trunk becomes more stable again? Isn't it possible to ensure that the trunk compiles at least? Kind Regards, Stefan
