On Sat, Jun 29, 2019 at 09:18:11AM -0400, Sam Hartman wrote:
> I think it would be helpful for both of us to describe ways in which you
> find that there are objectivity problems that would get in the way of
> presenting the data in that context.
>
> I think especially at that bof we'd like to avoid people feeling that
> some practice that they cared about was mischaracterized or
> misrepresented.
>
> Yet we kind of need one person to give a short presentation to get it
> into something that can fit into a bof.
>
> So any help you can provide pointing at things that seem too subjective
> would be appreciated.
Trying to unpack my gut feelings, I think the current table intermixes
the presentation of a taxonomy work to Debian as a whole, with an
iteration of dgit design work.
I'm currently not concerned with dgit[1], and I'm curious to see a
mapping of the complex landscape that is Debian in this regard. When I
read the table, I see "best practice" links that point to dgit
documentation and a "comments" column with judgemental words like
"clumsy", "competent", "avoid". Those are getting in the way of my
attempt to look at the landscape.
I'd like to be able to look at the landscape first, and take it in, and
then, as a separate step, see what the dgit maintainers, whose opinion I
actually very much respect, are making of it.
This decoupling would probably also give those people who are using a
layout currently commented as "avoid", "poor", or "clumsy", the dignity
of seeing documented the objective fact that they exist and took time to
document it by responding to the survey. And at the same time, could
give full freedom to the dgit maintainers to be as judgemental of any
workflow as they see fit[2], because it will be all well framed in the
specific context of dgit design.
Enrico
[1] I'm quite dgit-agnosting. My currently packaging practice is
"burnt out by a complex and changing ecosystem and trying not to do
any of it if I can avoid it. Excited at what is currently going on,
waiting excitedly at something sane to get established as a standard
and gain clear documentation and simple tooling. Possibly, as little
tooling as possible over a decently maintained upstream source."
[2] you know what I mean, please don't take it as a challenge :)
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>
Attachment:
signature.asc
Description: PGP signature