[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions about "Winding down my Debian involvement"



Hi Andreas

On 2019/03/20 11:22, Andreas Tille wrote:
> Recently I've read the article "Winding down my Debian involvement" from
> Michael Stapelberg[1].  I consider that article an interesting reading and
> I would love to hear the opinion of the candidates about it.

I've seen lots of people share it and praise it, but I'm in what's
probably a small minority that didn't think too much of it. He does
bring up some topics that deserve discussion, but I don't think any of
those topics is new or particularly shocking/interesting/revelating. I
think his statement "Developer experience is pretty painful" is a bit
uncalled for, especially since the blog post he links to that describes
the statement can basically be summarized as "working with debug symbols
are hard" and "I don't like the default behaviour of 'apt source' that
much". There are definitely parts of Debian development that could be
better, but if you're going to make a statement like he did, you have to
be willing to back it up imho.

The other topics he mentions: not easily searchable mailing lists, old
bug tracker, old package upload methods, fragmented workflow- yes, these
are all things that can (and should!) improve. But are they anything to
quit Debian over? I think not.

I'm sorry if that's not the answer you were looking for, but that's how
I generally feel about it.

> Besides your general opinion I'm interested in your opinion about some
> questions that immediately popped up when reading the article.
> 
>   1. I followed the hint to rsync checked out the source package have
>      read the 6k d/rules of it.  In line with the request for modernisation
>      I wonder whether the candidates see any chance to convince 
>      maintainers to stick to some standard like debhelper >= 9 as a
>      recommended build tool.  (Rsync is just a random example - I have
>      seen several other packages that made my work as bug hunter harder
>      than necessary and I know efforts like cross building which would
>      profit heavily from some unification.)

Just checked out that file, and at 98 lines, it's really not that bad
for a really old pre-debhelper-7 style makefile:

"""
Language          Files       Code    Comment  Comment %      Blank
----------------  -----  ---------  ---------  ---------  ---------
make                  1         98         18      15.5%         15
----------------  -----  ---------  ---------  ---------  ---------
Total                 1         98         18      15.5%         15
131
"""

I've recently adopted packages with worse make files than that and
successfully converting them wasn't too hard.

So, to answer your question, I do think having a wide discussion and
then some final decision for it scheduled would be useful. I wouldn't
want to force dh9+ per sé (people still use CDBS and are apparently
happy with it), but I do agree those old style makefiles are holding us
back.

I think a good way to go about it would be to propose that we have a
recommended (not necessarilly required) set of supported build systems,
and make it a release goal that we update all those really long make
files to anything more modern, supported and easy to work with (well,
basically debhelper :) ).

There's an idea I've been playing with in my head for the last few days,
I call it "Fixer teams". These are teams of people that exist for a
small amount of time to achieve a goal and then they disband.

For example, we'd establish a fixer team that can help people who want
to convert their old-style make files all the way to a modern debhelper,
we do a call for volunteers for that team, and then announce it
somewhere like d-d-a. The fixers can either check irc/mail for people
who request this help, or they could check a bug list and recommend a MR
on GitLab. Whether I'm DPL or not (or a fixer or not), I'm happy to help
anyone who would like to update their package in the meantime.

>   2. I consider packaging in Git on salsa.debian.org a big move
>      forward to some unified workflow for Debian packaging (thanks to
>      Salsa admins by the way).  Do you see any chance to convince
>      maintainers to maintain their packages on salsa.d.o as a
>      recommended development platform.

Yes! I do think GitLab/Salsa is one of the best things to have happened
to Debian in recent history. I posted a blog post that touches on some
salsa topics earlier tonight:

https://jonathancarter.org/2019/03/20/gitlab-and-debian/

I think "unified workflow" has good merits but putting it like that
sounds scary and I can see how there will be some push back. I agree
that it is a problem that there are nearly as many packaging workflows
as there are teams, and that at least getting them all documented
somewhere where they can be compared will make it easier to merge down
all the similarities between them, and perhaps highlight the differences
so that it's easier to eliminate some unneeded parts. After that you
could perhaps end up with a common workflow and the teams that need
exceptions can just add it to that workflow as addendums. With a process
like that where it happens in quick-succession baby steps it may be
easier getting large-scale buy-in / consensus for every step.

It's a bit late here so if something seems that it doesn't make sense,
then please quote for clarification :)

-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 to: