Sometimes {svn,git}.debian.org needs to be replaced by alioth.debian.org
Hi,
I several times observed that checking out as well commiting / pushing
to {svn.git}.debian.org while alioth.debian.org works perfectly. This
seems to be a temporary effect which occures from time to time and is
currently the case. Anybody else sharing this observations?
Kind regards
Andreas.
--
http://fam-tille.de
--
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/20131201084114.gb8...@an3as.eu
Bug#731037: ITP: liblist-rotation-cycle-perl -- module that cycles through a list of values via a singleton object implemented as closure.
Package: wnpp Owner: Radu-Bogdan Croitoru Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: liblist-rotation-cycle-perl Version : 1.009 Upstream Author : Imre Saling * URL : https://metacpan.org/release/List-Rotation-Cycle * License : Artistic or GPL-1+ Programming Lang: Perl Description : module that cycles through a list of values via a singleton object implemented as closure. Use List::Rotation::Cycle to loop through a list of values. Once you get to the end of the list, you go back to the beginning. List::Rotation::Cycle is implemented as a Singleton Pattern. You always just get 1 (the very same) Cycle object even if you use the new method several times. This is done by using Memoize on the new method. It returns the same object for every use of new that comes with the same List of parameters. This description was automagically extracted from the module by dh-make-perl. -- 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/1385891982.965307.2781.nullmailer@dotix
Bug#731042: ITP: libscalar-listify-perl -- module that produces an array(ref)? from a scalar value or array ref
Package: wnpp Owner: Radu-Bogdan Croitoru Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libscalar-listify-perl Version : 0.02 Upstream Author : Terrence Brannon * URL : https://metacpan.org/release/Scalar-Listify * License : Artistic or GPL-1+ Programming Lang: Perl Description : module that produces an array(ref)? from a scalar value or array ref A lot of Perl code ends up with scalars having either a single scalar value or a reference to an array of scalar values. In order to handle the two conditions, one must check for what is in the scalar value before getting on with one's task. Ie: $text_scalar = 'text'; $aref_scalar = [ 1.. 5 ]; print ref($text_scalar) ? (join ':', @$text_scalar) : $text_scalar; And this module is designed to address just that! -- 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/1385896845.999196.5734.nullmailer@dotix
Bug#731044: ITP: libarray-group-perl -- module that converts an array into array of arrayrefs of uniform size N
Package: wnpp Owner: Radu-Bogdan Croitoru Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libarray-group-perl Version : 3.0 Upstream Author : Terrence Brannon * URL : https://metacpan.org/release/Array-Group * License : Artistic or GPL-1+ Programming Lang: Perl Description : module that converts an array into array of arrayrefs of uniform size N The ngroup method reformats a list into a list of arrayrefs. It is often used for formatting data into HTML tables, amongst other things. dissect() returns a list of lists where the first element of each sublist will be one of the first elements of the source list, and the last element will be one of the last. This behaviour is much more useful when the input list is sorted. The key difference between the two methods is that dissect() takes elements from the start of the list provided and pushes them onto each of the subarrays sequentially, rather than simply dividing the list into discrete chunks. -- 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/1385898084.749924.18574.nullmailer@dotix
Bug#731046: ITP: golang-go.tools -- supplementary Go tools
Package: wnpp Severity: wishlist Owner: Michael Stapelberg * Package name: golang-go.tools Version : 0.0~hg20131126-1 Upstream Author : The Go Authors * URL : https://code.google.com/p/go.tools/ * License : BSD-3-clause Programming Lang: Go Description : supplementary Go tools This subrepository holds the source for various packages and tools that support the Go programming language. . Some of the tools, godoc and vet for example, used to be included in the golang-go package. Others, including the Go oracle and the test coverage tool, can be fetched with "go get". . Packages include a type-checker for Go and an implementation of the Static Single Assignment form (SSA) representation for Go programs. -- 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/20131201115603.13812.4252.report...@midna.lan
Bug#731049: ITP: libmodule-build-xsutil-perl -- Module::Build class for building XS modules
Package: wnpp Owner: Axel Beckert Severity: wishlist * Package name: libmodule-build-xsutil-perl Version : 0.05 Upstream Author : Hideaki Ohno * URL : https://metacpan.org/release/Module-Build-XSUtil * License : Artistic or GPL-1+ Programming Lang: Perl Description : Module::Build class for building XS modules Module::Build::XSUtil is subclass of Module::Build for support building XS modules. Beyond other features it supports checking for C99 and C++ compilers as well as to enable compiler warnings or debug options. Module::Build::XSUtil needs to be packaged because it is a new build-dependency for Mouse (libmouse-perl) from version 2.0.0 on. libmodule-build-xsutil-perl will be packaged under the hat of the Debian Perl Group. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20131201121628.gh13...@sym.noone.org
Bug#731053: ITP: libdevel-checkcompiler-perl -- Check compiler availability
Package: wnpp Owner: Axel Beckert Severity: wishlist * Package name: libdevel-checkcompiler-perl Version : 0.04 Upstream Author : Tokuhiro Matsuno * URL : https://metacpan.org/release/Devel-CheckCompiler * License : Artistic or GPL-1+ Programming Lang: Perl Description : Check compiler availability Devel::CheckCompiler checks the availability of a C99 compiler. If none is available, it exits with return code 0. libdevel-checkcompiler-perl is needed as build-dependency for libmodule-build-xsutil-perl (ITP: http://bugs.debian.org/731049) which again is a new build-dependency for recent libmouse-perl versions. The package will be maintained under the hat of the Debian Perl Group. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- 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/20131201125303.gi13...@sym.noone.org
Bug#731059: ITP: hy -- Lisp (s-expression based) interface to the Python programming language
Package: wnpp Severity: wishlist Owner: Paul Tagliamonte * Package name: hy Version : 0.9.11 Upstream Author : Paul Tagliamonte * URL : http://hylang.opg * License : MIT/Expat Programming Lang: Python and Hy Description : Lisp (s-expression based) interface to the Python programming language Hy is a Python <--> "Lisp" interop layer. It lets Hy code think Python is Hy, Python thinks Hy is Python and everyone's happy. This lets neckbeards take advantage of macros, but in Python, along with a sane, calming, s-expression based syntax for that true 1970's feel. The http://fraked.debian.net/ service is powered by Hy, and configured by the snitch dsl. Feel free to get hy at http://try-hy.appspot.com/, or check out the docs at http://hylang.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/20131201143731.5308.56146.report...@leliel.pault.ag
Bug#731071: ITP: python-rply -- pure python parser generator
Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath
* Package name: python-rply
Version : 0.6.1
Upstream Author : Alex Gaynor
* URL : https://github.com/alex/rply
* License : BSD-3-clause
Programming Lang: Python
Description : pure python parser generator
A pure python parser generator, that also works with RPython. It is a
more-or-less direct port of David Beazley's awesome PLY, with a new
public API, and RPython support.
This is the dependency for hy
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: Digital signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 30/11/13 at 22:07 -0600, Steve Langasek wrote: > On Sat, Nov 30, 2013 at 05:40:35PM +0100, Jakub Wilk wrote: > > * Steve Langasek , 2013-11-29, 12:01: > > >What do you propose as a mechanism for agreeing to a reduced NMU > > >delay for archive-wide changes? > > > My proposal is to realize that reduced delay for archive-wide > > changes is not needed. > > > Seriously, such changes will take months or years anyway, so what > > does reducing a 10-day delay buy you? > > It buys you being able to finish in months, instead of in years. > > It buys you not having to track dozens of in-flight NMUs in parallel, > letting you spend more of your time working on improving Debian instead of > doing paperwork. I fully agree that project-wide improvements should be encouraged, and that we should try to reduce the burden for people working on such tasks. So we need a efficient mechanism to protect such project-wide improvements to be blocked by a maintainer's unresponsiveness/inactivity blocks. However, on the other hand, the NMU process is disruptive for active maintainers, as the NMUer usually doesn't have insider knowledge of the package and its life cycle. So, it's really a question of how efficient we want the process to be, and how much we are willing to pay for that (in terms of disruptiveness). The current NMU rules allow someone to prepare a patch, file a bug with it, and upload to DELAYED/10, all in one go. The tracking needed for such a process is minimal, and the BTS, or BTS+UDD, likely can make it even easier. I agree that the 10-day delay might not be sufficient for transitions that require numerous stages, but in that case, I would totally understand if someone argued for DELAYED/5, especially if advanced notice is given (by listing all packages affected by a large-scale change). > It sets an appropriate project-wide expectation that certain NMUs are > sanctioned, so people (including new developers, NMs, or new contributors) > will feel supported in working on such tasks instead of being afraid to > stick their necks out. The need for review and feedback is another problem. It's often difficult to get feedback on a proposed change inside Debian. But I really don't think that it should be the release team's job alone to decide which project-wide improvements are good or bad. If it's too hard to reach consensus on -devel@ on a proposed improvement, I would rather prefer if we used the TC's ability to "offer advice". 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/20131201161735.gc28...@xanadu.blop.info
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
This one time, at band camp, Lucas Nussbaum said: > The need for review and feedback is another problem. It's often > difficult to get feedback on a proposed change inside Debian. But I > really don't think that it should be the release team's job alone to > decide which project-wide improvements are good or bad. If it's too hard > to reach consensus on -devel@ on a proposed improvement, I would rather > prefer if we used the TC's ability to "offer advice". Releases have, up to now, been the domain of the release team, since that's sort of what they do. What goals are set for a given release seem to me to be something squarely in that realm, especially given that there is no 'stick' - there's not really anything to compel others to play along. Can you explain why you think it would be a good idea to remove the power to decide their own goals from a team, and why you think it would be good for Debian to have one team drive another team's goals? This is so different to how we usually work that it seems jarring. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On Sun, Dec 1, 2013 at 12:53 PM, Stephen Gran wrote: > Can you explain why you think it would be a good idea to remove the > power to decide their own goals from a team, and why you think it would > be good for Debian to have one team drive another team's goals? This is > so different to how we usually work that it seems jarring. I believe the underlying friction is that the release team rejects a lot of goals as not affecting a sufficiently broad set of packages, which leaves no venue for organizing less broad but still useful and possibly disruptive (in a smaller way) changes. 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/CANTw=mmt_mgo5uky3hh3oz2wvkeuxjlyqybhsnazjzitsqv...@mail.gmail.com
Re: How many users for /usr/bin/view ?
On Thu, Nov 28, 2013 at 01:54:51PM +, Ian Jackson wrote: > The other possibily for Debian as a whole would be to ban vi clones > from offering /usr/bin/view, which I'm sure would annoy a lot more > people. Yeah, no, thanks. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#731083: ITP: libreligion-islam-prayertimes-perl -- Perl module that calculates muslim prayer times
Package: wnpp Severity: wishlist Owner: Xavier Guimard * Package name: libreligion-islam-prayertimes-perl Version : 1.02 Upstream Author : Ahmed Amin Elsheshtawy * URL : https://metacpan.org/release/Religion-Islam-PrayerTimes * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module that calculates muslim prayer times Religion::Islam::PrayerTimes calculates Muslim prayers times and sunrise for any location on the earth -- 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/20131201193117.13062.12931.reportbug@localhost
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 01/12/13 at 17:53 +, Stephen Gran wrote: > This one time, at band camp, Lucas Nussbaum said: > > The need for review and feedback is another problem. It's often > > difficult to get feedback on a proposed change inside Debian. But I > > really don't think that it should be the release team's job alone to > > decide which project-wide improvements are good or bad. If it's too hard > > to reach consensus on -devel@ on a proposed improvement, I would rather > > prefer if we used the TC's ability to "offer advice". > > Releases have, up to now, been the domain of the release team, since > that's sort of what they do. Sure. > What goals are set for a given release > seem to me to be something squarely in that realm, especially given that > there is no 'stick' - there's not really anything to compel others to > play along. Ah, interesting. My POV is that "release goals" are kind-of misnamed, because most of them are not specific to releases, but are instead general technical changes. Most of the goals proposed on https://wiki.debian.org/ReleaseGoals are very valid and interesting technical changes, but I really fail to see how they are specific to a given release. Maybe you could explain why you think that it's the case? > Can you explain why you think it would be a good idea to remove the > power to decide their own goals from a team, and why you think it would > be good for Debian to have one team drive another team's goals? This is > so different to how we usually work that it seems jarring. Release goals are usually achieved by contributors working on one specific goal, not by the release team (= the release team doesn't actively fix packages for release goals). The role of the release team regarding release goals is to: 1) evaluate/approve goals 2) follow progress (using BTS usertags, usually) and re-evaluate during the release cycle. So, I don't think that it's correct to describe release goals as the release team's "own goals". Then, yes, I question whether it should really be the release team's role to evaluate and approve such goals. I'm currently working on a delegation for the release team (non-final draft at [1]), and I agree that fictious goals such as "gcc 4.9 by default in jessie" or "GNOME 3.14 in jessie" would totally be in the realm of the release team, but are already covered in the delegation. If you think that the release team should have the power to decide on release goals, how should this draft delegation be changed to include that? [1] http://anonscm.debian.org/gitweb/?p=dpl/dpl-helpers.git;a=blob;f=release-delegation.txt - 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/20131201200300.ga5...@xanadu.blop.info
Bug#731085: ITP: r-bioc-shortread -- GNU R classes and methods for high-throughput short-read sequencing data
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-shortread Version : 1.20.0-1 Upstream Author : Bioconductor Package Maintainer * URL : http://www.bioconductor.org/packages/release/bioc/html/ShortRead.html * License : Artistic-2.0 Programming Lang: GNU R Description : GNU R classes and methods for high-throughput short-read sequencing data This BioConductor module is a package for input, quality assessment, manipulation and output of high-throughput sequencing data. ShortRead is provided in the R and Bioconductor environments, allowing ready access to additional facilities for advanced statistical analysis, data transformation, visualization and integration with diverse genomic resources. Remark: This package is maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-shortread/trunk/ -- 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/20131201202827.2931.19634.report...@mail.an3as.eu
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
This one time, at band camp, Lucas Nussbaum said: > On 01/12/13 at 17:53 +, Stephen Gran wrote: > > This one time, at band camp, Lucas Nussbaum said: > > > What goals are set for a given release seem to me to be something > > squarely in that realm, especially given that there is no 'stick' - > > there's not really anything to compel others to play along. > > Ah, interesting. My POV is that "release goals" are kind-of misnamed, > because most of them are not specific to releases, but are instead > general technical changes. > Most of the goals proposed on https://wiki.debian.org/ReleaseGoals are > very valid and interesting technical changes, but I really fail to see > how they are specific to a given release. Maybe you could explain why > you think that it's the case? The bullet-point new feature list for a given release is generally speaking, a combination of 'gnome x.x, kde x.x' style version enumeration and the result of release goals. See the bit about multiarch on http://www.debian.org/News/2013/20130504.en.html, for instance. I can't see how a set of new features targeted at the next release can't help but be related to the next release. > > Can you explain why you think it would be a good idea to remove the > > power to decide their own goals from a team, and why you think it > > would be good for Debian to have one team drive another team's > > goals? This is so different to how we usually work that it seems > > jarring. > > Release goals are usually achieved by contributors working on one > specific goal, not by the release team (= the release team doesn't > actively fix packages for release goals). Huh. My impression from watching the last several releases was that the release team was a lot more involved than that in actually doing the work of meeting release goals, and not just a note keeper for someone else's pet project. > The role of the release team regarding release goals is to: > 1) evaluate/approve goals > 2) follow progress (using BTS usertags, usually) and re-evaluate > during the release cycle. > So, I don't think that it's correct to describe release goals as the > release team's "own goals". OK, so you really do think the release team just does paper work for someone else's goals. I can understand why you don't have a problem changing who makes the decisions, then. I don't share your point of view about the amount of work the release team has historically put into this sort of thing. > Then, yes, I question whether it should really be the release team's > role to evaluate and approve such goals. I'm currently working on a > delegation for the release team (non-final draft at [1]), and I agree > that fictious goals such as "gcc 4.9 by default in jessie" or "GNOME > 3.14 in jessie" would totally be in the realm of the release team, but > are already covered in the delegation. It's good of you to allow them the freedom to be able to choose the compiler version in the next release. You should be careful about allowing them that much power, it might go to their heads. > If you think that the release team should have the power to decide on > release goals, how should this draft delegation be changed to include > that? I would presumably put something like: * Release Team members decide on the release goals for stable releases But I am a simple man. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#731088: ITP: libvirt-python -- libvirt python bindings
Package: wnpp Severity: wishlist Owner: "Guido Günther" * Package name: libvirt-python Version : 1.2.0 * URL : http://libvirt.org/git/?p=libvirt-python.git * License : LGPL 2.1 Programming Lang: Python Description : libvirt python bindings Upstream split out the python bindings so we need to reintroduce this as a new source package. -- 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/20131201210720.ga27...@bogon.sigxcpu.org
Re: Release sprint results - team changes, auto-rm and arch status
On Sat, Nov 30, 2013 at 11:25:01PM +, Ben Hutchings wrote: > > MUL is a MIPS32 instruction, which is not present on MIPS3 CPUs like the > > Loongson 2, MULT + MFLO should be used instead. There is no CPU bug > > there, it's like trying to build x86 code with SSE4 instructions, and > > then saying that all x86 CPUs which do not support the SSE4 instructions > > are buggy. > > That was only the first problem; read the whole entry. > The other problem can be attributed to a bug in the CPU... or not. The fact that mono works on one CPU and not on the other, while they have different instruction sets can not be attributed to the NOP issue. Without the analysis done in this same blog entry, the MUL "issue" could also have been taken for a CPU bug. Said otherwise, if a code works on a Pentium Pro, but not on a Pentium, one can't be sure that the problem is the F0 0F bug. It could also be code using the cmov instruction. Also note that the latest batches of the Loongson-2F CPUs have the bug fixed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- 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/20131201213355.ga21...@hall.aurel32.net
Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
On 01/12/13 at 20:38 +, Stephen Gran wrote: > This one time, at band camp, Lucas Nussbaum said: > > On 01/12/13 at 17:53 +, Stephen Gran wrote: > > > Can you explain why you think it would be a good idea to remove the > > > power to decide their own goals from a team, and why you think it > > > would be good for Debian to have one team drive another team's > > > goals? This is so different to how we usually work that it seems > > > jarring. > > > > Release goals are usually achieved by contributors working on one > > specific goal, not by the release team (= the release team doesn't > > actively fix packages for release goals). > > Huh. My impression from watching the last several releases was that the > release team was a lot more involved than that in actually doing the > work of meeting release goals, and not just a note keeper for someone > else's pet project. My memory might fail me. Could you provide an/some examples? Also, even if some release team members contributed to achieving release goals, are you sure that this was really done with the release team hat? As a counter-example, half of the Lintian maintainers are or were members of the release team at some point, but I don't think that the release team ever claimed that maintaining Lintian was part of their normal duties. > > If you think that the release team should have the power to decide on > > release goals, how should this draft delegation be changed to include > > that? > > I would presumably put something like: > * Release Team members decide on the release goals for stable releases I think that a delegation would need to be a bit more specific in defining what "release goals" are, and what it means to have a goal labelled as "release goal". At least for me, the current definition of "release goal" is rather unclear. 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/20131201213328.ga8...@xanadu.blop.info
Re: Role of Release Goals
>> I would presumably put something like: >> * Release Team members decide on the release goals for stable releases > I think that a delegation would need to be a bit more specific in > defining what "release goals" are, and what it means to have a goal > labelled as "release goal". At least for me, the current definition of > "release goal" is rather unclear. It does sound to me like you two are discussing two things: - There are project-wide changes to be done and someone needs to take a decision to do them to adjust some of our common rules to make them easier to do. Lets name them "technical project goals" - There are project-wide changes to be done that should be done in time for a certain release and someone needs to decide which of those are for which release, and to probably adjust some of our common rules even more. Ie. release-goals. I think the second one is more than sure a part of the release teams call. The first was with RT in the past, and it seems Lucas wants to move that elsewhere. I don't really see a problem in that - $someone decides on "technical project goals", whatever they are. And RT can decide that they should be for the next release. Or the one after. Setting a timeline until when its done. Additionally, the RT can (in whatever ways) come up with more release-goals, say "gcc must be version 42.0815 for jessie". Though I don't see why it needs a split now - has the RT done such a bad job with the goals? -- bye, Joerg The sun? That’s the hottest place on Earth. -- 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/87bo105hiv@gkar.ganneff.de
Re: Role of Release Goals
On 01/12/13 at 23:32 +0100, Joerg Jaspert wrote: > > >> I would presumably put something like: > >> * Release Team members decide on the release goals for stable releases > > I think that a delegation would need to be a bit more specific in > > defining what "release goals" are, and what it means to have a goal > > labelled as "release goal". At least for me, the current definition of > > "release goal" is rather unclear. > > It does sound to me like you two are discussing two things: > > - There are project-wide changes to be done and someone needs to take a >decision to do them to adjust some of our common rules to make them >easier to do. Lets name them "technical project goals" > > - There are project-wide changes to be done that should be done in time >for a certain release and someone needs to decide which of those >are for which release, and to probably adjust some of our common >rules even more. Ie. release-goals. If release goals are a subset of technical project goals, then I agree with your definition, yes. Which rules could need adjustment? - NMU rules? (I already argued against it, but feel free to disagree) - freeze exemption rules? In the draft delegation I pointed to, the release team can already decide which bugfixes are suitable for inclusion in the various suites, so freeze exemptions are already covered, though the release team expressed during the meeting that, to favor a shorter freeze, they might not allow freeze exemption for release goal bugfixes. > I think the second one is more than sure a part of the release teams > call. The first was with RT in the past, and it seems Lucas wants to > move that elsewhere. > > I don't really see a problem in that - $someone decides on "technical > project goals", whatever they are. And RT can decide that they should be > for the next release. Or the one after. Setting a timeline until when > its done. Additionally, the RT can (in whatever ways) come up with more > release-goals, say "gcc must be version 42.0815 for jessie". > > Though I don't see why it needs a split now - has the RT done such a bad > job with the goals? Heh :) no. See [1]. During the release team meeting, the release team was not super at ease with deciding whether specific technical goals were worthwhile for Debian. I fully understand that. Some technical goals have a very high impact on Debian. Let's take the "clang as secondary compiler"[2] one, for example: - there are very good reasons to do that: being able to rebuild Debian with Debian makes Debian the distribution of choice to work on static analysis, and general compiler testing. So this will result in many indirect improvements to Debian and Free Software in general. - but that goal has a high impact for Debian. There's a dependency on the "honor CC and CXX"[3] release goal proposal, that will require changes in many packages. For clang support itself, 11% of the packages are currently failing to build, and will require changes. Does Debian should invest time to fix all those issues, and then maintain the patches that will not be accepted by upstreams? And how should we decide that? Ask the release team to take the decision, even if it's quite unrelated to releases? I think that there are really two problems: 1) Have a recommended process to discuss project-wide technical goals, gather feedback, and reach consensus. As I wrote in https://lists.debian.org/debian-devel/2013/11/msg00455.html, I think that the discussion about them should happen on public lists. 2) If the release team wants it, have a process for carte blanche freeze exemptions for specific classes of bugfixes (typically, for large-scale changes that are close to completion at the beginning of the freeze). It's the release team decision to decide which classes of bugfixes are sufficiently low impact that they want to risk introducing regression that could lengthen the freeze. (And it's also up to the release team to decide whether they want to have such carte blanche freeze exemptions at all). [1] https://lists.debian.org/debian-devel-announce/2013/11/msg7.html [2] https://wiki.debian.org/ReleaseGoals/clang-secondary-compiler [3] https://wiki.debian.org/ReleaseGoals/honorCCandCXX 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/20131202070332.ga11...@xanadu.blop.info
Re: Release sprint results - team changes, auto-rm and arch status
]] Aurelien Jarno > Also note that the latest batches of the Loongson-2F CPUs have the bug > fixed. That doesn't help us when the MIPS porters seem to be unable to get us any reasonable machine with the bug fixed, even after repeated proddings. IIRC, aba has been poking at this on and off for about six months, but that doesn't help us until we actually have machines racked and set up as porter boxes/buildds. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/871u1vg1it@qurzaw.varnish-software.com
Re: Release sprint results - team changes, auto-rm and arch status
Op 28-11-13 21:04, Niels Thykier schreef: > It has also come to our attention that a few buildds do not use > throw-away chroots. This sometimes results in unclean builds and we > have therefore decided to only consider architectures which use > throw-away chroots for all suites on all buildds as candidate release > architectures. You're talking about praetorius here. It will revert to throwaway chroots the minute LVM gets unbroken in stable. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: OpenPGP digital signature
