On Thu, Aug 18, 2022 at 08:28:29AM -0700, Steve Langasek wrote:
> I'm concerned that this requires subscription to the package in Debian for
> this to not fall off the radar. We have merges.ubuntu.com which tracks
> which packages need to be updated, and the standing assumption is that the
> person who last uploaded the package to Ubuntu is responsible for following
> through on the merges. Is this not the current practice of the Ubuntu
> Server team?
I think Andreas' mention of using a subscription was just about being
more responsive, rather than as a substitute for grep-merges.
But to answer your question of what our team does:
We found that our packages weren't getting merged when last touched by
people outside the team, or people who had left. So instead we monitor
the status of all packages that we're subscribed to, and schedule such
outstanding merges and track their progress, as our primary means of
ensuring that merges happen.
This doesn't work so well when we touch packages outside the normal
scope of our team, such as during +1 maintenance, or sponsoring
something unrelated to the server team.
We do try to use grep-merges too though, and as it happens I reminded
everyone in our standup today that they need to do this.
However this is an individual thing, not a team thing. I think the
cracks identified above suggest that we should find a better way.
Thursday, 18 August 2022
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Hi
On Thu, Aug 18, 2022 at 12:28 PM Steve Langasek
<steve.langasek@ubuntu.com> wrote:
>
> Hi Andreas,
>
> On Thu, Aug 18, 2022 at 10:24:31AM -0300, Andreas Hasenack wrote:
>
> > I thought of:
> > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> > subscribe to the tiff package in debian, and sync it manually the next
> > time there is a debian upload
>
> I'm concerned that this requires subscription to the package in Debian for
> this to not fall off the radar. We have merges.ubuntu.com which tracks
> which packages need to be updated, and the standing assumption is that the
> person who last uploaded the package to Ubuntu is responsible for following
> through on the merges. Is this not the current practice of the Ubuntu
> Server team?
It is, and we have a weekly report[1] about it. I just go through this
extra step of subscribing to the package in the tracker so I don't
have to wait for that weekly report.
> There's a commandline tool, 'grep-merges', which lets you grep for packages
> you touched last by email. 'grep-merges hasenack' currently returns empty
> so you're currently good :)
Thanks ;)
1. https://lists.ubuntu.com/archives/ubuntu-server/2022-August/009372.html
(grep-merges is the last section in that email)
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Hi Andreas,
On Thu, Aug 18, 2022 at 10:24:31AM -0300, Andreas Hasenack wrote:
> I thought of:
> a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> subscribe to the tiff package in debian, and sync it manually the next
> time there is a debian upload
I'm concerned that this requires subscription to the package in Debian for
this to not fall off the radar. We have merges.ubuntu.com which tracks
which packages need to be updated, and the standing assumption is that the
person who last uploaded the package to Ubuntu is responsible for following
through on the merges. Is this not the current practice of the Ubuntu
Server team?
There's a commandline tool, 'grep-merges', which lets you grep for packages
you touched last by email. 'grep-merges hasenack' currently returns empty
so you're currently good :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
On Thu, Aug 18, 2022 at 10:24:31AM -0300, Andreas Hasenack wrote:
> I thought of:
> a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> subscribe to the tiff package in debian, and sync it manually the next
> time there is a debian upload
I'm concerned that this requires subscription to the package in Debian for
this to not fall off the radar. We have merges.ubuntu.com which tracks
which packages need to be updated, and the standing assumption is that the
person who last uploaded the package to Ubuntu is responsible for following
through on the merges. Is this not the current practice of the Ubuntu
Server team?
There's a commandline tool, 'grep-merges', which lets you grep for packages
you touched last by email. 'grep-merges hasenack' currently returns empty
so you're currently good :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Oh, this is a rabbit hole...
I'll just bite the bullet and drop the delta in 4ubuntu2, and watch
for new debian uploads.
On Thu, Aug 18, 2022 at 10:36 AM Marc Deslauriers
<marc.deslauriers@canonical.com> wrote:
>
> On 2022-08-18 09:24, Andreas Hasenack wrote:
> > Hi,
> >
> > On Wed, May 25, 2022 at 9:52 AM Lukas Märdian <slyon@ubuntu.com> wrote:
> >>
> >> Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
> >>> [...]
> >>>> We needed a version that does not contain the word "ubuntu", so it can be
> >>>> auto-synced, once the committed patch is uploaded into Debian. But at the same
> >>>> time we needed it to be bigger than the current version (1.0.1-3build2) and
> >>>> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We
> >>>> came up with the following:
> >
> > I found myself in a similar situation today, but not quite.
> >
> > I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
> > mismatch. Eventually the MIR[2] was approved, and I can now remove the
> > delta, but debian hasn't uploaded a new version yet. How to version
> > the ubuntu package and allow for auto-sync to sync it in the future?
> >
> > 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
> > kinetic upload without ubuntu in the version)
> >
> > I thought of:
> > a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> > subscribe to the tiff package in debian, and sync it manually the next
> > time there is a debian upload
> > b) use 4.4.0-5~build1
> > c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
> > we need another ubuntu upload *with* delta again, it gets messy
> > d) 4.4.0-4maysync1 is lower than the current one in kinetic
> >
> > I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
> > on the package on the debian side of things, but what do you think of
> > (b)?
> >
>
> Of course, as soon as you use 4.4.0-5~build1, debian will release 4.4.0-4.1 :)
>
> Marc.
>
> --
> ubuntu-devel mailing list
> ubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
On 2022-08-18 09:24, Andreas Hasenack wrote:
> Hi,
>
> On Wed, May 25, 2022 at 9:52 AM Lukas Märdian <slyon@ubuntu.com> wrote:
>>
>> Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
>>> [...]
>>>> We needed a version that does not contain the word "ubuntu", so it can be
>>>> auto-synced, once the committed patch is uploaded into Debian. But at the same
>>>> time we needed it to be bigger than the current version (1.0.1-3build2) and
>>>> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We
>>>> came up with the following:
>
> I found myself in a similar situation today, but not quite.
>
> I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
> mismatch. Eventually the MIR[2] was approved, and I can now remove the
> delta, but debian hasn't uploaded a new version yet. How to version
> the ubuntu package and allow for auto-sync to sync it in the future?
>
> 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
> kinetic upload without ubuntu in the version)
>
> I thought of:
> a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> subscribe to the tiff package in debian, and sync it manually the next
> time there is a debian upload
> b) use 4.4.0-5~build1
> c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
> we need another ubuntu upload *with* delta again, it gets messy
> d) 4.4.0-4maysync1 is lower than the current one in kinetic
>
> I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
> on the package on the debian side of things, but what do you think of
> (b)?
>
> Hi,
>
> On Wed, May 25, 2022 at 9:52 AM Lukas Märdian <slyon@ubuntu.com> wrote:
>>
>> Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
>>> [...]
>>>> We needed a version that does not contain the word "ubuntu", so it can be
>>>> auto-synced, once the committed patch is uploaded into Debian. But at the same
>>>> time we needed it to be bigger than the current version (1.0.1-3build2) and
>>>> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We
>>>> came up with the following:
>
> I found myself in a similar situation today, but not quite.
>
> I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
> mismatch. Eventually the MIR[2] was approved, and I can now remove the
> delta, but debian hasn't uploaded a new version yet. How to version
> the ubuntu package and allow for auto-sync to sync it in the future?
>
> 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
> kinetic upload without ubuntu in the version)
>
> I thought of:
> a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> subscribe to the tiff package in debian, and sync it manually the next
> time there is a debian upload
> b) use 4.4.0-5~build1
> c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
> we need another ubuntu upload *with* delta again, it gets messy
> d) 4.4.0-4maysync1 is lower than the current one in kinetic
>
> I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
> on the package on the debian side of things, but what do you think of
> (b)?
>
Of course, as soon as you use 4.4.0-5~build1, debian will release 4.4.0-4.1 :)
Marc.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
And I forgot the links:
1. https://launchpad.net/ubuntu/+source/tiff/4.4.0-4ubuntu1
2. https://bugs.launchpad.net/ubuntu/+source/lerc/+bug/1977551
On Thu, Aug 18, 2022 at 10:24 AM Andreas Hasenack <andreas@canonical.com> wrote:
>
> Hi,
>
> On Wed, May 25, 2022 at 9:52 AM Lukas Märdian <slyon@ubuntu.com> wrote:
> >
> > Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
> > > [...]
> > >> We needed a version that does not contain the word "ubuntu", so it can be
> > >> auto-synced, once the committed patch is uploaded into Debian. But at the same
> > >> time we needed it to be bigger than the current version (1.0.1-3build2) and
> > >> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We
> > >> came up with the following:
>
> I found myself in a similar situation today, but not quite.
>
> I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
> mismatch. Eventually the MIR[2] was approved, and I can now remove the
> delta, but debian hasn't uploaded a new version yet. How to version
> the ubuntu package and allow for auto-sync to sync it in the future?
>
> 4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
> kinetic upload without ubuntu in the version)
>
> I thought of:
> a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
> subscribe to the tiff package in debian, and sync it manually the next
> time there is a debian upload
> b) use 4.4.0-5~build1
> c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
> we need another ubuntu upload *with* delta again, it gets messy
> d) 4.4.0-4maysync1 is lower than the current one in kinetic
>
> I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
> on the package on the debian side of things, but what do you think of
> (b)?
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Version string to auto-sync an Ubuntu delta (maysync1 vs ~willsync1)
Hi,
On Wed, May 25, 2022 at 9:52 AM Lukas Märdian <slyon@ubuntu.com> wrote:
>
> Am 25.05.22 um 13:22 schrieb Marc Deslauriers:
> > [...]
> >> We needed a version that does not contain the word "ubuntu", so it can be
> >> auto-synced, once the committed patch is uploaded into Debian. But at the same
> >> time we needed it to be bigger than the current version (1.0.1-3build2) and
> >> wanted it to be smaller than a potential, future "1.0.1-3ubuntu1" version. We
> >> came up with the following:
I found myself in a similar situation today, but not quite.
I uploaded tiff 4.4.0-4ubuntu1[1] with a delta due to a component
mismatch. Eventually the MIR[2] was approved, and I can now remove the
delta, but debian hasn't uploaded a new version yet. How to version
the ubuntu package and allow for auto-sync to sync it in the future?
4.4.0-4 (debian) -> 4.4.0-4ubuntu1 (kinetic atm) -> 4.4.0-? (new
kinetic upload without ubuntu in the version)
I thought of:
a) bite the bullet. Upload 4.4.0-4ubuntu2 dropping the delta,
subscribe to the tiff package in debian, and sync it manually the next
time there is a debian upload
b) use 4.4.0-5~build1
c) 4.4.0-4willsync1 hits the problem discussed elsewhere here, that if
we need another ubuntu upload *with* delta again, it gets messy
d) 4.4.0-4maysync1 is lower than the current one in kinetic
I'm leaning towards (a) (4.4.0-4ubuntu2), I don't mind keeping an eye
on the package on the debian side of things, but what do you think of
(b)?
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Subscribe to:
Posts (Atom)