[Review Queue] mobilefirst-server
I spent the time reviewing the IBM MobileFirst-Server today. This one required 2 other IBM charms (DB2 and WebSphere Liberty) to deploy and the instructions indicated to deploy to the same server. The charms deployed but "No runtime environments deployed to this server" so that looks like something was not configured correctly. You can read more about it here: https://bugs.launchpad.net/charms/+bug/1478783 - Matt Bruzek -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [Process] Proposal to revise unmaintained charms workflow
+1 here. I would expect it to be dropped as soon as it's requested/filed. Plus, all the code would not be lost, since it's moved to ~unmaintained-charms. -- José Antonio Rey On Fri, Sep 4, 2015, 12:43 Marco Ceppi wrote: > Though you didn't ask, it's a +1 from me. I think the current process is > more gauged at weeding out charms that are abandoned by authors and doesn't > have a declaration for how to handle the use case where an author > explicitly wishes to drop maintainership. > > > Marco > > On Fri, Sep 4, 2015 at 1:40 PM Charles Butler < > charles.but...@canonical.com> wrote: > >> Greetings, >> >> We've recently encountered a scenario where our verbiage in the >> unmaintained charm process is a tad confusing and limiting given the >> scenario that a charm author requests to no longer maintain their charm. >> >> For reference, the document in question is located here: >> https://jujucharms.com/docs/stable/charm-unmaintained-process >> >> Given the scenario that a charm author wishes to maintain their charm and >> informs ~charmers they will no longer be developing, patching, or updating >> - essentially abandoned the charm - the verbiage states: >> >> >> >>1. >> >>File a bug against charm saying “Maintainer needed” >>2. >> >>Is charm broken? >>1. >> >> Follow “Workflow for identifying and triaging unmaintained charms” >> process >> >> >> This particular process includes a 30 day wait period to take *any* >> action on the charm. What we would like to propose is: >> >> A bug be filed for "Maintainer Needed", the charm be moved to >> ~unmaintained-charms, and a call to arms be issued to the list for a new >> maintainer. Thus not leaving a potentially broken charm in the charm-store >> for an extended time-wait scenario, allowing other potential consumers to >> encounter the unmaintained, and potentially broken charm. >> >> If someone steps into the role of maintainership, it's a simple process >> to put the charm back in the store under the new maintainer. >> >> If you have any dispute with this potential change, please respond to >> this thread. No verbal dispute will constitute acceptance, and we will >> amend during the Charmer Summit starting Sept 17th. >> >> Thanks >> >> Charles Butler - Juju Charmer >> Come see the future of datacenter orchestration: http://jujucharms.com >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [Process] Proposal to revise unmaintained charms workflow
Though you didn't ask, it's a +1 from me. I think the current process is more gauged at weeding out charms that are abandoned by authors and doesn't have a declaration for how to handle the use case where an author explicitly wishes to drop maintainership. Marco On Fri, Sep 4, 2015 at 1:40 PM Charles Butler wrote: > Greetings, > > We've recently encountered a scenario where our verbiage in the > unmaintained charm process is a tad confusing and limiting given the > scenario that a charm author requests to no longer maintain their charm. > > For reference, the document in question is located here: > https://jujucharms.com/docs/stable/charm-unmaintained-process > > Given the scenario that a charm author wishes to maintain their charm and > informs ~charmers they will no longer be developing, patching, or updating > - essentially abandoned the charm - the verbiage states: > > > >1. > >File a bug against charm saying “Maintainer needed” >2. > >Is charm broken? >1. > > Follow “Workflow for identifying and triaging unmaintained charms” > process > > > This particular process includes a 30 day wait period to take *any* action > on the charm. What we would like to propose is: > > A bug be filed for "Maintainer Needed", the charm be moved to > ~unmaintained-charms, and a call to arms be issued to the list for a new > maintainer. Thus not leaving a potentially broken charm in the charm-store > for an extended time-wait scenario, allowing other potential consumers to > encounter the unmaintained, and potentially broken charm. > > If someone steps into the role of maintainership, it's a simple process to > put the charm back in the store under the new maintainer. > > If you have any dispute with this potential change, please respond to this > thread. No verbal dispute will constitute acceptance, and we will amend > during the Charmer Summit starting Sept 17th. > > Thanks > > Charles Butler - Juju Charmer > Come see the future of datacenter orchestration: http://jujucharms.com > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Process] Proposal to revise unmaintained charms workflow
Greetings, We've recently encountered a scenario where our verbiage in the unmaintained charm process is a tad confusing and limiting given the scenario that a charm author requests to no longer maintain their charm. For reference, the document in question is located here: https://jujucharms.com/docs/stable/charm-unmaintained-process Given the scenario that a charm author wishes to maintain their charm and informs ~charmers they will no longer be developing, patching, or updating - essentially abandoned the charm - the verbiage states: 1. File a bug against charm saying “Maintainer needed” 2. Is charm broken? 1. Follow “Workflow for identifying and triaging unmaintained charms” process This particular process includes a 30 day wait period to take *any* action on the charm. What we would like to propose is: A bug be filed for "Maintainer Needed", the charm be moved to ~unmaintained-charms, and a call to arms be issued to the list for a new maintainer. Thus not leaving a potentially broken charm in the charm-store for an extended time-wait scenario, allowing other potential consumers to encounter the unmaintained, and potentially broken charm. If someone steps into the role of maintainership, it's a simple process to put the charm back in the store under the new maintainer. If you have any dispute with this potential change, please respond to this thread. No verbal dispute will constitute acceptance, and we will amend during the Charmer Summit starting Sept 17th. Thanks Charles Butler - Juju Charmer Come see the future of datacenter orchestration: http://jujucharms.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
transcode charm is unmaintained - call for maintainership
Hello juju! Dustin Kirkland has stepped down as the maintainer of the transcode charm. As a result of this action we've started an accelerated unmaintained process. The first step is this email asking if anyone is interested taking on maintainership of the charm to get it up to snuff for deployment. If we don't receive any interest in maintainership of the charm before 2015 Sept 11 the charm will be removed from the recommended charm namespace and put in cs:~unmaintained-charms/precise/transcode At that point transcode will still be deployable using the full namespace URL (cs:~unmaintained-charms/precise/transcode). At any point in time, either now or after the 11th of Sept, if you're interested in taking maintainership reply to this email or this bug https://bugs.launchpad.net/charms/+source/transcode/+bug/1492399 to start the new maintainership process. Thanks, Marco Ceppi -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [ANN] Charm Tools 1.6.1
Hey Adam, Thanks for the report. This was a known limitation at the moment as those dependencies require py3.1 which isn't in precise. The issues I alluded to earlier were for those users running trusty or higher. I don't realize there would be many people still on precise and figured I had a few more days to figure out this snafu. I'm on the case now and hope to have those three packages sorted in a few hours. Thanks, Marco Ceppi On Fri, Sep 4, 2015 at 5:38 AM Adam Collard wrote: > Hi Marco, > > On Wed, 2 Sep 2015 at 22:01 Marco Ceppi wrote: > >> The charm-tools 1.6.0 and 1.6.1 packages created a unique challenge in >> packaging. The result was a potentially broken apt/dpkg state on a few >> users machines. If you've attempted and upgrade in the past 24 hours you >> may have experienced some oddness with jujubundlelib, charm-tools, and >> other packages. Before reporting issues please make sure you've run `sudo >> apt-get update` and a `sudo apt-get install -f`. >> >> Going forward we're producing a new set of QA tests for our tooling to >> prevent having broken packages uploaded to the archive. >> > > Looks like they're still broken for Precise. > > charm-tools 0.6.1 has a declared dependency on python-yaml (>= 3.11), but > http://packages.ubuntu.com/search?keywords=python-yaml latest for Precise > is 3.10.x > > This leads to a broken package - > > > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created or been > moved out of Incoming. > > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > charm-tools : Depends: python-yaml (>= 3.11) but 3.10-2ubuntu0.1 is to be > installed > Depends: python-blessings but it is not installable > Depends: python-ruamel.yaml but it is not installable > E: Unable to correct problems, you have held broken packages. > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [ANN] Charm Tools 1.6.1
Hi Marco, On Wed, 2 Sep 2015 at 22:01 Marco Ceppi wrote: > The charm-tools 1.6.0 and 1.6.1 packages created a unique challenge in > packaging. The result was a potentially broken apt/dpkg state on a few > users machines. If you've attempted and upgrade in the past 24 hours you > may have experienced some oddness with jujubundlelib, charm-tools, and > other packages. Before reporting issues please make sure you've run `sudo > apt-get update` and a `sudo apt-get install -f`. > > Going forward we're producing a new set of QA tests for our tooling to > prevent having broken packages uploaded to the archive. > Looks like they're still broken for Precise. charm-tools 0.6.1 has a declared dependency on python-yaml (>= 3.11), but http://packages.ubuntu.com/search?keywords=python-yaml latest for Precise is 3.10.x This leads to a broken package - Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: charm-tools : Depends: python-yaml (>= 3.11) but 3.10-2ubuntu0.1 is to be installed Depends: python-blessings but it is not installable Depends: python-ruamel.yaml but it is not installable E: Unable to correct problems, you have held broken packages. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
