[Geoserver-devel] Blocker priority misuse

GeoServer GeoServer Developer
1

Hi,
recently I’ve started to see a trend of more jira issues being marked as “blockers”.

Blocker is, or should be, “end of the world, attend to immediately” type of issue, e.g., a build breakage
on the official build server, something that blocks every developer, but I see it used
as “it’s a blocker for me” instead, which I believe is misuse.

I know Jira has a definition here:
http://jira.codehaus.org/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels

and this thread is also interesting:
http://lists.opencastproject.org/pipermail/matterhorn/2009-August/002038.html

Imho before setting an issue to “blocker” level you should ask youself “is it really
blocking all developers?”
We’re all extremely busy, marking a issue at such a high level looks like a tentative
to get undeserved attention for an issue that is not actually affecting everybody.

Of course we can discuss this and come up with a meaning other than the usual one
if people feel strongly about it.

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

2

On 09/05/12 15:52, Andrea Aime wrote:

recently I've started to see a trend of more jira issues being marked as
"blockers".

Sorry, that sounds like me. :slight_smile:

Blocker is, or should be, "end of the world, attend to immediately" type
of issue, e.g., a build breakage
on the official build server, something that blocks every developer, but
I see it used
as "it's a blocker _for me_" instead, which I believe is misuse.

One word you have added here is "official". While I appreciate the work that OpenGeo have done in providing Hudson coverage, it is not the only build coverage for this project.

Despite several requests from me, the OpenGeo Hudson no longer builds in a path with spaces, so does not catch the File/URL conversion build failures I often report. These break the build on some Windows development boxes, and can break production deployments on Windows and other boxes in paths with spaces or internationalised paths ("Program Files", "Documents and Settings").

There are other reasons to run an "unofficial" build bot, including coverage of obscure modules like webservice; these are not OpenGeo's problem. Others have run build bots to cover other JDKs. If we set one up for Jody for OpenJDK would it be unofficial? Are only OpenGeo Hudson failures blockers?

I don't expect the community to monitor other buildbots, but I do expect to be able to report problems that break the build for bots or multiple developers as blockers.

I agree that it is annoying to have many blockers. I have been trying to fix this build all week:
http://geobuilder.arrc.csiro.au/geoserver/waterfall?show=GeoT-java15

I know Jira has a definition here:
http://jira.codehaus.org/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels
and this thread is also interesting:
http://lists.opencastproject.org/pipermail/matterhorn/2009-August/002038.html

I agree with all the Jira definitions except one: what Jira refers to as a Priority is in fact a Severity. These are not the same thing.

Imho before setting an issue to "blocker" level you should ask youself
"is it really
blocking all developers?"
We're all extremely busy, marking a issue at such a high level looks
like a tentative
to get undeserved attention for an issue that is not actually affecting
everybody.
Of course we can discuss this and come up with a meaning other than the
usual one
if people feel strongly about it.

How about "Blocker" meaning that a build bot is broken or several developers cannot build? I agree that one developer's build failure does not constitute a blocker. In the past I have reported blockers and been more than happy to reduce their Jira Priority when I realised that it was only affecting a single machine.

Would it help if I went back and fixed the Priority of recent Blockers for which temporary fixes have been committed?

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

3

I think we filled in our own definitions to help things along … let me check Jira.

Blocker-prevents development, Critical-prevents release, Major-prevents function, Minor-requires workaround, Trivial-cosmetic problem

So we refer to blocker as something that prevents the developers working on the project.

I am happy with these definitions; we may need to reclassify some of the existing issues.

Jody Garnett

On Wednesday, 9 May 2012 at 5:52 PM, Andrea Aime wrote:

Hi,
recently I’ve started to see a trend of more jira issues being marked as “blockers”.

Blocker is, or should be, “end of the world, attend to immediately” type of issue, e.g., a build breakage
on the official build server, something that blocks every developer, but I see it used
as “it’s a blocker for me” instead, which I believe is misuse.

I know Jira has a definition here:
http://jira.codehaus.org/secure/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels

and this thread is also interesting:
http://lists.opencastproject.org/pipermail/matterhorn/2009-August/002038.html

Imho before setting an issue to “blocker” level you should ask youself “is it really
blocking all developers?”
We’re all extremely busy, marking a issue at such a high level looks like a tentative
to get undeserved attention for an issue that is not actually affecting everybody.

Of course we can discuss this and come up with a meaning other than the usual one
if people feel strongly about it.

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

4

On Wed, May 9, 2012 at 10:57 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Blocker is, or should be, “end of the world, attend to immediately” type
of issue, e.g., a build breakage
on the official build server, something that blocks every developer, but
I see it used
as “it’s a blocker for me” instead, which I believe is misuse.

One word you have added here is “official”. While I appreciate the work that OpenGeo have done in providing Hudson coverage, it is not the only build coverage for this project.

Despite several requests from me, the OpenGeo Hudson no longer builds in a path with spaces, so does not catch the File/URL conversion build failures I often report. These break the build on some Windows development boxes, and can break production deployments on Windows and other boxes in paths with spaces or internationalised paths (“Program Files”, “Documents and Settings”).

There are other reasons to run an “unofficial” build bot, including coverage of obscure modules like webservice; these are not OpenGeo’s problem. Others have run build bots to cover other JDKs. If we set one up for Jody for OpenJDK would it be unofficial? Are only OpenGeo Hudson failures blockers?

Imho only the official build server counts as a blocker, because nobody should commit while the build is broken there.
Other build bots are treating cases that the community has not agreed to maintain at all, or at least at the same
level of urgency.

If you want your build bots to be “official” in my opinion you should address the community and get them
to agree that the case handled by such build bot deserves everybody immediate attention (since that’s what
a blocker issue is, a “stop the world and fix immediately” one).
The build bot should obviously made be available to developers and allow people to start a build
manually when they are trying to check if a certain fix worked.
The bot should also be described in detail so that people know how to reproduce the specific case it’s handling locally.

The OpenJDK case you’re mentioning is telling, nobody has agreed to give OpenJDK any urgency
since it’s so far not relevant business wise and nobody stepped up to be a “spare time OpenJDK maintainer”,
if someone sets up a OpenJDK build bot it’s appreciated, but it won’t be given particular priority over
any other random issue in jira (at least not by me).

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

5

My thoughts.

First when I think blocker I think blocker for users, not developers. So the first question i would ask when filing an issue is “is it likely a user will actually run into this issue?”.

The more build bots the better in my opinion but it should be communicated somewhere what that build bot does beyond the official one. And in part using that to determine if the issue should be a blocker. For instance, issues that arise from file/uri conversions for file paths with spaces is potentially a major show stopper for windows users which is a large contingent of users, so i would classify it as a blocker.

However a build that is breaking because it is testing a non-standard module, or even a non-standard (ie non-oracle) jdk i would not classify as blocker since it represents a smaller subset of geoserver users. Often I run into test failures on OSX because who knows why… but I realize i am using a platform most devs don’t so i just ignore it.

Long story short I think the person has to use there better judgement when filing a build breaking issue that doesn’t show up on the main build server.

$0.02

-Justin

On Wed, May 9, 2012 at 3:56 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, May 9, 2012 at 10:57 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Blocker is, or should be, “end of the world, attend to immediately” type
of issue, e.g., a build breakage
on the official build server, something that blocks every developer, but
I see it used
as “it’s a blocker for me” instead, which I believe is misuse.

One word you have added here is “official”. While I appreciate the work that OpenGeo have done in providing Hudson coverage, it is not the only build coverage for this project.

Despite several requests from me, the OpenGeo Hudson no longer builds in a path with spaces, so does not catch the File/URL conversion build failures I often report. These break the build on some Windows development boxes, and can break production deployments on Windows and other boxes in paths with spaces or internationalised paths (“Program Files”, “Documents and Settings”).

There are other reasons to run an “unofficial” build bot, including coverage of obscure modules like webservice; these are not OpenGeo’s problem. Others have run build bots to cover other JDKs. If we set one up for Jody for OpenJDK would it be unofficial? Are only OpenGeo Hudson failures blockers?

Imho only the official build server counts as a blocker, because nobody should commit while the build is broken there.
Other build bots are treating cases that the community has not agreed to maintain at all, or at least at the same
level of urgency.

If you want your build bots to be “official” in my opinion you should address the community and get them
to agree that the case handled by such build bot deserves everybody immediate attention (since that’s what
a blocker issue is, a “stop the world and fix immediately” one).
The build bot should obviously made be available to developers and allow people to start a build
manually when they are trying to check if a certain fix worked.
The bot should also be described in detail so that people know how to reproduce the specific case it’s handling locally.

The OpenJDK case you’re mentioning is telling, nobody has agreed to give OpenJDK any urgency
since it’s so far not relevant business wise and nobody stepped up to be a “spare time OpenJDK maintainer”,
if someone sets up a OpenJDK build bot it’s appreciated, but it won’t be given particular priority over
any other random issue in jira (at least not by me).

Cheers

Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

6

On 09/05/12 21:52, Justin Deoliveira wrote:

First when I think blocker I think blocker for users, not developers. So
the first question i would ask when filing an issue is "is it likely a
user will actually run into this issue?".

Sorry, I disagree with this; I am with Andrea (and the Jira definitions) on this one. The concept of a blocker is enmeshed with the test-driven development principle of not committing on a broken build except to fix that build. Because no developers should be committing or releasing, development is blocked.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

7

On 09/05/12 21:52, Justin Deoliveira wrote:

issues that arise from file/uri conversions for file paths with spaces
is potentially a major show stopper for windows users which is a large
contingent of users, so i would classify it as a blocker.

I would very much like to see OpenGeo Hudson build in a path with spaces (as it once did); under these circumstances, unit tests covering file/uri conversions will fail if these conversions are incorrect, making these failures a blocker. This is such a common occurrence we should be covering it on the official build bot.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

8

On 09/05/12 17:56, Andrea Aime wrote:

Imho only the official build server counts as a blocker, because nobody
should commit while the build is broken there.

Fair enough. I will refrain from filing blockers for failures in other builds.

It would be good to document this policy somewhere.

We should also list the official build servers. By implication, these are the supported platforms. (We may wish to add OpenJDK, for example.)

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

9

We should also list the official build servers. By implication, these
are the supported platforms. (We may wish to add OpenJDK, for example.)

We have a list of web resources in the wiki:

We can add that to the sphinx website if you desire.

Jody

10

On Thu, May 10, 2012 at 4:47 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

On 09/05/12 21:52, Justin Deoliveira wrote:

issues that arise from file/uri conversions for file paths with spaces
is potentially a major show stopper for windows users which is a large
contingent of users, so i would classify it as a blocker.

I would very much like to see OpenGeo Hudson build in a path with spaces (as it once did); under these circumstances, unit tests covering file/uri conversions will fail if these conversions are incorrect, making these failures a blocker. This is such a common occurrence we should be covering it on the official build bot.

Or you can offer a Windows build server that mimick OpenGeo’s one and
propose it as a second reference.
I wanted to do that myself, but my home network limitations (ADSL) prevent me from
standing it up (hardware wise I would have a spare machine under the desk
that would be suitable for the task and that also has a XP license)

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

11

On Wed, May 9, 2012 at 8:02 PM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

On 09/05/12 21:52, Justin Deoliveira wrote:

First when I think blocker I think blocker for users, not developers. So
the first question i would ask when filing an issue is “is it likely a
user will actually run into this issue?”.

Sorry, I disagree with this; I am with Andrea (and the Jira definitions) on this one. The concept of a blocker is enmeshed with the test-driven development principle of not committing on a broken build except to fix that build. Because no developers should be committing or releasing, development is blocked.

Fair enough. Was just sharing what my unofficial though process is when filing an issue and admitedly never verified it against a formal definition. I think the jira definitions make sense too.

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

12

On Thu, May 10, 2012 at 1:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, May 10, 2012 at 4:47 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

On 09/05/12 21:52, Justin Deoliveira wrote:

issues that arise from file/uri conversions for file paths with spaces
is potentially a major show stopper for windows users which is a large
contingent of users, so i would classify it as a blocker.

I would very much like to see OpenGeo Hudson build in a path with spaces (as it once did); under these circumstances, unit tests covering file/uri conversions will fail if these conversions are incorrect, making these failures a blocker. This is such a common occurrence we should be covering it on the official build bot.

Or you can offer a Windows build server that mimick OpenGeo’s one and
propose it as a second reference.
I wanted to do that myself, but my home network limitations (ADSL) prevent me from
standing it up (hardware wise I would have a spare machine under the desk
that would be suitable for the task and that also has a XP license)

I echo this. I don;t see any reason to not have more than one official build server. As long as the build server has a maintainer I don’t see a problem.

Cheers

Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

13

On Thu, May 10, 2012 at 3:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

On Thu, May 10, 2012 at 1:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, May 10, 2012 at 4:47 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

On 09/05/12 21:52, Justin Deoliveira wrote:

issues that arise from file/uri conversions for file paths with spaces
is potentially a major show stopper for windows users which is a large
contingent of users, so i would classify it as a blocker.

I would very much like to see OpenGeo Hudson build in a path with spaces (as it once did); under these circumstances, unit tests covering file/uri conversions will fail if these conversions are incorrect, making these failures a blocker. This is such a common occurrence we should be covering it on the official build bot.

Or you can offer a Windows build server that mimick OpenGeo’s one and
propose it as a second reference.
I wanted to do that myself, but my home network limitations (ADSL) prevent me from
standing it up (hardware wise I would have a spare machine under the desk
that would be suitable for the task and that also has a XP license)

I echo this. I don;t see any reason to not have more than one official build server. As long as the build server has a maintainer I don’t see a problem.

Yep. And I believe many more developers would be ok to have a reference Windows build server
that one has to pay attention to instead of a OpenJDK one (if nothing else, for business and
user base reasons)

Cheers
Andrea

–
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

14

On 10/05/12 21:24, Justin Deoliveira wrote:

Fair enough. Was just sharing what my unofficial though process is when filing an issue and admitedly never verified it against a formal definition. I think the jira definitions make sense too.

You were already following them: while considering the upcoming GeoServer beta, you searched for >= critical issues, implicitly following the Jira definition (critical blocks release). So I don't think your practice is out of line.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre