[FFe] Please include juju-core 1.10.0 in Ubuntu 13.04

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1172215/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Uploaded to raring for release team and archive admin review as discussed with Dave Walker.

FFe approved for NEW upload and review, for pure universe inclusion. Please commit (or drive) resolving any issues this could potentially introduce.

I am volunteering to NEW review, but have also requested an additional peer review.

Thanks.

Do we really need a New package the day before release?

Can you just do it next week and backport it?

That way we aren't stuck with it if thing go sideways (witness the joy of
supporting MaaS in precise - let's not do this again).

If the package is of sound quality, then doing it now - or next week and backporting is of little difference.

The consensus on the release team is it's better to get it into "S" and then backport. Since there will be no version in the release pocket, the backport version will be automatically selected and installed. That should make it a lot easier to provide a quality experience for raring users.

As discussed on IRC, everyone else on the release team thought differently.

I don't believe this decision makes sense for users.

The Go port of juju is supported, maintained, and users who opt in to using it now will be able to avoid a painful migration later.

Since this is fully opt-in, there is no advantage to waiting for backports to pull it in. It is a stand-alone package so will by definition not break anything else on the system. And having it in backports requires multiple steps of to get the package, enables a bunch of packages most server admins won't want, and thus requires pinning to get go juju.

What is the case against inclusion now? Just that it is new?

There is a flawed assumption in the above statement, that users will know to enable backports in the first place.

 I understand the concern of the release team, but the push for getting this version into 13.04 is to help alleviate the current less-than desirable situation in the juju community, and ultimately get our users over to the supported version of juju going forward. I strongly feel that the efforts to block this are more philosophical, than practical.

So, this isn't just a philosophical issue. Accepting something last-minute that people expect to support (rather than just dump in universe and forget) is actually a fair bit of potential future work.

We make a commitment that SRUs not regress, offer sane upgrade paths, etc. Dumping something in to the release pocket late that is "from an end-user perspective its not 100% feature complete" implies that your intent is to SRU it to completion later, which will be very hard to both review and upgrade safely.

We've offered a clear alternative, which is to upload it to s-series, backport to the backports pocket (which, contrary to popular belief, *is* enabled by default), and let people test it as a work in progress. That, to me, is FAR preferable to shipping something in the release pocket that's known-broken.

The nice thing about the Juju 1.10.0 is that it gives users a place to go after 13.04. They can just either upgrade to 13.10 or to the PPA version since this version of Juju allows that and move forward

The pyju version does not allow this, people will need to tear down their deployment and redeploy, so getting then in at the 1.10 level at a minimum is desirable, so IMO this should just drop-in replace the existing version so we can get people in an upgradeable state instead of using a package that is known-to-be dead.

On Wednesday, April 24, 2013 05:31:39 PM you wrote:
> There is a flawed assumption in the above statement, that users will
> know to enable backports in the first place.

There's a flawed assumption in your assumption. Backports are enabled by
default since Natty.

On Wednesday, April 24, 2013 05:31:16 PM you wrote:
> I don't believe this decision makes sense for users.
>
> The Go port of juju is supported, maintained, and users who opt in to
> using it now will be able to avoid a painful migration later.
>
> Since this is fully opt-in, there is no advantage to waiting for
> backports to pull it in. It is a stand-alone package so will by
> definition not break anything else on the system. And having it in
> backports requires multiple steps of to get the package, enables a bunch
> of packages most server admins won't want, and thus requires pinning to
> get go juju.

It requires no extra steps.

Known broken sounds incorrect for the situation here. What we have is known incomplete, which is significantly different both practically and philosophically.

100% feature complete is a software myth. So that's not a real argument.

But go juju has an upgrade path, and has a team ready to support it, and this is fully opt-in.

As for a fair bit of potential future work -- that is a possibility. But this is a critical package for many people, and we are giving them a way to move forward in a supported way, which is not the case currently, so it seems like that work will be valuable to users.

If we put it in backports next week, users can install it by using:

sudo apt-get install juju-core

If we put it in the release pocket now, users can install it by using:

sudo apt-get install juju-core

The backports option avoids all the risks Adam mentioned and affects users not
at all.

We are fully committed to not regressing and creating a sane upgrade path. We have people on this, to make sure that happens. And again this is a stand-alone package with no dependencies -- so I don't think the risks are that significant.

But I understand that this is not my decision. I'm just making the case for inclusion, because it is what I think is best for users today.

It looks like we're going to split the baby and accept it directly into raring-backports, so it will be available at release, but without creating all the attendant concerns members of the release team have expressed here and on IRC.

For avoidance of doubt, as an ubuntu-backporter, this "backport" is approved.

Let's leave the Ubuntu task open as a reminder to copy this forward to "S" (it's not automatic).

This bug was fixed in the package juju-core - 1.10.0.1-0ubuntu1~ubuntu13.04.1

---------------
juju-core (1.10.0.1-0ubuntu1~ubuntu13.04.1) raring-backports; urgency=low

  [ James Page ]
  * Initial release (LP: #1172215).

  [ Mark Mims ]
  * Install alternatives for juju, jujud and juju.1 manpages for
    co-installability with juju package.

  [ Dave Cheney ]
  * Initial packaging.
 -- James Page <email address hidden> Wed, 24 Apr 2013 22:34:47 +0100