If the development process is not done in the apache community, the code must go through the incubator.
small patches for bugfixes are exempt from this process, because there are explicit disclaimers around this in JIRA, etc. But here (and the original email expresses the intent very well), we are not speaking about small patches, but about a code donation. The code, if not developed in apache, should go through the incubator. The way I see it, the development as a whole must go through the incubator unless every single patch passes through JIRA anad is vetted by the pluto community. I'm -1 about the branch. On 8/25/06, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
David H. DeWolf wrote: > Yup, we just need to make sure that we provide the protocol in order to > follow Apache ByLaws. We need the PMC to have the correct level of > oversight. I'm no expert on this so I'll rely on Carsten and others for > their assistance. > > Carsten, if we take the patch and incremental commit approach do you > think we still need to go through the incubator? Hmm, I'm really not sure - in general patches do not have to go through the incubator, so the question becomes "when is it a patch and when is it a code donation?" Adding something to jira does not necessarily mean that it is a patch. Now, I don't want to imply that this will/is happening here with pluto 2.0, I just want to express the possibilities: it is not that hard to split up a big code donation into a set of patches. Allowing this would mean bypassing the incubator. So, we should really make sure that these are "real patches" (whatever that means) :) Anyways, i think we should ask our PMC; if they approve it, I'm fine. > In a way I kind of > agree with Craig that this development is more like "enhancements" to an > existing codebase (after all, it's all on top of 1.1) as opposed to a > totally new project. At the same time, I want to make sure we follow > the right protocol. Yes, that's my pov as well. It would be great if the people "behind the patches" :) would make themselves heard on this list though. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
