Agreed, it is also a good way to "integration test" the documented release
process to have at least 2 release managers have a go.
If there are no emails on a podling list with questions on how to do a
release, then that hints of potential hidden knowledge, which as we see is
critical for future he
On 20/08/2016 20:59, Mark Thomas wrote:
> 3. Identify somewhere to put all the good suggestions for, and links to
>examples of, smooth release processes and then pull all the links
>and suggestions from this thread to that place. I have a vague
>recollection of seeing such a thing previ
+1
In practice this is often really a problem with many projects :/
LieGrue,
strub
> On Wednesday, 28 September 2016, 10:41, Mark Thomas wrote:
> > On 20/08/2016 20:59, Mark Thomas wrote:
>> All,
>>
>> It seems there is general consensus that this is a good idea. I'm
>> therefore going
On 20/08/2016 20:59, Mark Thomas wrote:
> All,
>
> It seems there is general consensus that this is a good idea. I'm
> therefore going to do the following.
>
> 1. Draft some text to add to
>http://incubator.apache.org/guides/graduation.html#releases
>and bring that back to this list for d
On Tue, Aug 23, 2016 at 2:02 PM, Ted Dunning wrote:
> I wonder if the requirement might be better phrased along the lines of
> "must have releases completed by a total of > 2 release managers".
I really like this criteria and use it extensively with my podlings.
Thanks,
Roman.
-
;
> dennis.hamil...@acm.org> wrote:
> >>>
> >>> +1 to this, including the posts from Mark and Bertrand.
> >>>
> >>> I know of a project where this would have made a serious difference
> for graduation and subsequent sustainability.
> >>>
ng the posts from Mark and Bertrand.
>>>
>>> I know of a project where this would have made a serious difference for
>>> graduation and subsequent sustainability.
>>>
>>> - Dennis
>>>
>>>> -Original Message-
>>>>
6, 17:41, Dennis E. Hamilton
> wrote:
> >
>
>> -Original Message-
>> From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
>> Sent: Friday, August 19, 2016 03:19
>> To: general@incubator.apache.org
>> Subject: Re: Ease of release process a
On 8/20/16, 11:16 PM, "Christopher" wrote:
>By "source package must be able to build itself", are you suggesting that
>simple projects must create scripts inside the source itself to execute a
>simple tar/zip command (for example), instead of just documenting those
>lines? That seems a bit friv
gt;>
> >>> +1 to this, including the posts from Mark and Bertrand.
> >>>
> >>> I know of a project where this would have made a serious difference
> >>>for graduation and subsequent sustainability.
> >>>
> >>> - Dennis
&g
:
>>>
>>> +1 to this, including the posts from Mark and Bertrand.
>>>
>>> I know of a project where this would have made a serious difference
>>>for graduation and subsequent sustainability.
>>>
>>> - Dennis
>>>
>>>> -O
hane Curcuru [mailto:a...@shanecurcuru.org]
>>> Sent: Friday, August 19, 2016 07:08
>>> To: general@incubator.apache.org
>>> Subject: Re: Ease of release process and exit criteria
>>>
>>> Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
>>>>
On Fri, Aug 19, 2016 at 2:23 AM, Mark Thomas wrote:
> Hi,
>
> I've noticed a pattern in some the board reports of PMCs who are
> beginning to experience difficulties. In a notable number of cases a
> significant part of the problem is difficulty in producing a release.
> The sorts of phrases I am
In the JDO project, we have detailed build/release instructions, yet after
several years, every time we put out a release, there is something different. I
think it’s the nature of software, not only because the project changes ever so
slightly but the dependencies also change underneath you. So
As a data point, for Apache Geode we have a detailed release page:
https://cwiki.apache.org/confluence/display/GEODE/Release+Steps
We’ve been rotating RM’s for each release and the notes get enhanced each time
through the process.
Feedback welcome!
Thanks,
Anthony
> On Aug 19, 2016, at 7:33 A
Message-
>> From: Shane Curcuru [mailto:a...@shanecurcuru.org]
>> Sent: Friday, August 19, 2016 07:08
>> To: general@incubator.apache.org
>> Subject: Re: Ease of release process and exit criteria
>>
>> Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
>>> Hi M
On Fri, Aug 19, 2016 at 6:18 AM Mark Struberg
wrote:
> Good links.
>
> I’d like to add some information for projects who use GIT with maven:
>
> First and important: configure the maven-release-plugin to operate
> ‚locally‘
> https://github.com/apache/deltaspike/blob/master/pom.xml#L123
>
> The i
19, 2016 07:08
> To: general@incubator.apache.org
> Subject: Re: Ease of release process and exit criteria
>
> Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
> > Hi Mark,
> >
> > On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas
> wrote:
> >> ...I'm think
> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
> Sent: Friday, August 19, 2016 03:19
> To: general@incubator.apache.org
> Subject: Re: Ease of release process and exit criteria
>
> Good links.
>
> I’d like to add some informati
On 8/19/16, 7:08 AM, "Shane Curcuru" wrote:
>Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
>> Hi Mark,
>>
>> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas wrote:
>>> ...I'm thinking of a graduation criteria long the lines of:
>>> "Is the release process clearly documented to the point that so
Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
> Hi Mark,
>
> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas wrote:
>> ...I'm thinking of a graduation criteria long the lines of:
>> "Is the release process clearly documented to the point that someone new
>> to the project could produce a release bu
For Wicket I've crafted a release script that not only creates the
artifacts to vote on, but also generates the messages needed for
voting and announcing, and scripts to either promote or rollback a
release.
https://github.com/apache/wicket/blob/master/release.sh
It uses the aforementioned settin
In addition, the release steps here are also available on DS's website -
they've obviously been updated since the original, but are pretty close to
Mark's email: http://deltaspike.apache.org/steps_for_a_release.html
John
On Fri, Aug 19, 2016 at 6:18 AM Mark Struberg
wrote:
> Good links.
>
> I’d
I would personally love it if we came up with some best practices for new
projects as they're coming in. There's been a few very questionable ones
done in the past, not that they're bad or incorrect, but do become
burdensome. However, I've seen projects create amazing releases in short
periods of
Good links.
I’d like to add some information for projects who use GIT with maven:
First and important: configure the maven-release-plugin to operate ‚locally‘
https://github.com/apache/deltaspike/blob/master/pom.xml#L123
The important parts are
false
true
This will configure maven to NOT push
Hi Mark,
On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas wrote:
> ...I'm thinking of a graduation criteria long the lines of:
> "Is the release process clearly documented to the point that someone new
> to the project could produce a release build?"...
I like this - as another example we have
http
Hi,
I've noticed a pattern in some the board reports of PMCs who are
beginning to experience difficulties. In a notable number of cases a
significant part of the problem is difficulty in producing a release.
The sorts of phrases I am seeing are along the lines of releases "are
too difficult", "tak
Hi!
I've committed the first cut and updated the website. I'm also
adding a special section to the incubator report calling
out projects where we would require a readout from the
mentors.
I would really appreciate if others can help with making
the docs crisper, etc.
Thanks,
Roman.
On Tue, Aug
On 11 Aug 2014, at 10:14, Bertrand Delacretaz wrote:
With this in mind, I would remove almost everything from the "What is
retirement" section and keep just
A retired project is a project which has been closed down for various
reasons, instead of graduating as an Apache project. It is no lo
On Tue, Aug 12, 2014 at 8:08 AM, Roman Shaposhnik wrote:
> On Mon, Aug 11, 2014 at 1:14 AM, Bertrand Delacretaz
> wrote:
> > On Mon, Aug 11, 2014 at 2:22 AM, Roman Shaposhnik
> wrote:
> >> ...Including the patch below...
> >
> > Sorry to come in late but I had a look at [1] and it's way too
> >
On 12 August 2014 09:38, Bertrand Delacretaz wrote:
> On Tue, Aug 12, 2014 at 9:08 AM, Roman Shaposhnik wrote:
> > ... * since I haven't seen much of complaining, can I please commit my
> > proposed stuff and then we can pile additional edits on top of
> that?...
>
> Sure, my complaining
On Tue, Aug 12, 2014 at 9:08 AM, Roman Shaposhnik wrote:
> ... * since I haven't seen much of complaining, can I please commit my
> proposed stuff and then we can pile additional edits on top of that?...
Sure, my complaining is more a general issue about incubator.apache.org
>* re-rea
On Mon, Aug 11, 2014 at 1:14 AM, Bertrand Delacretaz
wrote:
> On Mon, Aug 11, 2014 at 2:22 AM, Roman Shaposhnik wrote:
>> ...Including the patch below...
>
> Sorry to come in late but I had a look at [1] and it's way too
> complicated IMO, and I don't think the proposed patch helps with that.
>
>
On Mon, Aug 11, 2014 at 2:22 AM, Roman Shaposhnik wrote:
> ...Including the patch below...
Sorry to come in late but I had a look at [1] and it's way too
complicated IMO, and I don't think the proposed patch helps with that.
In general http://incubator.apache.org/ is way too verbose and hard to
It makes sense. And it also seems to be a decent compilation of the points
agreed in the earlier and lengthy discussion on the topic.
Cos
On Sun, Aug 10, 2014 at 05:22PM, Roman Shaposhnik wrote:
> Seems like attachments are eaten away by general@
> Including the patch bellow
>
> Index: content/g
Seems like attachments are eaten away by general@
Including the patch bellow
Index: content/guides/retirement.xml
===
--- content/guides/retirement.xml (revision 1617182)
+++ content/guides/retirement.xml (working copy)
@@ -64,6 +64,7
Hi!
Sorry for the delay -- OSCON and then a vacation (that was long
promised to my family but never delivered) derailed my legislative
agenda at IPMC ;-)
Attached is the proposed patch to the Incubator website detailing
the policy.
Please comment.
Thanks,
Roman.
On Tue, Jul 15, 2014 at 11:47 P
On Wed, Jul 16, 2014 at 5:16 AM, Roman Shaposhnik
wrote:
> On Sat, Jul 12, 2014 at 4:15 AM, Christian Grobmeier
> wrote:
> > On 12 Jul 2014, at 8:05, Roman Shaposhnik wrote:
> >> That's actually the part of the thread that I have a lot of interest in.
> >> Is there any reason not to use attic fo
On Sat, Jul 12, 2014 at 4:15 AM, Christian Grobmeier
wrote:
> On 12 Jul 2014, at 8:05, Roman Shaposhnik wrote:
>> That's actually the part of the thread that I have a lot of interest in.
>> Is there any reason not to use attic for hibernated podlings?
>
> I am not sure if there is a real reason, b
On 12 Jul 2014, at 8:05, Roman Shaposhnik wrote:
> On Fri, Jul 11, 2014 at 1:18 AM, ant elder wrote:
>> As i've said i don't think thats a
>> very good rule and doesn't seem like its really been thought through
>> properly. For example, its kept saying that the podling would go to
>> the ASF Atti
On Fri, Jul 11, 2014 at 1:18 AM, ant elder wrote:
> I think its something like "If a podling is over a year old and not
> done a release then retire it".
Almost. What is being proposed is not an immediate retirement,
but rather a vote. So it should really read: "If a podling is over a
year old an
This is quite a long thread now so its not that clear what the actual
proposal is now, could you maybe state what the current proposal is?
I think its something like "If a podling is over a year old and not
done a release then retire it". As i've said i don't think thats a
very good rule and doesn
On Wed, Jul 9, 2014 at 1:48 AM, Rob Vesse wrote:
> On 09/07/2014 09:12, "Chris Douglas" wrote:
>
>>On Wed, Jul 9, 2014 at 12:23 AM, Roman Shaposhnik wrote:
>>> Again, why would code lose users? Remember we're talking
>>> about a situation of no releases here. Presumably those
>>> users who are c
On 09/07/2014 09:12, "Chris Douglas" wrote:
>On Wed, Jul 9, 2014 at 12:23 AM, Roman Shaposhnik wrote:
>> Again, why would code lose users? Remember we're talking
>> about a situation of no releases here. Presumably those
>> users who are comfortable building from the repo would
>> just keep do
On Wed, Jul 9, 2014 at 12:23 AM, Roman Shaposhnik wrote:
> Again, why would code lose users? Remember we're talking
> about a situation of no releases here. Presumably those
> users who are comfortable building from the repo would
> just keep doing so. And since there was no release,
> what else i
On Tue, Jul 1, 2014 at 11:01 PM, ant elder wrote:
> Right, and thats why i don't think a rule like that would be useful.
I still don't quite follow. Are you saying that the rule wouldn't
be useful, or that incubator -> attic migration wouldn't be?
> If Droids was made to retire the code would be
On Wed, Jul 2, 2014 at 3:35 AM, Joe Brockmeier wrote:
> On Tue, Jul 1, 2014, at 04:23 AM, ant elder wrote:
> > On Tue, Jul 1, 2014 at 4:46 AM, Roman Shaposhnik wrote:
> >
> > > Hi!
> > >
> > > Sorry for a belated reply -- at first I was following Doug's rule
> > > and then I got distracted ;-)
>
On Tue, Jul 1, 2014, at 04:23 AM, ant elder wrote:
> On Tue, Jul 1, 2014 at 4:46 AM, Roman Shaposhnik wrote:
>
> > Hi!
> >
> > Sorry for a belated reply -- at first I was following Doug's rule
> > and then I got distracted ;-)
> >
> > That said -- I really would like to drive us to some kind
> >
On Tue, Jul 1, 2014 at 4:46 AM, Roman Shaposhnik wrote:
> Hi!
>
> Sorry for a belated reply -- at first I was following Doug's rule
> and then I got distracted ;-)
>
> That said -- I really would like to drive us to some kind
> consensus (even if we have to do the vote) because
> the current situ
On Tue, Jun 24, 2014 at 12:27 PM, Rob Weir wrote:
> I'll offer OpenOffice as an example of how long an initial podling
> release can take in some cases, due to a number of factors:
I agree with all of your points. Most of all with your final conclusion.
I still can't help but comment on one singl
g. If we do not weight activity in general
> in, we
> reduce the exit criteria to: how fast can you do a release?
Are you proposing a hypothetical where for all that activity there's
no a single line of code produced? I hope not. Because this
is the only point where I feel super stron
On 25 Jun 2014, at 10:38, ant elder wrote:
On Wed, Jun 25, 2014 at 9:04 AM, Christian Grobmeier
wrote:
On 24 Jun 2014, at 21:27, Rob Weir wrote:
On Tue, Jun 24, 2014 at 9:57 AM, Upayavira wrote:
On Tue, Jun 24, 2014, at 12:02 PM, Christian Grobmeier wrote:
On 24 Jun 2014, at 7:24, Rom
On Wed, Jun 25, 2014 at 9:04 AM, Christian Grobmeier
wrote:
> On 24 Jun 2014, at 21:27, Rob Weir wrote:
>
> > On Tue, Jun 24, 2014 at 9:57 AM, Upayavira wrote:
> >>
> >>
> >> On Tue, Jun 24, 2014, at 12:02 PM, Christian Grobmeier wrote:
> >>> On 24 Jun 2014, at 7:24, Roman Shaposhnik wrote:
> >>
On 24 Jun 2014, at 21:27, Rob Weir wrote:
> On Tue, Jun 24, 2014 at 9:57 AM, Upayavira wrote:
>>
>>
>> On Tue, Jun 24, 2014, at 12:02 PM, Christian Grobmeier wrote:
>>> On 24 Jun 2014, at 7:24, Roman Shaposhnik wrote:
>>> That said, reminding people of the "release often and early" thing is
>>> g
t fathom how a community that is that active can't put
>> > itself to a task of making a release.
>>
>> Let's assume the Wave project would have more activity. Maybe lets say
>> they are operating with around 20 commits a month. It would be still
>>
a month on dev@
> > - AND less than 10 commits/jira modifications in a month
> > I can't fathom how a community that is that active can't put
> > itself to a task of making a release.
>
> Let's assume the Wave project would have more activity. Maybe lets
neral in, we
reduce
the exit criteria to: how fast can you do a release?
And: if you don't manage to make a release in the first year - no matter
how your
product looks like - you might be thrown out.
At the ends of the day, the release of an incubating project
is NOT a glorious exercis
On Thu, Jun 19, 2014 at 6:22 AM, Christian Grobmeier
wrote:
> I think its not enough to just look at release / committer additions.
>
> In the case of Wave, there was a committer addition in the past year. Still
> no commits, nor a release. Looking closer you would find that committer was
> added
On Thu, Jun 19, 2014 at 05:54AM, Marvin Humphrey wrote:
> On Wed, Jun 18, 2014 at 11:14 PM, Roman Shaposhnik wrote:
>
> > To this end, I'd like to prose a very simplistic criteria
> > for a potential retirement from the incubator: unless both
> > of of the following applies project get put to a r
On 19 Jun 2014, at 14:54, Marvin Humphrey wrote:
On Wed, Jun 18, 2014 at 11:14 PM, Roman Shaposhnik
wrote:
To this end, I'd like to prose a very simplistic criteria
for a potential retirement from the incubator: unless both
of of the following applies project get put to a retirement
IPMC vot
On Wed, Jun 18, 2014 at 11:14 PM, Roman Shaposhnik wrote:
> To this end, I'd like to prose a very simplistic criteria
> for a potential retirement from the incubator: unless both
> of of the following applies project get put to a retirement
> IPMC vote:
>* there has been a release in the past
On Wed, Jun 18, 2014 at 11:46 PM, Alexander Broekhuis wrote:
> as the retirement criteria would IMO be too harsh for Celix when we
> started.
>
In a similar vein, Drill currently has about the same number of commits and
mail messages as Hive does, but hasn't had a release in a while. They have
Hi,
2014-06-19 8:14 GMT+02:00 Roman Shaposhnik :
> Hi!
>
> based on a recent thread inspired by observing
> some of the podlings, I'd like to kick start a discussion
> around making an amendment to our Incubator
> policy:
> http://incubator.apache.org/incubation/Incubation_Policy.html
>
> It
On Wed, Jun 18, 2014 at 11:14 PM, Roman Shaposhnik wrote:
> To this end, I'd like to prose a very simplistic criteria
> for a potential retirement from the incubator: unless both
> of of the following applies project get put to a retirement
> IPMC vote:
>* there has been a release in the past
Hi!
based on a recent thread inspired by observing
some of the podlings, I'd like to kick start a discussion
around making an amendment to our Incubator
policy:
http://incubator.apache.org/incubation/Incubation_Policy.html
It feels like we're missing one important part to
the whole process --
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 27, 2003 2:33 PM
>>Stephen McConnell wrote:
> I think the real reason is that I have a lot of scepticism about the
> successful functioning of the Incubator. I imaging future scenarios
> where candidates are keep wa
Rodent of Unusual Size wrote:
Stephen McConnell wrote:
The incubator has a scope concerning "incubation". I hope the incubator
aims to to provide the role of gatekeeper together with a support
infrasture the accelerate the sucessful exit of incubated projects.
so far so good.
Wi
Stephen McConnell wrote:
>
> The incubator has a scope concerning "incubation". I hope the incubator
> aims to to provide the role of gatekeeper together with a support
> infrasture the accelerate the sucessful exit of incubated projects.
so far so good.
> Within the objective and scope, op
Rodent of Unusual Size wrote:
Stephen McConnell wrote:
My own theory is that this entire discussion is exceeding the bounds of
duristiction of the Incubator PMC.
why?
The incubator has a scope concerning "incubation". I hope the incubator
aims to to provide the role of gatekeeper tog
Stephen McConnell wrote:
>
> My own theory is that this entire discussion is exceeding the bounds of
> duristiction of the Incubator PMC.
why?
> Does the Incubator PMC have an formal opinion on this subject?
since there are a number of people discussing this from various
angles, the answer is
Berin Lautenbach wrote:
So what's the final verdict on releases?
I'm wondering about this myself.
My own theory is that this entire discussion is exceeding the bounds of
duristiction of the Incubator PMC. I.e. IMVVHO if the incubated
project wants to publish an artifact it needs to do one
Nicola,
Apologies - I've lost the plot a bit on this one :<.
So what's the final verdict on releases?
Cheers,
Berin
>
> From: Nicola Ken Barozzi <[EMAIL PROTECTED]>
> Subject: Re: Exit Criteria
> Date: 26/09/2003 16:23:36
> To: [EMAIL PROTECTED]
>
Erik Abele wrote:
...
...but the last part about restricting mirror usage seems a bit
strong to me. IMO the 'Incubatee' should be encouraged and trained to
use our mirroring system appropriately.
In fact this document, coupled with "at least a couple of releases to
exit", is at least wierd, as Ted
On 24/09/2003, at 10:54, Cliff Schmidt wrote:
On Tuesday, September 23, 2003 11:26 PM, Nicola Ken Barozzi wrote:
Noel J. Bergman wrote:
I put up a Wiki page for it here:
http://nagoya.apache.org/wiki/
apachewiki.cgi?IncubatorReleaseManagement
From the Wiki page:
"This means that Projects under
Rodent of Unusual Size wrote:
Berin Lautenbach wrote:
I've put something slightly different into the IncubatorMussings
document. I've said that the Incubator PMC *recommends* to the
Sponsoring Entity (the receiving PMC) that something has completed,
needs to continue or fails.
no, i don't th
On Tuesday, September 23, 2003 11:26 PM, Nicola Ken Barozzi wrote:
> Noel J. Bergman wrote:
>
> >Cliff Schmidt wrote:
> >
>>> while they are in the Incubator, they must ensure these releases are
>>> clearly labeled as being incubator releases, which are not fully
>>> endorsed by the ASF
>>
>>>
Ted Leung wrote:
On 9/23/2003 12:10 AM, Nicola Ken Barozzi wrote:
Ted Leung wrote:
Meritocracy / Community
Demonstrate an active and diverse development community
No single organization supplies more than 50% of the active
committers (must be at least 3 independent committers)
How do you ass
Noel J. Bergman wrote:
>Cliff Schmidt wrote:
>
while they are in the Incubator, they must ensure these releases are
clearly labeled as being incubator releases, which are not fully
endorsed by the ASF
Does this fit with what you had in mind?
Works for me. But you should make sure that it works f
> while they are in the Incubator, they must ensure these releases are
> clearly labeled as being incubator releases, which are not fully
> endorsed by the ASF
> Does this fit with what you had in mind?
Works for me. But you should make sure that it works for the Incubator PMC.
As I understand f
On Tue, 23 Sep 2003, Noel J. Bergman wrote:
> > You can call it the "anti-big-company" rule.
>
> Diversity is good on the grounds that (a) no one company can control the
> direction of an ASF project, and (b) the fate of one company doesn't dictate
> the fate of the project.
But also that the fa
On Tuesday, September 23, 2003 2:01 PM, Noel J. Bergman wrote:
(requriment on minimum number of such releases?)
>>> two?
>> That's two "Not official ASF releases" ;-)
>
> LOL Call them "Dress Rehearsals" :-) I agree that they should learn
> the process until it becomes a habit.
>
> I don't
Ted Leung wrote:
>On 9/23/2003 12:10 AM, Nicola Ken Barozzi wrote:
>> Ted Leung wrote:
>>> Meritocracy / Community
>>> Demonstrate an active and diverse development community
>>> No single organization supplies more than 50% of the active
>>> committers (must be at least 3 independent committ
Nicola Ken Barozzi wrote:
For example, for Lenya I'm wondering if Cocoon is the right place for
them, as I've not seen much involvment. I'll wait and see, but for
now I would not vote for exit as there is not much integration.
As a member of the Cocoon, or Incubator PMC?
Is there a differenc
On 9/23/2003 12:10 AM, Nicola Ken Barozzi wrote:
Ted Leung wrote:
Meritocracy / Community
Demonstrate an active and diverse development community
No single organization supplies more than 50% of the active
committers (must be at least 3 independent committers)
How do you assess that? Are
Berin Lautenbach wrote:
>
> I've put something slightly different into the IncubatorMussings
> document. I've said that the Incubator PMC *recommends* to the
> Sponsoring Entity (the receiving PMC) that something has completed,
> needs to continue or fails.
no, i don't think so. the incubato
Steven Noels wrote:
Nicola Ken Barozzi wrote:
If a project cannot work well with the Sponsor PMC it's a failure, the
Incubator will not agree to make it go. It may decide to swith
targets, but imposing a project on non-willing PMC is simply out of
question.
OK - good. Mind you that I don't int
Berin Lautenbach wrote:
Nicola Ken Barozzi wrote:
If a project cannot work well with the Sponsor PMC it's a failure, the
Incubator will not agree to make it go. It may decide to swith
targets, but imposing a project on non-willing PMC is simply out of
question.
Which may require a vote of the
Nicola Ken Barozzi wrote:
If a project cannot work well with the Sponsor PMC it's a failure, the
Incubator will not agree to make it go. It may decide to swith targets,
but imposing a project on non-willing PMC is simply out of question.
OK - good. Mind you that I don't intend this to be a criti
Nicola Ken Barozzi wrote:
If a project cannot work well with the Sponsor PMC it's a failure, the
Incubator will not agree to make it go. It may decide to swith targets,
but imposing a project on non-willing PMC is simply out of question.
Which may require a vote of the PMC in question to determi
Steven Noels wrote:
Nicola Ken Barozzi wrote:
Exactly.
The sponsoring PMC asks to have that project. This means that it
*wants* that project and that community. Why would it change its mind?
Because of things happening during incubation. What if a podling becomes
a mutant during incubation, in
Berin Lautenbach wrote:
Nicola Ken Barozzi wrote:
The sponsoring PMC asks to have that project. This means that it
*wants* that project and that community. Why would it change its mind?
Maybe there were reservations that the PMC wanted to have covered off
during incubation.
Practical example?
Nicola Ken Barozzi wrote:
Exactly.
The sponsoring PMC asks to have that project. This means that it *wants*
that project and that community. Why would it change its mind?
Because of things happening during incubation. What if a podling becomes
a mutant during incubation, in the best case changi
Nicola Ken Barozzi wrote:
The sponsoring PMC asks to have that project. This means that it *wants*
that project and that community. Why would it change its mind?
Maybe there were reservations that the PMC wanted to have covered off
during incubation. The best way to ensure that everyone is comf
t into the IncubatorMussings
document. I've said that the Incubator PMC *recommends* to the
Sponsoring Entity (the receiving PMC) that something has completed,
needs to continue or fails.
So it would then be up to the Sponsoring Entity to make a determination
on its own exit criteria (i.
Steven Noels wrote:
Nicola Ken Barozzi wrote:
Engagement by the XMLbeans community with the XML PMC and other ASF
sub communities, particularly infrastructure@ (this reflects my
personal bias that projects should pay an infrastructure "tax").
Incubator PMC has voted for graduation
XML PMC h
Nicola Ken Barozzi wrote:
Engagement by the XMLbeans community with the XML PMC and other ASF
sub communities, particularly infrastructure@ (this reflects my
personal bias that projects should pay an infrastructure "tax").
Incubator PMC has voted for graduation
XML PMC has voted for final a
Ted Leung wrote:
I don't know if we want to tackle this at the same time as Steven's
document on entering the incubator, but at the moment I"m more focused
on how to get podlings out of the incubator rather than getting them in.
A while ago I proposed some exit criteria for
Ted,
> There are a few XML beans specific items in this list, but I'd like to
> propose that we start a discussion of exit criteria based on this list.
Seems a reasonable starting point. I took the liberty of putting a generic
version of it on the Wiki:
http://nagoya.apac
I don't know if we want to tackle this at the same time as Steven's
document on entering the incubator, but at the moment I"m more focused
on how to get podlings out of the incubator rather than getting them in.
A while ago I proposed some exit criteria for XML beans -- I haven
Quoting Ted Leung <[EMAIL PROTECTED]>:
> Demonstrate ability to tolerate and resolve conflict within the
> community.
IMO this implies that a project has to force dissense, even if it hasn't. :-)
Jochen
-
To unsubscribe,
1 - 100 of 107 matches
Mail list logo
