Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Moray Allan <moray <at> sermisy.org>
Subject: Re: [all candidates] on distribution-wide changes and scalability
Newsgroups: gmane.linux.debian.devel.vote
Date: Friday 15th March 2013 16:41:31 UTC (over 4 years ago)
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
 
CD: 3ms