Sam Hartman:
"Niels" == Niels Thykier 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 em
> "Niels" == Niels Thykier 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
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
c
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
On Fri, Oct 07, 2022 at 09:13:56PM +0200, Timo Röhling wrote:
> * Wouter Verhelst [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
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 maintai
[...]
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 endle
* Wouter Verhelst [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 th
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.
> >
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
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 shou
> "Luca" == Luca Boccassi 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 dec
> - 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
>
On Fri, 2022-10-07 at 14:21 +0200, Timo Röhling wrote:
> * Wouter Verhelst [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.
>
Hi Wouter,
* Wouter Verhelst [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 D
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
ork 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 poi
17 matches
Mail list logo
