Moose-dev

moose-dev@list.inf.unibe.ch

6630 discussions

Reminder: CFP for IEEE Software - 1st Special Issue on Release Engineering

by Bram Adams

[Apologies for duplicate reception of this CFP] Reminder: IEEE SOFTWARE - 1ST SPECIAL ISSUE ON RELEASE ENGINEERING Submission Deadline: 1 August 2014 Publication: March/April 2015 More Information: http://releng.polymtl.ca/RELENG2014/html/SI.html Software used to be released in shrink-wrapped form, but the advent of agile methodologies and the web has overhauled the landscape. For example, a project like Mozilla Firefox releases every 6 weeks, generating updates for dozens of existing versions on 5 desktop, 2 mobile and 3 mobile desktop platforms, each of which for more than 80 locales. In other words, deployment of modern applications requires coordinating the release of applications on multiple mobile platforms, web platforms with centralized backend services, and native desktop clients. Furthermore, concepts like continuous delivery of software are no longer curiosities, but essential to retain a competitive edge. Release engineering deals with all activities in between regular development and actual usage of a software product by the end user, i.e., integration, build, test execution, packaging and delivery of software. Although research on this topic goes back for decades, the increasing heterogeneity and variability of software products along with the recent trend to reduce the release cycle to days or even hours starts to question some of the common beliefs and practices of the field. The IEEE Software Special Issue on Release Engineering solicits experience reports and papers on tools, methods, practices and techniques to streamline release engineering. We especially welcome submissions targeting recent challenges like continuous delivery and heterogeneous platform support, but the Special Issue is open to any of the following topics: * best practices for code movement (branching/integration) * continuous integration and testing * build and configuration of software * build system maintenance * testing and reporting infrastructures * package and dependency management * legal signoff and bill-of-materials * delivery and deployment of software * code signing and certificate management * continuous delivery, deployment, installation and software update * cloud provisioning and management * cloud service release management * interaction with app stores * mobile app release management * principles and automated techniques for release planning * release engineering for product line systems * devops and interaction with developers, end users, etc. * devops practices and tools * large-scale build and test farms * multi-platform build and test * feedback on continuous delivery and deployment The goals for this Special Issue are three-fold: * making researchers aware of the challenges and research opportunities, and practitioners aware of research in release engineering * sharing experiences with practical approaches, tools, methods and techniques for release engineering * building connections between different communities involved in release engineering. In an effort to engage with practitioners, one of the co-organizers of the Special Issue is a release engineer at Mozilla and one half of the reviewers will consist of release engineers, so we guarantee that each paper or abstract submission receives at least one review from a practitioner. Full submissions for the Special Issue must not exceed 5,400 words including figures and tables, which count for 200 words each. Submissions in excess of these limits may be rejected without refereeing. The articles we deem within the theme and scope will be peer-reviewed and are subject to editing for magazine style, clarity, organization, and space. We reserve the right to edit the title of all submissions. Be sure to include the name of the theme or Special Issue you are submitting for. We also solicit short “practice” papers from practitioners that contain experience reports. These papers do not need to make a research contribution, but should instead present the experiences of a practitioner or practitioners by describing things such as current release processes used, challenges faced, solutions attempted, and/or results obtained. Practice papers should not exceed 3,500 words. Articles should have a practical orientation and be written in a style accessible to practitioners. Overly complex, purely research-oriented or theoretical treatments are not appropriate. Articles should be novel. IEEE Software does not republish material published previously in other venues, including other periodicals and formal conference/workshop proceedings, whether previous publication was in print or in electronic form. For more information about the focus, please contact the Guest Editors: * Bram Adams (http://mcis.polymtl.ca/bram.html), Polytechnique Montréal, Canada * Stephany Bellomo (http://www.sei.cmu.edu/about/people/profile.cfm?id=bellomo_15351), SEI, USA * Christian Bird (http://research.microsoft.com/en-us/people/cbird/), Microsoft Research, USA * Foutse Khomh (http://www.khomh.net/), Polytechnique Montréal, Canada * Kim Moir (http://relengofthenerds.blogspot.com/), Mozilla, Canada For general author guidelines: http://www.computer.org/software/author.htm For submission details: software(a)computer.org

10 years, 6 months

Build failed in Jenkins: moose-5.0 #1848

by admin＠moosetechnology.org

10 years, 6 months

Roassal bug: remove labelled edge and the label stays

by Johan Fabry

Hola, I found a bug in Roassal: if an edge is labeled, and that edge is removed from the view at some point (using removeEdge:) then the label does not go away. This is quite annoying, given that my latest project adds and removes a lot of edges in the visualization on a frequent basis. :-( I verified this bug in the latest build. Code to reproduce is below. “From RTRoassalExample>>exampleArrowedAndLabelledLine. Last line is new” | v e1 e2 l | v := RTView new. e1 := (RTEllipse new size: 20) elementOn: 'hello'. e2 := (RTEllipse new size: 20) elementOn: 'world'. e1 @ RTDraggable. e2 @ RTDraggable. l := RTEdge from: e1 to: e2. l + (RTLine new color: Color red). l + (RTSimpleArrowHead new color: Color red). e2 translateBy: 60 @ 80. v addAll: { e1 . e2 . l }. e1 @ RTLabelled. e2 @ RTLabelled. "Note that the RTLabelled interaction has to be set after having added the element in the view" l @ (RTLabelled new text: 'lining up!'). v open. v canvas. v removeEdge: l “THIS IS THE NEW LINE" ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

10 years, 6 months

Jenkins build became unstable: moose-5.0 #1842

by admin＠moosetechnology.org

See <https://ci.inria.fr/moose/job/moose-5.0/1842/>

10 years, 6 months

Font problem is getting worse...

by Alexandre Bergel

Hi! We get this in a fresh moose image, on OSX: This is really a pity. This problem is so important, that we may directly output a roassal visualization in a separate window, bypassing Athens and directly using Cairo on SDL. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

10 years, 6 months

[Roassal2] Selecting multiple elements

by Roberto Minelli

Hi, Is there any way to perform multiple selection of elements in roassal? i.e., my idea would be to drag a sort of "selection rectangle” and select those elements whose bounds lie underneath the selection. Cheers and thanks in advance, Roberto

10 years, 6 months

Is there a stable ConfigurationOfGlamour for Pharo 3?

by MartinW

Is there a stable ConfigurationOfGlamour for Pharo 3? I loaded the last ConfigurationOfGlamour from Smalltalkhub and it defines only stable versions up to #'pharo2.x'. Is there a version i can securely use on Pharo 3 and it is just not defined in the ConfigurationOfGlamour #stable: method? -- View this message in context: http://forum.world.st/Is-there-a-stable-ConfigurationOfGlamour-for-Pharo-3-… Sent from the Moose mailing list archive at Nabble.com.

10 years, 6 months

Re: Playground details

by Stephan Eggermont

Spec-Examples-Morphic TabContainerMorph initialize super initialize. self changeProportionalLayout. container := PanelMorph new changeTableLayout; listDirection: #bottomToTop; color: Color white; yourself. tab := PluggableTabBarMorph on: self. tab width: 150. tab color: Color white darker darker. self addAll.

10 years, 6 months

Re: Playground details

by Stephan Eggermont

The new tab widget in Spec is not very different from the existing one. It behaves the same Stephan

10 years, 6 months

Issue 1078 in moose-technology: Syntax error do not raise when debugging

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1078 by v.blonde...(a)gmail.com: Syntax error do not raise when debugging http://code.google.com/p/moose-technology/issues/detail?id=1078 Describe the problem: what do you get? what do you expect? When I change a method in the GTDebugger with a syntax error, the save action is allowed (the orange corner vanishes but the code is not saved...) and the debugger goes to the top of the stack, but no error message is risen. I expect to have a message or at least not the ability to save How to reproduce the problem: step by step if necessary Execute: Object sorted You should have a DNU. Remove receiver: self in the Object>>doesNotUnderstand: method, now the method contains a syntax error (; followed of .) Save Additional information: platform, context which may impact the problem W7 - Moose latest Please fill in the labels with the following information: * Type-Defect * Component-GTDebugger -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

10 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev