You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2005/07/05 04:46:43 UTC
[CONSENSUS?] Preparation for M4 -- branch early
Do we have a consensus that we should branch at the beginning of the release cycle instead of at the end as we have done in the past?
If so, going to put out an email titled "M4 - 24 hour notice of branch", which I think would be a good release practice.
-David
On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote:
> On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
> > David Blevins wrote:
> > >On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
> > >
> > >>David Blevins wrote:
> > >>
> > >>>Anything I missed?
> > >>>
> > >>
> > >>SNAPSHOT elimination so the build is reproducible.
> > >
> > >
> > >Right. Missed that one for M3 IIRC.
> > >
> > >
> > >>Branch so that M4 can stabilize whilst other changes are being made.
> > >
> > >
> > >We do for every milestone. Don't expect this to be different.
> > >
> > >
> > >>Acceptance test process - how do we know what works (need to avoid a
> > >>broken release like M3).
> > >
> > >
> > >That's what I meant by:
> > >
> > > DB> We have a number of people interested in testing. I'll ping
> > > DB> them when I have something ready.
> > >
> > >Was thinking to branch when I dish out the binaries for testing.
> > >Rather than the "surprise, here is a binary" approach we've done in
> > >the past. Sounds pretty much like what you are proposing as well.
> > >
> >
> > Yes - in the past we've just tagged and moved on. This time I think we
> > should create the branch at the start of the process rather than at the
> > end as there seem to be a lot of pent up changes planned. Yes, we may
> > need to merge some critical changes back to this branch but hopefully
> > this can be kept to a minimum.
> >
> > So basically,
> > * create a branch now, say 1.0-M4-prep
> > * do the stuff we talking about now on that branch
> > * cut the final M4 distro
> > * drop the 1.0-M4-prep branch
> >
> > Other work can continue on the trunk without destablizing the M4 release.
> >
>
> +1 That's pretty much what I had in mind.
>
>
> -David
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 7/5/2005 1:33 AM, Jacek Laskowski wrote:
> Alan D. Cabrera wrote:
>
>> I'm not a big fan of performing development on a branch that, IMO,
>> should be frozen for QA. I'm not sure if that's what people are
>> proposing but, I just wanted to say that.
>
>
> Me, either, but wondering what we do if a fix pops up, shall we get
> rid of the M4 branch and do it over or...
Nope, fixing bugs on the candidate branch is normal.
Regards,
Alan
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Jacek Laskowski <jl...@apache.org>.
Alan D. Cabrera wrote:
> I'm not a big fan of performing development on a branch that, IMO,
> should be frozen for QA. I'm not sure if that's what people are
> proposing but, I just wanted to say that.
Me, either, but wondering what we do if a fix pops up, shall we get rid
of the M4 branch and do it over or...
> Alan
Jacek
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I'm not a big fan of performing development on a branch that, IMO,
should be frozen for QA. I'm not sure if that's what people are
proposing but, I just wanted to say that.
Regards,
Alan
On 7/4/2005 7:46 PM, David Blevins wrote:
>Do we have a consensus that we should branch at the beginning of the release cycle instead of at the end as we have done in the past?
>
>If so, going to put out an email titled "M4 - 24 hour notice of branch", which I think would be a good release practice.
>
>-David
>
>On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote:
>
>
>>On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
>>
>>
>>>David Blevins wrote:
>>>
>>>
>>>>On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
>>>>
>>>>
>>>>
>>>>>David Blevins wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Anything I missed?
>>>>>>
>>>>>>
>>>>>>
>>>>>SNAPSHOT elimination so the build is reproducible.
>>>>>
>>>>>
>>>>Right. Missed that one for M3 IIRC.
>>>>
>>>>
>>>>
>>>>
>>>>>Branch so that M4 can stabilize whilst other changes are being made.
>>>>>
>>>>>
>>>>We do for every milestone. Don't expect this to be different.
>>>>
>>>>
>>>>
>>>>
>>>>>Acceptance test process - how do we know what works (need to avoid a
>>>>>broken release like M3).
>>>>>
>>>>>
>>>>That's what I meant by:
>>>>
>>>> DB> We have a number of people interested in testing. I'll ping
>>>> DB> them when I have something ready.
>>>>
>>>>Was thinking to branch when I dish out the binaries for testing.
>>>>Rather than the "surprise, here is a binary" approach we've done in
>>>>the past. Sounds pretty much like what you are proposing as well.
>>>>
>>>>
>>>>
>>>Yes - in the past we've just tagged and moved on. This time I think we
>>>should create the branch at the start of the process rather than at the
>>>end as there seem to be a lot of pent up changes planned. Yes, we may
>>>need to merge some critical changes back to this branch but hopefully
>>>this can be kept to a minimum.
>>>
>>>So basically,
>>>* create a branch now, say 1.0-M4-prep
>>>* do the stuff we talking about now on that branch
>>>* cut the final M4 distro
>>>* drop the 1.0-M4-prep branch
>>>
>>>Other work can continue on the trunk without destablizing the M4 release.
>>>
>>>
>>>
>>+1 That's pretty much what I had in mind.
>>
>>
>>-David
>>
>>
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Gianny Damour <gi...@optusnet.com.au>.
+1
I like the idea to branch at the beginning and merge back any bug fixes
if need be.
Thanks,
Gianny
On 5/07/2005 12:46 PM, David Blevins wrote:
>Do we have a consensus that we should branch at the beginning of the release cycle instead of at the end as we have done in the past?
>
>If so, going to put out an email titled "M4 - 24 hour notice of branch", which I think would be a good release practice.
>
>-David
>
>On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote:
>
>
>>On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
>>
>>
>>>David Blevins wrote:
>>>
>>>
>>>>On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
>>>>
>>>>
>>>>
>>>>>David Blevins wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Anything I missed?
>>>>>>
>>>>>>
>>>>>>
>>>>>SNAPSHOT elimination so the build is reproducible.
>>>>>
>>>>>
>>>>Right. Missed that one for M3 IIRC.
>>>>
>>>>
>>>>
>>>>
>>>>>Branch so that M4 can stabilize whilst other changes are being made.
>>>>>
>>>>>
>>>>We do for every milestone. Don't expect this to be different.
>>>>
>>>>
>>>>
>>>>
>>>>>Acceptance test process - how do we know what works (need to avoid a
>>>>>broken release like M3).
>>>>>
>>>>>
>>>>That's what I meant by:
>>>>
>>>> DB> We have a number of people interested in testing. I'll ping
>>>> DB> them when I have something ready.
>>>>
>>>>Was thinking to branch when I dish out the binaries for testing.
>>>>Rather than the "surprise, here is a binary" approach we've done in
>>>>the past. Sounds pretty much like what you are proposing as well.
>>>>
>>>>
>>>>
>>>Yes - in the past we've just tagged and moved on. This time I think we
>>>should create the branch at the start of the process rather than at the
>>>end as there seem to be a lot of pent up changes planned. Yes, we may
>>>need to merge some critical changes back to this branch but hopefully
>>>this can be kept to a minimum.
>>>
>>>So basically,
>>>* create a branch now, say 1.0-M4-prep
>>>* do the stuff we talking about now on that branch
>>>* cut the final M4 distro
>>>* drop the 1.0-M4-prep branch
>>>
>>>Other work can continue on the trunk without destablizing the M4 release.
>>>
>>>
>>>
>>+1 That's pretty much what I had in mind.
>>
>>
>>-David
>>
>>
>
>
>
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by David Blevins <da...@visi.com>.
On Mon, Jul 04, 2005 at 10:57:45PM -0400, Aaron Mulder wrote:
> I want to get the key generator changes in for M4. However, I'm
> currently blocked because I can't add the new module to TranQL. So I'd
> like to resolve that before the branch. Other than that, I'm fine to go
> ahead with the 24 hour notice.
If we can nail that one quick that would be good. I remember you
testing out your stuff quite heavily at JavaOne.
I just noticed I have tranql commit, but would prefer Jeremy, Dain or
Gianny look at your changes.
>
> Oh, I think we also have a problem where the currently running
> module list never gets saved. So you always get the default services when
> you start the server. I think I remember a conversation about how it
> was caused by some bad logic around our shutdown hooks. That needs to be
> resolved too.
My gut says this seems like standard stabilization stuff that can
happen in the branch. I'm sure other things will pop up as people test.
Just my $0.02
-David
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 6/07/2005 6:23 AM, Aaron Mulder wrote:
>On Tue, 5 Jul 2005, Jeremy Boynes wrote:
>
>
>>I didn't -1 it, I said it wasn't a pre-req, as in I think we can release
>>M4 without it.
>>
>>As for a technical reason, where's the code? Last I saw was a patch for
>>TranQL that caused a circular dependency and screwed up the IP. If there
>>is something newer that addresses these issues I would be happy to look
>>at it.
>>
>>
>
> But I'm not asking for review of the patch. I'm asking to be able
>to apply it myself. (FYI, if by circular dependency you mean at the
>Geronimo depends on TranQL and vice versa level, we agreed in earlier
>discussions to move the builder to Geronimo, and the IP issue has been
>resolved.)
>
> I'm assuming that committership on Geronimo and OpenEJB
>fundamentally equates to committership on TranQL. If not, what is the
>process for becoming a committer on TranQL? (Is there a TranQL
>PMC-equivalent? Or do you personally make the call?)
>
>
Aaron,
Could you please open a JIRA and attach your patch? There is some lack
of visibility of your work and I think that the very first step is to
give an opportunity to everyone to look at your code. I assume that you
will gain commit access very shortly after.
Thanks,
Gianny
>Thanks,
> Aaron
>
>
>
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 5 Jul 2005, Jeremy Boynes wrote:
> TranQL is a Codehaus project so it is down to the despots, currently me.
> The barrier to entry is not high but so far I've not seen anything
> except that problematic patch.
Okay, sorry. It's clear I misunderstood the relationship between
the projects. It was inappropriate for me to just ask for commit on an
independent project.
As for the PK Gen change, I'm going to split it up a little
differently to ease the integration. I should be able to get on this
tonight.
Thanks,
Aaron
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 5, 2005, at 7:08 PM, Aaron Mulder wrote:
> Changing the subject since we're drifting again. This is related
> to another issue that's come up off-list, but we may as well open
> it to a
> broader discussion here.
Please note that I'm not defending TranQL (or Jeremy in his debate
with you about a TranQL patch) here, but interested in the subject in
general because I've long worried about our model of significant
fundamental technology being external to the project. I don't think
it's bad - I've just worried about it for all sorts of reasons
including community issues and IP issues.
>
> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
>
>> TranQL is a Codehaus project so it is down to the despots,
>> currently me.
>> The barrier to entry is not high but so far I've not seen anything
>> except that problematic patch.
>>
>
> Okay. Well, without getting into specifics, I'm not real
> comfortable with Geronimo being heavily dependent on a Codehaus
> project
> with precisely one, er, despot. I feel the same about the GBean.org
> kernel, which while not currently a part of Geronimo, will likely be a
> candidate for it (and this of course is one of the issues around it).
Using that criterion, you should feel the same about :
OpenEJB - codehaus project with one despot, David Blevins
TranQL - codehaus project with one despot, Jeremy
ActiveMQ - codehaus project with one despot, James (ok, there's also
Stewie, but he's been inactive...)
Xfire - ....
et al
and additionally
ActiveIO - 3 despots...
>
> Jeremy, would you consider either substantially enlarging the
> community of despots for TranQL, bringing it to Apache, or merging
> it into OpenEJB?
To TranQL's credit, it's added more committers (it has 10 total) over
the last year than Geronimo has, which is more than half of OpenEJBs
number, and has much smaller scope.
So instead of focusing on specific projects (I know that you are
having a debate w/ Jeremy about a patch you offered, and I'm not
trying to discount that but stick to the subject at hand) what about
focusing on risk and how we mitigate such risk? I see
* community risk
* technology risk
* IP risk
I don't believe we have tech or IP risk now at the moment. But it's
been a subject I've been pondering a lot because of Harmony - if it's
appropriate to use the same model of a "cloud" of associated but
independent projects given the IP stakes are so high. Actually, I
don't think that the IP stakes are higher at Harmony, but rather we
tend not to focus on them so much. I'd like to fix that here, but
that's for another thread.
>
> Dain, would you consider either substantially enlarging the
> community of despots for GBean.org, bringing it to Apache, or
> merging it
> into Geronimo (as a branch or sandbox module for the present, I
> presume)?
>
I think that the code should be brought to the project here. Dain
has every right to do this kind of work here in a sandbox or branch.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by Dain Sundstrom <da...@iq80.com>.
+10000
I think David nailed it. The Geronimo project should be really
careful when depending on projects that are not vibrant projects that
stand on their own (without geronimo involvement). It is clear that
neither GBean or TranQL are projects that stand on their own right now.
As for GBean, I can say that we, the GBean project, are actively
working on all of the criteria that you list, and we are working on
getting the kernel used by other projects (which should help to
spread out the risk).
-dain
On Jul 5, 2005, at 7:29 PM, sissonj@insession.com wrote:
> I agree that in the case of cglib it is unrealistic, since AFAIK
> none of
> their committers are involved in the Geronimo project and as you
> said it
> is a stable project.
>
> IMHO it would be realistic for the TranQL and GBean.org projects as
> the
> developers on those projects have been involved in the Geronimo
> project
> and I would hope they would be willing to spread their knowledge
> and get
> others in the Geronimo project involved for the best of both
> Geronimo and
> those 'evolving' external projects.
>
> It is probably hard to set a criteria in stone for when it does makes
> sense.
>
> Thanks,
>
> John
>
> David Jencks <dj...@gluecode.com> wrote on 06/07/2005 11:32:03 AM:
>
>
>> While I'm sympathetic to your goal here, the committer requirement is
>> unrealistic in general. I don't think it too likely that any of us
>> will become cglib committers in the near future, but it is a stable
>> project with plenty of other users.
>>
>> thanks
>> david jencks
>>
>> On Jul 5, 2005, at 6:19 PM, sissonj@insession.com wrote:
>>
>>
>>> I was just thinking about the issues of external project
>>> dependencies
>>> in
>>> general.. Should there be a process for evaluating the
>>> introduction of
>>>
>
>
>>> new
>>> 'critical' dependencies in Geronimo.
>>>
>>> I think we should at least ensure that a 'critical' external project
>>> meets
>>> a minimum criteria, for example:
>>>
>>> * An operational web site and documentation that describes the
>>> dependency
>>> (more than just a paragraph).
>>> * Operational mailing lists and mail archives
>>> * Operational bug tracking system
>>> * More than one Geronimo committer on the project
>>>
>>> Currently some of the projects being discussed in this thread do not
>>> meet
>>> the 'example' criteria above. Just picture yourself as a new
>>> Geronimo
>>> developer wanting to get involved. Go to these project websites and
>>> try
>>> looking at the mailing list archives and see how much information
>>> you
>>> can
>>> find about the project.
>>>
>>> What would be the impact to the Geronimo community if a critical
>>> project
>>> initially met this criterial then stops meeting the 'example'
>>>
> criteria?
>
>>>
>>> Have we identified the risks of depending on 'critical' external
>>> projects.
>>> I'm not saying we shouldn't rely upon them, but at least think
>>> about
>>> the
>>> risks and how they can be minimised. For example is it safe to rely
>>> upon
>>> these assumptions?:
>>>
>>> * that the project host will always be operating
>>> * that the project host will backup the project source (mistakes can
>>> happen) and that we will always have access to the source.
>>> * that mailing list archives for the project kept by the hosting
>>> project
>>> will always be available.
>>> * that the bug tracking records for the project will always be
>>> available
>>>
>>> If Geronimo is integrating best of breed external components, then
>>> IMHO,
>>> the project infrastructure and community around those components
>>> should be
>>> well established.
>>>
>>> John
>>>
>>> This e-mail message and any attachments may contain confidential,
>>> proprietary or non-public information. This information is intended
>>> solely for the designated recipient(s). If an addressing or
>>> transmission
>>> error has misdirected this e-mail, please notify the sender
>>>
> immediately
>
>>> and destroy this e-mail. Any review, dissemination, use or reliance
>>> upon
>>> this information by unintended recipients is prohibited. Any
>>> opinions
>>> expressed in this e-mail are those of the author personally.
>>>
>>> Aaron Mulder <am...@alumni.princeton.edu> wrote on 06/07/2005
>>> 09:08:13
>>> AM:
>>>
>>>
>>>> Changing the subject since we're drifting again. This is
>>>> related
>>>> to another issue that's come up off-list, but we may as well
>>>> open it
>>>> to
>>>>
>>> a
>>>
>>>> broader discussion here.
>>>>
>>>> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
>>>>
>>>>> TranQL is a Codehaus project so it is down to the despots,
>>>>> currently
>>>>>
>>> me.
>>>
>>>>> The barrier to entry is not high but so far I've not seen anything
>>>>> except that problematic patch.
>>>>>
>>>>
>>>> Okay. Well, without getting into specifics, I'm not real
>>>> comfortable with Geronimo being heavily dependent on a Codehaus
>>>> project
>>>> with precisely one, er, despot. I feel the same about the
>>>> GBean.org
>>>> kernel, which while not currently a part of Geronimo, will
>>>> likely be
>>>>
> a
>
>>>> candidate for it (and this of course is one of the issues around
>>>> it).
>>>>
>>>> Jeremy, would you consider either substantially enlarging the
>>>> community of despots for TranQL, bringing it to Apache, or merging
>>>> it into OpenEJB?
>>>>
>>>> Dain, would you consider either substantially enlarging the
>>>> community of despots for GBean.org, bringing it to Apache, or
>>>> merging
>>>>
>
>
>>>> it
>>>> into Geronimo (as a branch or sandbox module for the present, I
>>>>
>>> presume)?
>>>
>>>>
>>>> Thanks,
>>>> Aaron
>>>>
>>>
>>>
>>
>
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by si...@insession.com.
I agree that in the case of cglib it is unrealistic, since AFAIK none of
their committers are involved in the Geronimo project and as you said it
is a stable project.
IMHO it would be realistic for the TranQL and GBean.org projects as the
developers on those projects have been involved in the Geronimo project
and I would hope they would be willing to spread their knowledge and get
others in the Geronimo project involved for the best of both Geronimo and
those 'evolving' external projects.
It is probably hard to set a criteria in stone for when it does makes
sense.
Thanks,
John
David Jencks <dj...@gluecode.com> wrote on 06/07/2005 11:32:03 AM:
> While I'm sympathetic to your goal here, the committer requirement is
> unrealistic in general. I don't think it too likely that any of us
> will become cglib committers in the near future, but it is a stable
> project with plenty of other users.
>
> thanks
> david jencks
>
> On Jul 5, 2005, at 6:19 PM, sissonj@insession.com wrote:
>
> > I was just thinking about the issues of external project dependencies
> > in
> > general.. Should there be a process for evaluating the introduction of
> > new
> > 'critical' dependencies in Geronimo.
> >
> > I think we should at least ensure that a 'critical' external project
> > meets
> > a minimum criteria, for example:
> >
> > * An operational web site and documentation that describes the
> > dependency
> > (more than just a paragraph).
> > * Operational mailing lists and mail archives
> > * Operational bug tracking system
> > * More than one Geronimo committer on the project
> >
> > Currently some of the projects being discussed in this thread do not
> > meet
> > the 'example' criteria above. Just picture yourself as a new Geronimo
> > developer wanting to get involved. Go to these project websites and
> > try
> > looking at the mailing list archives and see how much information you
> > can
> > find about the project.
> >
> > What would be the impact to the Geronimo community if a critical
> > project
> > initially met this criterial then stops meeting the 'example'
criteria?
> >
> > Have we identified the risks of depending on 'critical' external
> > projects.
> > I'm not saying we shouldn't rely upon them, but at least think about
> > the
> > risks and how they can be minimised. For example is it safe to rely
> > upon
> > these assumptions?:
> >
> > * that the project host will always be operating
> > * that the project host will backup the project source (mistakes can
> > happen) and that we will always have access to the source.
> > * that mailing list archives for the project kept by the hosting
> > project
> > will always be available.
> > * that the bug tracking records for the project will always be
> > available
> >
> > If Geronimo is integrating best of breed external components, then
> > IMHO,
> > the project infrastructure and community around those components
> > should be
> > well established.
> >
> > John
> >
> > This e-mail message and any attachments may contain confidential,
> > proprietary or non-public information. This information is intended
> > solely for the designated recipient(s). If an addressing or
> > transmission
> > error has misdirected this e-mail, please notify the sender
immediately
> > and destroy this e-mail. Any review, dissemination, use or reliance
> > upon
> > this information by unintended recipients is prohibited. Any opinions
> > expressed in this e-mail are those of the author personally.
> >
> > Aaron Mulder <am...@alumni.princeton.edu> wrote on 06/07/2005
> > 09:08:13
> > AM:
> >
> >> Changing the subject since we're drifting again. This is related
> >> to another issue that's come up off-list, but we may as well open it
> >> to
> > a
> >> broader discussion here.
> >>
> >> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
> >>> TranQL is a Codehaus project so it is down to the despots, currently
> > me.
> >>> The barrier to entry is not high but so far I've not seen anything
> >>> except that problematic patch.
> >>
> >> Okay. Well, without getting into specifics, I'm not real
> >> comfortable with Geronimo being heavily dependent on a Codehaus
> >> project
> >> with precisely one, er, despot. I feel the same about the GBean.org
> >> kernel, which while not currently a part of Geronimo, will likely be
a
> >> candidate for it (and this of course is one of the issues around it).
> >>
> >> Jeremy, would you consider either substantially enlarging the
> >> community of despots for TranQL, bringing it to Apache, or merging
> >> it into OpenEJB?
> >>
> >> Dain, would you consider either substantially enlarging the
> >> community of despots for GBean.org, bringing it to Apache, or merging
> >> it
> >> into Geronimo (as a branch or sandbox module for the present, I
> > presume)?
> >>
> >> Thanks,
> >> Aaron
> >
>
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by David Jencks <dj...@gluecode.com>.
While I'm sympathetic to your goal here, the committer requirement is
unrealistic in general. I don't think it too likely that any of us
will become cglib committers in the near future, but it is a stable
project with plenty of other users.
thanks
david jencks
On Jul 5, 2005, at 6:19 PM, sissonj@insession.com wrote:
> I was just thinking about the issues of external project dependencies
> in
> general.. Should there be a process for evaluating the introduction of
> new
> 'critical' dependencies in Geronimo.
>
> I think we should at least ensure that a 'critical' external project
> meets
> a minimum criteria, for example:
>
> * An operational web site and documentation that describes the
> dependency
> (more than just a paragraph).
> * Operational mailing lists and mail archives
> * Operational bug tracking system
> * More than one Geronimo committer on the project
>
> Currently some of the projects being discussed in this thread do not
> meet
> the 'example' criteria above. Just picture yourself as a new Geronimo
> developer wanting to get involved. Go to these project websites and
> try
> looking at the mailing list archives and see how much information you
> can
> find about the project.
>
> What would be the impact to the Geronimo community if a critical
> project
> initially met this criterial then stops meeting the 'example' criteria?
>
> Have we identified the risks of depending on 'critical' external
> projects.
> I'm not saying we shouldn't rely upon them, but at least think about
> the
> risks and how they can be minimised. For example is it safe to rely
> upon
> these assumptions?:
>
> * that the project host will always be operating
> * that the project host will backup the project source (mistakes can
> happen) and that we will always have access to the source.
> * that mailing list archives for the project kept by the hosting
> project
> will always be available.
> * that the bug tracking records for the project will always be
> available
>
> If Geronimo is integrating best of breed external components, then
> IMHO,
> the project infrastructure and community around those components
> should be
> well established.
>
> John
>
> This e-mail message and any attachments may contain confidential,
> proprietary or non-public information. This information is intended
> solely for the designated recipient(s). If an addressing or
> transmission
> error has misdirected this e-mail, please notify the sender immediately
> and destroy this e-mail. Any review, dissemination, use or reliance
> upon
> this information by unintended recipients is prohibited. Any opinions
> expressed in this e-mail are those of the author personally.
>
> Aaron Mulder <am...@alumni.princeton.edu> wrote on 06/07/2005
> 09:08:13
> AM:
>
>> Changing the subject since we're drifting again. This is related
>> to another issue that's come up off-list, but we may as well open it
>> to
> a
>> broader discussion here.
>>
>> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
>>> TranQL is a Codehaus project so it is down to the despots, currently
> me.
>>> The barrier to entry is not high but so far I've not seen anything
>>> except that problematic patch.
>>
>> Okay. Well, without getting into specifics, I'm not real
>> comfortable with Geronimo being heavily dependent on a Codehaus
>> project
>> with precisely one, er, despot. I feel the same about the GBean.org
>> kernel, which while not currently a part of Geronimo, will likely be a
>> candidate for it (and this of course is one of the issues around it).
>>
>> Jeremy, would you consider either substantially enlarging the
>> community of despots for TranQL, bringing it to Apache, or merging
>> it into OpenEJB?
>>
>> Dain, would you consider either substantially enlarging the
>> community of despots for GBean.org, bringing it to Apache, or merging
>> it
>> into Geronimo (as a branch or sandbox module for the present, I
> presume)?
>>
>> Thanks,
>> Aaron
>
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
+1 I think you better stated what I was trying to get at.
Aaron
On Wed, 6 Jul 2005 sissonj@insession.com wrote:
> I was just thinking about the issues of external project dependencies in
> general.. Should there be a process for evaluating the introduction of new
> 'critical' dependencies in Geronimo.
>
> I think we should at least ensure that a 'critical' external project meets
> a minimum criteria, for example:
>
> * An operational web site and documentation that describes the dependency
> (more than just a paragraph).
> * Operational mailing lists and mail archives
> * Operational bug tracking system
> * More than one Geronimo committer on the project
>
> Currently some of the projects being discussed in this thread do not meet
> the 'example' criteria above. Just picture yourself as a new Geronimo
> developer wanting to get involved. Go to these project websites and try
> looking at the mailing list archives and see how much information you can
> find about the project.
>
> What would be the impact to the Geronimo community if a critical project
> initially met this criterial then stops meeting the 'example' criteria?
>
> Have we identified the risks of depending on 'critical' external projects.
> I'm not saying we shouldn't rely upon them, but at least think about the
> risks and how they can be minimised. For example is it safe to rely upon
> these assumptions?:
>
> * that the project host will always be operating
> * that the project host will backup the project source (mistakes can
> happen) and that we will always have access to the source.
> * that mailing list archives for the project kept by the hosting project
> will always be available.
> * that the bug tracking records for the project will always be available
>
> If Geronimo is integrating best of breed external components, then IMHO,
> the project infrastructure and community around those components should be
> well established.
>
> John
>
> This e-mail message and any attachments may contain confidential,
> proprietary or non-public information. This information is intended
> solely for the designated recipient(s). If an addressing or transmission
> error has misdirected this e-mail, please notify the sender immediately
> and destroy this e-mail. Any review, dissemination, use or reliance upon
> this information by unintended recipients is prohibited. Any opinions
> expressed in this e-mail are those of the author personally.
>
> Aaron Mulder <am...@alumni.princeton.edu> wrote on 06/07/2005 09:08:13
> AM:
>
> > Changing the subject since we're drifting again. This is related
> > to another issue that's come up off-list, but we may as well open it to
> a
> > broader discussion here.
> >
> > On Tue, 5 Jul 2005, Jeremy Boynes wrote:
> > > TranQL is a Codehaus project so it is down to the despots, currently
> me.
> > > The barrier to entry is not high but so far I've not seen anything
> > > except that problematic patch.
> >
> > Okay. Well, without getting into specifics, I'm not real
> > comfortable with Geronimo being heavily dependent on a Codehaus project
> > with precisely one, er, despot. I feel the same about the GBean.org
> > kernel, which while not currently a part of Geronimo, will likely be a
> > candidate for it (and this of course is one of the issues around it).
> >
> > Jeremy, would you consider either substantially enlarging the
> > community of despots for TranQL, bringing it to Apache, or merging
> > it into OpenEJB?
> >
> > Dain, would you consider either substantially enlarging the
> > community of despots for GBean.org, bringing it to Apache, or merging it
> > into Geronimo (as a branch or sandbox module for the present, I
> presume)?
> >
> > Thanks,
> > Aaron
>
>
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 5, 2005, at 9:19 PM, sissonj@insession.com wrote:
> I was just thinking about the issues of external project
> dependencies in
> general.. Should there be a process for evaluating the introduction
> of new
> 'critical' dependencies in Geronimo.
>
> I think we should at least ensure that a 'critical' external
> project meets
> a minimum criteria, for example:
>
> * An operational web site and documentation that describes the
> dependency
> (more than just a paragraph).
> * Operational mailing lists and mail archives
> * Operational bug tracking system
> * More than one Geronimo committer on the project
The last one is a hard one. It's an ideal, but for well-established,
stable technology, I don't think we need to require this. (I'm
trying to find a good example, but can't at the moment)
>
> Currently some of the projects being discussed in this thread do
> not meet
> the 'example' criteria above. Just picture yourself as a new Geronimo
> developer wanting to get involved. Go to these project websites
> and try
> looking at the mailing list archives and see how much information
> you can
> find about the project.
>
> What would be the impact to the Geronimo community if a critical
> project
> initially met this criterial then stops meeting the 'example'
> criteria?
This is an interesting point. One of the side-benefits of using
dependences under the Apache license, or one as liberal, is that in a
dire emergency, we could copy the code and keep going with it,
assuming the community around such code died or decided to do
something really wacky, like re-license under the GPL, or completely
change functionality.
>
> Have we identified the risks of depending on 'critical' external
> projects.
> I'm not saying we shouldn't rely upon them, but at least think
> about the
> risks and how they can be minimised. For example is it safe to
> rely upon
> these assumptions?:
>
> * that the project host will always be operating
> * that the project host will backup the project source (mistakes can
> happen) and that we will always have access to the source.
> * that mailing list archives for the project kept by the hosting
> project
> will always be available.
> * that the bug tracking records for the project will always be
> available
>
> If Geronimo is integrating best of breed external components, then
> IMHO,
> the project infrastructure and community around those components
> should be
> well established.
I agree 100% and want to add more. We also want to be sure that for
critical components
- there is a healthy, diverse community surrounding the codebase
(which IMO is a short way of saying what you said above)
- we have reasonable belief that the code contributed to projects we
use is free of claims of copyright infringement or knowingly
"submarined" patents (we can never be sure about patents we
accidentally infringe...)
For the last point, we can *never* be sure of this elsewhere, just
like we aren't sure of it here. However, the ASF system of legal
documents pertaining to incoming IP via our ICLA and CCLA combined
with our practice of using the incubator and specifically tasking
each PMC to be vigilant and conservative about IP issues ("when in
doubt, punt to Incubator...") means we have a demonstrated and
visible structure in place. This seems to provide a good basis for
a) catching any problems before they happen and b) in the unfortunate
event that a problem occurs, protecting the ASF, the project and the
community as much as possible from things like claims of contributory
infringement, etc.
I think that copyright, patent and other issues are going to continue
to be the focal point for the larger debate about OSS and the
software industry, and given that Geronimo's community is growing,
and Geronimo is growing in usefulness (and thus value to users), we
need to always remind ourselves that these issues are of tantamount
importance to the importance of a solid, healthy community.
geir
>
> John
>
> This e-mail message and any attachments may contain confidential,
> proprietary or non-public information. This information is intended
> solely for the designated recipient(s). If an addressing or
> transmission
> error has misdirected this e-mail, please notify the sender
> immediately
> and destroy this e-mail. Any review, dissemination, use or
> reliance upon
> this information by unintended recipients is prohibited. Any opinions
> expressed in this e-mail are those of the author personally.
>
> Aaron Mulder <am...@alumni.princeton.edu> wrote on 06/07/2005
> 09:08:13
> AM:
>
>
>> Changing the subject since we're drifting again. This is related
>> to another issue that's come up off-list, but we may as well open
>> it to
>>
> a
>
>> broader discussion here.
>>
>> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
>>
>>> TranQL is a Codehaus project so it is down to the despots, currently
>>>
> me.
>
>>> The barrier to entry is not high but so far I've not seen anything
>>> except that problematic patch.
>>>
>>
>> Okay. Well, without getting into specifics, I'm not real
>> comfortable with Geronimo being heavily dependent on a Codehaus
>> project
>> with precisely one, er, despot. I feel the same about the GBean.org
>> kernel, which while not currently a part of Geronimo, will likely
>> be a
>> candidate for it (and this of course is one of the issues around it).
>>
>> Jeremy, would you consider either substantially enlarging the
>> community of despots for TranQL, bringing it to Apache, or merging
>> it into OpenEJB?
>>
>> Dain, would you consider either substantially enlarging the
>> community of despots for GBean.org, bringing it to Apache, or
>> merging it
>> into Geronimo (as a branch or sandbox module for the present, I
>>
> presume)?
>
>>
>> Thanks,
>> Aaron
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by si...@insession.com.
I was just thinking about the issues of external project dependencies in
general.. Should there be a process for evaluating the introduction of new
'critical' dependencies in Geronimo.
I think we should at least ensure that a 'critical' external project meets
a minimum criteria, for example:
* An operational web site and documentation that describes the dependency
(more than just a paragraph).
* Operational mailing lists and mail archives
* Operational bug tracking system
* More than one Geronimo committer on the project
Currently some of the projects being discussed in this thread do not meet
the 'example' criteria above. Just picture yourself as a new Geronimo
developer wanting to get involved. Go to these project websites and try
looking at the mailing list archives and see how much information you can
find about the project.
What would be the impact to the Geronimo community if a critical project
initially met this criterial then stops meeting the 'example' criteria?
Have we identified the risks of depending on 'critical' external projects.
I'm not saying we shouldn't rely upon them, but at least think about the
risks and how they can be minimised. For example is it safe to rely upon
these assumptions?:
* that the project host will always be operating
* that the project host will backup the project source (mistakes can
happen) and that we will always have access to the source.
* that mailing list archives for the project kept by the hosting project
will always be available.
* that the bug tracking records for the project will always be available
If Geronimo is integrating best of breed external components, then IMHO,
the project infrastructure and community around those components should be
well established.
John
This e-mail message and any attachments may contain confidential,
proprietary or non-public information. This information is intended
solely for the designated recipient(s). If an addressing or transmission
error has misdirected this e-mail, please notify the sender immediately
and destroy this e-mail. Any review, dissemination, use or reliance upon
this information by unintended recipients is prohibited. Any opinions
expressed in this e-mail are those of the author personally.
Aaron Mulder <am...@alumni.princeton.edu> wrote on 06/07/2005 09:08:13
AM:
> Changing the subject since we're drifting again. This is related
> to another issue that's come up off-list, but we may as well open it to
a
> broader discussion here.
>
> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
> > TranQL is a Codehaus project so it is down to the despots, currently
me.
> > The barrier to entry is not high but so far I've not seen anything
> > except that problematic patch.
>
> Okay. Well, without getting into specifics, I'm not real
> comfortable with Geronimo being heavily dependent on a Codehaus project
> with precisely one, er, despot. I feel the same about the GBean.org
> kernel, which while not currently a part of Geronimo, will likely be a
> candidate for it (and this of course is one of the issues around it).
>
> Jeremy, would you consider either substantially enlarging the
> community of despots for TranQL, bringing it to Apache, or merging
> it into OpenEJB?
>
> Dain, would you consider either substantially enlarging the
> community of despots for GBean.org, bringing it to Apache, or merging it
> into Geronimo (as a branch or sandbox module for the present, I
presume)?
>
> Thanks,
> Aaron
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by Jacek Laskowski <jl...@apache.org>.
Aaron Mulder wrote:
> Okay. Well, without getting into specifics, I'm not real
> comfortable with Geronimo being heavily dependent on a Codehaus project
> with precisely one, er, despot. I feel the same about the GBean.org
> kernel, which while not currently a part of Geronimo, will likely be a
> candidate for it (and this of course is one of the issues around it).
It was *our* decision to rely on these projects. I agree we need to be
very careful about what they are in the future, but I don't think it's a
problem with TranQL at the moment. Although we could have considered
TranQL as a problem having seen some troubles recently, I'm sure we will
be able to work them out easily.
> Jeremy, would you consider either substantially enlarging the
> community of despots for TranQL, bringing it to Apache, or merging
> it into OpenEJB?
Do you think that committers behind selected projects would change their
rules to grant commit access only because Geronimo decides to rely on
their work? I don't think so and would be very surprised if they did.
Our approach to work with other projects should be to be in touch with
these projects and the time will show if we earn their appreciation
which would finally result in the commit access.
I remember someone said the commit access should be seen as an
acknowledgement of someone's contribution rather than what project (s)he
represents. I completely second that point.
> Dain, would you consider either substantially enlarging the
> community of despots for GBean.org, bringing it to Apache, or merging it
> into Geronimo (as a branch or sandbox module for the present, I presume)?
In case of the GBean project, it's much better since we don't yet rely
on them as much as we do on TranQL. It's still under discussion whether
it is the way to go or we will reinvent the wheel or come up with a
better alternative.
> Aaron
Jacek
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jul 5, 2005, at 7:58 PM, Dain Sundstrom wrote:
> On Jul 5, 2005, at 4:08 PM, Aaron Mulder wrote:
>
>
>> Dain, would you consider either substantially enlarging the
>> community of despots for GBean.org,
>>
>
> Absolutely. The whole thing has been on hold while we finished the
> TCK. Over time, as more people get involved we will have more
> committers and despots.
>
I think that if you brought the thing here, you'd have the same thing.
We could, if everyone agreed, to make it a subproject with separate
release cycles and even a separate committer list. It would have the
benefit of keeping the Geronimo kernel community together, make the
Geronimo Container more valuable, and resolve the problem of using
"Gbean" in the name of an independent project separate and outside of
the Geronimo project.
geir
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Project Dependencies: TranQL & maybe someday GBean.org
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 5, 2005, at 4:08 PM, Aaron Mulder wrote:
> Dain, would you consider either substantially enlarging the
> community of despots for GBean.org,
Absolutely. The whole thing has been on hold while we finished the
TCK. Over time, as more people get involved we will have more
committers and despots.
> bringing it to Apache, or merging it into Geronimo (as a branch or
> sandbox module for the present, I presume)?
That is something I will be bringing up for discussion on the gbean
mailing list later this week.
-dain
Project Dependencies: TranQL & maybe someday GBean.org
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Changing the subject since we're drifting again. This is related
to another issue that's come up off-list, but we may as well open it to a
broader discussion here.
On Tue, 5 Jul 2005, Jeremy Boynes wrote:
> TranQL is a Codehaus project so it is down to the despots, currently me.
> The barrier to entry is not high but so far I've not seen anything
> except that problematic patch.
Okay. Well, without getting into specifics, I'm not real
comfortable with Geronimo being heavily dependent on a Codehaus project
with precisely one, er, despot. I feel the same about the GBean.org
kernel, which while not currently a part of Geronimo, will likely be a
candidate for it (and this of course is one of the issues around it).
Jeremy, would you consider either substantially enlarging the
community of despots for TranQL, bringing it to Apache, or merging
it into OpenEJB?
Dain, would you consider either substantially enlarging the
community of despots for GBean.org, bringing it to Apache, or merging it
into Geronimo (as a branch or sandbox module for the present, I presume)?
Thanks,
Aaron
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> On Tue, 5 Jul 2005, Jeremy Boynes wrote:
>
>>I didn't -1 it, I said it wasn't a pre-req, as in I think we can release
>>M4 without it.
>>
>>As for a technical reason, where's the code? Last I saw was a patch for
>>TranQL that caused a circular dependency and screwed up the IP. If there
>>is something newer that addresses these issues I would be happy to look
>>at it.
>
>
> But I'm not asking for review of the patch. I'm asking to be able
> to apply it myself. (FYI, if by circular dependency you mean at the
> Geronimo depends on TranQL and vice versa level, we agreed in earlier
> discussions to move the builder to Geronimo, and the IP issue has been
> resolved.)
>
> I'm assuming that committership on Geronimo and OpenEJB
> fundamentally equates to committership on TranQL. If not, what is the
> process for becoming a committer on TranQL? (Is there a TranQL
> PMC-equivalent? Or do you personally make the call?)
>
TranQL is a Codehaus project so it is down to the despots, currently me.
The barrier to entry is not high but so far I've not seen anything
except that problematic patch.
--
Jeremy
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Tue, 5 Jul 2005, Jeremy Boynes wrote:
> I didn't -1 it, I said it wasn't a pre-req, as in I think we can release
> M4 without it.
>
> As for a technical reason, where's the code? Last I saw was a patch for
> TranQL that caused a circular dependency and screwed up the IP. If there
> is something newer that addresses these issues I would be happy to look
> at it.
But I'm not asking for review of the patch. I'm asking to be able
to apply it myself. (FYI, if by circular dependency you mean at the
Geronimo depends on TranQL and vice versa level, we agreed in earlier
discussions to move the builder to Geronimo, and the IP issue has been
resolved.)
I'm assuming that committership on Geronimo and OpenEJB
fundamentally equates to committership on TranQL. If not, what is the
process for becoming a committer on TranQL? (Is there a TranQL
PMC-equivalent? Or do you personally make the call?)
Thanks,
Aaron
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> On Mon, 4 Jul 2005, Jeremy Boynes wrote:
>
>>> I want to get the key generator changes in for M4. However, I'm
>>>currently blocked because I can't add the new module to TranQL. So I'd
>>>like to resolve that before the branch. Other than that, I'm fine to go
>>>ahead with the 24 hour notice.
>>
>>I don't think this is a pre-req for M4.
>
>
> Why not? The feature has the support of the group. The code is
> ready, the test pass, the itests pass, the TCK passes. If you'd like to
> -1 it please provide a technical reason.
I didn't -1 it, I said it wasn't a pre-req, as in I think we can release
M4 without it.
As for a technical reason, where's the code? Last I saw was a patch for
TranQL that caused a circular dependency and screwed up the IP. If there
is something newer that addresses these issues I would be happy to look
at it.
--
Jeremy
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 5/07/2005 1:55 PM, Aaron Mulder wrote:
>On Mon, 4 Jul 2005, Jeremy Boynes wrote:
>
>
>>> I want to get the key generator changes in for M4. However, I'm
>>>currently blocked because I can't add the new module to TranQL. So I'd
>>>like to resolve that before the branch. Other than that, I'm fine to go
>>>ahead with the 24 hour notice.
>>>
>>>
>>I don't think this is a pre-req for M4.
>>
>>
>
> Why not? The feature has the support of the group. The code is
>ready, the test pass, the itests pass, the TCK passes. If you'd like to
>-1 it please provide a technical reason.
>
>
I do not see a technical reason; yet, I see a release management reason.
This is an enhancement and hence this may be classified as a non
pre-requisite. Conversely, the fact that the running module list is not
saved is a bug and I do not think that a release should procede with a
single known bug.
It really depends on how we want to proceed; yet, in the case of a
feature freeze, I assume that features have been locked down.
At this stage, I think that the feature freeze gate has not yet been
reached - I may be wrong. If this gate has not yet been reached, then
you may have the time to add the feature.
Thanks,
Gianny
> Myself, I'd prefer to get it in to M4 because it involves a change
>to the EJB deployment syntax. I'd like to put it in a stable release
>ASAP. And the syntax of that plan has changed since M3 already.
>
>Thanks,
> Aaron
>
>
>
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by David Blevins <da...@visi.com>.
On Mon, Jul 04, 2005 at 11:55:11PM -0400, Aaron Mulder wrote:
> On Mon, 4 Jul 2005, Jeremy Boynes wrote:
> > > I want to get the key generator changes in for M4. However, I'm
> > > currently blocked because I can't add the new module to TranQL. So I'd
> > > like to resolve that before the branch. Other than that, I'm fine to go
> > > ahead with the 24 hour notice.
> >
> > I don't think this is a pre-req for M4.
>
> Why not? The feature has the support of the group. The code is
> ready, the test pass, the itests pass, the TCK passes. If you'd like to
> -1 it please provide a technical reason.
>
> Myself, I'd prefer to get it in to M4 because it involves a change
> to the EJB deployment syntax. I'd like to put it in a stable release
> ASAP. And the syntax of that plan has changed since M3 already.
>
Good points.
-David
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 4 Jul 2005, Jeremy Boynes wrote:
> > I want to get the key generator changes in for M4. However, I'm
> > currently blocked because I can't add the new module to TranQL. So I'd
> > like to resolve that before the branch. Other than that, I'm fine to go
> > ahead with the 24 hour notice.
>
> I don't think this is a pre-req for M4.
Why not? The feature has the support of the group. The code is
ready, the test pass, the itests pass, the TCK passes. If you'd like to
-1 it please provide a technical reason.
Myself, I'd prefer to get it in to M4 because it involves a change
to the EJB deployment syntax. I'd like to put it in a stable release
ASAP. And the syntax of that plan has changed since M3 already.
Thanks,
Aaron
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Jeremy Boynes <jb...@apache.org>.
Aaron Mulder wrote:
> I want to get the key generator changes in for M4. However, I'm
> currently blocked because I can't add the new module to TranQL. So I'd
> like to resolve that before the branch. Other than that, I'm fine to go
> ahead with the 24 hour notice.
>
I don't think this is a pre-req for M4.
> Oh, I think we also have a problem where the currently running
> module list never gets saved. So you always get the default services when
> you start the server. I think I remember a conversation about how it
> was caused by some bad logic around our shutdown hooks. That needs to be
> resolved too.
>
On the other hand, this is. However, it should not stop us starting a
branch as the fix can be merged back.
--
Jeremy
Re: [CONSENSUS?] Preparation for M4 -- branch early
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I want to get the key generator changes in for M4. However, I'm
currently blocked because I can't add the new module to TranQL. So I'd
like to resolve that before the branch. Other than that, I'm fine to go
ahead with the 24 hour notice.
Oh, I think we also have a problem where the currently running
module list never gets saved. So you always get the default services when
you start the server. I think I remember a conversation about how it
was caused by some bad logic around our shutdown hooks. That needs to be
resolved too.
Aaron
On Mon, 4 Jul 2005, David Blevins wrote:
> Do we have a consensus that we should branch at the beginning of the release cycle instead of at the end as we have done in the past?
>
> If so, going to put out an email titled "M4 - 24 hour notice of branch", which I think would be a good release practice.
>
> -David
>
> On Mon, Jul 04, 2005 at 07:15:34PM -0700, David Blevins wrote:
> > On Mon, Jul 04, 2005 at 06:38:23PM -0700, Jeremy Boynes wrote:
> > > David Blevins wrote:
> > > >On Mon, Jul 04, 2005 at 05:22:36PM -0700, Jeremy Boynes wrote:
> > > >
> > > >>David Blevins wrote:
> > > >>
> > > >>>Anything I missed?
> > > >>>
> > > >>
> > > >>SNAPSHOT elimination so the build is reproducible.
> > > >
> > > >
> > > >Right. Missed that one for M3 IIRC.
> > > >
> > > >
> > > >>Branch so that M4 can stabilize whilst other changes are being made.
> > > >
> > > >
> > > >We do for every milestone. Don't expect this to be different.
> > > >
> > > >
> > > >>Acceptance test process - how do we know what works (need to avoid a
> > > >>broken release like M3).
> > > >
> > > >
> > > >That's what I meant by:
> > > >
> > > > DB> We have a number of people interested in testing. I'll ping
> > > > DB> them when I have something ready.
> > > >
> > > >Was thinking to branch when I dish out the binaries for testing.
> > > >Rather than the "surprise, here is a binary" approach we've done in
> > > >the past. Sounds pretty much like what you are proposing as well.
> > > >
> > >
> > > Yes - in the past we've just tagged and moved on. This time I think we
> > > should create the branch at the start of the process rather than at the
> > > end as there seem to be a lot of pent up changes planned. Yes, we may
> > > need to merge some critical changes back to this branch but hopefully
> > > this can be kept to a minimum.
> > >
> > > So basically,
> > > * create a branch now, say 1.0-M4-prep
> > > * do the stuff we talking about now on that branch
> > > * cut the final M4 distro
> > > * drop the 1.0-M4-prep branch
> > >
> > > Other work can continue on the trunk without destablizing the M4 release.
> > >
> >
> > +1 That's pretty much what I had in mind.
> >
> >
> > -David
>