This depends on the project type - when you are enhancing the
existing code, this is manageable. When you are writing a new
application, using small patches is doable but not practical - it
will generate lots of noise.
Andrus
On May 24, 2006, at 2:00 PM, Garrett Rooney wrote:
> On 5/24/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
>> We have one proposal (cayenne-ropwsdl) where this totally makes sense
>> - the module being developed will be a part of Cayenne core and we
>> can't give the student access to the main repo.
>>
>> The other two are standalone applications that use Cayenne as a
>> library. So the patch would simply include all files and won't have
>> any diffs of the existing files. That'll work too of course, still I
>> would also want a student to use some kind of code repository
>> (SourceForge, Apache sandbox, ObjectStyle) to keep the intermediate
>> work, instead of synching patches to the repo every day or him/her
>> doing the work locally for extended periods of time.
>>
>> So how about a combination approach:
>>
>> 1. Setup an outside repo where a student can commit, and everybody
>> else can browse the code
>> 2. A student would submit the 'milestone' patches via Jira (generated
>> from the external repo)
>> 3. A mentor would review them and commit to the Apache repo
>>
>> This way we are not taking any shortcuts and reduce the burden on
>> mentors and students.
>
> Personally, I don't see why the student can't just work via patches.
> If they want to use some sort of version control for managing their
> work before it's committed that's their perogative, but their mentor
> should really be making sure that they're sending in small, digestible
> patches that can be applied to the source tree, rather than producing
> huge milestones outside the tree that are impossible to review when
> they're finally checked in because they're just too damn big.
>
> -garrett
>
This archive was generated by hypermail 2.0.0 : Wed May 24 2006 - 14:07:14 EDT