You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2006/05/24 18:44:42 UTC
Re: What next?
That's what I was wondering too. In our case the projects are
isolated from the rest of the code, so sandbox would be a preferred
approach. Cayenne project committers do not have the infrastructure
karma, so we will have to bother somebody else to set this up.
Alternatively I can setup an SVN sandbox on ObjectStyle.org (and I
can manage sandboxes for all other willing SoC apache projects as
well) ... not sure if that's a bad idea from Cayenne incubating
perspective (as we are moving the infrastructure from ObjectStyle to
Apache), but it makes sense from practical standpoint and takes some
load from the Infra.
Any comments on that?
Andrus
On May 22, 2006, at 3:13 PM, Ross Gardler wrote:
> How you manage your students is entirely up to you. Some people
> created a sandbox area in SVN, together with a temporary ASF
> account to access it. Others expected their students to go through
> the normal meritocracy process of earning commit priveledges.
>
> Bear in mind, that this whole process increases the load on the
> infrastructure team. It is worth ensuring the student knows how to
> submit patches via your issue tracker even if you intend to create
> a sandbox. That way you don't have to wait for the infra team to
> find the time.
>
> Ross
Re: What next?
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
> > Alternatively I can setup an SVN sandbox on ObjectStyle.org (and I can
> > manage sandboxes for all other willing SoC apache projects as well) ...
> > not sure if that's a bad idea from Cayenne incubating perspective (as
> > we are moving the infrastructure from ObjectStyle to Apache), but it
> > makes sense from practical standpoint and takes some load from the Infra.
> >
> > Any comments on that?
> >
>
> Rather than host something outside Apache, I would rather see students
> submit patches to Apache Jira issues. --It's good experience for how
> many Apache projects incorporate contributions.
+1.
The projects where I participate do it the way Jean suggests. IMHO
it's just as important to get new contributors used to the issue
tracker, to the patch submission process, to the dev mailing list
discussions, and the rest of the community-driven development
practices we use, as it is to get a chunk of code out of them.
Yoav
Re: What next?
Posted by Andrus Adamchik <an...@objectstyle.org>.
Heh, that's actually a more general problem with team development,
both open source and commercial. I've seen people who would not
commit their local work to CVS for weeks or months to postpone
dealing with integration issues :-)
So yes, communicating constant integration paradigm is important. And
providing the right tools is what makes it practical.
Andrus
On May 24, 2006, at 2:21 PM, Garrett Rooney wrote:
> On 5/24/06, Andrus Adamchik <an...@objectstyle.org> wrote:
>> It looks like recommending SVK per Kevin's SVK suggestion is a good
>> idea - there won't be a need for the external repo, and it will
>> remove the reviewing bottleneck from the patch process.
>
> Just be sure that you don't end up with the student doing all their
> work locally and not showing it to anyone until it's done. That
> totally defeats the point of open development, peer review, etc.
>
> -garrett
>
Re: What next?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 5/24/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> It looks like recommending SVK per Kevin's SVK suggestion is a good
> idea - there won't be a need for the external repo, and it will
> remove the reviewing bottleneck from the patch process.
Just be sure that you don't end up with the student doing all their
work locally and not showing it to anyone until it's done. That
totally defeats the point of open development, peer review, etc.
-garrett
Re: What next?
Posted by Andrus Adamchik <an...@objectstyle.org>.
It looks like recommending SVK per Kevin's SVK suggestion is a good
idea - there won't be a need for the external repo, and it will
remove the reviewing bottleneck from the patch process.
Andrus
On May 24, 2006, at 2:09 PM, Garrett Rooney wrote:
> On 5/24/06, Andrus Adamchik <an...@objectstyle.org> wrote:
>> 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.
>
> Noise is better than big code dumps that don't get reviewed, in my
> experience. It's also more representative of the way people generally
> are expected to work on an open source project.
>
> -garrett
>
Re: What next?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 5/24/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> 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.
Noise is better than big code dumps that don't get reviewed, in my
experience. It's also more representative of the way people generally
are expected to work on an open source project.
-garrett
Re: What next?
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <an...@objectstyle.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
>
Re: What next?
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 5/24/06, Andrus Adamchik <an...@objectstyle.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
Re: What next?
Posted by Andrus Adamchik <an...@objectstyle.org>.
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.
Andrus
On May 24, 2006, at 1:28 PM, Jean T. Anderson wrote:
> Andrus Adamchik wrote:
>> That's what I was wondering too. In our case the projects are
>> isolated
>> from the rest of the code, so sandbox would be a preferred approach.
>> Cayenne project committers do not have the infrastructure karma,
>> so we
>> will have to bother somebody else to set this up.
>>
>> Alternatively I can setup an SVN sandbox on ObjectStyle.org (and
>> I can
>> manage sandboxes for all other willing SoC apache projects as
>> well) ...
>> not sure if that's a bad idea from Cayenne incubating perspective
>> (as
>> we are moving the infrastructure from ObjectStyle to Apache), but it
>> makes sense from practical standpoint and takes some load from
>> the Infra.
>>
>> Any comments on that?
>>
>
> Rather than host something outside Apache, I would rather see students
> submit patches to Apache Jira issues. --It's good experience for how
> many Apache projects incorporate contributions.
>
> -jean
>
>
Re: What next?
Posted by Kevin Menard <km...@servprise.com>.
On Wed, 24 May 2006 13:28:55 -0400, Jean T. Anderson <jt...@apache.org>
wrote:
> Rather than host something outside Apache, I would rather see students
> submit patches to Apache Jira issues. --It's good experience for how
> many Apache projects incorporate contributions.
I can see the value in this, but speaking as someone that contributed a
fair amount of code without commit privileges, it's a sucky situation.
It's tantamount to asking the student to work on the code without an SCM
at all, which benefits no one. It's nothing ASF-specific but rather a
short-coming of a centralized SCM, such as Subversion.
I recommend that if we go this approach that we at least suggest using SVK
to the students. Incidentally, I started using SVK just this morning due
to the need to commit code while not connected to a server. Anyway,
because SVK interacts with subversion, students should be able to leverage
an SCM and contribute patches fairly easily. I do wonder how this falls
into the whole "development must be done in the open" stance Google has
taken.
--
Kevin
Re: What next?
Posted by "Jean T. Anderson" <jt...@apache.org>.
Andrus Adamchik wrote:
> That's what I was wondering too. In our case the projects are isolated
> from the rest of the code, so sandbox would be a preferred approach.
> Cayenne project committers do not have the infrastructure karma, so we
> will have to bother somebody else to set this up.
>
> Alternatively I can setup an SVN sandbox on ObjectStyle.org (and I can
> manage sandboxes for all other willing SoC apache projects as well) ...
> not sure if that's a bad idea from Cayenne incubating perspective (as
> we are moving the infrastructure from ObjectStyle to Apache), but it
> makes sense from practical standpoint and takes some load from the Infra.
>
> Any comments on that?
>
Rather than host something outside Apache, I would rather see students
submit patches to Apache Jira issues. --It's good experience for how
many Apache projects incorporate contributions.
-jean