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.
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.
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...
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.
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
Any opinions on above remaining issue?
Overall, RFC4 looks pretty reasonable to me.
Let's vote soon (once above issue is added to RFC4).
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
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."
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
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."
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
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
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
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."
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
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.
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 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:
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 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:
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 ?
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.
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.
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).
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.