Do we want to Require or Recommend DH

classic Classic list List threaded Threaded
116 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Guillem Jover
On Mon, 2019-05-13 at 08:33:44 -0400, Sam Hartman wrote:
> As promised, I'd like to start a discussion on whether we want to
> recommend using the dh command from debhelper as our preferred build
> system.

So, here's my take on this. I do use debhelper everywhere, I also use
dh mostly at work, and personally perhaps when it requires no overrides
or very very few of them, or as a replacement for equivs. I do not have
any major problem with debhelper nor dh, I find *both* styles more
pleasant than a hand-crafted debian/rules, but from here it seems like
some in this thread are oblivious to problems with its usage.

Design
------

* debhelper design's principle has been to be a thin layer, most of the
  heavy lifting used to get delegated to other tools and/or lower-layers.
* Both cdbs and dh are based on similar principles, which is to cover as
  much as possible automatically, and override/diverge on the specifics.
  The problem I see though is that they are implemented inside-out, and
  that is one big reason both end up being so much more complex than they
  need to be. This is obviously not a problem of their making!
* Both debhelper and cdbs have a concept of a versioned API. Which is
  nice because it makes it possible to introduce staged changes that
  could otherwise break the world. debhelper seems to be more strict
  about adhering to its API though, and it has proper documentation
  compared to cdbs which does not, which I think is the main reason I
  always found cdbs unappealing as you need to read its source code
  making its entire implementation its interface. This made me realize
  the same applies to dpkg's make fragments (which tend to be used with
  dh too), so I'll be adding man pages for those during 1.20.x. :)
* dh uses an implementation hack to be able to introspect on make.
  This is something that has always slightly put me off. I'm counting
  the days until I can remove a similar but way less clever hack in
  dpkg-buildpackage that tries to introspect on the build targets!

Technical
---------

* Not so simple:
  The proclaimed simplicity is only apparently so. Using dh might result
  in shorter debian/rules files, it might (perhaps) result in debian/rules
  listing only the exceptions; all these are one side of simplicity. At
  the same time it makes things more complex because it's yet another
  layer, an abstraction which hides (at the source level) implementation
  details, which you still need to know when having to modify the
  packaging; you need to know how each of dh, debhelper, the various tools
  debhelper uses, make, shell, the upstream build system, the source format
  and patching, the dpkg toolchains, etc. all work, and how they interact.
* Complex is still complex:
  For simple cases, it can indeed be very simple and obvious, for complex
  cases with tons of overrides and make variables, many times it does not
  seem better than an unrolled debhelper debian/rules file.
* Not so uniform:
  Uniformity even with required usage of dh (is not and) would not be
  as uniform as people might want to believe. This is still dependent
  on other helpers used (and which, say dh-exec), on make/shell style,
  on whether you implement the logic in make or shell or an external
  package-specific program (in whatever language) that you call from
  debian/rules, etc.
* No free global change:
  Makes pushing global changes somewhat easier? Yes, but also taking into
  account that any such change in most cases will still require a compat
  level bump, the maintainers making sure it works, and that any override
  has the potential to disable those changes. The main advantage is that
  it might remove the load on maintainers having to recall to do that
  specific change, they just need to make sure it works. It might also
  play in the other direction, with maintainers missing that they need to
  check for these changes "because dh takes care of everything". But this
  just enables a "passive deferred transition", and people that want to
  see a transition done *now* still might need to do tons of work.

Social
------

* It has already naturally gained majority mindshare, because in most
  cases and for most people, it's obviously better than the alternatives,
  I expect this will keep going as debhelper/dh improves, why the need
  for a forced push then for the people who are not yet convinced? This
  always looks suspect to me. For cases like this, I always find it's
  better to convince people with good arguments or better implementation
  and/or documentation, not with force, but dunno.
* A hard requirement means innovation might be thwarted, even if
  innovation is excempt, it would require people to justify beforehand
  (either publicly or to themselves) whether the new solution is going
  to end up being really better than the status quo even before it's
  started.
* Optimizing for NMUs seems wrong, we should be optimizing for long
  term maintainership. Something that can only be sustained by NMUs has
  a high chance of being orphaned and RMed from the archive. If it gets
  orphaned/adopted the new maintainer(s) can always switch to whatever
  anyway. Alienating productive and engaged maintainers in the name of
  the "collective" does not seem wise. For packages I require and I'm
  not able or willing to maintain, if the option is between them using
  an uncommon packaging style, or them being unmaintained or possibly
  removed, I'd pick the former any day. Neither potentially losing
  contributors over this seems wise.

Policy
------

* What does truly using dh mean? Given that dh and debhelper original
  principles were to be very thin layers? Is using many external
  Makefile fragments still using it? Is using many external helper
  tools explicitly still using it? Is overriding most of the dh
  sequence/commands still using it? Codifying the properties people
  seem to want in policy for something like dh, seems between hard to
  close to impossible.
* debhelper is a thin layer that implements policy, requiring it in
  policy feels very wrong (between tautological and a layer violation).
  Mentioning or recommending it seems fine though.
* Requiring a list of undetermined and open-ended exceptions for when
  dh is not appropriate looks like the wrong way to standardize
  something.
* Already recommended almost everywhere (docs, dh-make*, mentors,
  prevalent packaging style, word of mouth, etc.).


So, while I think debhelper and dh might in general make things easier
and simpler, and I personally prefer them (depending on the context) to
other packaging styles, I think (obviously with a very biased PoV) "they"
are still missing the point. And true clarity and simplicity can only be
achieved by rethinking some of the packaging foundational concepts we
use, and by trying to push stuff down the layers. And by more clear,
structured and holistic documentation too.


Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Jonas Smedegaard-2
Quoting Guillem Jover (2019-05-28 12:46:34)
>   [dh] has proper documentation compared to cdbs which does not, which
>   I think is the main reason I always found cdbs unappealing as you
>   need to read its source code making its entire implementation its
>   interface.

Another common technical¹ reason for disliking cdbs besides its lack of
documentation is its exposing the make language where dh hides it.


>   This made me realize the same applies to dpkg's make fragments
>   (which tend to be used with dh too), so I'll be adding man pages for
>   those during 1.20.x. :)

Nice to know that my total² lack of documenting cdbs has at least been
helpful in improving _other_ documentation ;-)


 - Jonas


¹ A common _non-technical_ reason is that cdbs is less popular than dh
and therefore a reason Debian has less contributors than if they were
given less choice.

² All existing documentation predates my taking lead of cdbs in 2009.

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

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

Re: Do we want to Require or Recommend DH

Thorsten Glaser-7
In reply to this post by Sam Hartman-5
I would very much like to argue that not using dh is not a bug,
but Joey Hess, with his credentials ☺, did that already (and much
better than I could):

http://joeyh.name/blog/entry/80_percent/

tl;dr: dh started as 80% solution, it’s maybe an 96% solution now,
but it’s not intended as, and won’t be, a 100% solution.

I’d also throw in that monocultures are not good, and that people
in general are happier when they aren’t forced into anything. Just
yesterday I had a bug that wouldn’t have happened with a non-dh7
rules file (incidentally, ordering matters, so I had to add a call
to mkdir -p debian/binarypackagename/some/directory into an over‐
ride). And finally, rules with too many overrides are actually
worse readable than classic debhelper style.

I also have packages where the automatic build system detection
of dh is wrong. Understandably wrong, but wrong nevertheless.

Oh, and… to learn, automagisms are not so good, because you don’t
see what’s going on, and can’t change it on an intuitive or more
fine-granular level (though with DH_VERBOSE=1 mandated by default
by recent Policy changes, this may have improved a little).

So… to each their own. I’d make a case for non-debhelper to be
allowed, but I know that’s not majority-capable… but if people
wish to use debhelper, dh7, or even *shudder* dbs or cdbs, fine.
Remember people make this often in their spare time and aren’t
getting paid for it so please keep the fun factor.

Thanks,
//mirabilos
--
This space for rent.

https://paypal.me/mirabilos to support my work.

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Andrey Rahmatullin-3
On Tue, Jun 04, 2019 at 01:37:46PM +0000, Thorsten Glaser wrote:
> I’d also throw in that monocultures are not good, and that people
> in general are happier when they aren’t forced into anything.
Yet people in general are also happier when they don't need to learn all
ways to do something.

> Just yesterday I had a bug that wouldn’t have happened with a non-dh7
> rules file (incidentally, ordering matters, so I had to add a call to
> mkdir -p debian/binarypackagename/some/directory into an over‐ ride).
dh_installdirs runs pretty early in the install target, what needed that
directory before dh_installdirs?

> I also have packages where the automatic build system detection
> of dh is wrong. Understandably wrong, but wrong nevertheless.
It's a feature of dh_auto_* and not of dh.

> Oh, and… to learn, automagisms are not so good, because you don’t
> see what’s going on,
You see what helpers are executed. You don't always see what do they do but
that's unrelated to dh(1).

> (though with DH_VERBOSE=1 mandated by default by recent Policy changes,
> this may have improved a little).
If you mean "The package build should be as verbose as reasonably
possible" then it doesn't really mandate DH_VERBOSE=1.

--
WBR, wRAR

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

Re: Do we want to Require or Recommend DH

Jonas Smedegaard-2
Quoting Andrey Rahmatullin (2019-06-04 15:58:33)
> On Tue, Jun 04, 2019 at 01:37:46PM +0000, Thorsten Glaser wrote:
> > I’d also throw in that monocultures are not good, and that people in
> > general are happier when they aren’t forced into anything.
> Yet people in general are also happier when they don't need to learn
> all ways to do something.

Who says people need to learn _all_ ways?

Must we all learn the ways of Java and DKMS and Haskell and and...?

Nice if we can _generally_ handle _most_ packages.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

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

Re: Do we want to Require or Recommend DH

Sam Hartman-3
In reply to this post by Thorsten Glaser-7
>>>>> "Thorsten" == Thorsten Glaser <[hidden email]> writes:

    Thorsten> I would very much like to argue that not using dh is not a
    Thorsten> bug, but Joey Hess, with his credentials ☺, did that
    Thorsten> already (and much better than I could):

    Thorsten> http://joeyh.name/blog/entry/80_percent/

He doesn't actually make that argument.

>Not being part of Debian anymore, I'm in the position of needing to
>point out something important about it anyway. So this post is less
>about pointing in a specific direction as giving a different angle to
>think about things.

He argues that dh may have evolved to be around a 96% solution at this
point.

That's entirely consistent with the idea that not using dh could be a
bug absent an exceptional situation.  (Appologies for not looking up the
wording from Ian's message; I mean what Ian calls unusual here.)



    Thorsten> tl;dr: dh started as 80% solution, it’s maybe an 96%
    Thorsten> solution now, but it’s not intended as, and won’t be, a
    Thorsten> 100% solution.

Nor have we claimed that it is.
There are several reasons for not using dh we've already identified.

    Thorsten> I’d also throw in that monocultures are not good, and that
    Thorsten> people in general are happier when they aren’t forced into
    Thorsten> anything.

Agreed.
Working on new tooling clearly needs to be one of the reasons for not
using dh to allow for development of new things.

    Thorsten> Just yesterday I had a bug that wouldn’t have
    Thorsten> happened with a non-dh7 rules file (incidentally, ordering
    Thorsten> matters, so I had to add a call to mkdir -p
    Thorsten> debian/binarypackagename/some/directory into an over‐
    Thorsten> ride). And finally, rules with too many overrides are
    Thorsten> actually worse readable than classic debhelper style.

    Thorsten> I also have packages where the automatic build system
    Thorsten> detection of dh is wrong. Understandably wrong, but wrong
    Thorsten> nevertheless.

    Thorsten> Oh, and… to learn, automagisms are not so good, because
    Thorsten> you don’t see what’s going on, and can’t change it on an
    Thorsten> intuitive or more fine-granular level (though with
    Thorsten> DH_VERBOSE=1 mandated by default by recent Policy changes,
    Thorsten> this may have improved a little).

    Thorsten> So… to each their own. I’d make a case for non-debhelper
    Thorsten> to be allowed, but I know that’s not majority-capable… but
    Thorsten> if people wish to use debhelper, dh7, or even *shudder*
    Thorsten> dbs or cdbs, fine.  Remember people make this often in
    Thorsten> their spare time and aren’t getting paid for it so please
    Thorsten> keep the fun factor.

The fun factor is important.

My reading of the community consensus is that the points you bring up
have been consider by the community.
You did not bring up new issues.

my reading is that the community believes that the fun factor of more
uniformity when dealing with a lot of packages justifies the restriction
of maintainer preference when there's not a sufficient justification for
a tool other than dh.

You're absolutely right that there is a tradeoff here.
And I think that Debian of 10 or 15 years ago would have evaluated the
tradeoff between the needs of a single maintainer and the needs of
people doing work across a lot of packages differently.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Sam Hartman-3
In reply to this post by Jonas Smedegaard-2
>>>>> "Jonas" == Jonas Smedegaard <[hidden email]> writes:

    Jonas> Quoting Andrey Rahmatullin (2019-06-04 15:58:33)
    >> On Tue, Jun 04, 2019 at 01:37:46PM +0000, Thorsten Glaser wrote:
    >> > I’d also throw in that monocultures are not good, and that
    >> people in > general are happier when they aren’t forced into
    >> anything.  Yet people in general are also happier when they don't
    >> need to learn all ways to do something.

    Jonas> Who says people need to learn _all_ ways?

    Jonas> Must we all learn the ways of Java and DKMS and Haskell and
    Jonas> and...?

no, but some of us must or at least must be prepared to.

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Thorsten Glaser-7
In reply to this post by Sam Hartman-3
Sam Hartman dixit:

>He doesn't actually make that argument.

Hmm. Right, he doesn’t spell it out, but I got the impression.
Perhaps my reading was wrong.

>There are several reasons for not using dh we've already identified.

Sure… but…
>The fun factor is important.
… that.

>My reading of the community consensus is that the points you bring up
>have been consider by the community.
>You did not bring up new issues.

This is diametral opposite to:

>my reading is that the community believes that the fun factor of more
>uniformity when dealing with a lot of packages justifies the restriction
>of maintainer preference when there's not a sufficient justification for
>a tool other than dh.

No. A maintainer normally deals with their own packages, or with
.dsc and debdiff, for NMU. (This is also an answer to the reply
from wrar. Oh, jonas also said so, reloading the list index page.)

Yes, some must learn those ways, but I don’t mind; that doesn’t
mean I’m more comfortable in dh7. Usually I’m not except for
extremely simple packages, or, partially, really new packages.

>You're absolutely right that there is a tradeoff here.
>And I think that Debian of 10 or 15 years ago would have evaluated the
>tradeoff between the needs of a single maintainer and the needs of
>people doing work across a lot of packages differently.

Is “the Debian of today” the *Debian* of today, or just a couple of
very involved people?

Do you consider all those people who just take care of their own
package, or couple of packages, in what little spare time they have?

I doubt those very involved people, with hundreds of packages in their
DDPO already (don’t laugh, I saw that), could shoulder the burden, were
those others to leave disgruntled by things being forced onto them.

bye,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
        -- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Andrey Rahmatullin-3
In reply to this post by Jonas Smedegaard-2
On Tue, Jun 04, 2019 at 04:10:38PM +0200, Jonas Smedegaard wrote:

> > > I’d also throw in that monocultures are not good, and that people in
> > > general are happier when they aren’t forced into anything.
> > Yet people in general are also happier when they don't need to learn
> > all ways to do something.
>
> Who says people need to learn _all_ ways?
>
> Must we all learn the ways of Java and DKMS and Haskell and and...?
>
> Nice if we can _generally_ handle _most_ packages.
To be able to handle most packages we must mandate that most packages use
an uniform workflow. That's different from "monocultures are not good"
etc.

--
WBR, wRAR

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

Re: Do we want to Require or Recommend DH

Ian Jackson-2
In reply to this post by Thorsten Glaser-7
Thorsten Glaser writes ("Re: Do we want to Require or Recommend DH"):
> No. A maintainer normally deals with their own packages, or with
> .dsc and debdiff, for NMU. (This is also an answer to the reply
> from wrar. Oh, jonas also said so, reloading the list index page.)

"Maintainer" is precisely the hat we wear when working on our own
packages.  But working with Debian is much more than just working on
our own packages.

There is QA work on the many packages with no specific maintainer;
there are cross-archive campaigns such as reproducible builds,
architecture support, init system diversity, i18n/l10n, and so on.
There is RC bugfixing etc. to try to make a release.  There is
security support, stable release management, and backports.

And of course as users and downstreams we wish to exercise our
software freedom: ie to modify the programs that run on our computer.
That freedom being the point of Debian.

For all these tasks, we often need to interact with or modify the
package's build machinery (to varying extent).  That means learning
the build machinery of every package we work on - at least well enough
to accomplish the task at hand.

> Is 'the Debian of today' the *Debian* of today, or just a couple of
> very involved people?

Well, Sam posed a consultation here on debian-devel.  My assessment of
the rough consensus of the discussion here is very similar to Sam's.
Do you agree with Sam's assessment of the apparent consensus on this
list ?

If not, how do you think the question you pose should be answered ?
Since it is a question of tradeoffs, with no definite right or wrong
answer, perhaps we should hold a GR ?  What do you think the result of
such a GR would be ?

I think such a GR would be a collosal waste of time.  This issue is
not important enough.  In particular, because the consensus is *not*
that you will *have to* change your packages.  What this discussion
has mostly concluded is that we should issue a *recommendation*.
*Not* a mandate.

You may be gently encouraged to change your packages.  In practice if
you refuse, it is not likely that anyone will want to fight you over
it.  You will probably be able to leave the bug open "wontfix", if
there is a bug at all, indefinitely.

> I doubt those very involved people, with hundreds of packages in their
> DDPO already (don't laugh, I saw that), could shoulder the burden, were
> those others to leave disgruntled by things being forced onto them.

So, nothing will be forced onto you and you do not need to fight this.


But I would like you to consider this: the primary responsibility of
the maintainer of a Debian package is a *management* responsibility.
Our job as maintainer is not to do all the work.  If we like to do the
work ourselves, great.  If we don't and the work goes undone, well,
c'est la vie; maybe someone else will have the energy.

But our one un-shirkable responsibility is that of creating an
environment where *others* can contribute.

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: Do we want to Require or Recommend DH

Andrey Rahmatullin-3
In reply to this post by Thorsten Glaser-7
On Tue, Jun 04, 2019 at 02:27:03PM +0000, Thorsten Glaser wrote:
> No. A maintainer normally deals with their own packages, or with
> .dsc and debdiff, for NMU. (This is also an answer to the reply
> from wrar. Oh, jonas also said so, reloading the list index page.)
A maintainer normally deals with their own packages, except those people
who actually prepare that NMU debdiff, yeah. Not sure what did you mean by
this.

> Yes, some must learn those ways, but I don’t mind;
Does this mean "some must learn many different things to be able to make
NMUs, but I don’t mind" or am I mistaken?

--
WBR, wRAR

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

Re: Do we want to Require or Recommend DH

Thorsten Glaser-7
In reply to this post by Ian Jackson-2
Ian Jackson dixit:

>There is QA work on the many packages with no specific maintainer;

Sure, in that case I’ll have to take it over or deal with it.

>there are cross-archive campaigns such as reproducible builds,
>architecture support, init system diversity, i18n/l10n, and so on.

These are done by specialists. I didn’t say *nobody* would need
to learn the others, just that not *everyone* needs, especially
not at first.

>There is RC bugfixing etc. to try to make a release.  There is

This is either a good learning chance, or just tackle an RC bug
in another package.

>security support, stable release management, and backports.

Again, specialists.

>Well, Sam posed a consultation here on debian-devel.  My assessment of
>the rough consensus of the discussion here is very similar to Sam's.

My point was to raise concerns of mine.

>Do you agree with Sam's assessment of the apparent consensus on this
>list ?

I’ve not read the entire discussion here. I stumbled upon this
by reading the DPL news and thus posted because I feared that
the point important to me might be underrepresented.

>Since it is a question of tradeoffs, with no definite right or wrong
>answer, perhaps we should hold a GR ?  What do you think the result of
>such a GR would be ?

Hmm, did not consider it, but a GR could fight being forced to
use dh7 if needed. Thanks for the idea.

>You may be gently encouraged to change your packages.  In practice if
>you refuse, it is not likely that anyone will want to fight you over
>it.  You will probably be able to leave the bug open "wontfix", if

Perhaps. Perhaps not. Perhaps, if that’s acceptable, it’ll be enough.

>there is a bug at all, indefinitely.

If. If it isn’t, leaving it wontfix or closing is guaranteed to be
acceptable. If it is, some clarification that it is acceptable is
needed or we’re entering vague territories (such as, where people
who don’t like a maintainer file RM requests against their packages
because they don’t follow this-and-that latest fad).

>So, nothing will be forced onto you and you do not need to fight this.

If optimistic, yes.

>But I would like you to consider this: the primary responsibility of
>the maintainer of a Debian package is a *management* responsibility.

Oh sure. But I just want to make the world better by packaging some
software for Debian, some of which I happen to be upstream of, some
of which I happen to have become upstream because of packaging it.
I occasionally join in teams, but mostly just wish to quietly do my
thing, undisturbed.

>But our one un-shirkable responsibility is that of creating an
>environment where *others* can contribute.

Oh, sorry, but, I disagree. Others can contribute in other packages,
I can do mine just fine. (Of course, the occasional contribution is
welcome, but I’m not going to bend my ways for it.)

Just like when I contribute somewhere, I’m, sometimes extremely rudely,
asked to take my problem (or even patch) upstream myself or go sod off.

bye,
//mirabilos
--
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.  <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Vincent Bernat-3
In reply to this post by Ian Jackson-2
 ❦  4 juin 2019 15:47 +01, Ian Jackson <[hidden email]>:

> If not, how do you think the question you pose should be answered ?
> Since it is a question of tradeoffs, with no definite right or wrong
> answer, perhaps we should hold a GR ?  What do you think the result of
> such a GR would be ?
>
> I think such a GR would be a collosal waste of time.  This issue is
> not important enough.  In particular, because the consensus is *not*
> that you will *have to* change your packages.  What this discussion
> has mostly concluded is that we should issue a *recommendation*.
> *Not* a mandate.
Well, a GR can be quick and it would help to know where people stand
instead of having a few vocal people decide for everyone. I think we
should impose the use of "dh" for bullseye (with an exception for teams
with more then 50 packages), but I honestly don't know how much this
opinion is shared.

It seems there is a pattern to dissuade people to hold a GR. The last GR
I remember is about changing "Chairman" to "Chair" in our constitution.
I don't remember it was a waste of time and it was pretty quick. And the
last "technical" GR was for systemd in 2014. We are in a project where
it is very hard to be heard because you can only participate in endless
debates.
--
Let him choose out of my files, his projects to accomplish.
                -- Shakespeare, "Coriolanus"

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

Using GRs

Sam Hartman-3

I definitely think that we should use GRs more.  I think that the DPL
can use their power to propose GRs to put a GR on the table with the
common set of ballot options in a way that I hope might be seen as
facilitating a discussion rather than trying to override people.
I absolutely am happy using that power to break deadlocks and end
endless discussions.

I don't see a deadlock that needs breaking on the dh issue at this time.
Right now we seem to be on track for being done June 16.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Alf Gaida
In reply to this post by Vincent Bernat-3
>> I think such a GR would be a collosal waste of time.  This issue is
>> not important enough.  In particular, because the consensus is *not*
GR's can be man made a collosal waste of time.

> Well, a GR can be quick and it would help to know where people stand
> instead of having a few vocal people decide for everyone. I think we
> should impose the use of "dh" for bullseye (with an exception for teams
> with more then 50 packages), but I honestly don't know how much this
> opinion is shared.
I followed the discussion closely but i don't get some points. I assume
that "dh" is here to stay - so in that case new packages should be done
with "dh", older packages should be converted. There might be some
packages which are not worth the additional work. Just leave a note why
and everyone is happy. So a GR would be a appr. tool to solve this
endless discussion fast.
> last "technical" GR was for systemd in 2014. We are in a project where
> it is very hard to be heard because you can only participate in endless
> debates.
I for myself have no time for endless debates - i have things to do in
Debian and upstream. And it's just boring to read the same arguments pro
and esp. contra again and again. I was quiet until now because the
debate don't change anything for me firsthand. I use dh for all my
packages already and don't think i will change it in the future. The
very most packages i'm interested in are dh - so no problem for me to
read and maybe fix them if needed. Will i touch complex things written
in cdbs? Hell no. Will i touch other complex things not in dh - hell,
no, not worth the time. One might think of as a bit stubborn or short
sighted, but to be true: It's lack of motivation - learning a bunch of
things i'm not interested in to change things i'm not that interested
in? Sounds nuts.

A solution could be: Deprecate some thing like cdbs an others if they
are really deprecated, be verbose about why and don't let packages that
using these things go into the repository. Can be done stepwise.

My 2¢

Alf

Reply | Threaded
Open this post in threaded view
|

Re: Do we want to Require or Recommend DH

Andreas Tille-5
In reply to this post by Thorsten Glaser-7
On Tue, Jun 04, 2019 at 03:06:13PM +0000, Thorsten Glaser wrote:
> Ian Jackson dixit:
> >But our one un-shirkable responsibility is that of creating an
> >environment where *others* can contribute.

@Ian:  I really like that quote that could define a modernised Debian.
 
> Oh, sorry, but, I disagree. Others can contribute in other packages,
> I can do mine just fine. (Of course, the occasional contribution is
> welcome, but I’m not going to bend my ways for it.)

IMHO this specifies Debian 15 years ago.  I fear this attitude will
decrease the relevance of Debian in future if we do not have the power
to change.

Kind regards

       Andreas.

--
http://fam-tille.de

1 ... 3456