Re: Mesos Jira workflow
+1 to removing Closed. In other projects, I've seen Resolved mean that a supposed fix has been committed, and Closed means that somebody (QA? Reporter?) has verified the fix, but we don't wait for verification, so it's probably pointless for us. +1 to removing Reopened, and just going back to Open/Accepted instead. +1 to BenH's request to be able to Resolve from any status, so that an Open issue can be quickly resolved as Duplicate or Won't Fix. We'll need to continue educating users about what Accepted means, especially if it becomes a required transition. Is there a way that we can require the Shepherd field to be filled out before something can be Accepted? On Tue, Jun 9, 2015 at 11:29 PM, Benjamin Hindman b...@eecs.berkeley.edu wrote: +1 This sounds great to me Marco. I love eliminating Reopened, as well as simplifying (constraining) other transitions. I couple of quick questions: Why does stoping progress go from In Progress back to Open instead of Accepted? Seems like it's still an Accepted issue just not being worked on. Can we resolve or close something directly from Open? For example, issues we're never going to work on or are duplicates or already fixed, etc. Do we need both Resolved and Closed? This has come up in the past, we tend to close issues after we cut a release with them, but it's kind of an extra step that I'm not convinced we really need to do. On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: [image: Inline image 1] (spaghetti workflow? :) I would propose to simplify it to the following: [image: Inline image 2] I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? *Marco Massenzio* *Distributed Systems Engineer*
Re: Mesos Jira workflow
For the ASF Jira we do not allow special permissions for customizing or changing settings, we have been down that road before and it turned into a mess. There are some settings within the ASF Jira which are global to all projects and can not be changed, but you can have a custom workflow and transitions. Happy to help with this once a final workflow is settled on (this will also impact your agile boards in use) -Jake On Tue, Jun 9, 2015 at 6:41 PM, Marco Massenzio ma...@mesosphere.io wrote: Hi Vinod, thanks for super-quick reply. We've already been through this in our internal (Mesosphere) Jira (on a completely different topic) so I know that this can be done, if we use our own custom Mesos workflow (here: https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows) which I think we already do. I would probably need to be given adequate permissions to modify it (avoiding to mess up in the process the entirety of ASF :) Once we agree that the proposed one works for folks here, I'll work with Jake and Infra folks, and figure out how to implement. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote: +jake Marco, this sounds good to me. Have you looked into see if JIRA allows us to constrain ourselves to this workflow? If yes, the next step would be to work with ASF infra to see if they are ok with us adopting a new workflow. IIRC, there are some JIRA settings that are global to all ASF projects and hence can't be customized. On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: [image: Inline image 1] (spaghetti workflow? :) I would propose to simplify it to the following: [image: Inline image 2] I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? *Marco Massenzio* *Distributed Systems Engineer*
Re: Mesos Jira workflow
Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing +1 making sure that “accepted is the gatekeeper and includes assigning the maintainer as a default shepherd — should we even go as far as to prevent “assigning” issues that have not gotten “accepted” and “shepherd assigned” ? +1 removing “reopened as it has no extra value for us Resolving without accepting to me sounds like a shortcut that we might want to prevent as it could be a bad example? On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! Marco Massenzio Distributed Systems Engineer On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io mailto:ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: (spaghetti workflow? :) I would propose to simplify it to the following: I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? Marco Massenzio Distributed Systems Engineer
Re: Native code error
Thank you for replying and for opening a ticket. I also added a ticket related to the issue: https://issues.apache.org/jira/browse/MESOS-2820 Should I close it? Thank you 2015-06-10 0:29 GMT+02:00 Niklas Nielsen nik...@mesosphere.io: Thanks Alberto - I finally got to look at the trace and added a ticket to track it: https://issues.apache.org/jira/browse/MESOS-2839 Thanks again! On 5 June 2015 at 00:39, Alberto Rodriguez ardl...@gmail.com wrote: Hi Niklas, Thank you for replying, see attached the full crash. Kind regards, 2015-06-03 19:36 GMT+02:00 Niklas Nielsen nik...@mesosphere.io: Hi Alberto, Can you share the full crash report with us? Niklas On 2 June 2015 at 02:37, Alberto Rodriguez ardl...@gmail.com wrote: Hi all, I've got a bunch of tests that are checking whether my spark process is able to connect to a mesos cluster. The happy path (mesos up running) is working fine the problem comes when I'm testing a connection with a wrong mesos ip then I'm getting the following error: WARNING: Logging before InitGoogleLogging() is written to STDERR W0602 11:26:03.549504 13269 sched.cpp:1323] ** Scheduler driver bound to loopback interface! Cannot communicate with remote master(s). You might want to set 'LIBPROCESS_IP' environment variable to use a routable IP address. ** # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7fcdf32c5660, pid=13125, tid=140517706200832 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libc.so.6+0x83660] cfree+0x220 # # Core dump written. Default location: /home/arodriguez/dev/datavis-master/back/core or core.13125 (max size 5 kB). To ensure a full core dump, try ulimit -c unlimited before starting Java again # # An error report file with more information is saved as: # /home/arodriguez/dev/datavis-master/back/hs_err_pid13125.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # /bin/sh: línea 1: 13125 Abortado(`core' generado) /usr/java/jdk1.7.0_75/jre/bin/java -javaagent:/home/arodriguez/.m2/repository/org/jacoco/org.jacoco.agent/0.7.2.201409121644/org.jacoco.agent-0.$.2.201409121644-runtime.jar=destfile=/home/arodriguez/dev/datavis-master/back/target/jacocoIT.exec -Xmx1024m -XX:MaxPermSize=256m -Dlogback.configurationFile=conf/logger/develop.logger.xml -Djava.security.polic$=conf/java.policy -XX:+HeapDumpOnOutOfMemoryError org.apache.maven.surefire.booter.ForkedBooter /home/arodriguez/dev/datavis-master/back/target/surefire/surefire6809257750333050101tmp /home/arodriguez/dev/datav$s-master/back/target/surefire/surefire_02320528722071658975tmp Any ideas?
Re: Mesos Jira workflow
+1 This sounds great to me Marco. I love eliminating Reopened, as well as simplifying (constraining) other transitions. I couple of quick questions: Why does stoping progress go from In Progress back to Open instead of Accepted? Seems like it's still an Accepted issue just not being worked on. Can we resolve or close something directly from Open? For example, issues we're never going to work on or are duplicates or already fixed, etc. Do we need both Resolved and Closed? This has come up in the past, we tend to close issues after we cut a release with them, but it's kind of an extra step that I'm not convinced we really need to do. On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: [image: Inline image 1] (spaghetti workflow? :) I would propose to simplify it to the following: [image: Inline image 2] I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? *Marco Massenzio* *Distributed Systems Engineer*
Re: Native code error
Mark it as a duplicate. On 10 Jun 2015 8:21 am, Alberto Rodriguez ardl...@gmail.com wrote: Thank you for replying and for opening a ticket. I also added a ticket related to the issue: https://issues.apache.org/jira/browse/MESOS-2820 Should I close it? Thank you 2015-06-10 0:29 GMT+02:00 Niklas Nielsen nik...@mesosphere.io: Thanks Alberto - I finally got to look at the trace and added a ticket to track it: https://issues.apache.org/jira/browse/MESOS-2839 Thanks again! On 5 June 2015 at 00:39, Alberto Rodriguez ardl...@gmail.com wrote: Hi Niklas, Thank you for replying, see attached the full crash. Kind regards, 2015-06-03 19:36 GMT+02:00 Niklas Nielsen nik...@mesosphere.io: Hi Alberto, Can you share the full crash report with us? Niklas On 2 June 2015 at 02:37, Alberto Rodriguez ardl...@gmail.com wrote: Hi all, I've got a bunch of tests that are checking whether my spark process is able to connect to a mesos cluster. The happy path (mesos up running) is working fine the problem comes when I'm testing a connection with a wrong mesos ip then I'm getting the following error: WARNING: Logging before InitGoogleLogging() is written to STDERR W0602 11:26:03.549504 13269 sched.cpp:1323] ** Scheduler driver bound to loopback interface! Cannot communicate with remote master(s). You might want to set 'LIBPROCESS_IP' environment variable to use a routable IP address. ** # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7fcdf32c5660, pid=13125, tid=140517706200832 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libc.so.6+0x83660] cfree+0x220 # # Core dump written. Default location: /home/arodriguez/dev/datavis-master/back/core or core.13125 (max size 5 kB). To ensure a full core dump, try ulimit -c unlimited before starting Java again # # An error report file with more information is saved as: # /home/arodriguez/dev/datavis-master/back/hs_err_pid13125.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # /bin/sh: línea 1: 13125 Abortado(`core' generado) /usr/java/jdk1.7.0_75/jre/bin/java -javaagent:/home/arodriguez/.m2/repository/org/jacoco/org.jacoco.agent/0.7.2.201409121644/org.jacoco.agent-0.$.2.201409121644-runtime.jar=destfile=/home/arodriguez/dev/datavis-master/back/target/jacocoIT.exec -Xmx1024m -XX:MaxPermSize=256m -Dlogback.configurationFile=conf/logger/develop.logger.xml -Djava.security.polic$=conf/java.policy -XX:+HeapDumpOnOutOfMemoryError org.apache.maven.surefire.booter.ForkedBooter /home/arodriguez/dev/datavis-master/back/target/surefire/surefire6809257750333050101tmp /home/arodriguez/dev/datav$s-master/back/target/surefire/surefire_02320528722071658975tmp Any ideas?
Re: Native code error
Done! Thank you! 2015-06-10 8:52 GMT+02:00 Alex Rukletsov a...@mesosphere.com: Mark it as a duplicate. On 10 Jun 2015 8:21 am, Alberto Rodriguez ardl...@gmail.com wrote: Thank you for replying and for opening a ticket. I also added a ticket related to the issue: https://issues.apache.org/jira/browse/MESOS-2820 Should I close it? Thank you 2015-06-10 0:29 GMT+02:00 Niklas Nielsen nik...@mesosphere.io: Thanks Alberto - I finally got to look at the trace and added a ticket to track it: https://issues.apache.org/jira/browse/MESOS-2839 Thanks again! On 5 June 2015 at 00:39, Alberto Rodriguez ardl...@gmail.com wrote: Hi Niklas, Thank you for replying, see attached the full crash. Kind regards, 2015-06-03 19:36 GMT+02:00 Niklas Nielsen nik...@mesosphere.io: Hi Alberto, Can you share the full crash report with us? Niklas On 2 June 2015 at 02:37, Alberto Rodriguez ardl...@gmail.com wrote: Hi all, I've got a bunch of tests that are checking whether my spark process is able to connect to a mesos cluster. The happy path (mesos up running) is working fine the problem comes when I'm testing a connection with a wrong mesos ip then I'm getting the following error: WARNING: Logging before InitGoogleLogging() is written to STDERR W0602 11:26:03.549504 13269 sched.cpp:1323] ** Scheduler driver bound to loopback interface! Cannot communicate with remote master(s). You might want to set 'LIBPROCESS_IP' environment variable to use a routable IP address. ** # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x7fcdf32c5660, pid=13125, tid=140517706200832 # # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build 1.7.0_75-b13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode linux-amd64 compressed oops) # Problematic frame: # C [libc.so.6+0x83660] cfree+0x220 # # Core dump written. Default location: /home/arodriguez/dev/datavis-master/back/core or core.13125 (max size 5 kB). To ensure a full core dump, try ulimit -c unlimited before starting Java again # # An error report file with more information is saved as: # /home/arodriguez/dev/datavis-master/back/hs_err_pid13125.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # /bin/sh: línea 1: 13125 Abortado(`core' generado) /usr/java/jdk1.7.0_75/jre/bin/java -javaagent:/home/arodriguez/.m2/repository/org/jacoco/org.jacoco.agent/0.7.2.201409121644/org.jacoco.agent-0.$.2.201409121644-runtime.jar=destfile=/home/arodriguez/dev/datavis-master/back/target/jacocoIT.exec -Xmx1024m -XX:MaxPermSize=256m -Dlogback.configurationFile=conf/logger/develop.logger.xml -Djava.security.polic$=conf/java.policy -XX:+HeapDumpOnOutOfMemoryError org.apache.maven.surefire.booter.ForkedBooter /home/arodriguez/dev/datavis-master/back/target/surefire/surefire6809257750333050101tmp /home/arodriguez/dev/datav$s-master/back/target/surefire/surefire_02320528722071658975tmp Any ideas?
Re: Mesos Jira workflow
Inline... On Tue, Jun 9, 2015 at 4:56 PM, Benjamin Mahler benjamin.mah...@gmail.com wrote: I don't have comment permissions on the doc, but it looks like you omitted a way to go from Reviewable - In Progress, which we often do when the reviewee has more work to do before being ready for additional reviews, for example. Great catch - added! (called it `fix` - anyone has any suggestions for something more suggestive?) I'm not sure what 'Closed' is supposed to represent, what does it mean to go from Resolved to Closed? Great question! I don't know (it was there, and I thought it worth leaving) In my previous experience, we used it to mark it as QA Certified In other words - developer(s) would run and test locally (or in Jenkins, or whatever) and mark the bug/story as Resolved - but it would only be declared Closed (and make it to the Release Notes) once QA had it tested against regressions, etc. I'm happy to remove it from the workflow (assuming Jira allows it) or we can leave it there. On Tue, Jun 9, 2015 at 3:41 PM, Marco Massenzio ma...@mesosphere.io wrote: Hi Vinod, thanks for super-quick reply. We've already been through this in our internal (Mesosphere) Jira (on a completely different topic) so I know that this can be done, if we use our own custom Mesos workflow (here: https://issues.apache.org/jira/plugins/servlet/project-config/MESOS/workflows ) which I think we already do. I would probably need to be given adequate permissions to modify it (avoiding to mess up in the process the entirety of ASF :) Once we agree that the proposed one works for folks here, I'll work with Jake and Infra folks, and figure out how to implement. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 3:15 PM, Vinod Kone vinodk...@apache.org wrote: +jake Marco, this sounds good to me. Have you looked into see if JIRA allows us to constrain ourselves to this workflow? If yes, the next step would be to work with ASF infra to see if they are ok with us adopting a new workflow. IIRC, there are some JIRA settings that are global to all ASF projects and hence can't be customized. On Tue, Jun 9, 2015 at 3:00 PM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: [image: Inline image 1] (spaghetti workflow? :) I would propose to simplify it to the following: [image: Inline image 2] I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? *Marco Massenzio* *Distributed Systems Engineer*
Re: Mesos Jira workflow
Thanks, everyone, for your suggestions: quick feedback was much appreciated! I've updated the Google Doc, I think we're in good shape, I'll wait until Friday to hear if anyone has still objections, then I'll work with Jake (thanks for offer to help!) to implement it. *Marco Massenzio* *Distributed Systems Engineer* On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote: Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed done +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing done +1 making sure that “accepted is the gatekeeper and includes assigning the maintainer as a default shepherd — should we even go as far as to prevent “assigning” issues that have not gotten “accepted” and “shepherd assigned” ? let's not gate fixing the workflow to my achieving the next level of Jira-Wizardry :) the goal can be achieved by education (and enforcement of the policy) I am totally in favor of asking folks NOT to work on non-accepted stories (or, conversely, if they come across issues that are NOT accepted, but want to do work and/or investigation, to assign to themselves and move to accepted state). +1 removing “reopened as it has no extra value for us it's history! Resolving without accepting to me sounds like a shortcut that we might want to prevent as it could be a bad example? On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! Marco Massenzio Distributed Systems Engineer On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io mailto:ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: (spaghetti workflow? :) I would propose to simplify it to the following: I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? Marco Massenzio Distributed Systems Engineer
Re: Mesos Jira workflow
On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote: Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed done +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing done +1 making sure that “accepted is the gatekeeper and includes assigning the maintainer as a default shepherd — should we even go as far as to prevent “assigning” issues that have not gotten “accepted” and “shepherd assigned” ? let's not gate fixing the workflow to my achieving the next level of Jira-Wizardry :) the goal can be achieved by education (and enforcement of the policy) I am totally in favor of asking folks NOT to work on non-accepted stories (or, conversely, if they come across issues that are NOT accepted, but want to do work and/or investigation, to assign to themselves and move to accepted state). +1 removing “reopened as it has no extra value for us it's history! Resolving without accepting to me sounds like a shortcut that we might want to prevent as it could be a bad example? On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! Marco Massenzio Distributed Systems Engineer On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io mailto:ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: (spaghetti workflow? :) I would propose to simplify it to the following: I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? Marco Massenzio Distributed Systems Engineer
Apply Now #MesosCon Conference Diversity Scholarship
Hi Mesos friends, We need your help promoting the #MesosCon diversity scholarship. #MesosCon, the annual open source #ApacheMesos developers conference, is now accepting applications for their diversity scholarship. It provides financial assistance for women (cis and trans), genderqueer people, people of color, and people with disabilities. Scholarship recipients will receive a free registration ticket, can request support for travel and hotel, and will automatically be enrolled in our buddy system program. To apply and learn more, click here http://events.linuxfoundation.org/events/mesoscon/attend/scholarship. To help promote via twitter click here https://twitter.com/apachemesos/status/608327682569433088. Thank you for your support, Kiersten Gaffney Planning Committee Member, #MesosCon Manager of Events, Mesosphere -- Kiersten Gaffney Manager of Events kiers...@mesosphere.io 415-559-3771
MesosCon 2015 Lightning Talk CFP now open
Good news, everyone: We’ve expanded the MesosCon program (http://mesoscon.org) to add lightning talks: 5-minute presentations for speakers to introduce a project they’re working on, or share an idea related to Mesos. Lightning talks will take place during lunchtime of the conference, which takes place August 20-21st, 2015 in Seattle WA. The form to propose a lightning talk is available here: https://docs.google.com/forms/d/1raB-IqA4gi0elYPBHmh5lB17jQdCQWrEeMslQGeihbs/viewform When preparing your proposal, keep in mind: * 5 minutes presentations will be enforced by a time-keeper. The 5-minute presentation includes any time you may wish for QA, so use your time wisely. * Slides are allowed, but not required. We will have a laptop on stage with slides queued up for those that submit them in advance; using your own laptop and transitioning to use it will be included in your 5 minutes so use your time wisely! * We encourage submissions that may have previously been shared as full proposals * Only one lightning talk may be submitted per person * Lightning talk speakers will be expected to purchase full tickets to the conference The CFP opens Wednesday, June 10th 2015 and will close July 15th; speakers will decided by members of the program committee and contacted by July 22nd regarding the status of their proposal. Good luck with your proposals! Hope to see you all at MesosCon. Dave
Re: Mesos Jira workflow
inline... On Tue, Jun 9, 2015 at 11:29 PM, Benjamin Hindman b...@eecs.berkeley.edu wrote: +1 This sounds great to me Marco. I love eliminating Reopened, as well as simplifying (constraining) other transitions. I couple of quick questions: Why does stoping progress go from In Progress back to Open instead of Accepted? Seems like it's still an Accepted issue just not being worked on. I thought about it and it occurs to me that there are three reasons why one would Stop Progress: 1. I haven't got time, and more important stuff came along (this is the case your question seems to imply) 2. I looked into it, and it really doesn't seem worth/desirable to do, ever (covered in Resolved - won't fix) 3. I looked into it, and I have my doubts this may ever be desirable, but I'll leave it to others to decide (the current Stop Progress) I've added a Pause Progress transition (back to Accepted) that covers case #1 - would this work? Can we resolve or close something directly from Open? For example, issues we're never going to work on or are duplicates or already fixed, etc. Sure - added. Do we need both Resolved and Closed? This has come up in the past, we tend to close issues after we cut a release with them, but it's kind of an extra step that I'm not convinced we really need to do. Got rid of Closed. As both Bens don't like it - I think it was doomed :) On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: [image: Inline image 1] (spaghetti workflow? :) I would propose to simplify it to the following: [image: Inline image 2] I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? *Marco Massenzio* *Distributed Systems Engineer*
Re: Mesos Jira workflow
inline... On Wed, Jun 10, 2015 at 12:44 AM, Adam Bordelon a...@mesosphere.io wrote: +1 to removing Closed. In other projects, I've seen Resolved mean that a supposed fix has been committed, and Closed means that somebody (QA? Reporter?) has verified the fix, but we don't wait for verification, so it's probably pointless for us. yep, gone. +1 to removing Reopened, and just going back to Open/Accepted instead. +1 to BenH's request to be able to Resolve from any status, so that an Open issue can be quickly resolved as Duplicate or Won't Fix. added. We'll need to continue educating users about what Accepted means, especially if it becomes a required transition. Is there a way that we can require the Shepherd field to be filled out before something can be Accepted? I don't think there is (and, to be honest, I am hesitant to require a Shepherd for the transition: it seems too high a bar - I'd suggest to require a Shepherd for the transition to In Progress). But totally +1 on educating the community about the semantics of Accepted (especially, the requirement of clear, well-written feature descriptions/bug reports) On Tue, Jun 9, 2015 at 11:29 PM, Benjamin Hindman b...@eecs.berkeley.edu wrote: +1 This sounds great to me Marco. I love eliminating Reopened, as well as simplifying (constraining) other transitions. I couple of quick questions: Why does stoping progress go from In Progress back to Open instead of Accepted? Seems like it's still an Accepted issue just not being worked on. Can we resolve or close something directly from Open? For example, issues we're never going to work on or are duplicates or already fixed, etc. Do we need both Resolved and Closed? This has come up in the past, we tend to close issues after we cut a release with them, but it's kind of an extra step that I'm not convinced we really need to do. On Tue, Jun 9, 2015 at 2:26 PM Marco Massenzio ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: [image: Inline image 1] (spaghetti workflow? :) I would propose to simplify it to the following: [image: Inline image 2] I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? *Marco Massenzio* *Distributed Systems Engineer*
Re: Introduction / Request to be added to Jira committers
Hey Oliver, thanks for the patch and really glad to hear that Mesos just works for you! As you can imagine, we'd love to add Uber to the Powered by page: http://mesos.apache.org/documentation/latest/powered-by-mesos/ Do you think that would be possible? Welcome to the club! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 6:47 PM, Oliver Nicholas b...@uber.com wrote: Hey Tim. We're not *currently* planning Storm work (I think it just works for us at the moment), but I suspect as we move more and more stuff over Mesos and start to expand our clusters and add complexity to our configurations, we'll have work to do on that side as well. -o On Tue, Jun 9, 2015 at 6:43 PM, Timothy Chen tnac...@gmail.com wrote: Hi Oliver, It's great to hear you're using the Storm over Mesos framework too! I think there are lots of improvements that can be made there, are you guys planning to help work on that framework as well? Tim On Tue, Jun 9, 2015 at 6:37 PM, Oliver Nicholas b...@uber.com wrote: Hello Folks, Name's Oliver Nicholas, I'm a sometimes-manager, sometimes-engineer here at Uber. We've been running some Storm jobs over Mesos for a year or two but are looking into moving larger workloads under Marathon now, and ironing out some kinks along the way. My first patch is pretty straightforward, and I'd love to get it committed so I can get on to the rest of them. My Jira username is bigo. https://issues.apache.org/jira/browse/MESOS-1825 https://reviews.apache.org/r/35270/ Thanks! -o -- *bigo* / oliver nicholas | staff engineer, infrastructure | uber technologies, inc. -- *bigo* / oliver nicholas | staff engineer, infrastructure | uber technologies, inc.
Re: Mesos Jira workflow
To go from accepted to open you need to go through in progress? On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio ma...@mesosphere.io wrote: Thanks, everyone, for your suggestions: quick feedback was much appreciated! I've updated the Google Doc, I think we're in good shape, I'll wait until Friday to hear if anyone has still objections, then I'll work with Jake (thanks for offer to help!) to implement it. *Marco Massenzio* *Distributed Systems Engineer* On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote: Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed done +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing done +1 making sure that “accepted is the gatekeeper and includes assigning the maintainer as a default shepherd — should we even go as far as to prevent “assigning” issues that have not gotten “accepted” and “shepherd assigned” ? let's not gate fixing the workflow to my achieving the next level of Jira-Wizardry :) the goal can be achieved by education (and enforcement of the policy) I am totally in favor of asking folks NOT to work on non-accepted stories (or, conversely, if they come across issues that are NOT accepted, but want to do work and/or investigation, to assign to themselves and move to accepted state). +1 removing “reopened as it has no extra value for us it's history! Resolving without accepting to me sounds like a shortcut that we might want to prevent as it could be a bad example? On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! Marco Massenzio Distributed Systems Engineer On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io mailto:ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: (spaghetti workflow? :) I would propose to simplify it to the following: I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? Marco Massenzio Distributed Systems Engineer
Re: Mesos Jira workflow
Don't forget that folks accidentally do things all the time in JIRA, so if you fence off the ability to go back you make an accident permanent, or does JIRA have some undo support I'm unaware of? On Wed, Jun 10, 2015 at 6:33 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler benjamin.mah...@gmail.com wrote: To go from accepted to open you need to go through in progress? That part wasn't changed from before? Anyways, why would you ever want to do that? This means that, at some point we looked at something, thought we would want to do that (at some point in future) then, eventually, changed our mind (we no longer want to do it) but will think some more at some other future point and (maybe) re-accept it? This seems an unlikely scenario? more likely, you figured out it wasn't a good idea after all (or maybe it turned out to be a duplicate - or some other features took the problem away) and we can move directly to resolved. Granted, we can obviously add an unaccept transition, but I would much prefer to keep this simple to avoid confusing people. (and, as you correctly pointed out, there is a path back to 'Open' if we really want to). On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio ma...@mesosphere.io wrote: Thanks, everyone, for your suggestions: quick feedback was much appreciated! I've updated the Google Doc, I think we're in good shape, I'll wait until Friday to hear if anyone has still objections, then I'll work with Jake (thanks for offer to help!) to implement it. *Marco Massenzio* *Distributed Systems Engineer* On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote: Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed done +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing done +1 making sure that “accepted is the gatekeeper and includes assigning the maintainer as a default shepherd — should we even go as far as to prevent “assigning” issues that have not gotten “accepted” and “shepherd assigned” ? let's not gate fixing the workflow to my achieving the next level of Jira-Wizardry :) the goal can be achieved by education (and enforcement of the policy) I am totally in favor of asking folks NOT to work on non-accepted stories (or, conversely, if they come across issues that are NOT accepted, but want to do work and/or investigation, to assign to themselves and move to accepted state). +1 removing “reopened as it has no extra value for us it's history! Resolving without accepting to me sounds like a shortcut that we might want to prevent as it could be a bad example? On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! Marco Massenzio Distributed Systems Engineer On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io mailto:ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: (spaghetti workflow? :) I would propose to simplify it to the following: I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? Marco Massenzio Distributed Systems Engineer
Re: Mesos Jira workflow
On Wed, Jun 10, 2015 at 6:44 PM, Benjamin Mahler benjamin.mah...@gmail.com wrote: Don't forget that folks accidentally do things all the time in JIRA, or in life :) eh eh I never forget that so if you fence off the ability to go back you make an accident permanent, or does JIRA have some undo support I'm unaware of? I am pretty sure that we can alter the state of a given issue to move it back to 'Open' (even if, as you pointed out, we need to take a detour via 'in progress') - but let me do some investigation and figure this one out. Thanks! On Wed, Jun 10, 2015 at 6:33 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler benjamin.mah...@gmail.com wrote: To go from accepted to open you need to go through in progress? That part wasn't changed from before? Anyways, why would you ever want to do that? This means that, at some point we looked at something, thought we would want to do that (at some point in future) then, eventually, changed our mind (we no longer want to do it) but will think some more at some other future point and (maybe) re-accept it? This seems an unlikely scenario? more likely, you figured out it wasn't a good idea after all (or maybe it turned out to be a duplicate - or some other features took the problem away) and we can move directly to resolved. Granted, we can obviously add an unaccept transition, but I would much prefer to keep this simple to avoid confusing people. (and, as you correctly pointed out, there is a path back to 'Open' if we really want to). On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio ma...@mesosphere.io wrote: Thanks, everyone, for your suggestions: quick feedback was much appreciated! I've updated the Google Doc, I think we're in good shape, I'll wait until Friday to hear if anyone has still objections, then I'll work with Jake (thanks for offer to help!) to implement it. *Marco Massenzio* *Distributed Systems Engineer* On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote: Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed done +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing done +1 making sure that “accepted is the gatekeeper and includes assigning the maintainer as a default shepherd — should we even go as far as to prevent “assigning” issues that have not gotten “accepted” and “shepherd assigned” ? let's not gate fixing the workflow to my achieving the next level of Jira-Wizardry :) the goal can be achieved by education (and enforcement of the policy) I am totally in favor of asking folks NOT to work on non-accepted stories (or, conversely, if they come across issues that are NOT accepted, but want to do work and/or investigation, to assign to themselves and move to accepted state). +1 removing “reopened as it has no extra value for us it's history! Resolving without accepting to me sounds like a shortcut that we might want to prevent as it could be a bad example? On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! Marco Massenzio Distributed Systems Engineer On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io mailto:ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: (spaghetti workflow? :) I would propose to simplify it to the following: I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? Marco Massenzio Distributed Systems Engineer
Re: Introduction / Request to be added to Jira committers
Yup, please do. On Wed, Jun 10, 2015 at 5:08 PM, Marco Massenzio ma...@mesosphere.io wrote: Hey Oliver, thanks for the patch and really glad to hear that Mesos just works for you! As you can imagine, we'd love to add Uber to the Powered by page: http://mesos.apache.org/documentation/latest/powered-by-mesos/ Do you think that would be possible? Welcome to the club! *Marco Massenzio* *Distributed Systems Engineer* On Tue, Jun 9, 2015 at 6:47 PM, Oliver Nicholas b...@uber.com wrote: Hey Tim. We're not *currently* planning Storm work (I think it just works for us at the moment), but I suspect as we move more and more stuff over Mesos and start to expand our clusters and add complexity to our configurations, we'll have work to do on that side as well. -o On Tue, Jun 9, 2015 at 6:43 PM, Timothy Chen tnac...@gmail.com wrote: Hi Oliver, It's great to hear you're using the Storm over Mesos framework too! I think there are lots of improvements that can be made there, are you guys planning to help work on that framework as well? Tim On Tue, Jun 9, 2015 at 6:37 PM, Oliver Nicholas b...@uber.com wrote: Hello Folks, Name's Oliver Nicholas, I'm a sometimes-manager, sometimes-engineer here at Uber. We've been running some Storm jobs over Mesos for a year or two but are looking into moving larger workloads under Marathon now, and ironing out some kinks along the way. My first patch is pretty straightforward, and I'd love to get it committed so I can get on to the rest of them. My Jira username is bigo. https://issues.apache.org/jira/browse/MESOS-1825 https://reviews.apache.org/r/35270/ Thanks! -o -- *bigo* / oliver nicholas | staff engineer, infrastructure | uber technologies, inc. -- *bigo* / oliver nicholas | staff engineer, infrastructure | uber technologies, inc. -- *bigo* / oliver nicholas | staff engineer, infrastructure | uber technologies, inc.
Re: Mesos Jira workflow
On Wed, Jun 10, 2015 at 6:19 PM, Benjamin Mahler benjamin.mah...@gmail.com wrote: To go from accepted to open you need to go through in progress? That part wasn't changed from before? Anyways, why would you ever want to do that? This means that, at some point we looked at something, thought we would want to do that (at some point in future) then, eventually, changed our mind (we no longer want to do it) but will think some more at some other future point and (maybe) re-accept it? This seems an unlikely scenario? more likely, you figured out it wasn't a good idea after all (or maybe it turned out to be a duplicate - or some other features took the problem away) and we can move directly to resolved. Granted, we can obviously add an unaccept transition, but I would much prefer to keep this simple to avoid confusing people. (and, as you correctly pointed out, there is a path back to 'Open' if we really want to). On Wed, Jun 10, 2015 at 2:16 PM, Marco Massenzio ma...@mesosphere.io wrote: Thanks, everyone, for your suggestions: quick feedback was much appreciated! I've updated the Google Doc, I think we're in good shape, I'll wait until Friday to hear if anyone has still objections, then I'll work with Jake (thanks for offer to help!) to implement it. *Marco Massenzio* *Distributed Systems Engineer* On Wed, Jun 10, 2015 at 2:11 PM, Marco Massenzio ma...@mesosphere.io wrote: On Wed, Jun 10, 2015 at 1:15 AM, Till Toenshoff toensh...@me.com wrote: Very helpful Marco… I like the idea of tightening our JIRA workflow. +1 removing “closed done +1 “reviewable” back to in progress — to me this is a very helpful signal for longer lasting comment addressing done +1 making sure that “accepted is the gatekeeper and includes assigning the maintainer as a default shepherd — should we even go as far as to prevent “assigning” issues that have not gotten “accepted” and “shepherd assigned” ? let's not gate fixing the workflow to my achieving the next level of Jira-Wizardry :) the goal can be achieved by education (and enforcement of the policy) I am totally in favor of asking folks NOT to work on non-accepted stories (or, conversely, if they come across issues that are NOT accepted, but want to do work and/or investigation, to assign to themselves and move to accepted state). +1 removing “reopened as it has no extra value for us it's history! Resolving without accepting to me sounds like a shortcut that we might want to prevent as it could be a bad example? On Jun 10, 2015, at 12:00 AM, Marco Massenzio ma...@mesosphere.io wrote: Hadn't realized that the mailing list forwarder would make the images unavailable, apologies about that. I've created this Google Doc https://docs.google.com/document/d/1KQIyEzFP3LF05FkW81SYcG50-HaACD2u-f2SPVAERI8/edit which should be open and accessible. Again, please let me know if anyone feels strongly that we should keep the current workflow. Thanks! Marco Massenzio Distributed Systems Engineer On Tue, Jun 9, 2015 at 2:26 PM, Marco Massenzio ma...@mesosphere.io mailto:ma...@mesosphere.io wrote: Folks, Please take a look at MESOS-2806: in a nutshell, our current workflow is rather convoluted and brings about a host of issues, when managing tasks' status transitions (detailed in the Jira - see screenshots there). This is what it currently looks like: (spaghetti workflow? :) I would propose to simplify it to the following: I'm sure we can think up all sorts of corner cases, but I would submit that simplicity would trump complexity and allow us to track progress (or lack thereof) of stories/tasks/bugs in a much more punctual manner. Anyone against it? Marco Massenzio Distributed Systems Engineer
