I'm also not an official part of the project, but I might be running the second or third largest Roller-based website ;-) and my opinion if it counts at all, is that if Dave/Allen can handle the heat in the kitchen, let them stay in the kitchen. I'm sure that's why they pay them the big bucks.
Now, realistically speaking, I'm not really sure how long you can keep such schedule because I think that you'll either run out of "good/useful" ideas to implement or Roller will become like Word/Excel filled of features that people don't care about. Also, development machines for roller will need bigger hard drives to cope the billions of lines of code that will accumulate with such aggressive schedule. End of joking tone. Start of serious tone. - Will monthly releases include a decent amount of bug fixing or will it only be new features? - Will Dave/Allen work at all on community requirements? - 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. :-) - Will every new feature *have* to be developed in branches to not interrupt your monthly schedule? - I can't think of any more questions at this moment. Also, ditto on Allen's anal comment about design docs, etc. Allen and I have had a thread going on authentication/user registry for a while and I hadn't heard from Matt at all. Allen was suggesting to revisit this and come out with a spec that then we could implement. I'm still trying to get my head around the current state of the world in Roller and I'm not sure whether Acegi is the right direction (I'm not familiar with the technology, that's all). It'd be funky to all of the sudden update from SVN and get everything reimplemented using Acegi. Just my $0.02. 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 > > > > >
