Re: Bits from the Release Team - Kicking off Wheezy
On Sat, Apr 30, 2011 at 12:28:06PM +0200, Stefano Zacchiroli wrote:
> Size is just one ingredient. There are plenty of other ways to diminish
> barrier to deploy big changes in Debian: wider commit access rights,
> larger VCS repositories, more liberal NMUs, etc. (Unsurprisingly,
> several Debian derivatives have decide to pursue those other ways and
> one might argue that they have done so learning from Debian experience.)
[...]
Oh yes, you really want to "attract" new contributors ? build debhub.com
(as in github) and force everyone to package stuff in there. Let people
propose patches, packaging new upstreams and so forth using merge
requests (as in github), and there you'll be attractive. We would have
invented "social packaging" (so 2.0-ish), and also lower the difficulty
to contribute patches in a more efficient way than the BTS (sorry but
the BTS *isn't* a tractable way to do heavy lifting, it's only good to
send small unrelated patches).
Also, I read about the idea of bringing PPA to Debian (which IMO is a
good idea, I know lots of people around me — me including for chromium
at the time when it wasn't in Debian yet — using Debian + PPA
repositories, it's useful). Well, PPA can be built atop "forking"
packages.
Sadly this will probably never happen because we're too large to decide
and agree upon a single VCS. And building something like that wouldn't
be successful with 4 very different VCSes (svn, git, hg, bzr). So
probably just a dream.
FWIW I think that "rolling" or "CUT" miss the point entirely. As a
Debian user I use stable on my servers (with a few backports for the 3-4
things I need bleeding edge for). For my desktop I use unstable, and
when that breaks (which is *very* rare, really) I go to snapshots and go
back a few versions. I couldn't care about testing any less. And at
work, every person I know either uses just stable or does the same as
me. I know no testing user around me. Of course I'm not pretending I
know the absolute Truth, but well, I find this whole "users want testing
badly" thing dubious.
No what we want is probably to be attractive to developers, while
keeping our standards about the stable release, which is what really
matters. And to do that, well, what we need is to make working for
Debian easier. Not harder. rolling is making working for Debian harder,
hence is a bad proposal. Harder because it means people will have more
work for a package. Maintainers are (me included) often too lazy to
prepare Stable updates because it's a PITA to have to work on a 1-yo
version of the package. Why would they be more motivated to work on
testing packages?
No we should focus instead on making packaging easier, not adding new
constraints, new goals. Here are a few thoughts on how to do that.
- enable PPA-like stuff, auto-built (best-effort).
- link that PPA stuff to the main repository in a way that "merging"
PPA into unstable is just a matter of one single command, or a few.
- make it easy for users to subscribe to PPAs, meaning you have to
have some kind of directory of PPAs with categorization (quite
stable, very experimental, gnome stuff, mozilla stuff, …whatever any
valuable information for the user IOW).
- PPA should focus on:
* co-installability when endurable;
* documented and working rollback to unstable (IOW downgrading a
package to unstable when co-installability is not possible
should work well enough, idealy using pinning and apt, but a
documented procedure is good enough too).
- get rid of experimental that would mostly become useless as PPA
would clearly be a superset of the features.
- make it easy to create new PPA repositories (aka "forks") for every
DD. Of course some attention not to overload buildd resources is
important so maybe "forks" should be restricted to a few
architectures instead of all of them.
- link anything that is uploaded to this PPA-like stuff tied to a
public VCS with some kind of VCS-agnostic wrapper that allow
maintainers to look at the patches corresponding to a given "forked"
PPA, allowing him to cherry-pick/merge IOW take what he thinks is
worthwhile.
- ideal build on top of that some kind of publish/notify (merge
requests in github) feature so that the "upstream" maintainer
doesn't have to know about who forks him to be notified when someone
has worked on a patch for his package.
- last but not least, make it sure that the PPA-like infrastructure
works with software that can be installed elsewhere, not
necessarily on Debian infrastructure, so that non DDs can set-up
their one PPA-like setup and fork Debian PPAs into them and still be
able to submit "merge requests". This would be distributed-PPAs, and
would be git "git" of packaging.
This would drastically lower the bar for many things:
- contributing to Debian ;
- propose coherent set of experimental packages (in experimental it's
very hard to test "the new xorg release" because it's impractical to
filter xorg packages from say the new KDE that sits in there at the
same time).
Testing is a Release Team tool before anything else. I don't think that
making it more complex is gonna be of any help. It'll just kill the
release team even more, and won't really solve anything. Plus I don't
think that testing is broken, it serves its purpose well.
What is broken is experimental. It has been created because 3 layers
weren't enough, but it hasn't really been thought more than that. If you
let me pursue the VCS analogy, just look at how git is developped. There
are 4 spaces:
- master: the releases (our stable)
- maint: where the fixes go until it's merged into master
(our stable-updates, somehow), and where next is merged when
next is released.
- next: where the devel happens, but nothing enters that before it
has seen enough peer-review. This is our testing+unstable.
- pu: as "proposed-updates". There are totally unrelated topic
branches here, glued together to check nothing is grossly
broken, but it's rarely a working branch, or rather it's
often broken. This is our experimental
What is my point: nobody uses pu as a whole, instead there are a lot of
topic branches that people can chose to enable in their "next", because
Junio always takes care that all topic can be merged into next. "pu" is
just a directory of them all. Then when a topic branch becomes "good
enough", it gets merged into next, and leaves pu.
We could make experimental (using a PPA-like decentralized
infrastructure) work like that. It would clearly make our users more
confident testing "experimental" stuff because each PPA is distinct from
the other and you don't risk pulling to much crap on your system.
It would solve the issues of e.g. reworking the packaging of llvm-2.8
(creating a llvm-2.8-NG PPA) and working on llvm-2.9 at the same time.
It would allow us to make all the software that is in "unstable only"
purposely go away (*-snapshot packages e.g., like gcc-snapshot and
similar) because a PPA would be the place to go.
And I'm sure there are lots of other good things it allows.
But really, let's focus on relieving the expensive scarce resource (aka
manpower, developers, maintainers) instead of adding burden on it for a
dubious claim that users want it. If you add more burden to the scarce
resource, instead of grabbing new "users", you'll end up with worse
quality and actually lose users: it's a lose-lose scenario on the long
term.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Reply to: