On 2013-03-14 19:55, Stefano Zacchiroli wrote:
This "inertia" folklore is surely supported by past history of the
time
it took us to deploy specific changes in large sets of packages. But
on
the other hand, in the last 5 to 10 years we have massively improved
our
ability to decide and deploy large changes by the means of: (a) large
maintenance teams who are able to decide on "their" packages and
deploy
changes using shared-access VCS, and (b) a more liberal use of NMUs
than
in the past.
It looks like I'm late to this thread: I don't see a lot of difference
between my opinions and what's already been written.
Questions for the candidates:
- on the judgement spectrum between "there is no inertia in Debian
and
that's good" and "there is a lot of inertia in Debian and that's
bad",
where would you put yourself?
I would agree with Steve:
Steve Langasek wrote:
(Being slow to implement technical consensus is a bad thing; but
inertia
that prevents changes from being foisted on the project before there
*is*
consensus is a *good* thing.)
I think that there can be too much inertia in specific cases, but that
tends to be correlated with weaknesses around the proposed tools.
- if you don't think that we're at our best on this front, what do
you
propose we change to improve?
In my platform I suggested that we might make distribution-wide changes
quicker by more vocally authorising NMUs to help with changeovers.
Separately, we might be able to improve integration between BTS patch
submission and package VCSs, especially for a "standard" VCS and
workflow.
However, I don't think the DPL is always best-placed to work on these
issues. As another example, although git is becoming the standard VCS
for now, it would probably have had quicker adoption with a clearer UI,
quicker agreement on best practices for packaging with git, and better
documents targetted at existing Debian maintainers. But while the DPL
can encourage people to improve UIs, agree on best practice, and write
better documents, someone who wants to focus on these things would
likely be better to work on them directly than try to do it by becoming
DPL.
- Debian should use the Technical Committee more proactively than we
presently do, to decide on "any technical matter where Developers'
jurisdictions overlap"; not only to solve conflicts (as we already
do), but also to *design* forthcoming changes in an authoritative
manner. [ Many large FOSS projects out there have technical boards
that work that way. ]
I don't think we are short of technical proposals in Debian, to need to
weigh down the Technical Committee with designing them.
In some cases, it could make sense for the Technical Committee to
declare a winner from several proposals, but even in this case I would
prefer the proposals to already have working implementations.
- Debian should decide to use a single VCS (say, Git), for all
packages,
uniform repository structure and work-flow, and give by default
read/write access to all DDs. This would allow push-button changes
to
all packages in the archive. We often speak about "reducing
package
ownership" during DPL campaigns, well, this is the ultimate step of
it. [ Ditto: I know no other large FOSS project out there allowing
the extreme diversity in VCS, work-flow, and ACLs that we have in
Debian at present. ]
I think we could get most of the positive benefits without forcing
everyone to use this VCS. Where maintainers aren't using it, changes
could be automatically committed by the archive tools on upload.
It seems likely to me that the additional benefit from forcing all
maintainers to use the single system for their work-in-progress would be
outweighed by the number of contributions we would lose as a result.
- Debian should seek more direct involvement from companies whose
businesses depend on Debian, so that their employees can help
volunteers in pushing archive-wide changes (once they're decided).
[ If you allow gatekeepers this would become, essentially, the
Linux
kernel development model. ]
I don't see that we stop companies' employees doing this currently. I
don't think that we have, or should have, a different barrier to wide
changes because someone is doing the work for a company.
It would be possible to ask companies to work on specific changes, but
in general they will naturally decide to work on items that are useful
to them, and won't work on ones that are not useful to them even if we
ask nicely. Where items are general blockers, that should be publicised
generally, not only to companies.
--
Moray
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/a73c88bc3efa77973876195aeb05b...@www.morayallan.com
