Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #12964 > unrolled thread

Multi-package projects

Back to article view | Back to linux.debian.project

Contents

  Multi-package projects Wouter Verhelst <wouter@debian.org> - 2022-10-07 13:50 +0200
    Re: Multi-package projects Ansgar <ansgar@43-1.org> - 2022-10-07 14:20 +0200
    Re: Multi-package projects Timo Röhling <roehling@debian.org> - 2022-10-07 14:30 +0200
      Re: Multi-package projects Ansgar <ansgar@43-1.org> - 2022-10-07 15:00 +0200
        Re: Multi-package projects Wouter Verhelst <wouter@debian.org> - 2022-10-07 20:40 +0200
      Re: Multi-package projects Wouter Verhelst <wouter@debian.org> - 2022-10-07 20:10 +0200
        Re: Multi-package projects Timo Röhling <roehling@debian.org> - 2022-10-07 21:20 +0200
          Re: Multi-package projects Wouter Verhelst <wouter@debian.org> - 2022-10-08 12:20 +0200
    Re: Multi-package projects Luca Boccassi <bluca@debian.org> - 2022-10-07 19:00 +0200
      Re: Multi-package projects Sam Hartman <hartmans@debian.org> - 2022-10-07 19:50 +0200
        Re: Multi-package projects Niels Thykier <niels@thykier.net> - 2022-10-08 09:10 +0200
          Re: Multi-package projects Niels Thykier <niels@thykier.net> - 2022-10-08 12:20 +0200
            Re: Multi-package projects Sam Hartman <hartmans@debian.org> - 2022-10-13 17:50 +0200
              Re: Multi-package projects Niels Thykier <niels@thykier.net> - 2022-10-13 18:30 +0200
          Re: Multi-package projects Wouter Verhelst <wouter@debian.org> - 2022-10-08 12:20 +0200
      Re: Multi-package projects Wouter Verhelst <wouter@debian.org> - 2022-10-07 20:00 +0200
    Re: Multi-package projects Niels Thykier <niels@thykier.net> - 2022-10-08 09:10 +0200

#12964 — Multi-package projects

Hi,

Debian does not have a good way to manage projects that require changes
to large numbers of source packages to be successful. Handling projects
like that currently requires buy-in from each individual package
maintainer; if the project does not manage to convince sufficient
numbers of maintainers, it is liable to fail.

This problem is bad enough when it is a noncontroversial project, but
gets worse when the project is controversial; some people will oppose
the project on principle because they believe it will not improve
Debian, which will result in effectively a mess of half-baked solutions
that can't really be used.

I've given this some thought over the past few days, and have come up
with something that I believe might work, and I would like to submit it
as a proposal to see what others think. I want to clarify that it was
not created with a specific multi-package project in mind, although I
will give some examples. Additionally, the proposal foresees a pretty
big role for the release team. I haven't discussed this with them (or
anyone else, for that matter), and so it might be that a new team will
have to be created if the release team thinks this won't be for them;
but I do think they would be the best fit (they would have to coordinate
with this proposed new team at any rate, anyway), so I'll not muddle the
waters by using wording like "the release team, or any other team that
would take up this role". Just imagine I did though ;-)

On to it:

- Any team of persons who would like to propose a project that requires
  changes to multiple packages will make, at the beginning of the
  release cycle, a proposal to the release team that outlines the
  proposed goals and scope of the project. (e.g., "SE Linux
  configuration for all daemons in the archive")
- The release team will make sure that interested parties are made aware
  of the proposed new projects, so that they can object/chime
  in/join/whatever. (e.g., send a d-d-a mail)
- After the merits and problems of the proposed new projects are
  discussed, the release team decides which projects are accepted for
  the next release.
  (I specifically do not mention what rules the release team should
  follow in deciding which projects to accept -- I trust their
  judgement)
- Accepted projects get the following:
  - A mailing list and a pseudo-package in the BTS to coordinate efforts
  - Relaxed NMU rules
    (People working on the project should *not* NMU at will; they are
    still expected to work with maintainers, who may request things like
    changes to proposed patches, short delays so that it won't conflict
    with other work the maintainer is doing on the package, and/or
    additional work, such as autopkgtests. However, in the absense of
    reasonable package maintainer objections, NMUs should be done at low
    threshold)
- At the beginning of the release cycle, the release team will also set
  a date at which point the currently-active multi-package projects are
  evaluated. This date is expected to be near the end of the release
  cycle.
- During the release cycle, the team driving the project is expected to
  submit patches to source packages where and as necessary, and to
  follow up on bug reports that are assigned to their pseudo-package.
- During the release cycle, people *not* driving the project are
  expected to apply patches speedily, in the spirit of collaboration.
  They are *not* expected to work on the project (although they are of
  course welcome to if they want to); any bugs that are filed that are
  related to the changes made by the multi-package project may be
  promptly reassigned to the project's pseudo-package and/or set to a
  non-RC severity. The team driving the project may *not* reassign the
  bug back to the package without either a patch that fixes the bug, or
  an explanation of why the bug is a bug in the code that is not related
  to the multi-package project (with the onus of proof here lying on the
  project).
- During the release cycle, the release team is may do things like keep
  an eye on the progress of the various projects and guide the teams
  driving them as to things they consider critical when the 
- When the date that was decided upon by the release team has arrived,
  multi-package projects will be evaluated, and each will be placed in
  one of the following four categories:
  - Succeeded: the project is complete, no further work is required for
    it. The pseudo-package will be closed, any bugs still assigned to it
    will be reassigned back to the relevant source package, and the
    maintainers of these packages will from now on be responsible for
    maintaining the required changes (this might be appropriate for a
    project that desires a change in how we do things, but that has no
    further work once the change has been done, such as, e.g., the
    usrmerge project could have been)
  - Failed: the project failed to reach its goals, and it is unlikely
    that it will ever do so. Any code in packages relevant to the
    project may be immediately removed by their maintainers before the
    release (there should be a sufficient amount of time for maintainers
    to do so before the freeze), whether it is functional or not.
  - Postponed: the project failed to reach all of its goals, but it is
    likely they might be able to do so in the next release cycle.
    Maintainers *may* remove code relevant to this project before the
    next release with the same rules as projects in the "failed"
    category, but the project will probably be back next release, so it
    is likely they'll have to add that code back by that time.
  - Maintained: the project reached it goals, and will be active in the
    next release. Outstanding patches (if any) should be fixed and/or
    applied ASAP; failure to apply such patches will become RC for the
    relevant source package. However, the project is not finished, and
    the pseudo-package will not be closed; further bugs that are
    relevant only to the given project may still be assigned to the
    pseudo-package, during this release cycle or future ones.
    Maintainers of the project are expected to continue to provide
    assistance to maintainers, and future evaluations of multi-package
    projects for future releases may reclassify the project as "failed"
    or "postponed" should it fall back in keeping up with maintainer
    requests (this classification might be appropriate for projects that
    require significant domain-specific knowledge, such as a "SE Linux
    configuration for all daemons" project, or that require testing on
    non-default installations, such as a "add support back for sysvinit"
    project).

The goal of this proposal is to attempt to balance the (sometimes
conflicting) interests of multiple parties:

- Package maintainers who are not interested in a project should not
  have to work on it (they can just reassign bugs and forget about
  them);
- Developers who are interested in a project should not be stymied by
  having to convince each and every individual developer of the merits
  of their proposal (they have to convince the project at large before
  they can get started, but once that's happened the project is active
  and maintainers are expected to apply reasonable patches); they get a
  chance to complete their project, but there is a clear "success or
  bust" cut-off point;
- Projects that will require ongoing maintenance will be maintained by
  the people who care about it; should these people disappear, there
  will again be a clear "success or bust" cut-off point after which the
  relevant code can be immediately removed.

Does any of that make sense?

Thanks,

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

[toc] | [next] | [standalone]

#12965

On Fri, 2022-10-07 at 13:37 +0200, Wouter Verhelst wrote:
> - After the merits and problems of the proposed new projects are
>   discussed, the release team decides which projects are accepted for
>   the next release.
>   (I specifically do not mention what rules the release team should
>   follow in deciding which projects to accept -- I trust their
>   judgement)

This sounds like you propose to create some sort of technical steering
committee which probably should not be required to be identical with
the release team.

But as a practical example: some people have suggested packages not
shipping configuration files in /etc (including, for example, init
scripts in /etc/init.d). As far as I understand some people even say it
is Debian's core mission to support such new configurations to give
more freedom to users.

How would this work and reduce conflicts with your proposal? Would it
be okay for people driving this change to, for example, just drop
/etc/init.d scripts? People caring about them could make software look
for them in /usr/lib/init.d or such reducing various problems with
removed-but-not-purged packages. Or would the people interested in
shipping less configuration files have to implement this for non-
standard init systems whose usage is explored as an experiment in
Debian?

Some people probably also want to continue to ship configuration files
as Debian does now. Should we require this to be user-configurable? Who
would be required to maintain maintainer scripts to support both
configurations? The group wanting to keep the old configuration or the
group wanting to support the new configuration? What if some people
don't want this user-configurable (hmm, make user-configurability user-
configurable?)?

Or should be release team just decide all of this and everyone will
accept this? I don't think that would work from past experience...

Ansgar

[toc] | [prev] | [next] | [standalone]

#12966

[Multipart message — attachments visible in raw view] — view raw

Hi Wouter,

* Wouter Verhelst <wouter@debian.org> [2022-10-07 13:37]:
>I've given this some thought over the past few days, and have come up
>with something that I believe might work, and I would like to submit it
>as a proposal to see what others think.
Great idea, thank you for your thoughts!
It reminds me of the Debian Enhancement Proposals [1], which aim to
solve a similar problem.

I have only one remark at this point: By definition, a project has a
limited scope and time frame, so at some point it has to end. For
things like /usr-merge, or any other transition, this is a good fit.

Adding features to Debian which require permanent additional
maintenance is more akin to supporting a release architecture. The
associated project would be the "incubation phase" where said
feature gets introduced and its viability proven, and one success
criterion would have to be the formation of a team that commits to
the required maintenance work for the future. Similar to the release
architectures, features should be evaluated at release time and
discontinued if the team can no longer provide the required support.


Cheers
Timo


[1] https://dep-team.pages.debian.net/

-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#12967

On Fri, 2022-10-07 at 14:21 +0200, Timo Röhling wrote:
> * Wouter Verhelst <wouter@debian.org> [2022-10-07 13:37]:
> > I've given this some thought over the past few days, and have come
> > up
> > with something that I believe might work, and I would like to
> > submit it
> > as a proposal to see what others think.
> Great idea, thank you for your thoughts!
> It reminds me of the Debian Enhancement Proposals [1], which aim to
> solve a similar problem.
> 
> I have only one remark at this point: By definition, a project has a
> limited scope and time frame, so at some point it has to end. For
> things like /usr-merge, or any other transition, this is a good fit.

I think we did try something similar for usrmerge already: the tech-
ctte was asked about the switch to the new filesystem for new
installations, making the new layout the only supported layout in the
future and migration of existing systems.

The proposal adds a few more bits reminding me of old concept of
release goals (which Debian dropped), but I'm not seeing how it would
avoid the problems we had (or have) with systemd or usrmerge. It hides
a lot of conflict behind this simple statement:

| - After the merits and problems of the proposed new projects are
|   discussed, the release team decides which projects are accepted for
|   the next release.
|   (I specifically do not mention what rules the release team should
|   follow in deciding which projects to accept -- I trust their
|   judgement)

and assuming everyone will then accept this decision.

Ansgar

[toc] | [prev] | [next] | [standalone]

#12973

Hi Ansgar,

On Fri, Oct 07, 2022 at 02:07:55PM +0200, Ansgar wrote:
> On Fri, 2022-10-07 at 13:37 +0200, Wouter Verhelst wrote:
> > - After the merits and problems of the proposed new projects are
> >   discussed, the release team decides which projects are accepted for
> >   the next release.
> >   (I specifically do not mention what rules the release team should
> >   follow in deciding which projects to accept -- I trust their
> >   judgement)
> 
> This sounds like you propose to create some sort of technical steering
> committee which probably should not be required to be identical with
> the release team.

Not really; we already have a technical committee, there is no need to
create another one.

> But as a practical example: some people have suggested packages not
> shipping configuration files in /etc (including, for example, init
> scripts in /etc/init.d). As far as I understand some people even say it
> is Debian's core mission to support such new configurations to give
> more freedom to users.
> 
> How would this work and reduce conflicts with your proposal? Would it
> be okay for people driving this change to, for example, just drop
> /etc/init.d scripts?
[...]

My proposal would indeed not work if there are multiple projects that
want to make conflicting changes (i.e., one team that wants to remove
all files from /etc, and one team that wants to add init scripts where
necessary, which would by necessity be in /etc). I would expect the
release team in this proposal to make sure that no such conflicting
projects are accepted at the same time (or at least, for them to attempt
to do so).

On Fri, Oct 07, 2022 at 02:36:13PM +0200, Ansgar wrote:
> The proposal adds a few more bits reminding me of old concept of
> release goals (which Debian dropped),

Yes, I can see that. However, there are a few crucial differences.

Release goals were just "project wide goals that the release team thinks
are a good idea". If a vocal minority objects to the goal, then they can
veto it, at least for their own packages.

The idea here is to add ways to work around such an inactivity veto.

> but I'm not seeing how it would
> avoid the problems we had (or have) with systemd or usrmerge.

> It hides
> a lot of conflict behind this simple statement:
> 
> | - After the merits and problems of the proposed new projects are
> |   discussed, the release team decides which projects are accepted for
> |   the next release.
> |   (I specifically do not mention what rules the release team should
> |   follow in deciding which projects to accept -- I trust their
> |   judgement)
> 
> and assuming everyone will then accept this decision.

It makes no such assumption; instead, it assumes that there will indeed
be people who oppose it, but that the project can still reach completion
even in the face of such opposition.

There are multiple ways in which Debian-wide projects fail:

- There will always be a group of developers who procrastinate on
  implementing the required changes. This proposal makes it explicit
  that the drivers of the project are expected to write the necessary
  patches, and are allowed to NMU those patches given inaction by other
  developers, so that procrastination cannot be the reason why the
  necessary updates are not performed (unless it is procrastination on
  the part of the project's drivers, but, well...).
- There are often some developers who prefer not to accept a given
  patch, because they don't want to be responsible for maintaining the
  offered code going forward. This proposal makes it explicit that the
  drivers of the project remain responsible for the necessary code, even
  after it has succeeded, and that it can be removed from packages with
  immediate effect should the project no longer have the necessary man
  power to keep up. This should (hopefully) mitigate that effect
  somewhat.
- And yes, there is often (or perhaps I should say, "usually") a group
  of people who think the whole idea is a bad idea to begin with, and
  that Debian shouldn't implement this bad idea at all. These people
  will refuse actively to accept the given patches, not for any of the
  other two reasons I mentioned, but because they would rather that the
  project fail. If the number of developers who feel this way is large
  enough, then the project will likely fail to meet the release team's
  standard of completeness when the project is evaluated. At this point,
  the opposition will have "won", and the project-specific code can be
  removed from the project. Alternatively, however (and what I consider
  more likely), the vocal group of people who decided not to accept
  these patches will turn out to be a small minority, the release team
  will evaluate that the project has succeeded, and suddenly these
  patches turn into RC bugs, meaning they will either be accepted
  anyway, or the package in question will be removed from the archive --
  either way, the proponents have "won", and the feature is available.

Perhaps my gut feeling that the third group of blockers are usually a
small (but vocal) minority is wrong, and this won't work at all. Perhaps
my gut feeling that the other two groups are much more commonly a reason
why a project isn't succeeding is also wrong, and then this also won't
work at all. But I think I'm not wrong, and therefore that it will work.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

[toc] | [prev] | [next] | [standalone]

#12972

On Fri, Oct 07, 2022 at 02:21:04PM +0200, Timo Röhling wrote:
> Hi Wouter,
> 
> * Wouter Verhelst <wouter@debian.org> [2022-10-07 13:37]:
> > I've given this some thought over the past few days, and have come up
> > with something that I believe might work, and I would like to submit it
> > as a proposal to see what others think.
> Great idea, thank you for your thoughts!
> It reminds me of the Debian Enhancement Proposals [1], which aim to
> solve a similar problem.

I'm not sure I agree with that assessment. I believe DEPs are mostly for
discussing changes that can then be voluntarily implemented by
individual package maintainers; whereas this is intended to allow those
who want the change to actually do the work for that change more easily,
which DEPs don't do. Perhaps I'm missing something?

> I have only one remark at this point: By definition, a project has a
> limited scope and time frame, so at some point it has to end. For
> things like /usr-merge, or any other transition, this is a good fit.

That's debatable, as the phrase "the Debian project" shows, but sure, I
guess we can rename things after the first release cycle if we think
it matters.

> Adding features to Debian which require permanent additional
> maintenance is more akin to supporting a release architecture. The
> associated project would be the "incubation phase" where said
> feature gets introduced and its viability proven, and one success
> criterion would have to be the formation of a team that commits to
> the required maintenance work for the future. Similar to the release
> architectures, features should be evaluated at release time and
> discontinued if the team can no longer provide the required support.

You may have missed it, but my proposal already contained a similar
suggestion:

> >  - Maintained: the project reached it goals, and will be active in the
> >    next release. Outstanding patches (if any) should be fixed and/or
> >    applied ASAP; failure to apply such patches will become RC for the
> >    relevant source package. However, the project is not finished, and
> >    the pseudo-package will not be closed; further bugs that are
> >    relevant only to the given project may still be assigned to the
> >    pseudo-package, during this release cycle or future ones.
> >    Maintainers of the project are expected to continue to provide
> >    assistance to maintainers, and future evaluations of multi-package
> >    projects for future releases may reclassify the project as "failed"
> >    or "postponed" should it fall back in keeping up with maintainer
> >    requests (this classification might be appropriate for projects that
> >    require significant domain-specific knowledge, such as a "SE Linux
> >    configuration for all daemons" project, or that require testing on
> >    non-default installations, such as a "add support back for sysvinit"
> >    project).

Yes, it absolutely makes sense to re-evaluate such projects for each
release cycle; and if the support from the drivers of this feature is no
longer available, then it should definitely be removed.

I suggested that it be evaluated together with other such features, at
the point where it is obvious whether or not such features are being
maintained; but I suppose that evaluating them together with the
viability of release architectures rather than with other similar
projects might work too. What matters is not *when*, but *that* it
happens.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

[toc] | [prev] | [next] | [standalone]

#12974

[Multipart message — attachments visible in raw view] — view raw

* Wouter Verhelst <wouter@debian.org> [2022-10-07 19:58]:
>I'm not sure I agree with that assessment. I believe DEPs are mostly for
>discussing changes that can then be voluntarily implemented by
>individual package maintainers; whereas this is intended to allow those
>who want the change to actually do the work for that change more easily,
>which DEPs don't do. Perhaps I'm missing something?
I'm not that much of an expert in DEP scope either, but what they do
share with your proposal is an associated state like your
Accepted/Succeded/Failed/Postponed/Maintained.

>> I have only one remark at this point: By definition, a project has a
>> limited scope and time frame, so at some point it has to end. For
>> things like /usr-merge, or any other transition, this is a good fit.
>That's debatable, as the phrase "the Debian project" shows, but sure, I
>guess we can rename things after the first release cycle if we think
>it matters.
I knew you would bring up the "Debian Project" :)

>You may have missed it, but my proposal already contained a similar
>suggestion:

I didn't miss it, but I think it should be a separate thing after
the intial project has finished successfully, for psychological
reasons: such a project will often be something experimental at
first, and I also believe we should not be afraid to terminate
projects which do not work out, if only to avoid endless
frustration.

But at some point, a project is no longer experimental, it becomes a
part of Debian proper. It may sound like pedantry on my part, but I
think it is a huge motivational boost to see your project "graduate"
to something new and shiny, even if it does not make much of a
difference in the daily workload.

The Eclipse Foundation does something similar, they start with
incubator projects, and once those have matured enough, they become
"real" Eclipse projects.


Cheers
Timo

-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#12980

On Fri, Oct 07, 2022 at 09:13:56PM +0200, Timo Röhling wrote:
> * Wouter Verhelst <wouter@debian.org> [2022-10-07 19:58]:
> > I'm not sure I agree with that assessment. I believe DEPs are mostly for
> > discussing changes that can then be voluntarily implemented by
> > individual package maintainers; whereas this is intended to allow those
> > who want the change to actually do the work for that change more easily,
> > which DEPs don't do. Perhaps I'm missing something?
> I'm not that much of an expert in DEP scope either, but what they do
> share with your proposal is an associated state like your
> Accepted/Succeded/Failed/Postponed/Maintained.
> 
> > > I have only one remark at this point: By definition, a project has a
> > > limited scope and time frame, so at some point it has to end. For
> > > things like /usr-merge, or any other transition, this is a good fit.
> > That's debatable, as the phrase "the Debian project" shows, but sure, I
> > guess we can rename things after the first release cycle if we think
> > it matters.
> I knew you would bring up the "Debian Project" :)
> 
> > You may have missed it, but my proposal already contained a similar
> > suggestion:
> 
> I didn't miss it, but I think it should be a separate thing after
> the intial project has finished successfully, for psychological
> reasons: such a project will often be something experimental at
> first, and I also believe we should not be afraid to terminate
> projects which do not work out, if only to avoid endless
> frustration.
> 
> But at some point, a project is no longer experimental, it becomes a
> part of Debian proper. It may sound like pedantry on my part, but I
> think it is a huge motivational boost to see your project "graduate"
> to something new and shiny, even if it does not make much of a
> difference in the daily workload.
> 
> The Eclipse Foundation does something similar, they start with
> incubator projects, and once those have matured enough, they become
> "real" Eclipse projects.

Ah, yes. I hadn't thought of that, but your suggestion makes sense in
that light. Thanks.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

[toc] | [prev] | [next] | [standalone]

#12969

[Multipart message — attachments visible in raw view] — view raw

> - After the merits and problems of the proposed new projects are
>   discussed, the release team decides which projects are accepted for
>   the next release.
>   (I specifically do not mention what rules the release team should
>   follow in deciding which projects to accept -- I trust their
>   judgement)

I like the idea in principle - just one comment here, isn't this role
pretty much tailored for the CTTE? It already has standing to make
project-wide decisions by existing rules, and in fact routinely does
so. This is pretty much how the Fedora equivalent, the Steering
Committee, operates, and it seems to work well over there.
Any reason you preferred the Release Team in the proposal?

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#12970

>>>>> "Luca" == Luca Boccassi <bluca@debian.org> writes:

    >> - After the merits and problems of the proposed new projects are
    >> discussed, the release team decides which projects are accepted
    >> for the next release.  (I specifically do not mention what rules
    >> the release team should follow in deciding which projects to
    >> accept -- I trust their judgement)

    Luca> I like the idea in principle - just one comment here, isn't
    Luca> this role pretty much tailored for the CTTE? It already has
    Luca> standing to make project-wide decisions by existing rules, and
    Luca> in fact routinely does so. This is pretty much how the Fedora
    Luca> equivalent, the Steering Committee, operates, and it seems to
    Luca> work well over there.  Any reason you preferred the Release
    Luca> Team in the proposal?

I actually think that the skills and outlook you need for an appeals
body of last resort are different than you need for the coordination of
which of an overlapping set of projects to coordinate into a release.

I don't know that the body making this decision should be the RT; I
worked on a proposal like this that I circulated privately to a few
people  while I was DPL.
There I was imagining something RT-like, probably with overlap in
composition with the RT, but possibly not the same as the RT.

Here are things I think the RT style composition has going for it.

* The RT is used to trying to find ways to say yes, but is also used to
  managing stability and trying to minimize the number of parts moving
  at once so that releases can happen.

* The RT needs to have buy-in; ultimately they are responsible for which
  changes are acceptable.  For example in usrmerge, ultimately it was
  the RT that was able to say that we aren't going to actually move
  files around until dpkg gets fixed.  Yes, their decision was
  consistent with the TC's decision, but the RT is used to, and good at
  saying "this is ready but that next step over there isn't yet."

* the RT members are involved at a very detailed technical level in
  stuff.  At an architecture review level, it's very easy to get stuck
  in the theoretical.  When the RT is sitting there looking at the
  actual patches and going "wait!  You want 60k lin.lines of changes in
  this close to the release," they see it is complex in a way that an
  architectural  overview might hide.

* The RT gets involved when things break.  They have a very good
  exposure to what kinds of changes introduce real complexity than comes
  back to bite us and what kinds of changes are safe.

* The RT is good at  keeping processes focused on goals that we have
  wide agreement on.  There is subjectivity, but with very few
  exceptions the RT isn't going to come back and tell me I shouldn't be
  able to do a transition; they are going to focus on working with me to
  make sure I'm ready for it and haven't missed details.  In a proposal
  like this, whoever is deciding which projects should go in cannot be
  making the decision based on technical merits; they would need to be
  deciding whether adequate consensus has been reached, whether there
  are people lined up to do the work, whether all the stakeholders have
  had a say, that sort of thing.  That looks a lot more like an
  architecture qualification than a TC decision.  However, some of that
  is a bit beyond the work the RT appears to usually do, and certainly
  throwing that onto the existing work for the RT without adding a bunch
  of volunteers sounds challenging.

And then there are the social factors.

* the RT has a history of being able to say no in a way that we can
  accept.  Oh, yes, there are some people who have gotten really upset
  (and I can think of one case where someone effectively minimized their
  Debian involvement) over RT decisions.
  But the RT has a really good track record of being able to say no
  without generating a project-wide storm.  They have a lot of social
  capital.

* I think that's in part because we all have positive interactions with
  the RT where we can see how they have helped us find a detail we
  missed in a transition, or asked an important question as we were
  proposing a stable update.  Perhaps not all of us, but many of us have
  seen the RT actively working with us to move stuff we care about
  forward.  Oh, I'm sure there's also frustration about how the RT
  doesn't move faster and the like.

* And at the end of the day, the RT makes releases, and we all get to
  benefit from them.
  In contrast, the TC:

* Is technically focused.  The TC has a history of doing its own
  technical evaluations rather than working with consensus processes
  elsewhere.  Sometimes that's exactly what we need, but I don't think
  that  we would want that for early coordination of which shared
  projects we're working on.
Also, the way that consensus stuff on debian-devel intermingled with TC
  bugs for usrmerge was a major step forward on this.

* The TC is a body of last resort.  That's a different mindset than
  trying to approve projects to get into releases.  The TC is much more
  likely to say some form of no--no, we won't override, no this is too
  early for the TC, no we won't have an opinion, no, we're the wrong
  group--than the release team.
  That's actually valuable given the TC's job.

* The last time the TC considered doing this job, they said no.
  Remember Debian roadmaps?
  At the time the DPL tried to get the TC involved, and was turned down.

Those are my thoughts.

I do think that the issues Ansgar raises are important.  But I also
think that something along these lines could lend legitimacy to
consensus-based discussions or point out where we need a non-consensus
decision earlier.
As an example, I think there was a huge  process failure in the usrmerge
work.
There was a consensus discussion on debian-devel that was used as
justification to make the default change in debootstrap.
The claim within the debootstrap change was that the debian-devel
discussion reached consensus.

As DPL, I went back and read that discussion.
I'm actually not convinced there was a consensus.
But because no one made a public consensus call, asserting their reading
of consensus where people could challenge it, we'll never know.
If there had been a consensus call, there would have been a lot more
legitimacy in shutting down people who objected to the debootstrap
change.

Similarly, a coordination team could have pushed back on usrmerge much
earlier pointing out that there were issues from the dpkg maintainer
that were not addressed.
I've made it no secret that I'm unhappy with the dpkg maintainer's
behavior recently.
Objections that are  inappropriate now would have been much more
reasonable earlier.
And they were made--perhaps not well, perhaps not repeatedly enough--but
they were made and dismissed earlier.
I'm not saying we should have agreed with them and taking a different
approach.
I'm saying that if we had an agreed process to consider those
objections, we could have either made a decision about those objections
earlier, or discovered we were not able to make such a decision.
If we failed to make a decision, then one side could not claim that the
objections had been handled.
If we made a decision,  then we'd be expected to fall in behind that
decision.

In effect, we'd be deciding as a project what counts as steamrollering
and what was just  being in the rough part of a consensus.
We could for example decide that we would penalize projects for not
dealing with concerns raised early by stakeholders, but if those
projects took the time to deal with concerns raised at the appropriate
points, the bar for later concerns would be raised significantly.

And yes, we might well discover we were unable to make decisions on some
projects--possibly including things like usrmerge.
I think even that would be a significant improvement.


--Sam

[toc] | [prev] | [next] | [standalone]

#12975

> [...]
> 
> Here are things I think the RT style composition has going for it.
> 
> [... long list of praise for the RT ...]
 >

Hi,

I agree that the RT has a long list of pros for this role.  However, I 
feel this discussing is overlooking one vital detail. Namely that the RT 
is a thankless job of endless work caused by 1000 developers having 
their own priorities.

This mail thread is now suggesting that the release team should have one 
more task on top of that that is not at the RT's *core* role (namely 
getting a stable release out the door).

For people that feel that the RT should coordinate this, then in 
practice I think that comes with the obligation to volunteer into the RT 
and perform the work.

Additionally, as an x-RT member that was present when release goals was 
axed. One of the reasons, why I supported axing release goals was that 
it was a lot of coordination and tracking on the RT side while the 
people proposing the goals often went "Sounds like you got this now, 
kthxbye" one the goal was accepted.

Obviously, there are some differences between this proposal and the old 
release goals - but at the end of the day, I still feel this is dropping 
a lot of extra work on the RT so people can use them as meatshields in 
their debate. To me that is an excellent way of burning out the Release 
Team and therefore I advice against it.

>   In contrast, the TC:
> [...]

Also, the TC is a conflict resolution body.  If they are part of 
managing these goals people might feel they are partial to the goal and 
not a neutral party making them less inclined to trust the TC making an 
unbiased ruling when one of the projects are in scope of a conflict.

Thanks,
~Niels

[toc] | [prev] | [next] | [standalone]

#12978

Wouter Verhelst:
> On Sat, Oct 08, 2022 at 08:06:33AM +0200, Niels Thykier wrote:
> [...]
> 
> OK, thanks. This was the reason why I added that disclaimer at the top
> of my previous email; if the release team doesn't want to do the work
> (which would be completely reasonable!) then obviously we'd have to
> create a new team.
> 

Indeed - I noted that. :)  My answer to Sam's email was due how it went 
into details with why Sam saw the RT as a good candidate team for this 
role and I wanted to present a counterargument to Sam's email.

>> Additionally, as an x-RT member that was present when release goals was
>> axed. One of the reasons, why I supported axing release goals was that it
>> was a lot of coordination and tracking on the RT side while the people
>> proposing the goals often went "Sounds like you got this now, kthxbye" one
>> the goal was accepted.
> 
> Yeah, that's not helpful. I think the requirement of the team to
> actually do the work in my proposal (and the project even being rejected
> at the end of the release cycle if they don't do the work) should help
> in remedying that, though? Or do you have a different perspective?
> 

The original release goals proposal already had as requirement that 
someone else was tracking the goal. Not sure whether we were explicit 
enough with it back then and the proposal here might be better at this.

However, even if it is more explicit, we continuously see conflict 
between people saying they are volunteering/doing a task and another 
side feeling these people are not doing "enough".  This was the case 
between the "advocates" in release goals and me on the release team back 
in the day.  It is every release between porters and one of the many 
stakeholders in architecture qualification.

This has a tendency of becoming very subjective - and subjective 
measurements tend to escalate conflicts in the cases where one side 
disagree with the measurement.

This is one of the arguments for having "SMART" release goals (with the 
"M" being "Measurable") back in the day.  It still did not work that 
well because volunteer effort is hard to measure objectively.  And this 
problem is very likely to show up for this proposal as well.

>> Obviously, there are some differences between this proposal and the old
>> release goals - but at the end of the day, I still feel this is dropping a
>> lot of extra work on the RT so people can use them as meatshields in their
>> debate. To me that is an excellent way of burning out the Release Team and
>> therefore I advice against it.
> 
> Right, so it's not a job for the release team then. Makes sense.
> 
 > [...]

At the end of the day, I think the release team should answer themselves 
whether they want to accept it - I do not and should not speak on their 
behalf.  However, looking at this from the release team point of view, I 
cannot see a single reason why they would want this extra 
responsibility. Accordingly, I would expect them to say "No thank you" 
and I recommend people not building this proposal around the RT taking 
this role (or at least have a contingency plan for the RT saying "No 
thank you").

Thanks,
~Niels

[toc] | [prev] | [next] | [standalone]

#12998

[Multipart message — attachments visible in raw view] — view raw

>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes:

    Niels> Indeed - I noted that. :) My answer to Sam's email was due
    Niels> how it went into details with why Sam saw the RT as a good
    Niels> candidate team for this role and I wanted to present a
    Niels> counterargument to Sam's email.

I'd like to be heard differently.
Quoting my original mail:

>I don't know that the body making this decision should be the RT; I
>  worked on a proposal like this that I circulated privately to a few
>  people  while I was DPL.
>  There I was imagining something RT-like, probably with overlap in
>  composition with the RT, but possibly not the same as the RT.

and later:
>However, some of that
>    is a bit beyond the work the RT appears to usually do, and certainly
>    throwing that onto the existing work for the RT without adding a bunch
>    of volunteers sounds challenging.

[toc] | [prev] | [next] | [standalone]

#12999

Sam Hartman:
>>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes:
> 
>      Niels> Indeed - I noted that. :) My answer to Sam's email was due
>      Niels> how it went into details with why Sam saw the RT as a good
>      Niels> candidate team for this role and I wanted to present a
>      Niels> counterargument to Sam's email.
> 
> I'd like to be heard differently.

Hi Sam,

Duly noted. My apologies for the inconvenience caused by my inadequate 
paraphrasing of your message.

~Niels

[toc] | [prev] | [next] | [standalone]

#12979

On Sat, Oct 08, 2022 at 08:06:33AM +0200, Niels Thykier wrote:
> > [...]
> > 
> > Here are things I think the RT style composition has going for it.
> > 
> > [... long list of praise for the RT ...]
> >
> 
> Hi,
> 
> I agree that the RT has a long list of pros for this role.  However, I feel
> this discussing is overlooking one vital detail. Namely that the RT is a
> thankless job of endless work caused by 1000 developers having their own
> priorities.
> 
> This mail thread is now suggesting that the release team should have one
> more task on top of that that is not at the RT's *core* role (namely getting
> a stable release out the door).
> 
> For people that feel that the RT should coordinate this, then in practice I
> think that comes with the obligation to volunteer into the RT and perform
> the work.

OK, thanks. This was the reason why I added that disclaimer at the top
of my previous email; if the release team doesn't want to do the work
(which would be completely reasonable!) then obviously we'd have to
create a new team.

> Additionally, as an x-RT member that was present when release goals was
> axed. One of the reasons, why I supported axing release goals was that it
> was a lot of coordination and tracking on the RT side while the people
> proposing the goals often went "Sounds like you got this now, kthxbye" one
> the goal was accepted.

Yeah, that's not helpful. I think the requirement of the team to
actually do the work in my proposal (and the project even being rejected
at the end of the release cycle if they don't do the work) should help
in remedying that, though? Or do you have a different perspective?

> Obviously, there are some differences between this proposal and the old
> release goals - but at the end of the day, I still feel this is dropping a
> lot of extra work on the RT so people can use them as meatshields in their
> debate. To me that is an excellent way of burning out the Release Team and
> therefore I advice against it.

Right, so it's not a job for the release team then. Makes sense.

> >   In contrast, the TC:
> > [...]
> 
> Also, the TC is a conflict resolution body.  If they are part of managing
> these goals people might feel they are partial to the goal and not a neutral
> party making them less inclined to trust the TC making an unbiased ruling
> when one of the projects are in scope of a conflict.

Indeed, I'm not convinced the TC is the right body to handle this. They
might perhaps be involved as an escalation point if there are
disagreements, but nothing beyond that.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

[toc] | [prev] | [next] | [standalone]

#12971

On Fri, Oct 07, 2022 at 05:54:40PM +0100, Luca Boccassi wrote:
> > - After the merits and problems of the proposed new projects are
> >   discussed, the release team decides which projects are accepted for
> >   the next release.
> >   (I specifically do not mention what rules the release team should
> >   follow in deciding which projects to accept -- I trust their
> >   judgement)
> 
> I like the idea in principle - just one comment here, isn't this role
> pretty much tailored for the CTTE?

Perhaps, yes.

> It already has standing to make
> project-wide decisions by existing rules, and in fact routinely does
> so. This is pretty much how the Fedora equivalent, the Steering
> Committee, operates, and it seems to work well over there.
> Any reason you preferred the Release Team in the proposal?

A general principle that I think it's generally better to have the
people who are involved in implementing a decision also be the people
who made the decision in the first place; and it would be the release
team who gets to say (in the end) whether a goal has been reached or
not. I expect the TC to be involved when there are things that are more
complicated (either because the release team is unwilling to take a
decision and asks the TC to step in, or because they did take a decision
but someone believes they took the wrong one, as an escalation process).

But maybe that was wrong, and we should let the TC decide on which
projects are accepted. This part of the proposal isn't very fleshed out
(mostly because I don't have enough insight on how the release team
works), and while it is crucial that it works well for the whole
proposal to work, the specifics of *how* it works are not that crucial.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

[toc] | [prev] | [next] | [standalone]

#12976

> Hi,
> 
> Debian does not have a good way to manage projects that require changes
> to large numbers of source packages to be successful. Handling projects
> like that currently requires buy-in from each individual package
> maintainer; if the project does not manage to convince sufficient
> numbers of maintainers, it is liable to fail.
> 
> [...]
> 
> Does any of that make sense?
> 
> Thanks,
> 
> -- 
>      w@uter.{be,co.za}
> wouter@{grep.be,fosdem.org,debian.org}
> 
> I will have a Tin-Actinium-Potassium mixture, thanks.


Hi

What you are writing makes sense to me. However, to me it sounds a bit 
like a "technical solution to a social problem".

This solution relies on the assumption that everyone in the project 
automatically "accepts" the solution with no hard feelings.  Yet, I feel 
that our primary issue is that despite TC ruling and GRs, we have 
contributors that do not "accept" the solutions nor the process outcomes 
to end the conflict - and I do not see what would make people accept 
this process as a end of the conflict (when a GR could not).

Thanks,
~Niels

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.project

csiph-web