[GRASS-dev] RFC 4: Release procedure

Hello,

Recent discussion have convinced me that we might need a more clearly defined release procedure for the GRASS project in order to make release more fluid and less conflictual.

I very rapidly drafted a RFC for that:

http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

It's a very early draft and discussions and modifications are more than welcome.

Moritz

Hi,

2014-06-11 11:30 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:

Recent discussion have convinced me that we might need a more clearly
defined release procedure for the GRASS project in order to make release
more fluid and less conflictual.

thanks for your effort.

I very rapidly drafted a RFC for that:

http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

It's a very early draft and discussions and modifications are more than
welcome.

AT first look, draft looks reasonable. More comments later.

Martin

--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa

On Wed, Jun 11, 2014 at 11:30 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

I very rapidly drafted a RFC for that:

http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

To me the proposed procedure looks very good.
We may test it asap with GRASS 7.0.0beta3 if you agree.

Markus

On 15 June 2014 01:12, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Jun 11, 2014 at 11:30 AM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

I very rapidly drafted a RFC for that:

http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

To me the proposed procedure looks very good.

me too, It is a good compromise between strong rules (like QGIS) and
nothing as GRASS now, it leave open time between one release to the
other but it is strong from Proposal of release to final release...

Markus

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell <smitch@me.com> wrote:

Agreed, and I like Markus’ idea of testing it on an upcoming release.

(just a low priority comment here)

While doing so it turns out that one week between RC2 and final is a bit short.
And some urgent fixes came in only during the RC procedure. We need to
as a phrase if this requires a new RC (not this time though!) or not
or depends.

Overall, RFC4 looks pretty reasonable to me.

Markus

Hi,

On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell <smitch@me.com> wrote:

Agreed, and I like Markus’ idea of testing it on an upcoming release.

(just a low priority comment here)

While doing so it turns out that one week between RC2 and final is a bit short.
And some urgent fixes came in only during the RC procedure. We need to
[add] a phrase if this requires a new RC (not this time though!) or not
or depends.

Overall, we got the release out :slight_smile:
Any opinions on above remaining issue?

Overall, RFC4 looks pretty reasonable to me.

Let's vote soon (once above issue is added to RFC4).

Markus

On 01/03/15 19:02, Markus Neteler wrote:

Hi,

On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell <smitch@me.com> wrote:

Agreed, and I like Markus’ idea of testing it on an upcoming release.

(just a low priority comment here)

While doing so it turns out that one week between RC2 and final is a bit short.
And some urgent fixes came in only during the RC procedure. We need to
[add] a phrase if this requires a new RC (not this time though!) or not
or depends.

Overall, we got the release out :slight_smile:
Any opinions on above remaining issue?

I think that with time we will get better at this procedure and the one week limit should be ok, but I have no objections to add a phrase to step 6 such as

"A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted. If an important bug is discovered for which a fix needs some more testing, an RC3 can exceptionally be published, with another week of testing before final release."

Moritz

I agree with the suggested modification by Moritz,

Helena

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Mar 3, 2015, at 3:31 AM, Moritz Lennert wrote:

On 01/03/15 19:02, Markus Neteler wrote:

Hi,

On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell <smitch@me.com> wrote:

Agreed, and I like Markus’ idea of testing it on an upcoming release.

(just a low priority comment here)

While doing so it turns out that one week between RC2 and final is a bit short.
And some urgent fixes came in only during the RC procedure. We need to
[add] a phrase if this requires a new RC (not this time though!) or not
or depends.

Overall, we got the release out :slight_smile:
Any opinions on above remaining issue?

I think that with time we will get better at this procedure and the one week limit should be ok, but I have no objections to add a phrase to step 6 such as

"A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted. If an important bug is discovered for which a fix needs some more testing, an RC3 can exceptionally be published, with another week of testing before final release."

Moritz
_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc

I agree.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Mar 3, 2015, at 6:55 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

I agree with the suggested modification by Moritz,

Helena

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@ncsu.edu
NCSU GeoForAll Lab (NCSU OSGeoREL)
"All electronic mail messages in connection with State business which are sent to or received by this account are subject to the NC Public Records Law and may be disclosed to third parties.”

On Mar 3, 2015, at 3:31 AM, Moritz Lennert wrote:

On 01/03/15 19:02, Markus Neteler wrote:

Hi,

On Tue, Feb 17, 2015 at 1:54 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Fri, Jun 20, 2014 at 3:39 AM, Scott Mitchell <smitch@me.com> wrote:

Agreed, and I like Markus’ idea of testing it on an upcoming release.

(just a low priority comment here)

While doing so it turns out that one week between RC2 and final is a bit short.
And some urgent fixes came in only during the RC procedure. We need to
[add] a phrase if this requires a new RC (not this time though!) or not
or depends.

Overall, we got the release out :slight_smile:
Any opinions on above remaining issue?

I think that with time we will get better at this procedure and the one week limit should be ok, but I have no objections to add a phrase to step 6 such as

"A final, concerted bug squashing effort by all developers of no more than one week. During that same time the release announcement is drafted. If an important bug is discovered for which a fix needs some more testing, an RC3 can exceptionally be published, with another week of testing before final release."

Moritz
_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
grass-psc Info Page

_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
grass-psc Info Page

Hi,

2015-03-03 9:31 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:

"A final, concerted bug squashing effort by all developers of no more than
one week. During that same time the release announcement is drafted. If an
important bug is discovered for which a fix needs some more testing, an RC3
can exceptionally be published, with another week of testing before final
release."

make sense to me, Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

On 04/03/15 09:19, Martin Landa wrote:

Hi,

2015-03-03 9:31 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:

"A final, concerted bug squashing effort by all developers of no more than
one week. During that same time the release announcement is drafted. If an
important bug is discovered for which a fix needs some more testing, an RC3
can exceptionally be published, with another week of testing before final
release."

make sense to me, Martin

Ok, I've added the change. In any case we are a small enough team to handle things flexibly if needed. For me, the idea of elaborating a release procedure is mostly to make the process more explicit and thus ease communication, not to hammer laws into stone

Moritz

On Wed, Mar 4, 2015 at 6:03 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 04/03/15 09:19, Martin Landa wrote:

Hi,

2015-03-03 9:31 GMT+01:00 Moritz Lennert <mlennert@club.worldonline.be>:

"A final, concerted bug squashing effort by all developers of no more
than one week. During that same time the release announcement is drafted. If
an important bug is discovered for which a fix needs some more testing, an
RC3 can exceptionally be published, with another week of testing before final
release."

make sense to me, Martin

Ok, I've added the change. In any case we are a small enough team to handle
things flexibly if needed. For me, the idea of elaborating a release
procedure is mostly to make the process more explicit and thus ease
communication, not to hammer laws into stone

Great, so I'll make a motion on this in the next days unless any
objection pops up before.

Markus

Hi Markus,

2015-03-04 20:29 GMT+01:00 Markus Neteler <neteler@osgeo.org>:

[...]

Great, so I'll make a motion on this in the next days unless any
objection pops up before.

it seems that there are no objections :slight_smile: Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

2015-10-20 9:12 GMT+02:00 Martin Landa <landa.martin@gmail.com>:

Great, so I'll make a motion on this in the next days unless any
objection pops up before.

it seems that there are no objections :slight_smile: Martin

reading it again, I would say that in some cases upcoming RC2 could be
released as final. Eg. for upcoming 7.0.2 we have RC1 released. In two
weeks should become RC2, in this case I can image to release final
instead of RC2. So alternative roadmap could be:

Step 3 (X+30 days) - Hard freeze & RC1
Step 4 - Bug squashing
Step 5 (X+44 days) - Final.

In other words I would make RC2 as optional step only we will need it.
It can happen that two RCs could be overkill. What do you think?
Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

On 20/10/15 09:18, Martin Landa wrote:

2015-10-20 9:12 GMT+02:00 Martin Landa <landa.martin@gmail.com>:

Great, so I'll make a motion on this in the next days unless any
objection pops up before.

it seems that there are no objections :slight_smile: Martin

reading it again, I would say that in some cases upcoming RC2 could be
released as final. Eg. for upcoming 7.0.2 we have RC1 released. In two
weeks should become RC2, in this case I can image to release final
instead of RC2. So alternative roadmap could be:

Step 3 (X+30 days) - Hard freeze & RC1
Step 4 - Bug squashing
Step 5 (X+44 days) - Final.

In other words I would make RC2 as optional step only we will need it.
It can happen that two RCs could be overkill. What do you think?

The idea of the RC2 was to provoke some more last-minute testing as some fixes might have been introduced after RC1 and I'm not sure how many people test the release branch between RC's. This way we make it more prominent and can send out a call to everyone to please test RC2. This does not mean that RC2 cannot be identical to final. It's just a last chance to spot any serious issues.

So, I would plead for leaving it in. 5 days more or less is not that much, or ?

Moritz

Hi,

2015-10-20 9:36 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:

The idea of the RC2 was to provoke some more last-minute testing as some
fixes might have been introduced after RC1 and I'm not sure how many people
test the release branch between RC's. This way we make it more prominent and
can send out a call to everyone to please test RC2. This does not mean that
RC2 cannot be identical to final. It's just a last chance to spot any
serious issues.

So, I would plead for leaving it in. 5 days more or less is not that much,
or ?

I understand the point, on the other hand it's extra work for release
manager and packager which would sometimes make sense to avoid and be
so not strict in the way that RC2 step could be optional (or skipped
if no objection from community). On the other hand we can add more
steps (RC3, RC4, ...) if it will be necessary in the case of extra
complicated release.

Any comments, ideas? Thanks, Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

On Tue, Oct 20, 2015 at 4:29 PM, Martin Landa <landa.martin@gmail.com>
wrote:

Hi,

2015-10-20 9:36 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:

> The idea of the RC2 was to provoke some more last-minute testing as some
> fixes might have been introduced after RC1 and I'm not sure how many
people
> test the release branch between RC's. This way we make it more prominent
and
> can send out a call to everyone to please test RC2. This does not mean
that
> RC2 cannot be identical to final. It's just a last chance to spot any
> serious issues.
>
> So, I would plead for leaving it in. 5 days more or less is not that
much,
> or ?

I understand the point, on the other hand it's extra work for release
manager and packager which would sometimes make sense to avoid and be
so not strict in the way that RC2 step could be optional (or skipped
if no objection from community). On the other hand we can add more
steps (RC3, RC4, ...) if it will be necessary in the case of extra
complicated release.

Any comments, ideas? Thanks, Martin

I agree with Martin, I guess it's quite a bit of work involved in it and it
seems we now started to release more often than in previous years, which is
a good trend. So I would rather release more often with less RCs.

Anna

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

On Tue, Oct 20, 2015 at 11:25 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Tue, Oct 20, 2015 at 4:29 PM, Martin Landa <landa.martin@gmail.com>

...

I understand the point, on the other hand it's extra work for release
manager and packager which would sometimes make sense to avoid and be
so not strict in the way that RC2 step could be optional (or skipped
if no objection from community). On the other hand we can add more
steps (RC3, RC4, ...) if it will be necessary in the case of extra
complicated release.

Any comments, ideas? Thanks, Martin

I agree with Martin, I guess it's quite a bit of work involved in it and it
seems we now started to release more often than in previous years, which is
a good trend. So I would rather release more often with less RCs.

I agree on this since each RC takes hours of work (check, package,
upload, write and email announcements, updated many CMS Web pages,
chase packagers etc etc).

Markus

Dear all,

2015-10-25 19:37 GMT+01:00 Markus Neteler <neteler@osgeo.org>:

I agree with Martin, I guess it's quite a bit of work involved in it and it
seems we now started to release more often than in previous years, which is
a good trend. So I would rather release more often with less RCs.

I agree on this since each RC takes hours of work (check, package,
upload, write and email announcements, updated many CMS Web pages,
chase packagers etc etc).

what about following GDAL "approach"? Release manager usually writes
to ML "do you agree that upcoming RCX will be released as final?". If
no objection appears within few days, than the new version is
released. In RFC4 we should require RC1 at least. So first candidate
for final release would be upcoming RC2.

Martin

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa