In practical terms, it would probably be made easier if it was
mandatory for all packages to be on Salsa, either in the 'debian'
namespace or in a team namespace (but not under individual users).
Please don't get me wrong: I do not consider Fedora a commercial
entity. I simply subscribe the statement that we are facing some
problems in Debian since we are not a commercial entity.
I think the framing is slightly misleading: it's true that a
commercial entity with a hierarchical structure would not have the
same issue, but the point I am making is that there's nothing stopping
a non-commercial entity from having a structure that allows the same decision-making and executing, as proved by Fedora.
Hence, it's not
just the fact that Debian is not a commercial entity that leads to the
status quo, but the combination of not being a commercial entity
_plus_ precise and explicit choices about project governance.
If you compare this to Debian what exactly is your proposal to change
for the better?
For starters there needs to be a decision on whether the status quo is
fine or change is needed. That is non-obvious, I have my opinion but
others will have theirs. It would mean the end of "my package is my
fiefdom", and a move towards collective maintenance.
From the organizational point of view, it would require a GR to change
in the constitution to enshrine the power to take technical decisions
and make them happen into a constitutional body - the CTTE will
probably say "no no no not us, please, no", but I'm pretty sure that's exactly where such power should reside, especially because they don't
want it.
A procedure to submit proposals for discussion with the whole
project should be established (we already have the DEP process for
example), that ends with a vote of the decision makers body. And once
the body makes a technical strategy decision, them or whoever they
want to empower, can go and make it happen, without having to walk on eggshells and dance around sacred cows - the time to dissent and
discuss is _before_ the decision is made, not _after_.
In Fedora every
proposal must include a criteria to allow declaring that the game's a
bogey and plan to rollback, in case something goes wrong, but this is
again decided by the decision makers body.
In practical terms, it would probably be made easier if it was
mandatory for all packages to be on Salsa, either in the 'debian'
namespace or in a team namespace (but not under individual users).
Then perhaps for each approved decision, until the project is
completed the implementer(s) would automatically get write access to
all teams namespaces to push the changes - as MRs because reviews are
good, but with the powers to merge them too.
I'm getting ahead of myself, but hopefully you get the idea.
Hi Marc,
Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
On Wed, Apr 03, 2024 at 10:37:37AM +0200, Andreas Tille wrote:
"we now use Wayland
instead of X11", "please don't create your system users with adduser and more, use a declarative approach".
At the moment, we simply dont take such decisions. I think that's a problem.
I think I get your point now. Thanks for these examples. You might
have a point in these specific ones but I see Debian leading in other aspects.
As far as I know other major distributions do not undertake the time_t
64bit transition (whether this marks leadership or not is questionable
but it will make us the leading distribution on those architectures in future).
I'm not well informed about other distributions but seeked the internet
and for instance found some article about reproducible builds from
2019[2] where Debian and ArchLinux are mentioned frequently but Fedora
is not. I've picked that older article since taking the lead means who started that effort and I think we are in this game.
Apropos ArchLinux: I would love if Debian would manage to craft such a
great documentation in Wiki. That's not a "technological" lead but
we've lost the lead in documentation by far which is in my perception a weaker point than the time we adopt one or the other technical change.
I think we are doing a good job regarding CI with adding autopkgtests
(but we could do even better for sure). I'm not informed about the
status of CI in other distributions and whether there exists something
like Salsa CI. I'm positively convinced that Debian has reached a level
of complexity which makes CI tests mandatory for every important package
and I would love if we could do the lead here.
Are our technical
decision-making processes up to today's challenges?
Would you mind clarifying this question? We have the CTTE as decision-making instance but I'm not sure whether you are refering to this.
The CTTE is a tie-breaker which is only invoked to resolve a fight. And
if invoked, the decision takes months. In other sitations, we keep
fighting in the open, probably doing a GR, which makes the news even
before we have decided anything.
That's the price we currently pay for being not a commercial entity,
I fully subscribe to this statement.
so
that we don't have a project leader who has the power to say "we're
going to do X", like the board or the managing director of a commercial company has.
I consider the DPL as a "Leader with no power". Convincing a huge
number of volunteers to pull a string into the same direction is a way
harder job than telling employees of a company what to do next. I'm
aware of this challenge.
Seriously, I don't how Fedora takes their technical
decision, but there has to be a reason why they're so far ahead of us technologically.
I need to admit that I (currently) don't know much about Fedora (but I
hope I could fix this in the near future). At Chemnitzer Linuxtage I
took the chance to talk to OpenSUSE and Nix about organisatorical
solutions. There was no booth by Fedora I could show up.
There are many people who see Debian as a technology project, with the technical goal of producing The Universal Operating System.
What are you planning to do to Debian from a technical and technological point of view? What do we well, where do we suck on the technical site?
If we do suck in some technical points, what are you planning to do to improve those things?
What is your position about technical leadership?
Are our technical
decision-making processes up to today's challenges?
Thanks for your consideration to answer these questions despite
platforms containing language about this topic.
Hi Luca,
Am Thu, Apr 04, 2024 at 12:47:11PM +0100 schrieb Luca Boccassi:
That's the price we currently pay for being not a commercial entity,
I fully subscribe to this statement.
I don't think commercial entities have anything to do with this.
Fedora is not a commercial entity (please, no FUD about RH) and yet it
can take decisions and implement them just fine. It's entirely a
question of self-organization and what rules we decide for the
project.
Please don't get me wrong: I do not consider Fedora a commercial
entity. I simply subscribe the statement that we are facing some
problems in Debian since we are not a commercial entity.
I need to admit that I (currently) don't know much about Fedora (but I hope I could fix this in the near future). At Chemnitzer Linuxtage I took the chance to talk to OpenSUSE and Nix about organisatorical solutions. There was no booth by Fedora I could show up.
In short, Fedora project members elect a technical committee, FESCO. Project members can submit proposals to this committee for
project-wide changes, which votes on whether to approve them or reject them. If they are approved, the committee and the proposer are
empowered to enact the changes distro-wide - whether individual
package maintainers like them or not. An approved proposal can fail
and be rolled back for technical reasons (e.g.: unexpected issues crop
up at implementation time), but not because random package maintainers practice obstructionism because they don't like the decision.
If you compare this to Debian what exactly is your proposal to change
for the better?
From the organizational point of view, it would require a GR to changein the constitution to enshrine the power to take technical decisions
In practical terms, it would probably be made easier if it was
mandatory for all packages to be on Salsa, either in the 'debian'
namespace or in a team namespace (but not under individual users).
Realistically, even if you decide "everything is now team maintained", if there is only 1 person who cares about a certain package there won't be any team member doing anything about it. So having it on salsa or whatever won't really do much, besides being annoying for people who have to change their workflow for no reason.
Also let's not forget that it is expected for people who are not DD to contribute to debian, and they can only create repositories on salsa under their own name (for good reason, mostly).
Am Thu, Apr 04, 2024 at 02:41:00PM +0100 schrieb Luca Boccassi:
Please don't get me wrong: I do not consider Fedora a commercial
entity. I simply subscribe the statement that we are facing some problems in Debian since we are not a commercial entity.
I think the framing is slightly misleading: it's true that a
commercial entity with a hierarchical structure would not have the
same issue, but the point I am making is that there's nothing stopping
a non-commercial entity from having a structure that allows the same decision-making and executing, as proved by Fedora.
Well, do you think well-respected members of our community who disagree
with a change of structure are "nothing"? In preparation of my platform
I started kind of a test ballon inside DPT where I spotted something I considered wrong inside the team policy and suggested a change[1].
There were a lot of positive responses and finally the change was
accepted. But even before this happened we've lost two major
contributors[2] (leaving more or less silently) and [3]. I confirm I
made mistakes in this process and hopefully learned from it.
So we have to deal with people and changing a structure that has evolved
over >30 years might be harder than in the case of other distributions
with a different history. IMHO changing a structure is harder than
creating one from scratch.
_plus_ precise and explicit choices about project governance
Hence, it's not
just the fact that Debian is not a commercial entity that leads to the status quo, but the combination of not being a commercial entity
_plus_ precise and explicit choices about project governance.
I'm kindly inviting everybody to join me in drafting a GR about this (no matter whether I might get elected or not).
If you compare this to Debian what exactly is your proposal to change
for the better?
For starters there needs to be a decision on whether the status quo is
fine or change is needed. That is non-obvious, I have my opinion but
others will have theirs. It would mean the end of "my package is my fiefdom", and a move towards collective maintenance.
I share this opinion 100%.
From the organizational point of view, it would require a GR to change
in the constitution to enshrine the power to take technical decisions
and make them happen into a constitutional body - the CTTE will
probably say "no no no not us, please, no", but I'm pretty sure that's exactly where such power should reside, especially because they don't
want it.
I fail to see the logic in this "especially because they don't want it"
but I agree that I see the potential decision making body in the CTTE.
To say it clearly: It should by no means be DPL (and I hope your logic
does not apply to this statement as well. ;-P )
A procedure to submit proposals for discussion with the whole
project should be established (we already have the DEP process for example), that ends with a vote of the decision makers body. And once
the body makes a technical strategy decision, them or whoever they
want to empower, can go and make it happen, without having to walk on eggshells and dance around sacred cows - the time to dissent and
discuss is _before_ the decision is made, not _after_.
To stick to one example I gave in an other thread on this list: Assuming
we decided to move all packages on Salsa, I could start importing
packages that are not on Salsa and upload these starting from the day
after this decision without asking the maintainer?
In Fedora every
proposal must include a criteria to allow declaring that the game's a
bogey and plan to rollback, in case something goes wrong, but this is
again decided by the decision makers body.
Interesting detail which is probably not feasible for every decision
(since its hard to imagine how to roll back a "move all packages on
Salsa" decision).
Am Tue, Apr 02, 2024 at 10:12:56PM +0200 schrieb Marc Haber:
There are many people who see Debian as a technology project, with the technical goal of producing The Universal Operating System.
What are you planning to do to Debian from a technical and technological point of view? What do we well, where do we suck on the technical site?
I see a big problem that we do not follow common standards. While we
have some teams with strict policies setting those standards internally
to a different level of strictness there is no Debian wide consensus
about things like
A. Packages should be maintained on Salsa
B. Lets use dh (if possible - I was told there are exceptions)
C. Commit to latest packaging standards
D. Make more than one person responsible for a package
E. General QA work of contributors not mentioned as Maintainer /
Uploader
[I will reference these items below by their letters]
I'm addressing this in the paragraph "Packaging standards" of my
platform. I'm also very concerned about packages who don't get
any attention any more ("smelly packages") which has two major
reasons:
1. We do not have contributors with free capacity to care for
problems in other peoples packages
2. Even if we had those the strict ownership of packages pevents
that new contributors can step in. When reading the paragraph
about NMUs in developers reference[1] this is probably
sensible for actively maintained packages - but what about
those packages which do not show any activity for years?
I notived you are maintaining
select count(*) from (SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url like '%salsa%') tmp;
20
packages on Salsa in various teams. Great! You also have
udd=> SELECT DISTINCT source, maintainer, uploaders, vcs_browser FROM sources WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url not like '%salsa%' order by source;
source | maintainer | uploaders | vcs_browser
----------------------+----------------------------------------------+-----------+--------------------------------------------------------------------------
apg | Marc Haber <mh+debian-packages@zugschlus.de> | | http://git.debian.org/?p=collab-maint/apg.git;a=summary
console-log | Marc Haber <mh+debian-packages@zugschlus.de> | | http://git.debian.org/?p=collab-maint/console-log.git;a=summary
dnstop | Marc Haber <mh+debian-packages@zugschlus.de> | | http://git.debian.org/?p=collab-maint/dnstop.git;a=summary
policyrcd-script-zg2 | Marc Haber <mh+debian-packages@zugschlus.de> | | http://git.debian.org/?p=collab-maint/policyrcd-script-zg2.git;a=summary
(4 rows)
I verified on Salsa that all those are imported to debian/ name space on Salsa (which is also great - I have seen lots of other packages who are
not imported to Salsa). It would help if you could sooner or later
consider uploading those packages.
When seeking for other reasons I've
found 11 bugs via
udd=> SELECT id, package, source, arrival, severity, title FROM bugs WHERE source IN (SELECT DISTINCT source FROM sources WHERE release = 'sid' and (maintainer ilike '%Marc%Haber%' or uploaders ilike '%Marc%Haber%') AND vcs_url not like '%salsa%');
which I will not list here to not lengthen this mail. My guess is you
are aware of this but have reasons / time constraints to not act for the moment.
What would you think if someone would push the following
commits and uploads to unstable:
1. Fix vcs_url + vcs_browser (A.)
2. Fix some bug(s) (E.)
3. Runs Janitor / routine-update which changes (C.)
4. Converts to dh (if not yet which I did not checked) (B.)
5. Turn d/copyright into machine readable form (if not yet which
I did not checked) (C.)
6. Finds a team where the package fits into moves the repository
to that team space and moves you to Uploaders (D.)
Assume you will be asked about those changes but you have no time
to answer (for whatever reason). What of those changes is OK for
you and how long would you expect the potential contributor to your
packages to wait until taking action?
What is your position about technical leadership?
IMHO we could gain/keep technical leadership if we would manage to apply
our technical standards to all the things we consider important.
Are our technical
decision-making processes up to today's challenges?
Would you mind clarifying this question? We have the CTTE as
decision-making instance but I'm not sure whether you are refering to
this.
Thanks for your consideration to answer these questions despite
platforms containing language about this topic.
I hope this answer contained the amount of details you were expecting.
On Thu, 4 Apr 2024 at 21:30, Salvo Tomaselli <tiposchi@tiscali.it> wrote:
In practical terms, it would probably be made easier if it was
mandatory for all packages to be on Salsa, either in the 'debian' namespace or in a team namespace (but not under individual users).
Realistically, even if you decide "everything is now team maintained", if there is only 1 person who cares about a certain package there won't be any team member doing anything about it.
So having it on salsa or whatever won't
really do much, besides being annoying for people who have to change their workflow for no reason.
Sure, but this is in the context of project-wide changes discussed above.
Also let's not forget that it is expected for people who are not DD to contribute to debian, and they can only create repositories on salsa under their own name (for good reason, mostly).
Such contributors need a DD sponsor, which means access can be granted
to individual repositories.
Am Wed, Apr 03, 2024 at 05:53:46PM +0200 schrieb Marc Haber:
I think this can't just be seen by looking at the statistiks. Many small packages do their job and don't need constant attention as long as they still build and work.
I agree that pure statistics is not telling the whole story. However,
those statistics give some feeling about the issue which for sure needs
to be verified on case-by-case basis. I can assure you that I usually inspect the list of smelly packages[1] whether there are hits for my
name (currently one false positive and one package where I'm forced to
use cdbs) but also look for packages I might be able to salvage from
there. I've found some impressive hits for this purpose in the past
that are supporting my point besides stupid statistics.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 36:18:14 |
| Calls: | 6,707 |
| Files: | 12,239 |
| Messages: | 5,353,434 |
