To clarify my opinion, I should add that for LTS purposes, I think it's
important that we have a path to "ratchet up" the minimum ciphersuite
standard, and therefore it's appropriate to do in SRU as a policy.
Theoretically this would be for any release, including past releases,
and future ratchets
I'm attending a team event tomorrow and so won't be available for my
shift.
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Unfortunately I have spent more than a shift's worth of time already
this week on dealing with an SRU regression. I am behind on other tasks
so I will not be able to do my usual shift tomorrow. Depending on how
much more of my time it needs, I may have to cut my shift next week as
well.
Please
Hi Phil,
Thank you for working on verifiable package builds!
On Wed, Jun 05, 2024 at 12:20:28PM +0100, Phil Roche wrote:
> I am bringing this to your attention as in support of being able to verify
> package builds in Ubuntu LTS releases I propose that we no change rebuild
> the above packages.
Hi Mario,
Thank you for caring for the fwupd package in Ubuntu!
One adminsitrative question: fwupd is in main and the Foundations team
are committed to looking after it. Is your proposal made on behalf of or
in coordination with the Foundations team? If not, what's the Foundation
team's view on
As a member of the Technical Board who is not on the Release Team, it
always struck me as odd that the TB is responsible for determining which
flavours qualify for the LTS label.
Personally, if someone from the release team says it's OK, then I agree.
I don't think I have anything to add or
On Sat, Dec 02, 2023 at 10:09:15PM -0800, Steve Langasek wrote:
> Historically, we have taken the position on the SRU team that SRUs which are
> still in progress when a release goes EOL are not deleted; the rationale
> being that if the package builds more than one binary, and some user has
>
On Fri, Oct 13, 2023 at 03:03:52PM -0300, Renan Rodrigo Barbosa wrote:
> Great! Thank you very much Steve.
> Now I think we are only missing a sign-off from the Release team, and the
> document to be linked in
> https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template right?
Yes, but I think
Hi!
On Tue, Oct 10, 2023 at 03:27:46PM +0200, Sebastien Bacher wrote:
> I've an action items from the TB to reach out to the concerned teams to ask
> if they could provide a such documentation, which is why I'm writing to you
> now.
I agree that we should have some documented process and policy.
[adding Technical Board to Cc]
On Thu, Sep 14, 2023 at 05:39:50PM +0100, Robie Basak wrote:
> This is now ready for feedback and review. We will need sign-offs from
> the Pro client developers (the subset of the Server Team that is
> maintaining this package) as well as the SRU team, Rel
Hi Adrien,
Thank you for working on improving OpenSSL in our stable releases! Steve
has already said that performance improvements are acceptable. That's
fine by me as well, but of course subject to review of the specific
changes. I wanted to talk about your longer term goals though:
On Mon, Aug
On Wed, Jul 05, 2023 at 12:05:49PM -0300, Renan Rodrigo Barbosa wrote:
> I am reaching out to discuss some changes to the ubuntu-advantage-tools
> package SRU Exception. (https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates)
>
> 1. The first thing to note is that the link above is not listed as an
Hi,
As a list of 46 packages this is rather large and non-trivial to review.
Presumably we'll want to group them by upstream (are all managed by the
OpenStack umbrella upstream, or are there exceptions?) and then take a
view on them as a whole.
On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey
On Fri, Jun 23, 2023 at 10:26:12AM -0700, Steve Langasek wrote:
> Auto-closure of bug tasks was irrelevant to me. We almost never have bug
> tasks open in Launchpad against stable series of packages, *except* when
> they have been opened as part of the SRU process. I didn't even bother to
> look
On Thu, Jun 22, 2023 at 02:59:39PM +0200, Jean-Baptiste Lallement wrote:
> Can you please be concise and provide a list of bullet points that must be
> addressed to move forward?
Question 1. Do you want:
a) an exception that allows you to change behaviour on existing
installations when users
For reference, here are the definitions of options 2 and 3:
> >> 2) Reference them normally but then require or expect that the bugs are
> >> verified anyway, even though that's not strictly necessary because of
> >> the agreed QA process as part of the exception.
> >>
> >> 3) Reference them
On Wed, Jun 21, 2023 at 11:43:12AM +0200, Jean-Baptiste Lallement wrote:
> This special case is now documented on https://wiki.ubuntu.com/AdsysUpdates
> . Can you please review this exception?
Thank you for putting this together!
From that text:
> The scope of this exception excludes major
In the case of an SRU using some kind of exception to bump to a newer
upstream version (whether that's a microrelease, a feature changing
major release or a backport of something) we can end up with:
1. Some kind of tracking bug that explains the exception, for which the
SRU team agrees a QA
On Thu, Jun 15, 2023 at 09:00:09AM +0200, Didier Roche wrote:
> >>In other cases where such upstream automatic testing is not
> >>available, exceptions must still be approved by at least one member of
> >>the Ubuntu Technical Board.
> >If the TB is being that specific about *micro*-releases, then
On Wed, Jun 14, 2023 at 09:31:42AM +0200, Didier Roche wrote:
> Unfortunately, like many projects, there is a constant tension between the
> request for new features backport (adsys, as being an enterprise product,
> only really makes sense in a LTS context) and bug fixes. Most of the new
>
On Wed, Apr 19, 2023 at 12:30:04PM +0100, Robie Basak wrote:
> Here's the minimal patch for Focal, with thanks to the respective
> upstream authors:
Sorry, I think I might have missed the change that drops language from
the composition of tarball_filename when I generated this
On Thu, Apr 06, 2023 at 04:11:23PM -0400, Thomas Ward wrote:
> To cherry pick this would require extensive reverse engineering of the code
> to figure out which pieces apply to the *older* versions of
> torbrowser-launcher. Unfortunately, since there are no *bugfix* releases of
>
Hi Simon,
Thank you for this detailed assessement of the current situation and
in your work to get bugfixes to Ubuntu users!
Some questions come to mind.
What's the impact to users of not taking this action? Do we have
specific cases of users being affected by bugs for which the upstream
stable
On Fri, Apr 14, 2023 at 12:45:41PM -0700, Steve Langasek wrote:
> I'm happy to have that discussion - I just didn't want to leave the MRE in
> its current state as a foot-gun to other SRU team members given the
> information we currently have.
+1 - sorry, I didn't mean to imply otherwise. We
On Fri, Apr 14, 2023 at 11:23:22AM -0700, Steve Langasek wrote:
> It is the nature of MRE exceptions that we declare that *such scrutiny is
> not required*, because we trust that upstream has a microrelease policy in
> place that makes this unnecessary.
>
> While upstream has legitimate reasons
Hi Thomas,
Thank you for caring for this package in Ubuntu!
I'm not sure I follow why this is difficult to fix by cherry-picking
fixes. It seems to me that there are two bugs mentioned - one which is a
two line fix, and one which refers to upstream URLs changing, which
presumably is a change in
On Thu, Mar 16, 2023 at 04:29:29PM +0100, Lukasz Zemczak wrote:
> Would it be possible for us to perform the vote online, via the ML?
> I'd appreciate TB members to participate here with questions or votes.
> From my side, as I already worked on the flavor bits from the
> release-team POV, I am +1
, 2023 at 03:48:30PM +, Robie Basak wrote:
> > 3) So instead I temporarily disabled the _effect_ of the packagesets by
> > removing ~canonical-oem-metapackage-uploaders from the packageset ACLs,
> > which I do have permission to do.
>
> Ok, please revert this.
Re
Documentation link:
https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Canonical_OEM_metapackage_packageset
devel-permissions@ is being spammed every few minutes with this, so I've
taken the following emergency actions:
1) I've attempted to filter all emails from
Hi Seb,
Thank you for raising this.
On Wed, Jan 25, 2023 at 11:23:55AM +0100, Sebastien Bacher wrote:
> In Lunar we changed the telegram-desktop deb to be 'a snap installer', which
> was done on upstream request. The telegram-desktop snap is maintained by
> upstream.
>
> Now we are considering
On behalf of the Technical Board, I've been working with the flavour
leads, as well as prospective new flavour leads, to address the concerns
raised in this thread.
I think we reached a conclusion at the Ubuntu Summit in Prague,
including on specific drafts for a documented process and specific
On Fri, Nov 18, 2022 at 10:12:25AM -0800, Steve Langasek wrote:
> DMB is only on Cc:, but they appear to own this code.
>
> origin
> https://git.launchpad.net/~developer-membership-board/+git/oem-meta-packageset-sync
> (fetch)
Documentation here:
On Tue, Oct 11, 2022 at 09:58:36AM +0300, Timo Aaltonen wrote:
> Christopher James Halse Rogers kirjoitti 28.9.2022 klo 10.07:
> >It's not entirely clear to me what you want to do here.
> >
> >If you need to fix some bugs in Jammy, and updating to thermald 2.5.0 is
> >basically the same as
Hi Erich,
On Fri, Sep 09, 2022 at 05:32:45PM -0700, Erich Eickmeyer wrote:
> You may have seen my post and discussion in the MLs of ubuntu-devel, kubuntu-
> devel and ubuntu-studio-devel (really, those with the Plasma desktops)
> lacking
> a way to be notified when a new Ubuntu version is
Hi Michael,
Thank you for the additional information.
On Mon, Jul 04, 2022 at 05:21:17PM +1200, Michael Hudson-Doyle wrote:
> I have a general desire to be more proactive about bringing upstream fixes
> to 22.04 LTS than we have been but perhaps aiming to get these fixes in
> before .1 is not
Hi Michael,
On Thu, Jun 30, 2022 at 12:43:20PM +1200, Michael Hudson-Doyle wrote:
> I also want to get an SRU into jammy in time for the release of 20.04.1
> which is due August 4, probably aiming for an upload some time next week.
I assume you mean 22.04.1.
Is there a particular reason this
On Mon, May 02, 2022 at 11:28:43AM -0700, Brian Murray wrote:
> Members of the Ubuntu SRU team should now be able to review packages in
> the Unapproved queue and accept them to -proposed for Ubuntu 22.04 LTS.
My queue control buttons have appeared in the Launchpad Web UI at least,
so it looks
Hi,
It also doesn't look like I'm going to be able to do my normal shift
tomorrow or next Wednesday. I expect that I'll be back to normal after
that.
If there's something I've already looked at that is waiting on a
followup then feel free to ping me tomorrow and I'll try to take a look.
Robie
It doesn't look like I'm going to be able to get to my SRU shift today.
Sorry for the late notice.
Robie
signature.asc
Description: PGP signature
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
e can move the repository
and/or provide ACLs to relevant other teams as needed.
Robie
On Mon, Dec 13, 2021 at 09:04:54AM -0800, Steve Langasek wrote:
> On Mon, Dec 13, 2021 at 07:31:16AM +, Robie Basak wrote:
> > On Sat, Dec 11, 2021 at 10:19:12AM -0800, Steve Langasek wrote:
> > > O
On Fri, Nov 19, 2021 at 12:54:22PM -0500, Sergio Durigan Junior wrote:
> I'd like to raise something. I apologize for sending this message in
> such short notice.
>
> I am working on net-snmp, squid and a few other packages during this
> transition, and I am feeling concerned with how
Sorry, I will be unable to do my SRU shift on 2021-10-06.
signature.asc
Description: PGP signature
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Sorry, I will be unable to do my SRU shift on 2021-09-15.
signature.asc
Description: PGP signature
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
On Mon, Jul 26, 2021 at 11:09:19AM -0700, Brian Murray wrote:
> P.S. While sending this kind of notification isn't part of our standard
> procedure I think it should be. Going forward if you can't do your SRU
> vanguard shift please let the list know so we can find someone to cover
> the vanguard
Hi Erich,
We discussed this at the Technical Board meeting yesterday. We don't
have a full answer yet, but the general thought is that there are a set
of expectations for: 1) third party repositories enabled by default; and
2) packages installed from third party repositories via the archive;
that
Hi Erich,
On Sat, Jun 19, 2021 at 03:32:18PM -0700, Erich Eickmeyer wrote:
> While I would have created a snap version, I don't have the know-how, and the
> flatpak version works very well. As such, we'd like to include this flatpak
> version in Ubuntu Studio. I have packaged and uploaded a
In Launchpad, the precise distro_series is still listed as "active".
However, it doesn't appear in apt any more at
http://archive.ubuntu.com/ubuntu/dists/. This is breaking git-ubuntu,
which uses the active series list from Launchpad[1] to decide what apt
suites exist. As a result, git-ubuntu
On Mon, Apr 26, 2021 at 10:39:19AM +0200, Lukasz Zemczak wrote:
> What I think is usually done so early in the cycle is a forward
> binary-copy to the devel series when such an SRU is accepted.
Thanks! Does this mean that the the SRU process for the package in
Hirsute is followed as normal
On Mon, Apr 26, 2021 at 09:26:45AM +0100, Robie Basak wrote:
> As usual, there were some packages left over in the Unapproved and New
> queues and these will need to be handled specially.
What's the normal process for handling these? As it stands, most of
these uploads have bee
I switched queue admin over from ~ubuntu-release to ~ubuntu-sru for
Hirsute this morning, so Hirsute SRU processing can now proceed as
normal for new uploads.
As usual, there were some packages left over in the Unapproved and New
queues and these will need to be handled specially.
signature.asc
I appreciate you bringing this up and proposing improvements!
On Thu, Jul 30, 2020 at 10:36:02AM +0100, Iain Lane wrote:
> I often come across SRU bugs from developers that seem to treat the
> Regression Potential section as a place to argue why their upload is not
> risky and should be
Hi Chad,
Thank you for taking the time to explain and document this proposed
change. Consider it accepted. I've updated the wiki accordingly.
Specifically, the cloud-init testing strategy seems adequate without the
specific solutions testing section. That section exists as a "bonus"
because we
On Mon, Apr 22, 2019 at 08:39:27PM +0200, Michal Stanke wrote:
> I wanted to ask if there is any API or machine friendly format with the
> list of Ubuntu releases, which would be updated when a new version is out
> too.
Fetch JSON from https://api.launchpad.net/devel/ubuntu/series
Then look at
Hi Luke,
Thank you for reporting this.
As far as I can tell, the problem is that update-manager is failing to
produce the correct URL because the binary package version number
mismatches the source package version number. If I'm right, then this is
a bug in update-manager in providing an
Hi Sebastian,
Thank you for bringing this up. I always prefer to have decisions like
this made explicitly and then documented so that everyone is clear and
that SRUs don't get held up due to confusion about expectations. It'd be
useful to get this case clarified.
What follows is just my personal
Hi MH,
Thank you for caring for I2P packaging in Ubuntu!
On Fri, Dec 28, 2018 at 12:49:16PM +0100, Masayuki Hatta wrote:
> We'd like to put .39 to the next Ubuntu release. Could you tell me
> the "dead line" date?
>
> (I tried to find the release cycle info on Ubuntu Wiki, but couldn't
>
On Thu, Oct 25, 2018 at 05:00:09PM -0600, Steve Langasek wrote:
> If that means you agree with Dimitri's recommendations regarding ignorable
> autopkgtest failures, could you please update
> lp:~ubuntu-sru/britney/hints-ubuntu-xenial accordingly with badtest hints?
I checked and was satisfied
On Thu, Oct 25, 2018 at 01:30:41PM -0700, Brian Murray wrote:
> For the record this was released to -updates by somebody.
That was me. Sorry, I should have noted it here.
Robie
signature.asc
Description: PGP signature
--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify
Hi Balint,
On Mon, Aug 13, 2018 at 03:23:30PM +0200, Balint Reczey wrote:
> I found some cases where SRUs (for example for unattended-upgrades)
> listed new default values as comments in the main configuration file.
> Upon upgrade this changed configuration file may trigger a question to
> the
On Wed, Aug 08, 2018 at 11:09:59AM -0400, Daniel Watkins wrote:
> One extra argument for waiving the requirement: this package does most
> of its work on first-boot of an instance; we have to manually build new
> GCE images specifically to be able to test it. Users who just enable
> -proposed and
Hi Steve,
Summary: I still think we should have an actual justification for
waiving the aging requirement. I still don't think that we've actually
been given a justification in this case. Give me one and I'll
reconsider, but IMHO without any justification, we should either change
policy to drop
Hi Balint,
On Thu, Jul 26, 2018 at 11:05:11PM +0800, Balint Reczey wrote:
> Robie Basak pointed out that in the stable release exception [1] for
> gce-compute-image-packages the wording does not explicitly lift the
> requirement for the the package to reach the minimal age (7 days)
Recently we seem to have changed the process somewhat, removing the
documentation about creating bug tasks for stable releases. I propose to
reverse this, and give more uploaders permission to create "SRU" bug
tasks, for the following reasons.
I've just come across my first review where the
[dropping all from Cc leaving only the list]
Thanks to Simon for handling the migration of the seeds to git.
This left the instructions on changing the seeds in
https://wiki.ubuntu.com/SeedManagement out of date, so I have updated
it. If the instructions are wrong, I hope it's at least a
[adding pkg-mysql-maint; see
https://lists.ubuntu.com/archives/ubuntu-quality/2018-March/007069.html
for previous thread posts]
Hi Otto,
On Fri, Mar 23, 2018 at 12:29:49PM +, Robie Basak wrote:
> I guess that the discussion is complete now? How do you want to proceed?
>
> Will y
On Wed, Mar 21, 2018 at 08:53:20PM -0700, Steve Langasek wrote:
> Particularly for a case of an autopkgtest that has regressed via
> security/SRU, I think it matters to clean these up, as not doing so means we
> lose any information about whether *other* SRUs are causing user-affecting
>
Hi Otto,
I guess that the discussion is complete now? How do you want to proceed?
Will you upload a src:mariadb-10.1 update to Debian? If not, I suppose I
need to upload a src:mariadb-10.1 upload to Ubuntu to fix it for Bionic
at least?
Robie
signature.asc
Description: PGP signature
--
On Wed, Mar 21, 2018 at 08:53:20PM -0700, Steve Langasek wrote:
> Hi Robie,
>
> On Wed, Mar 21, 2018 at 05:02:34PM +0000, Robie Basak wrote:
> > Dimitri uploaded a dep8 fix for dovecot in bug 1757265.
>
> > I've always been reluctant to accept SRUs for things that ar
Dimitri uploaded a dep8 fix for dovecot in bug 1757265.
I've always been reluctant to accept SRUs for things that are not user
impacting.
For consistency, please could we decide a policy on this?
To be clear, this isn't about SRU paperwork. Normally I'd happily accept
a bundled dep8 fix in an
On Fri, Mar 16, 2018 at 09:43:35AM +0200, Otto Kekäläinen wrote:
> I have owned several pre-installed Ubuntu laptops and all of them come
> with their custom repositories pre-installed in
> /etc/apt/sources.list.d/, which install custom versions of Linux
> modules or whatever that are absolute
On Fri, Mar 16, 2018 at 12:01:11AM +0200, Otto Kekäläinen wrote:
[I've rearranged the quote ordering to bring common topics together]
> I don't think it has unacceptable knock-on effects if reverted. On the
> contrary, if not reverted, the knock-on effects will be massive.
[...]
> And keep the
On Thu, Mar 08, 2018 at 10:01:32PM +, Robie Basak wrote:
> I'd like to bring the release team's attention to this bug:
>
> https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169
>
> This seems like a matter where people are getting quite personally
> and emotiona
I'd like to bring the release team's attention to this bug:
https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1753169
This seems like a matter where people are getting quite personally
and emotionally involved, so I think it's probably best for most of us
to stay out of it and leave it to our
On Wed, Feb 07, 2018 at 06:51:13AM -0500, Jeremy Bicha wrote:
> Also, some flavors like Kylin can't post to ubuntu-devel without moderation.
To be clear (for others), this isn't by some particular policy. I
believe that people can be whitelisted into ubuntu-devel@. I don't think
that anyone would
On Mon, Jul 31, 2017 at 04:15:25PM -0700, Brian Murray wrote:
> This looks good to me, it might be useful to include bug 1640978 in the
> wiki page so people have an idea of what a proper SRU of the Certbot
> family looks like.
Good idea! I've added the bug link to the wiki page. Thank you for
I've prepared SRU exception documentation for the Certbot family of
packages (think Let's Encrypt) at:
https://wiki.ubuntu.com/StableReleaseUpdates/Certbot
The current SRU tracking bug is https://launchpad.net/bugs/1640978
I'd appreciate review of this plan please. If there are no objections,
https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
says: "In other cases where such upstream automatic testing is not
available, exceptions must still be approved by at least one member of
the Ubuntu Technical Board."
So if the SRU team determine that a proposed new upstream
On Tue, Jun 27, 2017 at 02:29:33PM +0100, Dimitri John Ledkov wrote:
> There is no way to distinguish changes of each microcode, what it
> does, and which bugs it fixes and to create templates on how to
> reproduce and validate each bug / vulnerability that is fixed. My
> understanding is that
Hi Dimitri,
Thank you for raising this here.
On Tue, Jun 27, 2017 at 10:45:39AM +0100, Dimitri John Ledkov wrote:
> Instead, I have been asked by an SRU team member to create a more typical
> targetted SRU update which uses divergent packaging on per-series basis,
> increasing the delta of each
On Mon, Nov 21, 2016 at 04:43:26PM +, Adam Conrad wrote:
> On Mon, Nov 21, 2016 at 04:36:52PM +0000, Robie Basak wrote:
> >
> > Dan asked for gce-compute-image-packages to be added to the ubuntu-cloud
> > packageset, which seems fine to me. But when checking out the
Dear Release Team,
Dan asked for gce-compute-image-packages to be added to the ubuntu-cloud
packageset, which seems fine to me. But when checking out the package I
noticed that it is unseeded and in universe. This seems to be at odds to
me that it is "installed in the official Ubuntu images on
On Wed, Oct 19, 2016 at 12:41:26PM -0700, Steve Langasek wrote:
> I understand the intent. Testing -proposed as a whole then still leaves you
> the problem of root-causing any regressions. Have you had success in
> feeding back the results of your testing into the SRU process?
I'd like to
I just filed this bug: https://bugs.launchpad.net/ubuntu/+bug/1634201; I
Cc'd the bug so as to try and not fragment any discussion.
During development, we have packages in -proposed that fail to migrate,
as expected, for good reason.
At release time, these packages are still present. For
Hi Pieter,
Thank you for looking out for the PowerDNS packaging in Ubuntu!
I'm forwarding your question to the Ubuntu Release Team to ask their
opinion.
For your second option, remember that ordinary bugfixes are absolutely
fine to land even after feature freeze, so if your subsequent alphas,
On Fri, Aug 21, 2015 at 11:35:50AM -0700, Steve Langasek wrote:
This all sounds completely reasonable to me. Thanks for letting us
know.
Great! Thank you for confirming.
At some point during the release cycle I imagine you'll want to start using
the SRU process anyway instead of pushing
Dear Ubuntu Release Team,
juju-core has an exception for major release updates, including new
features, in stable releases[1].
It seems to me that this implies that it's fine for me to also upload
new upstream feature releases to the development release during feature
freeze, as would make
in future.
We think option A fits better with the needs of nginx users, but welcome
further discussion.
Please can we agree on feature freeze and SRU policy exceptions so that
we can execute option A, or otherwise discuss alternatives?
Thanks,
Robie Basak and Thomas Ward
Ubuntu Server Team
[1] https
On Tue, Oct 07, 2014 at 07:30:49PM -0600, Adam Conrad wrote:
If upstream doesn't intend to reuse version numbers, you're over-
complicating with the PPA business. Just do this soft release to
proposed, test it and, if it sucks, remove and iterate, if it's good,
everyone wins.
If the concen
On Wed, Oct 08, 2014 at 06:49:05AM +0200, Martin Pitt wrote:
Steve Langasek [2014-10-07 17:14 -0700]:
Given that Juju is covered by a provisional micro release exception[1], I
don't understand the ordering concern. MREs are granted on the condition
that the upstream release process is
Replying to both Steve and Adam here, since I think they touch upon the
same point.
On Tue, Oct 07, 2014 at 05:14:57PM -0700, Steve Langasek wrote:
Given that Juju is covered by a provisional micro release exception[1], I
don't understand the ordering concern. MREs are granted on the condition
On Wed, Oct 08, 2014 at 07:34:12AM -0400, Scott Kitterman wrote:
If they aren't going to reuse the version number, why not go ahead and
release? Seems much simpler workflow wise and if there's a problem, they're
bumping to a new version anyway. Nothing says they have to advertise the new
Dear Release Team,
I'd like to change how I upload Juju to the archive, both to the
development release and SRUs, for QA purposes.
I'd like to understand if this is 1) workable technically and the best
way to do it; and 2) reasonable and acceptable process-wise.
First, an explanation of why I
On Tue, Jul 29, 2014 at 07:28:49PM +, process-component-mismatches-diff
wrote:
o hiera: hiera
[Reverse-Depends: ruby-hiera (MAIN)]
Looks like this is just a rename from ruby-hiera to hiera, and the
source is the same.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751386 and
On Fri, Jun 20, 2014 at 09:46:57PM +, process-component-mismatches-diff
wrote:
o nodejs: nodejs nodejs-dbg nodejs-dev
[Reverse-Depends: Rescued from nodejs, node-less]
o twitter-bootstrap: libjs-twitter-bootstrap libjs-twitter-bootstrap-docs
[Reverse-Depends: Rescued from
94 matches
Mail list logo
