Re: Bits from the Release Team - Kicking off Wheezy
Heya, Raphael, it would be so great to reply to messages in single mails instead of squeezing (are you release-themed, or what?) all of your answers into one mail. I'm really tired of chasing a specific answer From you through the whole thread. Raphael Hertzog writes: > But I don't plan to work on any of those if the project does not agree to > promote testing to something that can be advertised as usable by end-users > and as something that we strive to support on a best-effort basis. What does a best-effort basis mean? Who is going to install a "rolling" release instead of "testing"? I cannot imagine a use case where this might make sense, and I haven't found any presentation of one by you. Marc pgpYD4XASJLPW.pgp Description: PGP signature
Re: limits for package name and version (MBF alert: ... .deb filenames)
* Ben Hutchings , 2011-04-23, 15:06: [...] === version, strings longer than 30 (unique ones) === 0.9.15+post20100705+gitb3aa806-2 0.0.0+git20091215.9ec1da8a-2+b2 1.0.0~alpha3~git20090817.r1.349dba6-2 1:2.5.0~alpha4+svn20091009-1+b2 2.1.14+2.6.32.13-201005151340-1 1:2.2cvs20100105-true-dfsg-5+b1 0.9.8+hg20101101.b35a000870cc-1 0.5.10~alpha0+git201005030944-2 1.1.1+ooo-build3.0.0.9+r14588-9 1.2.0~pre3+snap20071004+dfsg-3+b1 3.0~a2+hg1075.9a478044c65c~dfsg1-1 Clearly, all of these are able to wrap name within 30 chars. [...] I would like to see policy forbid the use of commit hashes in versions. They aren't ordered, and the information about exactly which commit the snapshot was can be included in the changelog. Seconded. Mercurial revision numbers should not be used either as they are not consistent between repositories But they are stable within a single repository (as long as you don't perform lossless operations). And usually there is exactly one well-defined upstream repository, so if you know what you are doing (i.e., use their numbering), revision number can be good enough. (they really were a stupid idea in a distributed VCS). Local changeset identifiers are convenient; it's faster to type a few digits than to copy&paste a hash. -- Jakub Wilk -- 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/20110429233251.ga8...@jwilk.net
Re: Bits from the Release Team - Kicking off Wheezy
Raphael Hertzog wrote: > If the release team is open to try this out, I'm volunteering > to help implement this (i.e. at the very least managing transitions > while the rest of the release team is concentrated on patch review for > finalizing the stable release). I'am also happy to invest some effort > on updating our infrastructure to cope better with some of the problems > that we will face. And also on writing documentation to make it easier > to recruit new volunteers. Raphael, I don't think that the release team (nor the rest of project) need to be involved at this point (other than to be kept informed). You're certainly free to create an unofficial rolling.debian.net right now, set up new rolling-testing and rolling-unstable distributions with your own choice of transition/sync rules (including syncage from testing and unstable proper), and announce its availability to first adopters. The only point that the project needs to be involved is directly after the wheezy release, where you'll need to convince the release team to copy testing-rolling to testing proper and unstable-rolling to unstable. And even if they don't agree to that, the first adopters can manually re-upload their packages to the official upload queues. Actions speak a whole lot loader than words and design by committee is unlikely to get you anywhere. And a GR (as mentioned in your blog post) is overkill and unlikely to be productive anyway. Look at the "welcoming new contributors" GR; what did that actually accomplish? There isn't anything new to show for it, there are no new means to bring contributors in, and the number of new people hasn't really changed. So, really what I'm saying is just go for it. Prove that its something worthwhile so the project has a basis for adopting it. Best wishes, Mike -- 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/20110429185004.b9821953.michael.s.gilb...@gmail.com
Re: Bits from the Release Team - Kicking off Wheezy
Stefano Zacchiroli wrote:
> To complement that with even more user testing, I think we should
> consider advertising specific (late) frozen snapshots as
> alpha/beta{1,2,3} development releases. Several other distros are doing
> that and I do believe they have good reasons for doing so, which might
> apply to us as well. For once, it's undeniable that there is some
> "announcement effect" in the world we live in: at each development
> release we might hope to get more explicit testing than only relying on
> the "you can always test testing and let us know" philosophy.
>
> In the Squeeze release we have done better than before by calling for
> explicit upgrade testing (kudos to the Release Team!), but a specific
> plan of alpha/beta/... might bring even more testing, especially if the
> media help us out with some hype.
>
> This proposal comes with its own drawbacks, as the need of synchronizing
> with d-i releases and CD/DVD images, but that might be mitigating by
> saying that a specific alpha/beta/ is only for upgrades and not for from
> scratch installations. Any other drawbacks of doing development
> releases I might have missed?
FWIW, d-i already has a history of numerous beta releases, including CD
images, although it was somewhat crippled by our inability to call them
betas of Debian as a whole, not just d-i (although I think we managed to
fool some people about that), as well as our inability to target them to
a non-moving suite. Those release have kind of dropped off (there was
only one for squeeze), due to those issues and also limited manpower in
the d-i team, which needs to be kept focused on d-i (and not on fixing
eg, bugs in the desktop). All of which I tried to find a way to address
with the CUT proposal.
--
see shy jo
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
Lucas Nussbaum wrote: > On 28/04/11 at 12:05 -0400, Joey Hess wrote: > > And at the same time, having a non-frozen rolling release available > > during freeze time could easily distract people from working on > > testing/frozen at all, because a shiny rolling release that they and > > some users can use is still available. I am unhappy during the current > > choke point of testing being frozen, but that choke point does serve as > > an incentive for the whole project to work in the same direction: toward > > actually getting a good stable release out. > > That's not true. It serves as an incentive for a large number of DDs to > just do something else until the freeze is over and they can start > working on their packages again. (easy to show by looking at the number > of distinct uploaders over time, for example). I apologise for using the word "whole" and spawning an apparently useless sub-thread (though with some nice data I guess). Obviously, "the whole project" is never aligned at working on any one goal; however a freeze is the point in time at which more of the project is involved in getting the release out than other times. > > To most users of testing, a 5 month period when it > > doesn't update as much, but is also more constantly usable is mostly > > a draw; that period is when testing has the most new users. > > Interesting. Where does that information come from? Being subscribed and reading every message of debian-user for decades, as well as at least seeing the titles of all installation reports ever reported, as well as I think some popcon numbers. In other words: Gut feeling of an overfed neural network. -- see shy jo signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
* Stefano Zacchiroli (z...@debian.org) [110429 14:22]: > In general we need to promote the reduction of (potential) bottlenecks > in Debian rather than the contrary. ... and don't get me wrong: I'm very > well aware that this specific "bottleneck" is a very good feature to > have for the preparation of a stable release, given it means more > scrutiny and ultimately more quality. But given that "rolling" seems to > be willing to trade some of that stability off in favor of fresher > software, it might be warranted to lift it off there. Sorry, but I think that's really the wrong way to go. Someone needs to fix that brokeness in the end, and these "someone" is a very limited set of people. I can well remember the effort it took me to clean up testing after the last larger release managers exchange, and I'm not going to do that again. On the other hand, the entry barier into the release team isn't too high. If someone is willing to work e.g. only on encouraging packages fixing important bugs to testing faster, please get in contact with one of the release managers (or me), and we can certainly arrange something in the interesst of all. But just making more mess in testing for PR reasons doesn't sound like a good idea to me. Andi -- 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/20110429214853.gn15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* Raphael Hertzog (hert...@debian.org) [110428 22:16]: > On Thu, 28 Apr 2011, sean finney wrote: > > On Thu, Apr 28, 2011 at 02:55:31PM +0200, Raphael Hertzog wrote: > > > Good. I just want to point out that "frozen" built on top on rolling > > > (which is what we're proposing here) is different from "frozen" built on > > > top of unstable (which is what we had before the introduction of testing). > > > > Or more clearly: frozen built on top of the next release, after it is > > snapshotted/branched, you mean, right? > > No. Frozen in 199x started as a snapshot of unstable with all the > problems that unstable can have. The rules governing testing/rolling > ensure that a large class of problem simply cannot exist in that > distribution. I read about lowering the entry bariers so that packages with RC bugs and not being built on all architectures could enter your new testing. This doesn't sound like it fixes these issues. Besides, we usually have a few hundered RC bugs to get fixed after the freeze, and doing that via unstable has proven to work well. Andi -- 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/20110429214310.gm15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110428 20:21]: > Interestingly, you seem to be confused about RC bugs. ;) Can you please stop the ad-hominem attacks? Thanks. Andi -- 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/20110429214010.gl15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum (lu...@lucas-nussbaum.net) [110428 19:57]: > On 28/04/11 at 18:04 +0200, Mehdi Dogguy wrote: > > On 28/04/2011 17:25, Lucas Nussbaum wrote: > > > On 28/04/11 at 16:52 +0200, Mehdi Dogguy wrote: > > >> > > >> 1) At the beginning of the developement cycle, (with the new plan) you > > >> start from testing, and not the new stable. So, you don't start with a > > >> base that's rc-bug free, or at least, as polished as the new stable is. > > > > > > That's true. But the counter-argument to that is that, since new > > > packages will get some testing in rolling, all the new and broken stuff > > > will not land in unstable at the same time, and we won't end up with 800 > > > > > > "new rolling"? (and you seem to use "testing" in the next sentence). > > (I really think that we should forget about "rolling" for now… since it's > > confusing even for you) > > No, I meant unstable. What happens currently is that most DDs hold off > work during the freeze, and then upload new and broken stuff shortly > after the release, leading to several concurrent transitions. People try out new things in experimental, and it seems to work mostly well to get new stuff migrated from there via unstable to testing once the release is done (except that we try to not do too many things in parallel - and things have improved within the recent years). > Could we try to stay on focus and constructive, and avoid bringing > poneys in the discussion? Oh, I thought that discussion is just about poneys? Andi -- 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/20110429213746.gk15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* Raphael Hertzog (hert...@debian.org) [110428 14:55]: > On Thu, 28 Apr 2011, Mehdi Dogguy wrote: > > > So your "testing" is essentially the pre-2000 "frozen" distribution [1], > > > and > > > your "rolling" is basically the current "testing" without the need to > > > freeze? > > > If that's the case, calling the distributions > > > unstable/testing/frozen/stable > > > might make everyone less confused :-) > > > > uh… thanks! that's more clear, indeed. > > Good. I just want to point out that "frozen" built on top on rolling > (which is what we're proposing here) is different from "frozen" built on > top of unstable (which is what we had before the introduction of testing). The main drawback for frozen was that there is now a suite with quite some bad bugs which need to be fixed. And that we're lacking man power to fix that independend from unstable. I don't see the large difference. Andi -- 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/20110429212452.gi15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* Raphael Hertzog (hert...@debian.org) [110428 16:26]: > - reduce the set of architectures required for migration to testing to > i386/amd64/armel and have buildd of other architectures prioritize > missing builds in testing over missing builds in unstable > (freeze should be enough time even for slow arches to catch up and FTBFS > on already release architectures is still RC) Most packages missing testing migration due to not built is because the package is *broken*. Not because the buildds are slow. I don't think it makes any sense to migrate an package to testing which is broken on some architectures. Unless you consider all other architectures to be second-class citicens. > - be less strict and keep old binaries (and thus 2 versions of the same > source package) in testing. This applies in particular for libraries > going through SONAME changes and which can happily coexist during a > transition. That was already discussed and approved for testing I think in Helsinki. However, it needs someone implementing code, and isn't as easy as it looks like. Feel free to submit patches though. > - allow/encourage usage of t-p-u to rebuild unstable packages that are > ready to transition except for the fact that they are entangled in a > transition that's already done. Andi -- 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/20110429212843.gj15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* Raphael Hertzog (hert...@debian.org) [110428 11:29]: > On Thu, 28 Apr 2011, Stefano Zacchiroli wrote: > > We might disagree with the process Raphael is proposing, but my reading > > of [1] is that he is asking for comments on the *goals* that, in his > > opinion, "rolling" is supposed to fulfill. We can discuss whether those > > goals are worthwhile or not even if there is no plan (yet) on how to > > implement them. Of course people might consider that a futile exercise, > > but from an investigative point of view, it looks like an interesting > > exercise to me. > > Ack. Besides that, the plan is relatively straightforward and has been > well described by Sean Finney in another answer here. I don't think the plan is straightforward, but just "not working". It's easy to write down things that other people need to do - but that won't work. Please show the man power necessary to get your plan implemented - otherwise, all is moot. Andi -- 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/20110429212254.gh15...@mails.so.argh.org
Re: Bits from the Release Team - Kicking off Wheezy
* sean finney (sean...@debian.org) [110427 19:54]: > Hi Mehdi, > > On Wed, Apr 27, 2011 at 05:58:46PM +0200, Mehdi Dogguy wrote: > > Funny… reading your recent blogpost, you seem to not understand yet what > > you want to put into Rolling (and how). So, how can we comment on > > something that's not set or clearly described yet? Make a plan first, ask > > for questions later, please. > > > > There are certainly some ideas flowing here and there… but I can't find a > > document that describes clearly what that suite is! > > I can try and more clearly describe what *I* was proposing, though I'm > not sure that it 100% matches up with what others have been discussing > concerning CUT and "rolling". To try to lower any ambiguity I'll > do my best at avoiding using those terms and instead stick with more > straightforward and boring terms: > > * unstable always feeds to testing > * "release N" == "testing", until the "freeze". You know that we had once "frozen", and have given up since as that didn't scale even back then? This concept needs double or tripple man power from what we currently have. That's the show-stopper. Andi -- 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/20110429212031.gg15...@mails.so.argh.org
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Sun, 24 Apr 2011 23:46:10 +0100, Ben Hutchings wrote: > On Sun, 2011-04-24 at 22:46 +0100, Wookey wrote: > [...] > > I do think that getting the 'win32' arch name and triplet defined in > > dpkg-architecture is stage 1 for you. I thought we'd already done that > > years ago, when this last came up, but obviously not. > > dpkg-architecture already supports 269 options including such > > not-very-useful combinations as uclibc-linux-s390 and solaris-alpha, > > so it really ought to know about the win32 and win64 ABIs. It's > > generally a very simple patch to a few tables in dpkg to add a new arch. > [...] > > By the way, it should be something like 'win32-i386' rather than just > 'win32'. The non-x86 ports of NT 3.x and 4.0 are not really relevant > but an ARM port of Windows is supposed to be coming soon. That's an excellent point, and the dpkg proposal in http://bugs.debian.org/606825 takes care of it. % dpkg-architecture -amingw64-arm dpkg-architecture: warning: Specified GNU system type arm-w64-mingw32 does not match gcc system type i486-linux-gnu. DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_MULTIARCH=i386-linux-gnu DEB_HOST_ARCH=mingw64-arm DEB_HOST_ARCH_OS=windows DEB_HOST_ARCH_CPU=arm DEB_HOST_ARCH_BITS=32 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_GNU_CPU=arm DEB_HOST_GNU_SYSTEM=w64-mingw32 DEB_HOST_GNU_TYPE=arm-w64-mingw32 DEB_HOST_MULTIARCH=arm-w64-mingw32 Regards, Stephen signature.asc Description: PGP signature
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Sun, 24 Apr 2011 22:46:40 +0100, Wookey wrote: > +++ Stephen Kitt [2011-04-24 19:14 +0200]: > > > So I would be opposed to making such a change in policy for the time > > > being; I think cross-compilers should stick with the traditional > > > cross-compiler directories and stay away from the multiarch directories > > > until we have more practical experience with multiarch under our belts > > > and can make some educated decisions about how we want this to all fit > > > together. > > > > OK. > > I expect the multiarch paths to replace the 'traditional > cross-compiling' paths in due course for all target architectures, > including ones that aren't Debian-suported (i.e currently > mingw-whatever-you-call-it, avr32, msp430), for both native use and > cross-compiling. Steve will have to explain to me why we might want to > use different paths for non-self-hosting arches. It seems to me that > having one canonical place to look for arch-dependent files is good > whether you want them for running or for (cross-)building. > > But we do need to proceed carefully in order to get this right, and > the cross-only arches are a little way down our list of issues :-) I'd > be interested to hear how you currently do things in mingw world (and > more importantly what things you want to be able to do) so that we can > take your needs into account. I personnally don't speak for upstream, and most of the documentation available upstream discusses either Windows builds or sysroot-based builds in /usr/local. There has been a fair amount of discussion in the past though, including a proposed patch for dpkg (http://bugs.debian.org/606825) and a specification document on the Debian wiki (http://wiki.debian.org/Mingw-W64 which also has links to other distributions' documentation). I don't particularly like the sysroot approach, and I believe multiarch would provide the same functionality, i.e. being able to host at least the headers and libraries (and link-time DLLs) for cross-compiled libraries. I see two immediate requirements for MinGW-w64 in Debian: * being able to build wine-gecko; * replacing mingw32 and gcc-mingw32. Looking further, being able to host -dev packages to provide a nice cross-building environment would be desirable. Being able to host cross-compiled runtime binaries and DLLs doesn't seem quite so useful to me, although people using Debian to build installation packages for Windows would probably disagree. > I do think that getting the 'win32' arch name and triplet defined in > dpkg-architecture is stage 1 for you. I thought we'd already done that > years ago, when this last came up, but obviously not. > dpkg-architecture already supports 269 options including such > not-very-useful combinations as uclibc-linux-s390 and solaris-alpha, > so it really ought to know about the win32 and win64 ABIs. It's > generally a very simple patch to a few tables in dpkg to add a new arch. > > Having the mappings between Debian arch name, gnu triplet and multiarch > path all in one place is vital to making all this stuff work properly. It is indeed, see above for the existing bug report. I take it people were perhaps awaiting Dmitrijs' test results before pursuing things; I've built a patched dpkg and so far the results seem OK, although perhaps not to Adam's liking since the multiarch directories still end up being MinGW-w64 specific: % dpkg-architecture -amingw64-amd64 dpkg-architecture: warning: Specified GNU system type x86_64-w64-mingw32 does not match gcc system type i486-linux-gnu. DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_MULTIARCH=i386-linux-gnu DEB_HOST_ARCH=mingw64-amd64 DEB_HOST_ARCH_OS=windows DEB_HOST_ARCH_CPU=amd64 DEB_HOST_ARCH_BITS=64 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_GNU_CPU=x86_64 DEB_HOST_GNU_SYSTEM=w64-mingw32 DEB_HOST_GNU_TYPE=x86_64-w64-mingw32 DEB_HOST_MULTIARCH=x86_64-w64-mingw32 % dpkg-architecture -amingw64-i386 dpkg-architecture: warning: Specified GNU system type i486-w64-mingw32 does not match gcc system type i486-linux-gnu. DEB_BUILD_ARCH=i386 DEB_BUILD_ARCH_OS=linux DEB_BUILD_ARCH_CPU=i386 DEB_BUILD_ARCH_BITS=32 DEB_BUILD_ARCH_ENDIAN=little DEB_BUILD_GNU_CPU=i486 DEB_BUILD_GNU_SYSTEM=linux-gnu DEB_BUILD_GNU_TYPE=i486-linux-gnu DEB_BUILD_MULTIARCH=i386-linux-gnu DEB_HOST_ARCH=mingw64-i386 DEB_HOST_ARCH_OS=windows DEB_HOST_ARCH_CPU=i386 DEB_HOST_ARCH_BITS=32 DEB_HOST_ARCH_ENDIAN=little DEB_HOST_GNU_CPU=i486 DEB_HOST_GNU_SYSTEM=w64-mingw32 DEB_HOST_GNU_TYPE=i486-w64-mingw32 DEB_HOST_MULTIARCH=i386-w64-mingw32 Other distributions and upstream always use i686 for 32-bit MinGW-w64, which is why I used that too in my current packages. I believe it would still be possible to have a multiarch using Debian's CPU definitions as above, but build binutils and gcc with the i686-based triplet so that the commands wo
Re: Multiarch, policy and cross-compiler libraries for non-Debian architectures
On Wed, 27 Apr 2011 18:44:39 +0200, Goswin von Brederlow wrote: > Stephen Kitt writes: > > So if I understand things correctly that would mean using /usr/lib/win32 > > and /usr/lib/win64, regardless of the binutils/gcc triplet (which is fine > > as > > If that is what dpkg-architecture outputs. The path should never be > hardcoded. That makes sense, of course. > > Goswin, I take it you're advocating building _win32.deb packages (or > > something similar) - is that correct? I didn't even realise that would be > > possible without appropriate buildds... I know about “dpkg-buildpackage > > -aâ€_ or “pdebuild --architectureâ€_ for local rebuilds, but would > > rebuilding such a package be possible on the existing buildd network? > > No. You would still build a _all.deb. The debian/rules file would just > ask dpkg-architecture what the right multiarch dir is for the win32 ABI. > You can ask dpkg-architecture for information of an architecture other > than what you are building for. OK, thanks for clarifying that! Regards, Stephen signature.asc Description: PGP signature
Re: Bits from the Release Team - Kicking off Wheezy
On Freitag, 29. April 2011, Holger Levsen wrote: > 29445 successful and 72 failed logs plus 526 packages not being tested > (which is what we have today) is a reasonable state IMO. (reasonable yes, but we definitly can do better!) -- 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/201104291824.49292.hol...@layer-acht.org
Re: Bits from the Release Team - Kicking off Wheezy
Hi, sorry that I'm late to this party and that this mail is mostly an AOL... On Mittwoch, 30. März 2011, Luk Claes wrote: > # package quality > Advocate: Holger Levsen and Luk Claes > State: confirmed > Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality > > This is a never ending goal of sustaining our packages quality by > improving our tests and following up closely... so needless to say that > I would still advocate this one. Me too. The biggest obstacle in releasing with http://piuparts.debian.org/wheezy/ showing zero failures are: - me/someone not reporting the bugs detected there - the maintainers not fixing those filed / presented to them in the PTS - #595652 [debian-policy] db packages failing to install... 29445 successful and 72 failed logs plus 526 packages not being tested (which is what we have today) is a reasonable state IMO. Do you think a piuparts / policy workshop (or something) is useful at DebConf11? cheers, Holger -- 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/201104291803.03595.hol...@layer-acht.org
Re: Ubuntu Font Licence 1.0
[ Note that we decided to include the debian-devel list in our reply, as this issue seems to have already found a wider audience, which we want to invite to this discussion too. Please stay ontopic and away from ranting about Ubuntu/Canonical/Whatever, gains nothing for anyone, but help to resolve the issues at hand. Thanks. ] On 12462 March 1977, Paul Sladen wrote: > Hello all, I've see the following message to pkg-font; (at the moment > I'm on a quest for information and not seeking to take a viewpoint): > "[Pkg-fonts-devel] ubuntu-font-family-sources_0.70.1-1_amd64.changes > REJECTED" > > http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/2011-April/006515.html Yes. Turns out there was a slight misunderstanding on our side. It was believed that a prod message containing an explanation had already been sent out before the reject happened, so the reject was more concise than it should have been. > Juliank has forwarded the above to a bug report: > "Naming restrictions in UFL considered non-free by Debian" > https://bugs.launchpad.net/ubuntu-font-licence/+bug/769874 Heck, thats large already. Oh fun. > and tried to guess/interpret. The email above notes a "discussion in > the FTP Team". Would you/FTP master be able to provide a summary of > the that discussion and add it to the bug report (LP: #769874)---this > would make it easier to pass on to right people and flag up that > there's a serious issue if there is one. "To post a comment you must log in." - Sorry, but no, thanks. If there would be a useful mail interface given (asking on IRC got one, but it needs registered mail addresses which just sucks), sure, but we are not jumping through extra hoops here. Please pass this mail to wherever it should end up additionally instead. > If it's helpful, there's a diff against the SIL OFL at: > http://font.ubuntu.com/ufl/ofl-1.1-ufl-1.0.diff.html > and there is a FAQ about the interim status/changed from the SIL OFL > at (if for TL;DR, there are 9 bullet points at end): > http://font.ubuntu.com/ufl/FAQ.html > Some people on #debian-devel have raised versioning interaction with: > http://www.debian.org/social_contract.html#guidelines (4) > "The license may require derived works to carry a different name > or version number from the original software." > For clarity, I don't think the aim in developing an open/libre font is > to distribute it under a non-DFSG licence! Thus, it would be useful > to be take an FTP master summary back, to the people who can further > deal with it and to be able to hold up the individual points > specifically. Ok, well, lets try. The definitions include -- "Substantially Changed" refers to Modified Versions which can be easily identified as dissimilar to the Font Software by users of the Font Software comparing the Original Version with the Modified Version. -- What constitutes "easily identified as dissimilar"? Is it necessary to check all characters in the font and if so, what check is meant? Is it different if the md5sum of the font file is different? Is there a set of special characters to check? We actually doubt there can be an agreement when a font is dissimilar for users, not with that text. Typographers would likely see something as dissimilar where most users (us included) would see no difference at all. Taken alone this may not be a show-stopper, but the definition is used later on in such a way that the lack of clarity becomes a major issue. §1 seems ok, except for some curiousity about the definition of "easily viewed by the user"? Is a "strings font.ttf" easy? Or does it need to be some kind of ttf viewer app? Does one need to make sure there is one for all the platforms one intends to distribute? That might be a FAQ entry somewhere, but that curious part just had to ask it. This is not a reject reason though. §3 sounds ok to us. §4 in itself is free, even though it does take away even the authors possibility to dual-license a work, should one chose to use this license. Harsh, but nothing keeping it out of the archive. So, the interesting part is §2, which is why it is listed last. And as a short summary: We think that aspects of this section make the license unsuitable for works in Debian main. Taking §2b first. This subsection is in itself ok, DFSG 4 does allow to require a different name for a distribution of modified version, although "similar names" seems to be a bit of a gray area. The major issues arise in subsections §2a and c. These two subsections include between them an invariant section. This type of invariance is not something covered by DFSG 4. DFSG 4 tries to allow a copyright holder to say "If you change foo, you must not call it foo", but does not have similar provisions to allow a copyright holder to say things such as "You must not call foo by any other name" or "If you change foo, the name you must use is bar". Especially noting the parenthetical
Re: Bits from the Release Team - Kicking off Wheezy
On Fri, Apr 29, 2011 at 02:44:53PM +0200, Bernd Zeimetz wrote: > On 03/31/2011 09:25 AM, Vincent Danjean wrote: > > > Martin F. Krafft started to implement a replacement of ifupdown that > > is better designed. But, due to lack of manpower I think, this project > > did not finish. See this archives of netconf-de...@lists.alioth.debian.org > > for more info. > > Instead of Martin's project you might want to look into ipcfg by Wouter > Verhelst, which is in experimental already. Yes, except that it's not very useful in its current state. The basic design is a bit flawed; and while it can do a few basic things (I have been using it on my laptop since quite a while), I don't want to maintain it with those flaws present. I'm afraid I'd need to rewrite significant parts of it for it to be useful. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20110429135806.ga13...@celtic.nixsys.be
Re: Bits from the Release Team - Kicking off Wheezy
Bernd Zeimetz (29/04/2011): > Instead of Martin's project you might want to look into ipcfg by > Wouter Verhelst, which is in experimental already. You may want not to. Last I checked (#dd yesterday, but not quoting without permission), the idea was to scratch everything and start over. Mraw, KiBi. signature.asc Description: Digital signature
Bug#624539: ITP: sparkline-php -- A sparkline graphing library for php
Package: wnpp Severity: wishlist Owner: Fabrizio Regalli Package name: sparkline-php Version : 0.2 Upstream Author : James Byers URL : http://sparkline.org/ License : GPL Programming Lang: php Description : A sparkline graphing library for php Hi, I would like to re-introduce this package previously removed from SID archive. -- 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/20110429132647.16496.37105.reportbug@debianfab
Re: Bits from the Release Team - Kicking off Wheezy
Hi, On Fri, 29 Apr 2011, Stefano Zacchiroli wrote: > On Thu, Apr 28, 2011 at 05:34:50PM +0200, Mehdi Dogguy wrote: > > I'm still reading and thinking… so, don't have an answer yet. But, it > > you'd like me to read your ideas, you're going to put some efforts and > > post them here, instead of pointing me to your blog. really. > > AOL. > > I do appreciate that Raphael is putting efforts in advertising this > discussion using his blog, but that should not come with drawbacks such > as forcing people to follow it or getting in the way of those who might > be offline while reading mailing list threads. For the record, I do agree as well. I was not expecting the discussion on -devel that quickly and hoped to start a discussion later on with a more polished proposal. I gave the link because I did not had time to properly reintegrate the analysis provided on my blog in my mail but I still thought that it would help to go forward in the current discussion. But that's not a good reason to not have added a text dump at least. So thanks for that! Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110429131245.ga17...@rivendell.home.ouaza.com
Re: Bits from the Release Team - Kicking off Wheezy
On 29/04/2011 14:21, Stefano Zacchiroli wrote: > On Thu, Apr 28, 2011 at 10:55:01PM +, Philipp Kern wrote: >> On 2011-04-28, Raphael Hertzog wrote: >>> But I don't plan to work on any of those if the project does not agree to >>> promote testing to something that can be advertised as usable by end-users >>> and as something that we strive to support on a best-effort basis. >> >> It's already the case that you can go and send a mail to debian-release@ that >> package X needs to be put into testing more quickly than the set urgency or >> asking for permission to upload to t-p-u to fix bugs if the upload is >> entangled. And apart from that it's supported on a best-effort basis already >> with bug fixes trickling from unstable into it and critical stuff being >> fixed faster. > > Sure. But the procedures you mention above all require work from the > maintainer + the release team, while they would require work only from > the maintainer in the (hypothetical) "rolling" scenario. Under heavy > load periods for the release team---not only freezes, but also periods > with a huge stack of transitions to be completed---the presence of an > extra participant might easily become a bottleneck inducing more work > (and stress) on everybody shoulders and more delays. > In the (hypothetical) "rolling" scenario¹, one should still follow the same procedure to get the package speedy-migrated (or uploaded to r-p-u, if applicable). So, I don't see where you're winning. I could be missing something here though. ¹: which has, still, to be defined clearly. > […] > > So yes, you're right that _technically_ we can achieve the same with > current procedures, but I argue that the underlying procedure doesn't > scale (which is unsurprising, given it's been designed for a different > purpose). > It doesn't mean that it's a problem. Well, yes, it can be enhanced… but I'd say we didn't see periods where all Release Team members were really that busy to not be able to add an age-days hint or approve a t-p-u upload. I'm not sure we will see that day. And the same issue remains true with rolling scenario (existence of that bottleneck). Having that said, avoiding bottlenecks when possible is better. Regards, -- Mehdi Dogguy مهدي الدڤي http://dogguy.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/4dbab79a.1010...@dogguy.org
Re: [RFC] Changing APT to pre-depend on ${shlibs:Depends}
On Thu, Apr 28, 2011 at 18:48, Julian Andres Klode wrote:
> But that we do want to prevent a broken APT -- when using the common
> "dpkg -i ...; apt-get install -f" idiom (where ... is APT) -- certainly
> is an argument.
Let me try to rephrase that:
The only strong positive argument for the change is that a user might
break APT if he carelessly runs dpkg -i apt.deb ?
Thats a pretty weak argument in my eyes if that is really meant:
While dpkg -i … is common, i seriously doubt that it is common to install
an upgrade of apt with it as people do this trickery for packages they can't
get from an archive easily.
(Why do they do this trigger? -> We should fix the cause, not the result)
In this sense, i would have bigger fears that they install a newer
(incompatible) libwhatever alongside a silly game with dpkg -i breaking
APT (or anything else depending on libwhatever) which nothing can prevent.
I personally have no problem with the pre-depends on a technical level,
but as they seem to provide nothing worthwhile i would like to avoid
problems on a social level which will arise as soon as you try to argue
why APT gets pre-depends and many many other packages a "normal"
user can't live without doesn't get them. Be it another package manager
with a (currently) smaller market share or something completely different:
I mean, if i break nano how am i supposed to edit a file? sed?
And yes, i know, in theory you have vim-tiny around, but that could
be broken, too, and i assume you will find a lot of people saying
'it is always broken!' -- and editors was just a bad example…
I could have said kernel, grub or ${important-package} instead…
Best regards
David Kalnischkies (who is a vi fanboy at heart)
--
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/banlktimzjt-db-qcxjzop0w1m.m0x...@mail.gmail.com
Re: Bits from the Release Team - Kicking off Wheezy
On 03/31/2011 09:25 AM, Vincent Danjean wrote: > Martin F. Krafft started to implement a replacement of ifupdown that > is better designed. But, due to lack of manpower I think, this project > did not finish. See this archives of netconf-de...@lists.alioth.debian.org > for more info. Instead of Martin's project you might want to look into ipcfg by Wouter Verhelst, which is in experimental already. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4dbab2c5.1010...@debian.org
Re: Bits from the Release Team - Kicking off Wheezy
On Thu, Apr 28, 2011 at 10:55:01PM +, Philipp Kern wrote:
> On 2011-04-28, Raphael Hertzog wrote:
> > But I don't plan to work on any of those if the project does not agree to
> > promote testing to something that can be advertised as usable by end-users
> > and as something that we strive to support on a best-effort basis.
>
> It's already the case that you can go and send a mail to debian-release@ that
> package X needs to be put into testing more quickly than the set urgency or
> asking for permission to upload to t-p-u to fix bugs if the upload is
> entangled. And apart from that it's supported on a best-effort basis already
> with bug fixes trickling from unstable into it and critical stuff being
> fixed faster.
Sure. But the procedures you mention above all require work from the
maintainer + the release team, while they would require work only from
the maintainer in the (hypothetical) "rolling" scenario. Under heavy
load periods for the release team---not only freezes, but also periods
with a huge stack of transitions to be completed---the presence of an
extra participant might easily become a bottleneck inducing more work
(and stress) on everybody shoulders and more delays.
In general we need to promote the reduction of (potential) bottlenecks
in Debian rather than the contrary. ... and don't get me wrong: I'm very
well aware that this specific "bottleneck" is a very good feature to
have for the preparation of a stable release, given it means more
scrutiny and ultimately more quality. But given that "rolling" seems to
be willing to trade some of that stability off in favor of fresher
software, it might be warranted to lift it off there.
So yes, you're right that _technically_ we can achieve the same with
current procedures, but I argue that the underlying procedure doesn't
scale (which is unsurprising, given it's been designed for a different
purpose).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
On Thu, Apr 28, 2011 at 05:34:50PM +0200, Mehdi Dogguy wrote: > > See > > http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/ > > for a more detailed answer and related suggestions to limit this problem. > > I'm still reading and thinking… so, don't have an answer yet. But, it > you'd like me to read your ideas, you're going to put some efforts and > post them here, instead of pointing me to your blog. really. AOL. I do appreciate that Raphael is putting efforts in advertising this discussion using his blog, but that should not come with drawbacks such as forcing people to follow it or getting in the way of those who might be offline while reading mailing list threads. You can find below a text dump of Raphael's blog post mentioned above, for reference/quoting/whatever. Cheers. -- snip [ from http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/ ] No freeze of Debian’s development, what does it entail? April 28, 2011 By Raphaël Hertzog 15 Comments The main feature of rolling is that it would never freeze. This is not without consequences. Possible consequences It can divert developers from working on the release No freeze means developers are free to continue their work as usual in unstable. Will it be more difficult to release because some people will spend their time working on a new upstream version instead of fixing RC bugs in the version that is frozen? Would we lose the work of the people who do lots of NMU to help with the release? It makes it more difficult to cherry-pick updates from unstable No freeze also means that unstable is going to diverge sooner from testing and it will be more difficult to cherry-pick updates from unstable into testing. And the release team likes to cherry-pick updates that have been tested in unstable because updates that comes through testing-proposed-updates have often not been tested and need thus a more careful review. Frozen earth My responses to the objections Those are the two major objections that we’ll have to respond to. Let’s try to analyze them a bit more. It’s not testing vs rolling On the first objection I would like to respond that we must not put “testing” and “rolling/unstable” in opposition. The fact that a contributor can’t do its work as usual in unstable does not mean that he will instead choose to work on fixing RC bugs in testing. Probably that some do, but in my experience we simply spend our time differently, either working more on non-Debian stuff or doing mostly hidden work that is then released in big batches at the start of the next cycle (which tends to create problems of its own). I would also like to argue that by giving more exposure to rolling and encouraging developers to properly support their packages in rolling, it probably means that the overall state of rolling should become gradually better compared to what we’re currently used to with testing. The objection that rolling would divert resources from getting testing in a releasable shape is difficult to prove and/or disprove. The best way to have some objective data would be to setup a questionnaire and to ask all maintainers. Any volunteer for that? Unstable as a test-bed for RC bugfixes? It’s true that unstable will quickly diverge from testing and that it will be more difficult to cherry-pick updates from unstable into testing. This cannot be refuted, it’s a downside given the current workflow of the release team. But I wonder if the importance of this workflow is not overdone. The reason why they like to cherry-pick from unstable is because it gives them some confidence that the update has not caused other regressions and ensures that testing is improving. But if they’re considering to cherry-pick an update, it’s because the current package in testing is plagued by an RC bug. Supposing that the updated package has introduced a regression, is it really better to keep the current RC bug compared to trading it for a new regression? It sure depends on the precise bugs involved so that’s why they prefer to know up-front about the regression instead of making a blind bet. Given this, I think we should use testing-proposed-updates (tpu) as a test-bed for RC bug fixes. We should ask beta-testers to activate this repository and to file RC bugs for any regression. And instead of requiring a full review by a release manager for all uploads to testing-proposed-updates, uploads should be auto-accepted provided that they do not change the upstream version and that they do not add/remove binary packages. Other uploads would still need manual approval by the release managers. On top of this, we can also add an infrastructure to encourage peer-reviews of t-p-u uploads so that reviews become more opportunistic instead of systematic. Positive reviews would help reduce the aging required in t-p-u before being accepted into testing.
Re: Bits from the Release Team - Kicking off Wheezy
On Thu, Apr 28, 2011 at 04:52:29PM +0200, Mehdi Dogguy wrote:
> 2) During the freeze, you're killing an important step in the Release
> process which is "the testing". Packages that move from sid to testing are
> tested by a huge user base (sid users), and then double-tested by testing
> users.
I concur this might be a problem. At the same time I also find quite
convincing Lucas' arguments about the fact that with the introduction
(or better advertising, name one) of rolling we are likely to get more
earlier testing---as in "review", not as in the suite name---than with
the current scheme.
To complement that with even more user testing, I think we should
consider advertising specific (late) frozen snapshots as
alpha/beta{1,2,3} development releases. Several other distros are doing
that and I do believe they have good reasons for doing so, which might
apply to us as well. For once, it's undeniable that there is some
"announcement effect" in the world we live in: at each development
release we might hope to get more explicit testing than only relying on
the "you can always test testing and let us know" philosophy.
In the Squeeze release we have done better than before by calling for
explicit upgrade testing (kudos to the Release Team!), but a specific
plan of alpha/beta/... might bring even more testing, especially if the
media help us out with some hype.
This proposal comes with its own drawbacks, as the need of synchronizing
with d-i releases and CD/DVD images, but that might be mitigating by
saying that a specific alpha/beta/ is only for upgrades and not for from
scratch installations. Any other drawbacks of doing development
releases I might have missed?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum [110429 11:17]: > On 29/04/11 at 11:00 +0200, Bernhard R. Link wrote: > > * Lucas Nussbaum [110429 10:51]: > > > I think that you misunderstood my data. It's the number of **distinct** > > > (different) **uploaders**. If you uploaded just one package during the > > > freeze period, then you are not in the 20%. > > > > You did not give numbers of uploaders in the freeze time, but by > > month. So I still count in the other months. (And with one specific > > package maintained less, I might have an avarage of less than a package > > uploaded per freeze). > > I did: > > One could argue that, even if you are involved in RC bug squashing, you > > might > > not be making uploads that frequently, and that would explain why the > > number of > > distinct uploaders is going down. So let's take a step backward: > > Distinct uploaders to unstable from 01/01/2008 to 30/07/2008: 1229 > > Distinct uploaders to unstable from 30/07/2008 to 14/02/2008: 978 (lenny > > freeze) > > Distinct uploaders to unstable from 06/02/2010 to 06/08/2010: 1187 (6 > > months before freeze) > > Distinct uploaders to unstable from 06/08/2010 to 05/02/2011: 926 (squeeze > > freeze) > > The 20% was based on those numbers, not on the per-months data. If you > take the per-month data, it's much worse, e.g: 2010-01: 661 uploaders ; > 2011-01: 313 uploaders. Oh, sorry, did miss that part. But as I wrote, without one specific package of mine I'd guess I had an avarage of half a upload per freeze (and even on that 'many' release related uploads I'm almost proud) so with 40% of people in that situation you'd already get those numbers. (I do not claim there is no such effect you proclaim, just that your numbers in my eyes mean that it cannot be nearly as strong as you suggest). Bernhard R. Link -- 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/20110429100328.ga24...@pcpool00.mathematik.uni-freiburg.de
Re: Bits from the Release Team - Kicking off Wheezy
On 29/04/11 at 11:00 +0200, Bernhard R. Link wrote: > * Lucas Nussbaum [110429 10:51]: > > I think that you misunderstood my data. It's the number of **distinct** > > (different) **uploaders**. If you uploaded just one package during the > > freeze period, then you are not in the 20%. > > You did not give numbers of uploaders in the freeze time, but by > month. So I still count in the other months. (And with one specific > package maintained less, I might have an avarage of less than a package > uploaded per freeze). I did: > One could argue that, even if you are involved in RC bug squashing, you might > not be making uploads that frequently, and that would explain why the number > of > distinct uploaders is going down. So let's take a step backward: > Distinct uploaders to unstable from 01/01/2008 to 30/07/2008: 1229 > Distinct uploaders to unstable from 30/07/2008 to 14/02/2008: 978 (lenny > freeze) > Distinct uploaders to unstable from 06/02/2010 to 06/08/2010: 1187 (6 months > before freeze) > Distinct uploaders to unstable from 06/08/2010 to 05/02/2011: 926 (squeeze > freeze) The 20% was based on those numbers, not on the per-months data. If you take the per-month data, it's much worse, e.g: 2010-01: 661 uploaders ; 2011-01: 313 uploaders. - Lucas -- 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/20110429091657.ga11...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum [110429 10:51]: > I think that you misunderstood my data. It's the number of **distinct** > (different) **uploaders**. If you uploaded just one package during the > freeze period, then you are not in the 20%. You did not give numbers of uploaders in the freeze time, but by month. So I still count in the other months. (And with one specific package maintained less, I might have an avarage of less than a package uploaded per freeze). Bernhard R. Link -- 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/20110429090029.ga23...@pcpool00.mathematik.uni-freiburg.de
Re: Bits from the Release Team - Kicking off Wheezy
On 29/04/11 at 10:33 +0200, Bernhard R. Link wrote: > * Lucas Nussbaum [110428 22:06]: > > So, we are losing a large number of contributors (> 20%) during freezes. And > > it's also possible that some of them don't come back (looking at the months > > following freezes, it takes some time to reach the pre-freeze numbers). > > I can only say that I usually have a much lower upload frequency > while freeze, which with one specific package less might even be > a total stall while most past freeze times. And I would not call > myself "lost" due to that. I think that you misunderstood my data. It's the number of **distinct** (different) **uploaders**. If you uploaded just one package during the freeze period, then you are not in the 20%. Of course, a better way to detect whether we are actually losing contributors during the freeze would be to look at the archives of debian-devel-changes@ + debian-bugs-rc@. But we don't have a tool for that (yet ; there's a GSOC project that could address that). Lucas -- 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/20110429085117.ga9...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
On 29/04/11 at 10:23 +0200, Holger Levsen wrote: > 2. In the past there used to be two rather opposites use-cases of testing: > some (luckely more than just the release team) see it as a tool to develop > stable. Others see it (mostly) as a usable distribution. > I'm unconvinced that splitting testing into rolling+testing will benefit both > use cases. (And I think this is shared rather widely in this thread.) I think that the proposal is to: - rename 'testing' to 'rolling' to make it clear that it's usable as a rolling release - add a new 'frozen' suite, used only during freezes, to prepare the next stable release So, it's not splitting testing into rolling+testing. It's changing testing to rolling outside of freezes, and splitting testing into rolling+frozen during freezes. - Lucas -- 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/20110429084630.ga9...@xanadu.blop.info
Re: Bits from the Release Team - Kicking off Wheezy
* Lucas Nussbaum [110428 22:06]: > Eh? How do you fix stuff in the next release if you don't make uploads? > I'm not saying that the number of uploads should stay the same: it's > normal to see it going down during freezes, since there are less things > to change. However, if we think that DDs participate in RC bug fixing, > the number of distinct uploaders should not go down. Not every RC bug fixing means an upload from that developer. And not all work in trying to help RC bug fixing is actually sucessfull. And testing is usually more about RC bug filing than RC bug fixing. > So, we are losing a large number of contributors (> 20%) during freezes. And > it's also possible that some of them don't come back (looking at the months > following freezes, it takes some time to reach the pre-freeze numbers). I can only say that I usually have a much lower upload frequency while freeze, which with one specific package less might even be a total stall while most past freeze times. And I would not call myself "lost" due to that. A freeze is a significantly different phase, especially as my upstream development is usually heavily synced to Debian development, but if I am annoyed at something in that phase, then it is about people whining that they are not allowed to ignore or even sabotage the release process. Bernhard R. Link -- 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/20110429083311.ga23...@pcpool00.mathematik.uni-freiburg.de
Bug#624518: ITP: python-initgroups -- Python binding of initgroups
Package: wnpp Severity: wishlist Owner: Arnaud Fontaine * Package name: python-initgroups Version : 2.13.0 Upstream Author : Zope Corporation and Contributors * URL : http://pypi.python.org/pypi/initgroups * License : ZPL-2.1 Programming Lang: Python Description : Python binding of initgroups Convenience uid/gid helper function (initgroups) used in Zope2. This package is only meaningful for Python <= 2.6 because since Python 2.7, initgroups is provided in os module. As soon as Python 2.6 is deprecated, it can be safely dropped. This package will be maintain as part of the pkg-zope team. -- 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/20110429082444.28881.79376.reportbug@cartman
Re: Bits from the Release Team - Kicking off Wheezy
Hi, On Donnerstag, 28. April 2011, Joey Hess wrote: > Raphael Hertzog wrote: > > There are other possible changes but I want to discuss them separately > > because even without those changes, the testing without freeze is a > > worthwhile goal in itself. [...] > I think these are interesting ideas, but they don't seem to be specific > to rolling; it seems they could be applied to testing just as well, > and indeed mostly you've phrased them as applying to testing. Absolutly. From observing the discussion, there are two points I'd like to add: 1. If debian-devel@ doesnt get the distinction between rolling, frozen and testing right, no one else will. And appearantly rolling has already caught as a name, I saw a laptop running "Debian mint rolling" yesterday... My point is, if there will be a fourth suite, the name(s) absolutly must be chosen very carefully. 2. In the past there used to be two rather opposites use-cases of testing: some (luckely more than just the release team) see it as a tool to develop stable. Others see it (mostly) as a usable distribution. I'm unconvinced that splitting testing into rolling+testing will benefit both use cases. (And I think this is shared rather widely in this thread.) So IMO testing should be made more constantly usable (ie by better documentation how to deal with things, by better promotion (ie by means of a symlink rolling->testing)) but the tension described in 2. should be kept, as it's benefiting both use cases of testing. cheers, Holger -- 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/201104291023.50825.hol...@layer-acht.org
