On Tue, 2005-08-09 at 13:59, Elias Torres wrote: > - Will monthly releases include a decent amount of bug fixing or will > it only be new features?
of course. we'll include any bug fixes we can manage. ultimately it's dependent on the priority of the bug. and we fully expect that from time to time we will devote an entire release specifically to fixing bugs. > - Will Dave/Allen work at all on community requirements? hopefully we are always considering what the community wants when choosing what we work on, and at the very least we are working with the community when developing features to make sure we are solving not just our own problems. > - What happens when the rest of the folks don't have the time > bandwidth to design/spec out common features between Sun/BSC and rest > of the community? Will you end up making all of the decisions > regarding feature X? I guess this is how OS works anyways, whoever is > writing the code makes the decisions. :-) no, we never just "make the decision for the community". we always try to involve the dev list whenever making changes that affect roller and of course if the dev community doesn't really speak up about something then it's possible we just move ahead with the attitude, "well, you had your chance to say something earlier." > - Will every new feature *have* to be developed in branches to not > interrupt your monthly schedule? only if the developer is not willing to assure everyone that their code will be ready for the next release. this is a good practice anways if you ask me. if you are developing something at a slower pace then everyone else then you should have to work in a different branch. > - I can't think of any more questions at this moment. phew. -- Allen > > Regards, > > Elias Torres > > 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). > > > > -- 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 > > > > > > > >
