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). -- 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 > >
