Are Martin and Sam's platforms equivalent?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Are Martin and Sam's platforms equivalent?

Jose Miguel Parrella
Thanks to all candidates for putting together your rebuttals. It's
always good to see lots of "if elected, I plan to work with other
candidates"

Martin, do you really see "lot of parallels" with Sam's platform?

Sam's platform is all about innovative people mechanics. I would much
rather prefer a DPL that works _less_, but having DPL and not just DDs
propose GRs and bring up issues to tech-ctte is interesting.

The question is _what_ would be up for discussion, given it's only a
year. Sam's platform is principled about the DPL not having an agenda
and OK with leaving some things as they are. In Sam's platform, the
difficulty of making changes in Debian is a "perception".

I don't think any platform in this vote can be reduced to "what's your
position re. Stapelberg" (it's been a great debate) and Martin's
platform is more about questioning status quo... so much so that he
acknowledges the platform is highly critical of Debian (in a good way IMHO)

I get that no one wants to run for DPL on a platform of "let's get rid
of the DPL" but Sam says he doesn't "see significant changes in
governance required" while Martin mentions "change" 9 times, including:
"I think Debian has reached a point where it's important to
fundamentally rethink how our community operates"

It's also clear there's a different approach to money and resources in
the two platforms. I like it that we see opportunities to work together
but I don't think these platforms are equivalent or differ only in the
personal style of the candidate.

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Sam Hartman-3
>>>>> "Jose" == Jose Miguel Parrella <[hidden email]> writes:

    Jose> The question is _what_ would be up for discussion, given it's
    Jose> only a year.

In the discussions here, three items have come up that resonate with me
significantly:

1) Can we recommend/require dh > 9?

2) Do we want to more strongly recommend that people have packages in
Git repos on Salsa?

3) An eventual Git-based source format.

Note that I've discussed these as pure items about policy around
packaging.  However, embedded in these discussions will be questions of
work flow and collaboration.

So, at a minimum, I'd like to try and lead discussions on these 3 items.
The specific discussions will be very different, but I think they will
all be valuable discussions in helping make it easier to contribute to
Debian.

I'm sure other issues will come up, but those three are specifically
items that people in the -vote discussion seem open to discussing more
broadly and that I think are real pain points.


    Jose> Sam's platform is principled about the DPL not
    Jose> having an agenda and OK with leaving some things as they
    Jose> are.

I don't think the DPL should have an agenda on what the answer should
be.  I think a DPL should have an agenda on questions to ask and on how
they will focus their effort.
(And I think collaboration with others is a great way to broaden that
agenda and allow us to make progress on more than one person's focuses)


    Jose> In Sam's platform, the difficulty of making changes in
    Jose> Debian is a "perception".

It's a bit more complex than that.  First, I do think that there is a
perception change is hard.  That alone is bad: it discourages people
from driving changes and creates a perception that Debian is harder to
join and contribute to.

Beyond that though, I think that decisions are actually difficult to make.
I think that fixing that may involve better use of tools that we already
have rather than new tools.  I think we could do a lot more of
summarizing and leading discussions and calling consensus explicitly to
the extent we have it.  I think we could do a lot more of helping people
feel heard and considered so they do not feel a need to repeat the same
point again and again.  I think that putting someone in charge of
driving a discussion can be valuable because they can help make sure
that important parties don't drop the discussion and things don't stall.

And as I discussed, I think that we can find less confrontational ways
to use our existing tools to make decisions when consensus doesn't
happen.


    Jose> I get that no one wants to run for DPL on a platform of "let's
    Jose> get rid of the DPL" but Sam says he doesn't "see significant
    Jose> changes in governance required" while Martin mentions "change"
    Jose> 9 times, including: "I think Debian has reached a point where
    Jose> it's important to fundamentally rethink how our community
    Jose> operates"

I don't think the way Martin uses operates is really similar to the way
I use governance.
Which is to say I don't see an inherent conflict in saying that Debian's
governance doesn't need to change significantly, while the way Debian
operates does.

I suspect Martin and I do disagree some here, especially around
degreee and on how well Debian is working today.  I'm just not sure the
text you point to is a good example of that disagreement.


    Jose> It's also clear there's a different approach to money and
    Jose> resources in the two platforms.

That's not obvious to me.  Martin and I seem reasonably well aligned on
*what* we'd like to have happen with money.  Martin is willing to take
more risk than I am to get there (or try something new) on the money
front; especially he's willing to risk more controversy.
I'd love to accomplish the same goals, but I'm not willing to take on as
much risk to do it, and I think the best way for me to drive those goals
might well be to delegate to someone else.


signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Martin Michlmayr
In reply to this post by Jose Miguel Parrella
* Jose Miguel Parrella <[hidden email]> [2019-03-26 15:30]:
> Martin, do you really see "lot of parallels" with Sam's platform?

My platform contains two major topics: 1) creating a more healthy
commercial ecosystem around Debian and 2) changing the culture.

While Sam doesn't mention 1), I do see a lot of parallels regarding 2).

> Sam's platform is all about innovative people mechanics.
...
> I get that no one wants to run for DPL on a platform of "let's get rid
> of the DPL" but Sam says he doesn't "see significant changes in
> governance required" while Martin mentions "change" 9 times, including:
> "I think Debian has reached a point where it's important to
> fundamentally rethink how our community operates"

Right, there's probably a difference in how severe Sam and I perceive
the problems to be, but when it comes to culture I think there are
parallels in terms of what needs to change.  That's what I was
referring to in my rebuttal.

> It's also clear there's a different approach to money and resources
> in the two platforms.

Yes.

--
Martin Michlmayr
https://www.cyrius.com/

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Adrian Bunk-3
In reply to this post by Sam Hartman-3
On Tue, Mar 26, 2019 at 07:06:26PM -0400, Sam Hartman wrote:

> >>>>> "Jose" == Jose Miguel Parrella <[hidden email]> writes:
>
>     Jose> The question is _what_ would be up for discussion, given it's
>     Jose> only a year.
>
> In the discussions here, three items have come up that resonate with me
> significantly:
>
> 1) Can we recommend/require dh > 9?
>
> 2) Do we want to more strongly recommend that people have packages in
> Git repos on Salsa?
>
> 3) An eventual Git-based source format.
>
> Note that I've discussed these as pure items about policy around
> packaging.  However, embedded in these discussions will be questions of
> work flow and collaboration.
>
> So, at a minimum, I'd like to try and lead discussions on these 3 items.
> The specific discussions will be very different, but I think they will
> all be valuable discussions in helping make it easier to contribute to
> Debian.

They might be relevant for people already in Debian.

If you want to "make it easier to contribute to Debian" for non-DDs,
I'd say they are mostly irrelevant and the actual problems are elsewhere:

1. Non-DDs getting single changes into Debian
If you are not a DD, there is no process to get a change into
Debian if the maintainer is MIA or is one of those maintainers
who ignores the BTS and only uploads new upstream versions.
Note that I am not talking about contoversial changes NAKed by the
maintainer, I am talking about 10 year old clearly correct patches
or "New upstream version" bugs that are rotting in the BTS.
Whether a patch is rotting in the BTS or is rotting in a MR on salsa
doesn't really make a difference on the underlying problem.

2. Package sponsorship
Any mentoring outreach aimed at finding new contributors should start
with no longer frustrating the people who have already started to
contribute. They might stop their contributions.
There are too few people reviewing packages at sponsorship-requests,
but proper and timely reviews would be very important both for not
frustrating new contributors and ensuring that new contributors
are learning to do high-quality packaging.
Spending any resources on finding new contributors who are starting
at zero doesn't really make sense as long as people who are already
contributing have to wait months for getting their ITPs reviewed
and uploaded (and then have to wait additional months while the
package is in NEW).

> I'm sure other issues will come up, but those three are specifically
> items that people in the -vote discussion seem open to discussing more
> broadly and that I think are real pain points.
>...

My points are non-issues for DDs participating in a -vote discussion,
but are real barriers for people who are beginning to contribute.

Coming from the Debian bubble, it was a surprising experience when the
first patch I submitted to Yocto was on the master branch a day later.

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Sean Whitton
Hello,

On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote:

> 1. Non-DDs getting single changes into Debian
> If you are not a DD, there is no process to get a change into
> Debian if the maintainer is MIA or is one of those maintainers
> who ignores the BTS and only uploads new upstream versions.
> Note that I am not talking about contoversial changes NAKed by the
> maintainer, I am talking about 10 year old clearly correct patches
> or "New upstream version" bugs that are rotting in the BTS.
> Whether a patch is rotting in the BTS or is rotting in a MR on salsa
> doesn't really make a difference on the underlying problem.

I'm not sure about this -- there is the same NMU process everyone else
uses, except that you need a sponsor.  Which brings me to...

> 2. Package sponsorship
> Any mentoring outreach aimed at finding new contributors should start
> with no longer frustrating the people who have already started to
> contribute. They might stop their contributions.
> There are too few people reviewing packages at sponsorship-requests,
> but proper and timely reviews would be very important both for not
> frustrating new contributors and ensuring that new contributors
> are learning to do high-quality packaging.
> Spending any resources on finding new contributors who are starting
> at zero doesn't really make sense as long as people who are already
> contributing have to wait months for getting their ITPs reviewed
> and uploaded (and then have to wait additional months while the
> package is in NEW).
This is a huge problem, indeed.

The two current processes that you identify as getting in newcomers' way
-- RFS bugs and the NEW queue -- are slow simply because of the fact
that both of them are understaffed.  It's the usual problem with Debian
not having the manpower we would like to have.

The question is whether those processes could be changed such that the
manpower problem would be less keenly felt.  I cannot myself see any way
to achieve that -- there are tooling issues but improving the relevant
tools would not significantly speed either queue.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Jonathan Carter (highvoltage)-2

On 2019/03/30 00:16, Sean Whitton wrote:

> On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote:
>> 2. Package sponsorship
>> Any mentoring outreach aimed at finding new contributors should start
>> with no longer frustrating the people who have already started to
>> contribute. They might stop their contributions.
>> There are too few people reviewing packages at sponsorship-requests,
>> but proper and timely reviews would be very important both for not
>> frustrating new contributors and ensuring that new contributors
>> are learning to do high-quality packaging.
>> Spending any resources on finding new contributors who are starting
>> at zero doesn't really make sense as long as people who are already
>> contributing have to wait months for getting their ITPs reviewed
>> and uploaded (and then have to wait additional months while the
>> package is in NEW).
>
> This is a huge problem, indeed.
>
> The two current processes that you identify as getting in newcomers' w
ay
> -- RFS bugs and the NEW queue -- are slow simply because of the fact
> that both of them are understaffed.  It's the usual problem with Debia
n
> not having the manpower we would like to have.
>
> The question is whether those processes could be changed such that the
> manpower problem would be less keenly felt.  I cannot myself see any w
ay
> to achieve that -- there are tooling issues but improving the relevant
tools would not significantly speed either queue.

I acknowledge that it's a problem, but I don't agree that much that it's
a *huge* problem.

Here are the RFS bugs list:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;d
ist=unstable

Those 30 bugs which close ITPs are all reasonably recent (most bug
numbers start with 92...), and since we're in deep freeze they will
naturally be low priority.

That leaves 14 requests, of which one introduces a removed package back
to the archive, one would cause a transition, and a few of those have
been addressed and are going trough discussion / solving issues.

That leaves less than 10 packages that need reviewing right now. I do
think that reviewing/sponsoring should be a lot better, and that more
DDs should play their part, and that our tooling can improve to bring
more visibility to these requests, but I would classify this more as a
medium priority problem TBH... hmm, am I being pedantic about
classification of problems... I digress..

More packages moving to teams have been a great thing for Debian, I
think we should leverage that more for sponsorship requests. It would be
nice if a DD looked at their DDPO page and it would also show
outstanding sponsorship requests for the teams they're part of. It's
great that the DDPO pages now show outstanding merge requests from salsa
in the VCS column, I would've probably missed the few MRs I've received
so far if it wasn't for that.

If a quarter of active DDs checked the RFS list / mentors.debian.net
just once a month and reviewed a package, there would probably be no
problem in terms of waiting to get a package sponsored whatsoever, I
think we could do more to advertise the todo list, maybe a weekly report
to debian-devel like the WNPP report may work well.

In the #debian-python IRC channel, when a sponsorship request lands
there it goes in to the channel topic. I admit that I often forget to
look there myself, but there are small changes like that that could
become a project-wide cultural habbit that might also help bring
attention to sponsorship requests.

Well, that's just my views as a DD who thinks this is important and this
is an area I'd like to put some focus on regardless of the DPL elections
.

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Sean Whitton
Hello Jonathan,

On Sat 30 Mar 2019 at 10:23AM +02, Jonathan Carter wrote:

> That leaves less than 10 packages that need reviewing right now. I do
> think that reviewing/sponsoring should be a lot better, and that more
> DDs should play their part, and that our tooling can improve to bring
> more visibility to these requests, but I would classify this more as a
> medium priority problem TBH... hmm, am I being pedantic about
> classification of problems... I digress..
>
> More packages moving to teams have been a great thing for Debian, I
> think we should leverage that more for sponsorship requests. It would be
> nice if a DD looked at their DDPO page and it would also show
> outstanding sponsorship requests for the teams they're part of. It's
> great that the DDPO pages now show outstanding merge requests from salsa
> in the VCS column, I would've probably missed the few MRs I've received
> so far if it wasn't for that.
>
> If a quarter of active DDs checked the RFS list / mentors.debian.net
> just once a month and reviewed a package, there would probably be no
> problem in terms of waiting to get a package sponsored whatsoever, I
> think we could do more to advertise the todo list, maybe a weekly report
> to debian-devel like the WNPP report may work well.
If I may summarise, your response is to invite more DDs to spend time
reviewing sponsorship requests, and improve tooling a bit to reduce the
friction in doing that; in particular, by pointing team members to
sponsorship requests for packages that either are or will be maintained
under the umbrella of that team.

As I said in the message to which you're replying, I am not convinced
that any tooling improvements are going to change the state of play in
this area.

So, then, your response is to ask more people to spend time on it.  The
problem with that is that it ignores the good reasons people have for
not spending time on it!

If I have relevant expertise or experience to improve Debian in some
particular respect (e.g. fixing bugs in a packages written in a
particular programming language that isn't so commonly used), I have
strong reason to use my time to deploy that expertise and experience,
rather than review some sponsorship requests.  The latter very rarely
requires skills not possessed by all DDs.

Such reasons are defeasible, such as if I just really feel like
reviewing sponsorship requests, but I think it's at the heart of the
problem.  We *all* have particular things we can do better than most
other DDs, so we have strong reason to work on those, not on something
that all of us can do.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Jonathan Carter (highvoltage)-2
Hi Sean

On 2019/03/31 21:05, Sean Whitton wrote:

> On Sat 30 Mar 2019 at 10:23AM +02, Jonathan Carter wrote:
>> That leaves less than 10 packages that need reviewing right now. I do
>> think that reviewing/sponsoring should be a lot better, and that more
>> DDs should play their part, and that our tooling can improve to bring
>> more visibility to these requests, but I would classify this more as a
>> medium priority problem TBH... hmm, am I being pedantic about
>> classification of problems... I digress..
>>
>> More packages moving to teams have been a great thing for Debian, I
>> think we should leverage that more for sponsorship requests. It would be
>> nice if a DD looked at their DDPO page and it would also show
>> outstanding sponsorship requests for the teams they're part of. It's
>> great that the DDPO pages now show outstanding merge requests from salsa
>> in the VCS column, I would've probably missed the few MRs I've received
>> so far if it wasn't for that.
>>
>> If a quarter of active DDs checked the RFS list / mentors.debian.net
>> just once a month and reviewed a package, there would probably be no
>> problem in terms of waiting to get a package sponsored whatsoever, I
>> think we could do more to advertise the todo list, maybe a weekly report
>> to debian-devel like the WNPP report may work well.
>
> If I may summarise, your response is to invite more DDs to spend time
> reviewing sponsorship requests, and improve tooling a bit to reduce the
> friction in doing that; in particular, by pointing team members to
> sponsorship requests for packages that either are or will be maintained
> under the umbrella of that team.
>
> As I said in the message to which you're replying, I am not convinced
> that any tooling improvements are going to change the state of play in
> this area.
>
> So, then, your response is to ask more people to spend time on it.  The
> problem with that is that it ignores the good reasons people have for
> not spending time on it!
>
> If I have relevant expertise or experience to improve Debian in some
> particular respect (e.g. fixing bugs in a packages written in a
> particular programming language that isn't so commonly used), I have
> strong reason to use my time to deploy that expertise and experience,
> rather than review some sponsorship requests.  The latter very rarely
> requires skills not possessed by all DDs.
>
> Such reasons are defeasible, such as if I just really feel like
> reviewing sponsorship requests, but I think it's at the heart of the
> problem.  We *all* have particular things we can do better than most
> other DDs, so we have strong reason to work on those, not on something
> that all of us can do.

Well, maybe you and I just fundamentally disagree on this one then. My
point was that if only 10 more DD's each took care of one more
sponsorship request of the last month, we'd now basically efficiently
have no backlog. As for your comment that additional tooling won't help,
I know it will help at least for me, because I check my QA pages often
because they're comprehensive, except for sponsorship requests. If they
were more prominent, then at least I would spend more opportunistic
attention to them. I certainly wasn't suggesting that DDs abandon some
of the deep-focus work that they're doing to do forced reviews, so, I
would not say that your summary is a fair representation of what I was
putting across.

-Jonathan


--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Sean Whitton
Hello,

On Sun 31 Mar 2019 at 09:46PM +02, Jonathan Carter wrote:

> Well, maybe you and I just fundamentally disagree on this one then. My
> point was that if only 10 more DD's each took care of one more
> sponsorship request of the last month, we'd now basically efficiently
> have no backlog. As for your comment that additional tooling won't help,
> I know it will help at least for me, because I check my QA pages often
> because they're comprehensive, except for sponsorship requests. If they
> were more prominent, then at least I would spend more opportunistic
> attention to them. I certainly wasn't suggesting that DDs abandon some
> of the deep-focus work that they're doing to do forced reviews, so, I
> would not say that your summary is a fair representation of what I was
> putting across.
Fair enough, thanks.  I don't look at QA summaries opportunistically, so
I see why we'd have different impressions in this area.

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Paul Wise via nm
In reply to this post by Sean Whitton
On Mon, Apr 1, 2019 at 3:05 AM Sean Whitton wrote:

> If I have relevant expertise or experience to improve Debian in some
> particular respect (e.g. fixing bugs in a packages written in a
> particular programming language that isn't so commonly used), I have
> strong reason to use my time to deploy that expertise and experience,
> rather than review some sponsorship requests.  The latter very rarely
> requires skills not possessed by all DDs.

OTOH, if you spend your time mentoring someone in that area, then once
they have gotten up to speed, you could potentially be responsible for
double the output after doing mentoring compared to before the
mentoring :)

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Paul Wise via nm
In reply to this post by Sean Whitton
On Tue, Apr 2, 2019 at 6:11 AM Sean Whitton wrote:

> Fair enough, thanks.  I don't look at QA summaries opportunistically, so
> I see why we'd have different impressions in this area.

I wonder if folks are using how-can-i-help, that reports sponsorship
requests for packages you have installed these days. Of course that
doesn't help for new packages.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Ian Jackson-2
In reply to this post by Sean Whitton
Sean Whitton writes ("Re: Are Martin and Sam's platforms equivalent?"):
> On Fri 29 Mar 2019 at 04:43PM +02, Adrian Bunk wrote:
> > 2. Package sponsorship
...
> > There are too few people reviewing packages at sponsorship-requests,
> > but proper and timely reviews would be very important both for not
> > frustrating new contributors and ensuring that new contributors
> > are learning to do high-quality packaging.

I hesitate to bang this drum again, but this would be a great place to
think about how we can use git more.

Ideally, our default sponsorship workflow would *not involve source
packages or orig tarballs at all*.

> The question is whether those processes could be changed such that the
> manpower problem would be less keenly felt.  I cannot myself see any way
> to achieve that -- there are tooling issues but improving the relevant
> tools would not significantly speed either queue.

Whenever I do sponsorship I find the task of consuming the bits I have
been provided by my sponsee far outweighs the task of checking what
they have done to the package.

This is seriously exacerbated by the additional friction which occurs
if I have any comment on the package which results in a respin.

If sponsorship was as simple as
    git debsponsor clone <package>
    cd <package>
    git diff dgit/dgit/sid # or maybe git diff upstream/stable-4.12
    dgit push-source
then (i) I would want to do much more sponsorship (ii) my sponsees
would get the kind of timely service I can provide for `oh this is a
5 min job' type of task, rather than what I can provide for `this
might take half an hour or it might take two hours'.

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: Are Martin and Sam's platforms equivalent?

Adam Borowski-3
On Wed, Apr 03, 2019 at 12:40:45PM +0100, Ian Jackson wrote:
> I hesitate to bang this drum again, but this would be a great place to
> think about how we can use git more.
>
> Ideally, our default sponsorship workflow would *not involve source
> packages or orig tarballs at all*.

It's too easy to get orig tarballs wrong.  Until all or most upstreams have
public git with tags, this might be problematic.  For this reason, I tend to
ask for an upload to mentors.d.n even when provided with a
some-random-workflow-git-repo (I especially hate anything related to gbp).

> If sponsorship was as simple as
>     git debsponsor clone <package>
>     cd <package>
>     git diff dgit/dgit/sid # or maybe git diff upstream/stable-4.12
>     dgit push-source

Shouldn't this include actual build, etc?  I have sponsored over 1000
uploads, yet not a single time I skipped the build step.  Sponsorees don't
tend to package libreoffice-sized stuff, and even uploads I otherwise merely
rubber-stamp too often miss some obscure B-Dep or something.  There's no way
I'd upload even an one-line change without a test build + bin-debdiff.

And, without a built package, you can't look at lintian.  It automates a
good part of reviewing.

> then (i) I would want to do much more sponsorship (ii) my sponsees
> would get the kind of timely service I can provide for `oh this is a
> 5 min job' type of task, rather than what I can provide for `this
> might take half an hour or it might take two hours'.

While git does have many upsides, I fail to see how it'd be better for
estimating required effort.  For comparison, my workflow is:

.--==[ .bashrc ]
alias lsdebs='grep ^Package: debian/control |cut -d" " -f2 >/tmp/deb-list'
alias diffdebs='for x in `cat /tmp/deb-list`;do c "$x" && apt download "$x" && debdiff --wt "$x"_*deb;done'
`--

dget <pasted URL, preferably from mentors>
cd <package>
lsdebs
dpkg-buildpackage -S -d    # repack, gen changes
cd ..
sbuild <package.dsc>
diffdebs
apt source <package>
debdiff package_*.dsc|colordiff|less -R

This is the point where, having glanced at both diffs, I decide whether to rubber-stamp
or to do actual review.  Of course folks like Gürkan can pass even complex
changes with only a cursory look, newbies and poor-quality contributors get
even trivial changes fully reviewed, usual folks are in the middle.

What I'd wish for, is some CI that takes sponsoree-provided package, builds
it, and provides ready bin-lintian, src-debdiff, bin-debdiff, and the .debs
to look over -- but such a tool can be fed a dgit repo just the same as
existing mentors .dsc packages.  Unless you make dgit fully distributed like
"dget from some random URL" is, there's no gain.

And, monstrosities like gbp or patches-unapplied make quilt-in-git workflows
nastier to review than just comparing two unpacked dirs, the old way.


So, if you'd want to make _me_ happy, it would be nice if you could kill
quilt dead.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀