Re: Multi-package projects
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.
Reply to: