Re: Numbering of snapshots/release candidates/etc (was: Re: [general][M3] release candidate status)

[Mark Hindess <ma...@googlemail.com>]

On 3 October 2007 at 13:32, "Stepan Mishura" <st...@gmail.com> wrote:
> On 10/2/07, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > Something to think about after M3...
> >
> > On 2 October 2007 at 14:46, "Stepan Mishura" <st...@gmail.com> wro
> te:
> > >
> > > Hi,
> > >
> > > Currently, the next milestone candidate (r580985) is under testing.
> >
> > It might be more consistent if we named candidates/snapshots/etc
> > using the canonical revision number - i.e. the last change revision
> > number - rather than some arbitrary revision number after it (and
> > before the next change).
> >
> 
> I agree. I think this may correlate with auto selection of revision
> number for the next snapshot. The idea is to create automation for
> collecting/analysing integrity testing results and choosing the best
> revision for some period of time (for example, 48 hours)

Sounds good so long as we can find a way to pick the best revision 
without doing too many queries against the svn server. ;-)

-Mark.

Re: Numbering of snapshots/release candidates/etc

[Stepan Mishura <st...@gmail.com>]

On 10/3/07, Gregory Shimansky <gs...@gmail.com> wrote:
> Stepan Mishura wrote:
> > On 10/3/07, Mark Hindess wrote:
> >> On 3 October 2007 at 13:34, Gregory Shimansky <gs...@gmail.com> wrote:
> >>> Mark Hindess wrote:
> >>>> On 3 October 2007 at 13:32, "Stepan Mishura" <st...@gmail.com> wro
> >>> te:
> >>>>> On 10/2/07, Mark Hindess <ma...@googlemail.com> wrote:
> >>>>>> Something to think about after M3...
> >>>>>>
> >>>>>> On 2 October 2007 at 14:46, "Stepan Mishura" <st...@gmail.com> w
> >>> ro
> >>>>> te:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Currently, the next milestone candidate (r580985) is under testing.
> >>>>>> It might be more consistent if we named candidates/snapshots/etc
> >>>>>> using the canonical revision number - i.e. the last change revision
> >>>>>> number - rather than some arbitrary revision number after it (and
> >>>>>> before the next change).
> >>>>>>
> >>>>> I agree. I think this may correlate with auto selection of revision
> >>>>> number for the next snapshot. The idea is to create automation for
> >>>>> collecting/analysing integrity testing results and choosing the best
> >>>>> revision for some period of time (for example, 48 hours)
> >>>> Sounds good so long as we can find a way to pick the best revision
> >>>> without doing too many queries against the svn server. ;-)
> >>> I think it is possible to use "svn info" to get "Last Changed Rev" out
> >>> of the repository. It doesn't query the server at all.
> >> Of course, and that is what I had in mind when suggesting we fix our
> >> processes, but it sounded like Stepan had something more sophisticated
> >> in mind.
> >
> > There is a chance that the code for the "Last Changed Rev" is broken
> > and it doesn't make sense to build and test a new snapshot. We publish
> > 3 snapshots per week and there were cases when we had only 1 snapshot
> > because of broken build, mass tests failures ... I think we should
> > avoid publishing broken snapshots.
>
> I don't quite understand what is the difference between current revision
> number that is >= "Last Changed Rev", but denotes a revision that has no
> changes since "Last Changed Rev" in Harmony source tree.
>
> As far as I understand checking out harmony with currently used revision
> numbers and "Last Changed Rev" should produce identical source trees for
> Harmony, so it is just a matter of naming snapshots. If a snapshot is
> broken for the "Last Changed Rev" it shall remain broken until some
> changes are done to the source code which will change "Last Changed Rev"
> number.

Yes, that is correct. But we are talking (IMHO it is implied) that we
build snapshots not only for milestones. During active development
(between two milestones) we also do snapshot testing and choose some
revision number. And it is not the "Last Changed Rev".

Thanks,
Stepan.

Re: Numbering of snapshots/release candidates/etc

[Gregory Shimansky <gs...@gmail.com>]

Stepan Mishura wrote:
> On 10/3/07, Mark Hindess wrote:
>> On 3 October 2007 at 13:34, Gregory Shimansky <gs...@gmail.com> wrote:
>>> Mark Hindess wrote:
>>>> On 3 October 2007 at 13:32, "Stepan Mishura" <st...@gmail.com> wro
>>> te:
>>>>> On 10/2/07, Mark Hindess <ma...@googlemail.com> wrote:
>>>>>> Something to think about after M3...
>>>>>>
>>>>>> On 2 October 2007 at 14:46, "Stepan Mishura" <st...@gmail.com> w
>>> ro
>>>>> te:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Currently, the next milestone candidate (r580985) is under testing.
>>>>>> It might be more consistent if we named candidates/snapshots/etc
>>>>>> using the canonical revision number - i.e. the last change revision
>>>>>> number - rather than some arbitrary revision number after it (and
>>>>>> before the next change).
>>>>>>
>>>>> I agree. I think this may correlate with auto selection of revision
>>>>> number for the next snapshot. The idea is to create automation for
>>>>> collecting/analysing integrity testing results and choosing the best
>>>>> revision for some period of time (for example, 48 hours)
>>>> Sounds good so long as we can find a way to pick the best revision
>>>> without doing too many queries against the svn server. ;-)
>>> I think it is possible to use "svn info" to get "Last Changed Rev" out
>>> of the repository. It doesn't query the server at all.
>> Of course, and that is what I had in mind when suggesting we fix our
>> processes, but it sounded like Stepan had something more sophisticated
>> in mind.
> 
> There is a chance that the code for the "Last Changed Rev" is broken
> and it doesn't make sense to build and test a new snapshot. We publish
> 3 snapshots per week and there were cases when we had only 1 snapshot
> because of broken build, mass tests failures ... I think we should
> avoid publishing broken snapshots.

I don't quite understand what is the difference between current revision 
number that is >= "Last Changed Rev", but denotes a revision that has no 
changes since "Last Changed Rev" in Harmony source tree.

As far as I understand checking out harmony with currently used revision 
numbers and "Last Changed Rev" should produce identical source trees for 
Harmony, so it is just a matter of naming snapshots. If a snapshot is 
broken for the "Last Changed Rev" it shall remain broken until some 
changes are done to the source code which will change "Last Changed Rev" 
number.

-- 
Gregory

Re: Numbering of snapshots/release candidates/etc

[Stepan Mishura <st...@gmail.com>]

On 10/3/07, Mark Hindess wrote:
>
> On 3 October 2007 at 13:34, Gregory Shimansky <gs...@gmail.com> wrote:
> > Mark Hindess wrote:
> > > On 3 October 2007 at 13:32, "Stepan Mishura" <st...@gmail.com> wro
> > te:
> > >> On 10/2/07, Mark Hindess <ma...@googlemail.com> wrote:
> > >>> Something to think about after M3...
> > >>>
> > >>> On 2 October 2007 at 14:46, "Stepan Mishura" <st...@gmail.com> w
> > ro
> > >> te:
> > >>>> Hi,
> > >>>>
> > >>>> Currently, the next milestone candidate (r580985) is under testing.
> > >>> It might be more consistent if we named candidates/snapshots/etc
> > >>> using the canonical revision number - i.e. the last change revision
> > >>> number - rather than some arbitrary revision number after it (and
> > >>> before the next change).
> > >>>
> > >> I agree. I think this may correlate with auto selection of revision
> > >> number for the next snapshot. The idea is to create automation for
> > >> collecting/analysing integrity testing results and choosing the best
> > >> revision for some period of time (for example, 48 hours)
> > >
> > > Sounds good so long as we can find a way to pick the best revision
> > > without doing too many queries against the svn server. ;-)
> >
> > I think it is possible to use "svn info" to get "Last Changed Rev" out
> > of the repository. It doesn't query the server at all.
>
> Of course, and that is what I had in mind when suggesting we fix our
> processes, but it sounded like Stepan had something more sophisticated
> in mind.

There is a chance that the code for the "Last Changed Rev" is broken
and it doesn't make sense to build and test a new snapshot. We publish
3 snapshots per week and there were cases when we had only 1 snapshot
because of broken build, mass tests failures ... I think we should
avoid publishing broken snapshots.

Thanks,
Stepan.

Re: Numbering of snapshots/release candidates/etc

[Mark Hindess <ma...@googlemail.com>]

On 3 October 2007 at 13:34, Gregory Shimansky <gs...@gmail.com> wrote:
> Mark Hindess wrote:
> > On 3 October 2007 at 13:32, "Stepan Mishura" <st...@gmail.com> wro
> te:
> >> On 10/2/07, Mark Hindess <ma...@googlemail.com> wrote:
> >>> Something to think about after M3...
> >>>
> >>> On 2 October 2007 at 14:46, "Stepan Mishura" <st...@gmail.com> w
> ro
> >> te:
> >>>> Hi,
> >>>>
> >>>> Currently, the next milestone candidate (r580985) is under testing.
> >>> It might be more consistent if we named candidates/snapshots/etc
> >>> using the canonical revision number - i.e. the last change revision
> >>> number - rather than some arbitrary revision number after it (and
> >>> before the next change).
> >>>
> >> I agree. I think this may correlate with auto selection of revision
> >> number for the next snapshot. The idea is to create automation for
> >> collecting/analysing integrity testing results and choosing the best
> >> revision for some period of time (for example, 48 hours)
> > 
> > Sounds good so long as we can find a way to pick the best revision 
> > without doing too many queries against the svn server. ;-)
> 
> I think it is possible to use "svn info" to get "Last Changed Rev" out 
> of the repository. It doesn't query the server at all.

Of course, and that is what I had in mind when suggesting we fix our
processes, but it sounded like Stepan had something more sophisticated
in mind.

Regards,
 Mark.

Re: Numbering of snapshots/release candidates/etc

[Gregory Shimansky <gs...@gmail.com>]

Mark Hindess wrote:
> On 3 October 2007 at 13:32, "Stepan Mishura" <st...@gmail.com> wrote:
>> On 10/2/07, Mark Hindess <ma...@googlemail.com> wrote:
>>> Something to think about after M3...
>>>
>>> On 2 October 2007 at 14:46, "Stepan Mishura" <st...@gmail.com> wro
>> te:
>>>> Hi,
>>>>
>>>> Currently, the next milestone candidate (r580985) is under testing.
>>> It might be more consistent if we named candidates/snapshots/etc
>>> using the canonical revision number - i.e. the last change revision
>>> number - rather than some arbitrary revision number after it (and
>>> before the next change).
>>>
>> I agree. I think this may correlate with auto selection of revision
>> number for the next snapshot. The idea is to create automation for
>> collecting/analysing integrity testing results and choosing the best
>> revision for some period of time (for example, 48 hours)
> 
> Sounds good so long as we can find a way to pick the best revision 
> without doing too many queries against the svn server. ;-)

I think it is possible to use "svn info" to get "Last Changed Rev" out 
of the repository. It doesn't query the server at all.

-- 
Gregory