Re: Ubuntu Backports charter
On Tue, Mar 22, 2022 at 4:27 PM Robie Basak wrote:
>
> On Tue, Mar 22, 2022 at 04:10:38PM -0400, Dan Streetman wrote:
> > The team has had previous discussions around governance, yes, and of
> > course those discussions played a part in forming this document. I
> > don't really know what exactly you mean by any/all discussions being
> > 'incorporated' into the document?
>
> For example, I had suggested the text "Any review process must accept or
> reject every backport request on its technical merit, and be neutral to
> who is requesting it" with a footnote that explained the rationale as
> "the process must avoid the current situation where only privileged
> people can get their uploads reviewed, and everyone else is blocked"
>
> ("current" there is now, I believe, "past")
>
> However the equivalent text you have now only says "The mission of the
> Ubuntu Backporters Team is to maintain the backports pocket of all
> stable Ubuntu releases." with no mention of that.
>
> In fact that's the case for basically everything I proposed previously.
>
> Is this deliberate? Would you consider replacing your "Mission
> Statement" with the text I suggested previously?
I don't think so, no.
> And if not, why not?
Because your statements aren't a mission, they are policy; and your
statements are not objective. For example, "all requests receive an
appropriate answer in a reasonable amount of time" is not at all
objective and so has no actual meaning in a charter.
>
> > > IMHO it's best if each team - including the backporters team - decides
> > > for themselves how they want to operate, and are free to change things
> > > as and when they want. To that extent, if the backporters team wants
> > > have a detailed document like the one you have written, then that's
> > > absolutely fine.
> > >
> > > But why are you looking for the TB to "ratify" it
> >
> > So that the powers delegated to the team are explicitly stated...
>
> I agree that this part makes sense.
>
> > that the "main" rules are also explicitly stated (with "main" being
> > subjective, and decided by our team).
>
> Why do you want this to be part of the TB's ratification?
Because it's completely unclear what powers/policies/rules the TB
reserves for itself.
>
> > > and lock in the
> > > requirement that the TB must approve any changes? For example, you've
> > > said "This charter, and any changes to it, must be approved by the TB
> > > before taking effect" but also you've got minutiae in there such as
> > > which IRC channel is used and on what network. Won't causing the TB to
> > > "lock this in" be excessively beaurocratic? And what if you need a minor
> > > change? Are you expecting to go to the TB every time? Won't that be
> > > impractical?
> >
> > Sorry, these questions seem subjective and rhetorical - I'm not sure
> > if you intend for our team to answer them? Do they need to be answered
> > for the TB to review and/or ratify this charter?
>
> I don't think the questions are rhetorical. I do think they need
> answering because if unanswered then I don't understand why it's within
> scope for the TB to consider ratifying these details at all.
>
> Summary:
>
> 1) Details of team responsibilities and "powers delegated to the team"
> make sense for the TB to ratify.
>
> 2) Details of how the team carries out their responsibilities seem like
> matters for the team to manage themselves and I currently don't see why
> they're any business of the TB unless some kind of conflict or other
> problem arises (and I don't know of any). I invite further discussion
> and argument to why they should be within the scope of the TB today, but
> in the absence of any explanation or argument, I'm inclined to consider
> this part out of scope and therefore (wearing my TB hat) decline to get
> involved.
There is no section called "team responsibilities" nor "powers
delegated to the team" so I'm not 100% clear on what you *do* think
the TB needs to ratify, vs. what you *do not* think the TB should be
involved in...can you clarify?
Any sections that you feel should be removed from the Charter (i.e.
moved into the team official policies document:
https://wiki.ubuntu.com/UbuntuBackports/Policies), please let me know.
Assuming you are speaking for the TB, of course.
>
> Robie
--
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: Ubuntu Backports charter
On Tue, Mar 22, 2022 at 04:10:38PM -0400, Dan Streetman wrote:
> The team has had previous discussions around governance, yes, and of
> course those discussions played a part in forming this document. I
> don't really know what exactly you mean by any/all discussions being
> 'incorporated' into the document?
For example, I had suggested the text "Any review process must accept or
reject every backport request on its technical merit, and be neutral to
who is requesting it" with a footnote that explained the rationale as
"the process must avoid the current situation where only privileged
people can get their uploads reviewed, and everyone else is blocked"
("current" there is now, I believe, "past")
However the equivalent text you have now only says "The mission of the
Ubuntu Backporters Team is to maintain the backports pocket of all
stable Ubuntu releases." with no mention of that.
In fact that's the case for basically everything I proposed previously.
Is this deliberate? Would you consider replacing your "Mission
Statement" with the text I suggested previously? And if not, why not?
> > IMHO it's best if each team - including the backporters team - decides
> > for themselves how they want to operate, and are free to change things
> > as and when they want. To that extent, if the backporters team wants
> > have a detailed document like the one you have written, then that's
> > absolutely fine.
> >
> > But why are you looking for the TB to "ratify" it
>
> So that the powers delegated to the team are explicitly stated...
I agree that this part makes sense.
> that the "main" rules are also explicitly stated (with "main" being
> subjective, and decided by our team).
Why do you want this to be part of the TB's ratification?
> > and lock in the
> > requirement that the TB must approve any changes? For example, you've
> > said "This charter, and any changes to it, must be approved by the TB
> > before taking effect" but also you've got minutiae in there such as
> > which IRC channel is used and on what network. Won't causing the TB to
> > "lock this in" be excessively beaurocratic? And what if you need a minor
> > change? Are you expecting to go to the TB every time? Won't that be
> > impractical?
>
> Sorry, these questions seem subjective and rhetorical - I'm not sure
> if you intend for our team to answer them? Do they need to be answered
> for the TB to review and/or ratify this charter?
I don't think the questions are rhetorical. I do think they need
answering because if unanswered then I don't understand why it's within
scope for the TB to consider ratifying these details at all.
Summary:
1) Details of team responsibilities and "powers delegated to the team"
make sense for the TB to ratify.
2) Details of how the team carries out their responsibilities seem like
matters for the team to manage themselves and I currently don't see why
they're any business of the TB unless some kind of conflict or other
problem arises (and I don't know of any). I invite further discussion
and argument to why they should be within the scope of the TB today, but
in the absence of any explanation or argument, I'm inclined to consider
this part out of scope and therefore (wearing my TB hat) decline to get
involved.
Robie
signature.asc
Description: PGP signature
--
ubuntu-backports mailing list
ubuntu-backports@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: Ubuntu Backports charter
On Tue, Mar 22, 2022 at 3:34 PM Robie Basak wrote: > > On Mon, Mar 21, 2022 at 12:44:43PM -0400, Dan Streetman wrote: > > I see this charter as the one and only official document (except where > > the charter specifically delegates to other document(s)) for guiding > > what the team does and how the team does it. It supersedes any > > previous discussion. Is that what you are asking? > > I'm asking to what extent you consider the previous discussion to have > been incorporated into your current document, if at all. The team has had previous discussions around governance, yes, and of course those discussions played a part in forming this document. I don't really know what exactly you mean by any/all discussions being 'incorporated' into the document? > > IMHO it's best if each team - including the backporters team - decides > for themselves how they want to operate, and are free to change things > as and when they want. To that extent, if the backporters team wants > have a detailed document like the one you have written, then that's > absolutely fine. > > But why are you looking for the TB to "ratify" it So that the powers delegated to the team are explicitly stated and so that the "main" rules are also explicitly stated (with "main" being subjective, and decided by our team). > and lock in the > requirement that the TB must approve any changes? For example, you've > said "This charter, and any changes to it, must be approved by the TB > before taking effect" but also you've got minutiae in there such as > which IRC channel is used and on what network. Won't causing the TB to > "lock this in" be excessively beaurocratic? And what if you need a minor > change? Are you expecting to go to the TB every time? Won't that be > impractical? Sorry, these questions seem subjective and rhetorical - I'm not sure if you intend for our team to answer them? Do they need to be answered for the TB to review and/or ratify this charter? > > In case it's not clear, I think what you're proposing is rather > different from my suggestion. I was focusing on the team > responsibilities only - very deliberately leaving *how* the team might > choose to fulfil those responsibilities out of it. > > Robie -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: Ubuntu Backports charter
On Mon, Mar 21, 2022 at 12:44:43PM -0400, Dan Streetman wrote: > I see this charter as the one and only official document (except where > the charter specifically delegates to other document(s)) for guiding > what the team does and how the team does it. It supersedes any > previous discussion. Is that what you are asking? I'm asking to what extent you consider the previous discussion to have been incorporated into your current document, if at all. IMHO it's best if each team - including the backporters team - decides for themselves how they want to operate, and are free to change things as and when they want. To that extent, if the backporters team wants have a detailed document like the one you have written, then that's absolutely fine. But why are you looking for the TB to "ratify" it and lock in the requirement that the TB must approve any changes? For example, you've said "This charter, and any changes to it, must be approved by the TB before taking effect" but also you've got minutiae in there such as which IRC channel is used and on what network. Won't causing the TB to "lock this in" be excessively beaurocratic? And what if you need a minor change? Are you expecting to go to the TB every time? Won't that be impractical? In case it's not clear, I think what you're proposing is rather different from my suggestion. I was focusing on the team responsibilities only - very deliberately leaving *how* the team might choose to fulfil those responsibilities out of it. Robie signature.asc Description: PGP signature -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1965800] Re: debhelper in focal-backports not usable for i386 package building (missing dependency)
archive admins dont think i386ing the RPM source is a good idea based on my brief discussiom in #ubuntu-release debugedit has splitsource in later versions, perhaps a split-source is needed here. However I would suggest we defer to archive admins for best approach here -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1965800 Title: debhelper in focal-backports not usable for i386 package building (missing dependency) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: [Bug 1965800] Re: debhelper in focal-backports not usable for i386 package building (missing dependency)
So it would need 2 addition to the i386 whitelist. Feel free to bring an archive administrator in the loop, I think it's only them who have the power to do that (if we want to go through that route). Except that I just realized that rpm (and debugedit) in focal are in universe. So it would also need a MIR, which is definitely not happening for a stable release. I also guess that's the reason debugedit was split off rpm. So I suppose we either need to check whether backporting debugedit would make it build on i386, or revert that change in debhelper. On Tue, 22 Mar 2022, 1:31 pm David Ward, <1965...@bugs.launchpad.net> wrote: > I am able to build src:rpm for focal i386 using pbuilder, as long as > p7zip-full:i386 is built first. > > -- > You received this bug notification because you are a member of Ubuntu > Backporters, which is subscribed to the bug report. > https://bugs.launchpad.net/bugs/1965800 > > Title: > debhelper in focal-backports not usable for i386 package building > (missing dependency) > > To manage notifications about this bug go to: > > https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800/+subscriptions > > > -- > ubuntu-backports mailing list > ubuntu-backports@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports > -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1965800 Title: debhelper in focal-backports not usable for i386 package building (missing dependency) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1965800] Re: debhelper in focal-backports not usable for i386 package building (missing dependency)
I am able to build src:rpm for focal i386 using pbuilder, as long as p7zip-full:i386 is built first. -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1965800 Title: debhelper in focal-backports not usable for i386 package building (missing dependency) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1965800] Re: debhelper in focal-backports not usable for i386 package building (missing dependency)
I think we have three choices here: 1. revert Matthias' change from debhelper/13.3.4ubuntu1 (2021-03-19) that make use of debugedit (honestly I don't even understand *why* he did that) 2. backport debugedit too (honestly I don't remember if that would be enough to make it build on i386, however, or it also needs an addition to the i386 whitelist) 3. get the archive admins to add src:rpm in the i386 whitelist, and rebuild it (if that's enough to make it build and doesn't require more). I'd be for option 1 here. comments welcome. -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1965800 Title: debhelper in focal-backports not usable for i386 package building (missing dependency) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debhelper/+bug/1965800/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1965855] Re: p7zip source package needs "Multiarch: foreign" in debian/control
that's hardly the reason that debhelper/focal-backports is uninstallable on i386. Remember that Multi-Arch fields are used for multi-arch installations, that are irrelevant for things like native builds, and are totally unused in buildds and such. ** Changed in: p7zip (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1965855 Title: p7zip source package needs "Multiarch: foreign" in debian/control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/p7zip/+bug/1965855/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
[Bug 1965855] Re: p7zip source package needs "Multiarch: foreign" in debian/control
** Changed in: p7zip (Debian) Status: Unknown => Fix Released -- You received this bug notification because you are a member of Ubuntu Backporters, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/1965855 Title: p7zip source package needs "Multiarch: foreign" in debian/control To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/p7zip/+bug/1965855/+subscriptions -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
