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 madco...@debian.org OOO http://www.madism.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110430233219.ga14...@madism.org