On 8/9/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > On Tue, 2005-08-09 at 11:22, Matt Raible wrote: > > Dave and Allen, > > > > You guys are obviously biased in your votes here - primarily because > > Roller is your job and you've been mandated to schedule the releases > > to more fit their work schedule. I don't blame you. > > > > You guys are contributing the most code, and handling all release > > aspects - so I believe the decision is up to you. I'm in favor of > > whatever you guys advocate. If you are going to go through with this, > > it'd be nice to see a release schedule so we know when it's best to > > commit code. I'd like to integrate Acegi this week or next, but if > > there's a release coming out soon, I should probably wait. > > Dave and I are certainly influenced by our commitments to our team here at > Sun, but ultimately the decision should come from the community at large. > > I think a release schedule is a good idea and as usual we will want to > communicate to everyone on the team when a release is nearing so that we can > coordinate changes to the repository. This also gives commiters a chance to > better guage what release they want to target certain code for. > > About commiting the Acegi stuff, my biggest concern here is not where/when to > commit it but rather that I don't recall any formal proposal being sent > around. I know we talked about this a few times, but I like to see some kind > of document that at least talks about ... > > - are there db schema changes required, and if so what changes. > - very generally, what is the new code design. what classes are new, > changed, removed? how do they fit together? > - what changes would there be to the UI, if any? > > Hopefully I am not coming off as anal, but I am generally of the opinion that > our greatest opportunity for teamwork comes at design time, not implemenation > time. So to really collaborate on this project as effectively as possible I > think we need to have good design docs that are reviewed by everyone before > coding beings (or gets too far along).
There should be no Java code changes required by Acegi, nor any database changes. I don't plan on committing anything until everyone has looked at the code and approves it. More than anything, I simply plan on trying to make it work. Since AppFuse used to use the same authentication system that Roller does, and now it uses Acegi - it should be an easy thing to implement. I'm sorry if I implied I was going to commit it as soon as I finished it - I will definitely write up a detailed e-mail on how it works once I'm done. At that time, we can decided as a group if it should be committed or not. Matt > > -- Allen > > > > > > Matt > > > > On 8/9/05, Lance Lavandowska <[EMAIL PROTECTED]> wrote: > > > On 8/9/05, Allen Gilliland <[EMAIL PROTECTED]> wrote: > > > > > > > > > (2) Strict non-breakage policies on the trunk. Successful build = > > > > > full > > > > > test passage. > > > > > > > > i'm not sure i agree here. obviously we can't have ppl commiting code > > > > that is 25% complete or code that is completely broken, but who does > > > > that anyways? i think most of us develop a feature in our own > > > > workspace and only commit it when we believe it's reasonably complete. > > > > > > Heh, Allen (as a relatively late-comer) isn't familiar with the > > > Lavandowska "it's good enough" Principle. I've often committed code > > > that just-barely does what it is intended to do. Often it's provided > > > as a proof-of-concept, intended to elicit feedback and cooperation, > > > that gets pushed into production. > > > > > > Now this mostly came about when we didn't do branches (I think because > > > none of us were familiar/comfortable enough with them). Now that I've > > > trimmed my code contributions down to once-per-year I think there is > > > much less danger from the Lavandowska Principle. > > > > > > Lance > > > > >
