Re: Question for DD candidates: The race against NOTA
On Thu, Mar 18, 2010 at 2:07 AM, Gunnar Wolf gw...@gwolf.org wrote: Of course - But we do have a press team. If we were to lack a Leader, the press team would just become the contact point for the press, right? Without a leader, the press team would have to be delegated by the body of developers, through a GR or similar election, in order to actually be the voice of Debian. (note that I am not against the DPL position, I am just entertaining the idea) I beg you to please stop entertaining it until it at least seems possible. -- Besos, Marga -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e8bbf0361003180502p1bcddf70ia6c664d5e3893...@mail.gmail.com
Re: Question for DD candidates: The race against NOTA
Hi! Margarita Manterola schrieb: Without a leader, the press team would have to be delegated by the body of developers, through a GR or similar election, in order to actually be the voice of Debian. Leaving out meta questions, when one can be considered to be the voice of Debian, but the press team are already delegates. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ba21f94.4060...@debian.org
Re: Question for DD candidates: The race against NOTA
On Wed, Mar 17, 2010 at 11:07:32PM -0600, Gunnar Wolf wrote:
Of course - But we do have a press team. If we were to lack a Leader,
the press team would just become the contact point for the press,
right?
Right, but the difference is in directionality.
The press team puts into use their abilities to communicate properly
something which has been decided by others entities of the project which
are entitled to take the actual decision (specific teams or the DDs as a
whole by the means of a GR). The press team however cannot answer to
specific questions on behalf of the project, whereas the DPL can.
Of course the DPL should not be pressed into _taking_ decision by the
question he/she receives. The DPL, being a _representative_ role towards
the world, should only reply on subjects which have been already decided
upon by other project entities. But that's a different matter.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Question for DD candidates: The race against NOTA
On Thu, Mar 18, 2010 at 9:41 AM, Alexander Reichle-Schmehl toli...@debian.org wrote: Without a leader, the press team would have to be delegated by the body of developers, through a GR or similar election, in order to actually be the voice of Debian. Leaving out meta questions, when one can be considered to be the voice of Debian, but the press team are already delegates. I know, but if we were to be without a DPL, those delegations could not be re-validated. It is not clear by reading the Constitution what would happen to the DPL delegates if there was no DPL. However, even assuming that all delegations stand, if someone resigns to their post and there's no DPL then there's no way of replacing that someone with someone else, without some voting implied. I'm sorry, but I really don't see any use to all this mind exercise, could we stop now, please? -- Besos, Marga -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e8bbf0361003180553y2cca3ffhffbdf1da830fe...@mail.gmail.com
Re: Q for all candidates: (Old) Architecture Support
В Thu, 18 Mar 2010 00:02:56 +0900, Charles Plessy написа: Le Wed, Mar 17, 2010 at 03:49:16PM +0200, Yavor Doganov a écrit : * There should be an entitiy within the project to decide which arch gets released and which not I do not completely agree with this: I think that the porters should have much more latitude on how to what their port contain. If they can assemble a reasonable subset of Debian's packages into a working system that matches the expectations of the users and that Debian can be proud of. Interesting. Are you suggesting that bugs (mostly of the FTBFS type) should be ignored at the discretion of the porters and other important teams on a per-package basis (e.g. Nobody in their right mind would install `foo' here, so it's OK to ignore the bug)? I think that this is a dangerous path to follow. IMHO it is the fastest way to *prematurely* kill an arch. Problems will start to accumulate, and issues with non-trivial inter-dependencies (e.g. resolving one major bug depends on the fix for another, sometimes in a different package) will pile up on the TODO stack, which at some point would inevitably lead to enough, this arch is problematic, so we have no choice but to exclude it from the release. Ideally, all architectures should be equal (in practice they are not, but theoretically the criteria are the same). If the project allows the lapses you seem to suggest, that would be the end of all but mainstream archs. IMVHO. Architectures that lose their mainstream position and therfore upstream support in popular heavy-weight applications could survive much longer. I seriously doubt that if your view/plan is in force. IIRC, this plan was discussed on -m68k (at least) several times in the past, and this is a plan to hide bugs, to sweep them under the carpet. YMMV, of course. (Just as a side note, you would be surprised how much impossible to use complex/heavyweight packages people install and run (even for testing purposes) on slow architectures. It is hard to predict the limit of users' patience, therefore I conclude that it is not possible to state with certainty package foo is not suitable for arch bar because of performance reasons. And yes, I say this from the standpoint of experience -- my home machine park is Jurassic, and still I manage to do what I intend to do with the tiny computer power available.) if nobody wants to fix the bug, it is a good indicator that everybody has more important, more rewarding, and in the end more fun things to do, and that we should trust their judgement by changing our release strategy instead of maintaining an institution that opposes people. I disagree with this sentiment, but who am I to disagree... If nobody wants to fix the bug, this probably means that the majority of users are not affected by this bug. However, it has always been my understanding that a Debian package maintainer should look a little bit more forward than her own packages, and should do her best to ensure that everything she maintains is at least buildable on all Debian architectures, including unofficial ones (whether former stable ones or new, struggling to become official). -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hntf4s$k...@dough.gmane.org
Re: Question for DD candidates: The race against NOTA
On Thu, Mar 18, 2010 at 09:53:46AM -0300, Margarita Manterola wrote: I know, but if we were to be without a DPL, those delegations could not be re-validated. It is not clear by reading the Constitution what would happen to the DPL delegates if there was no DPL. However, even assuming that all delegations stand, if someone resigns to their post and there's no DPL then there's no way of replacing that someone with someone else, without some voting implied. Actually, if there's no DPL, then the secretary and the chairman of the TC must jointly take up the role of the DPL (what, you didn't think the world would end, did you? ;-) I'm sorry, but I really don't see any use to all this mind exercise, could we stop now, please? My thoughts exactly. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html signature.asc Description: Digital signature
Re: Q for all candidates: (Old) Architecture Support
On Wed, Mar 17, 2010 at 10:49 AM, Yavor Doganov ya...@gnu.org wrote: Debian has been known through the years for its excellent support for many architectures. In theory, a released arch should be as stable as the common/popular archs. (In practice, it is/was pretty close, which is good enough.) Yes, this has always been something that makes me be proud of about Debian, and I'd definitely like for it to continue that way. (... skipping the bulk of the analysis ...) What do you think the project should do (with or without or regardless of your help as potential DPL) to preserve this goodness (maximum supported architectures) for as long as possible? Do you think it is goodness or you're in the good riddance camp? I would like to support as many architectures as possible. We cannot deny the passage of time, however, and so we must accept that some architectures are bound to stop being supported. This even happened some years ago with 386. We still call the common architecture i386, but a real 386 computer wouldn't be able to run the current systems, since the kernel requires at least 486. The only way for an architecture to be supported is to have enough people interested in it, enough porters working on the toolchain, the kernel, and helping the maintainers with the arch specific bugs. If there's enough interest in the arch, then it's probably going to survive, if too many people lose interest, then it becomes impossible to maintain the port. The root of the problem then comes back to lack of enough contributors, which is one of the problems I plan to tackle if I'm elected. I'm not really sure on how to attract more people to contribute as porters, since that usually requires having access and interest in a particular platform, but with the use of porting tools, like using QEMU to emulate a particular architecture where a bug needs debugging, we could try to encourage more external contributors to help fix porting bugs, and thus help keeping the overall health of the port. Also, we could try to improve motivation on bug fixing, by reminding developers that each time they fix an arch specific bug they are improving the overall quality of the software and that we really appreciate having high quality software. -- Besos, Marga -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e8bbf0361003181302q3af153d2k73484b6b7eede...@mail.gmail.com
Re: Question for all candidates: Release process
Le Mon, Mar 15, 2010 at 08:09:19AM +0100, Lucas Nussbaum a écrit : During the last debconf, the freeze of squeeze was first announced to take place in December, then this decision was cancelled, and now we are in March. - How do you analyze what happened during last summer? What went wrong? - What is your opinion on the motivations for the proposal to freeze in December? Specifically, in the future, should we try to coordinate our release process with Ubuntu's? - So, we are now in March. What is your opinion with the release process so far? When do you see the release happening? Hi Lucas, I was really disapointed when I read the press release. After announcing a decision to the public, it is very difficult to change it; it really gave me the impression to have my arm twisted. The freeze of Lenny was quite long, and I tried to play the game, not updating my packages but doing release-oriented work (including some tasks very specific to Debian Med, which did not have an impact on Lenny's releasability). As a consequence, I was very worried that I would not be able to update my packages to all the new upstream releases that happened during the freeze, if we would freeze again in December. This said, I am well aware that all my packages are not essential to Debian's life, and I decided to not complain too much and trust the judgement of the release team. However, my personal opinion was that it is not a good idea to release Debian with packages less up to date and a shorter security support than Ubuntu. I would rather release on the years where there is no Ubuntu LTS. This way, people trained to use dpkg-based distributions have the opportunity to install a recent release with a reasonably long support each year, instead of each second year. I think that this would maximise Debian and Ubuntu's user base. In this elections I propose to change our release philosophy. Depending how oftern the kernel, libc, GNU, GCC, X.org, and other bright software stars align in the sky, it could mean that we could release a core distribution more often (than each second year) if we were interested in committing to this effort. Still, a synchronisation with Ubuntu is taking the problem in the wrong direction, I think. I do not have a long experience in collaborations with Ubuntu but it seems that to meet deadlines, they do not hesitate to diverge with upstream projects much more than what we are used to. I do not think that we shall follow them in this path. I see more collaborations made on opportunity basis, when both distribution's choices are naturally converging. We can not promise to be ready to release the 1st of April 2012. Now we are in March and I do not know when we will release. For the Lenny release, with the release goals, the progressive freeze and information emails from the release team, we went through milesones that I think helped a lot the Project have a good feeling of the timing. The last footstep took more time. It was written often that it is because there were too many RC bugs, but I think that the true reason is that we were waiting for the installer team. I do not write this to throw a stone to them, but to repeat once again that fixing abandonned package does not make the release closer [but if you have fun with this, do not stop! Debian is also about having fun]. Turning the spotlights on the most difficult blockers would be very helpful. I do not know if we can release soon, in the sense that I do not know if the packages providing the core functionalities of our operating system are ready. Honestly, as a DD I am not interested to fix bugs like python packages that do not work with version 2.6 if the maintainer does not at least ask for help (I would rather be interested to participate to bolder package removal sessions). If many other DDs share the same impression, and if all RC bugs are left in the same bag without indication of priority, then we probably will not release soon. Milestones like freezing the toolchain would send a strong message that it is time to refocus our efforts from our own packages and team to the last blockers. Since the original plan was to release with Ubuntu LTS and that will not be done, as a DPL I would ask the release team to update the project on its plans. Have we lost the announced benefits of a joint release and postopone for more than a couple of months to allow more developments, or are we very close to freeze our core toolchains anyway ? Frans Pop wrote an insightful email on how the release is also a lot of communication work. If I am elected DPL, I will emphasise this role in the delegation given to the release managers. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100319012849.ga1...@kunpuu.plessy.org
