On Fri, Jun 13, 2025 at 1:06 PM Utkarsh Gupta
<utkarsh.gupta@canonical.com> wrote:
> Whilst at it, might I suggest the DMB terms to be 1 year with
> self-renew instead of 2 years? This will at least aid the volunteers
> in feeling less committed if they wish to apply at all.
FWIW, the memberships expire in 33 hours from now. :)
- u
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
On Wed, Jun 11, 2025 at 3:08 PM Robie Basak <robie.basak@ubuntu.com> wrote:
> > So something like a 2-year term a volunteer commits to. Perfectly fine
> > (not ideal) to step down at any point in time. And should ask TB to
> > run again when their membership is about to expire (like T-30 days or
> > something).
>
> To save on admin, would you consider it sufficient to use Launchpad's
> team membership expiry feature? We could set the term to two years in
> Launchpad, and allow members to self-renew with the usual explicit
> affirming action. If a member doesn't want to make a further two year
> commitment, they could then allow their Launchpad team membership to
> lapse with no further action. It'd be nice to communicate with the DMB
> and TB at the time, of course, but we don't have to make that a
> requirement.
That'd be good, yes. +1.
Whilst at it, might I suggest the DMB terms to be 1 year with
self-renew instead of 2 years? This will at least aid the volunteers
in feeling less committed if they wish to apply at all.
> I'd be happy to document what the TB and DMB take the team membership
> term, expiry and self-renewal to *mean* in a policy document - that
> would be a straightforward, bounded and one-off task.
Definitely. +1.
- u
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
So I wonder if it's worth continuing with elections at all? What if the
Technical Board were to just appoint DMB members as they felt
appropriate with a simple announcement, inviting prospective members to
apply to the TB directly?
On Mon, May 19, 2025 at 05:10:44PM +0000, Benjamin Drung wrote:
>Hi,
>
>I am a little late to the party.
Way later here :)
>On Tue, 2025-04-08 at 11:49 +0200, Christian Ehrhardt wrote:
>> On Tue, Apr 8, 2025 at 9:29 AM Julian Andres Klode
>> <julian.klode at canonical.com> wrote:
>> >
>> > On Wed, Apr 02, 2025 at 02:55:46PM +0100, Robie Basak wrote:
>> > > Some packages that are Ubuntu-only have `ubuntu` in the version string,
>> > > which automatically stops autosync, which is probably what we want.
>> > >
>> > > Other such Ubuntu-only packages do not, so if Debian were to package
>> > > something with the same source package name, it may autosync, which is
>> > > probably not what we want.
>> > >
>> > > Unless it's in the sync blocklist, but now there are three possible
>> > > states for an Ubuntu-only package to be with respect to autosync, which
>> > > is just unnecessary work for concerned reviewers.
>> > >
>> > > I just reviewed the following SRUs, which (sort of) uses a mix of both:
>> > >
>> > > lxd-installer | 1 | focal | source
>> > > lxd-installer | 1 | jammy | source
>> > > lxd-installer | 4 | noble | source
>> > > lxd-installer | 4ubuntu0.1 | noble-updates | source
>> > > lxd-installer | 4ubuntu0.2 | noble/unapproved/39f530b | source
>> > > lxd-installer | 8 | oracular | source
>> > > lxd-installer | 8.1 | oracular/unapproved/74f18e3 | source
>> > > lxd-installer | 12 | plucky | source
>> > >
>> > > Could we agree that all Ubuntu-only packages SHOULD always contain
>> > > `ubuntu` in their version string (this would usually be -0ubuntuX or
>> > > 0ubuntuX[1] if native) then, so that we don't have to think about it?
>> > >
>> > > Are there any reasons for an exception to this rule, where an autosync
>> > > would actually be desirable if Debian were to introduce such a package?
>> > > If it's not for a common reason, then perhaps an additional policy might
>> > > be that there SHOULD be something in debian/README.source that explains
>> > > any deviation from this.
>> >
>> > Funny enough I had that same conversation with Scott James Remnant many
>> > years ago on upstart, which had like 0.1.0-1 versions in Ubuntu at the
>> > time.
>> >
>> > I also had exactly the problem where it synced software-properties
>> > from Debian because it was not in the blocklist, and software-properties
>> > Debian packaging ended up weird (0.90debian1, possibly not an actual
>> > version number)
>> >
>> > But also this is going to get even weirder if we have a package we
>> > develop and start to use the ubuntu version string. Then my Debian
>> > version of foo 1ubuntu1 will end up 1ubuntu1debian1.
>> >
>> > Like I can guarantee you, someone will upload 1ubuntu2 with code
>> > changes and the Debian uploader will need to package that, rather
>> > than a 2ubuntu1.
>>
>> True and backed with a real story,
>> but I feel we should still strive to make the normal cases better and
>> consistent,
>> despite the existence of edge cases - WDYT?
>
>I read the full discussion and the current
>https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/VersionStrings.md
>
>I dislike adding `ubuntu0` to Ubuntu native packages because it is
>confusing. I have different alternatives to propose.
+1.
I was just reviewing this ubuntu-advantage-tools (pro client) merge
proposal and I realized a new `ubuntu0` suffix was added to the package
version after this discussion.
I understand this was done for the sake of complying with the proposal
in this thread, and more specifically, to Benjamin's reply. However, the
`0` after `ubuntu` seems to serve no purpose there. if we are releasing
version `36ubuntu0` and need to add a missing `Depends` to this native
package, we will bump the version to something like `36.1ubuntu0` and
never to `36ubuntu1`.
This new format seems to hinder automation for tools like `dch` to
automatically bump versions in changelogs.
>
>We could recommend avoiding native packages for Ubuntu-only packages.
>This makes it easier for Debian to adopt the package, makes versioning
>and backports simpler. For example I did this change for Apport and I do
>not regret it.
>
>Alternative ideas:
>
>1. Add `ubuntu` instead of `ubuntu0` as suffix to make it more obvious
>what is going on. I would less likely change `1ubuntu` into `1ubuntu1`
>than `1ubuntu0` into `1ubuntu1` (taking the example from Julian).
I like this proposal since it could be adopted/tested without disrupting
the current versioning models of our existing native packages.
>
>2. Use `0ubuntu[version]` instead of `[version]ubuntu0`.
>
>--
>Benjamin Drung
>Debian & Ubuntu Developer
>
--
Athos Ribeiro
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
On Tue, Jun 10, 2025 at 4:28 PM Simon Chopin <schopin@ubuntu.com> wrote:
> For the sake of clarity: appointments should still have clearly defined
> durations and existing members should explicitly reapply.
That's fair. And also what I had in mind especially when LP membership
(currently at least) is expiry based.
So something like a 2-year term a volunteer commits to. Perfectly fine
(not ideal) to step down at any point in time. And should ask TB to
run again when their membership is about to expire (like T-30 days or
something).
> A common risk in FOSS communities is one of volunteers burning out.
> Having periodic checkpoints where one must explicitly assess whether
> they still have the time and energy to serve is fairly healthy.
Definitely. Agreed.
> Case in point: I'm not running again, but I don't think I could have
> ever explicitly quit.
Well, you could've communicated to us regardless. ;)
Anyway, thank you for serving your time in DMB. Hope you can step up
again in the future.
- u
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
On lun. 09 juin 2025 12:25:54, Utkarsh Gupta wrote:
[snip]
> > So I wonder if it's worth continuing with elections at all? What if the
> > Technical Board were to just appoint DMB members as they felt
> > appropriate with a simple announcement, inviting prospective members to
> > apply to the TB directly?
>
> That makes a whole lot of sense, honestly. Unless doing poorly, those
> in DMB should be able to continue serving the board till they'd like -
> I see no reason why we should remove them especially when we don't
> have more volunteers to replace them with, as we've all noted this
> time and also many times in the past.
>
> I think the Techboard should delegate DMB and could/should rotate the
> seats however they see fit.
For the sake of clarity: appointments should still have clearly defined
durations and existing members should explicitly reapply.
A common risk in FOSS communities is one of volunteers burning out.
Having periodic checkpoints where one must explicitly assess whether
they still have the time and energy to serve is fairly healthy.
Case in point: I'm not running again, but I don't think I could have
ever explicitly quit.
Cheers,
Simon
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel