Re: Question for all candidates: Release process
* Charles Plessy ple...@debian.org [100327 06:17]: I think that the ‘RPM hell’ that you used to comment my propositions is more related to a situation when independant distributions are using the same package format, than when a distribution offers multiple repositories that obey to a policy that keeps the whole system functional. Even repositories from the same project tend to diverge enough that everything fails apart from a user perspective. One of the biggest practical advantages of Debian is that there is one Release of virtually everything. Everything fits and no incompatiblities of the different 'unimportant' things (Remember what is unimportant for the general is still important for most the people using it). Thus splitting the archive in core and non-core can at worst create multiple diverging no longer matching repositories for the different tasks. And at best causes one core system freezing earlier and then all the rest freezing based on that, which is something Debian already tried without splitting things apart and I got the impression people did not think that lead to anything but problems. Regarding my proposal, that is internal to Debian, I do not think that it is impossible. What I propose is a way for package maintainers to signal that their package is peripheral in the Debian system, in an opt-in manner. Debian is running out of manpower, and I think that it will be useful to let know that a given package can be given a low priority for tasks. We lack manpower in core tasks. In the packages that are too big to fail. People never had much problem to keep packages unimportant for the general out of releases (even to the point of packages I miss desperately). Some system to direct focus might be nice, but I really doubt it would change things much. Anyone with a little bit of knowledge knows what the core packages are and that fixing those is more important. You can't tell me that the hordes of gosh, there is a bug in some little game that is RC since 3 days, with a one-line fix that is already in all VCSes but in no package because there was no upload for a year, let's NMU fast people will suddenly stop reaching for low-hanging fruits and instead look at bugs that cannot be fixed without looking for at least a week at it? Our current priority system does not fit that task. Because of the rules about conflicts, important packages like postfix are of priority extra. How is postfix important? It's not installed by default, the majority of people does not need it. It may be important to you and many other people, but virtually every package is important to at least one person. With a priority system improved along this direction, I think it opens the possibility to let some architectures release without the least important packages. What is let some architecture release supposed to mean. Being subscribed to some architecture specific lists, I cannot remember people active for some architecture ever requesting they do not want some package. Usually that is the maintainers of the packages that complain that those architectures are not enough like i386 to simply choke code that should never had been open source because even the possiblity that a human would look at it is a crime against humanity. Not having some package in some architecture makes that architecture much less attractive, because differences suck. Most people having more than stuff still booting in 16 bit mode usually have multiple architectures. Having one Debian that is the same everywhere is a very big advantage from the point of the user. I cannot imagine some architecture no longer wanting that, because that would mostly be suicide. So is this let supposed to mean allow or to mean force? We also already have a possiblity to release without some package on some architecture. Just stop building it and request removal from unstable. There is a reason we frown upon this. Building stuff everywhere and make it work everywhere is a big investment in quality and making things fit for the future. I doubt without years of fixing bugs everywhere to make things work on alpha (which could be seen to be mostly an architecture born dead in a commercial sense quite early), introducing amd64 could have been done thus smootly as it comparatibly was. And all those alignment issues on most architectures usually also speed up code in i386 if fixed properly... Hochachtungsvoll, Bernhard R. Link -- 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/20100328105131.ga6...@pcpool00.mathematik.uni-freiburg.de
Re: Question to all candidates: DPL's role in important package maintenance
On Sat, Mar 27, 2010 at 06:27:00PM -0500, Kumar Appaiah wrote:
First of all, I wish you all the very best for the elections!
Hi Kumar, thanks a lot!
This has led some parts of the community (Debian Python, in this
case) to knock the doors of the tech-ctte[1] (recommended reading,
unless you have done so already).
I'm aware of the issue and I'm subscribed to the bug report.
My question to you is, do you envision a role for the DPL in fixing
such inadequate maintenance of important packages, or are you of the
opinion that is it up to the affected Debian community to stop
whining and step up with some action themselves?
I do see a DPL role in fixing this kind of issues between the maintainer
of an important package and the community revolving around all its
satellite packages. While the proper mechanism to solve this kind of
issues is exactly the tech-ctte, I believe there is quite some room of
moral suasion that the DPL should do (or delegate) to avoid this kind
of issues escalate or go on for much too long anyhow. When the does not
work, there isn't much more that the DPL can do.
In the specific case you mention, I'm aware that Steve has tried to
mediate at least in the form of offering resources to organize a F2F
meeting with all involved people (as reported in the bug log), but
unfortunately some of the involved parties did not reply to the
offer. All this is TTBOMK, on all sides of the issues.
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 to all candidates: DPL's role in important package maintenance
On Sun, Mar 28, 2010 at 16:51, Stefano Zacchiroli z...@debian.org wrote: ... unfortunately some of the involved parties did not reply to the offer. Not some, just one: the Python maintainer. (as said in the bug log.) Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/8b2d7b4d1003280756h3d26b5b0h79225ccfeca89...@mail.gmail.com
Re: Question to all candidates: DPL's role in important package maintenance
Dear Zack, Thanks for the response. On Sun, Mar 28, 2010 at 04:51:52PM +0200, Stefano Zacchiroli wrote: My question to you is, do you envision a role for the DPL in fixing such inadequate maintenance of important packages, or are you of the opinion that is it up to the affected Debian community to stop whining and step up with some action themselves? [snip] In the specific case you mention, I'm aware that Steve has tried to mediate at least in the form of offering resources to organize a F2F meeting with all involved people (as reported in the bug log), but unfortunately some of the involved parties did not reply to the offer. All this is TTBOMK, on all sides of the issues. Probing further on this response of yours: The method adopted for resolution of this conflict has, for better or for worse, happened behind-the-scenes. Now, some in the project feel that this is the best way to avoid a conflagration of sorts, but others feel that this back channel approach does not augur well for a project which strives to adopt open procedures. Would you, as DPL, facilitate such negotiations in the open (for instance, on a publicly viewable mailing list), or under wraps? Thanks! Kumar -- Linux: the operating system with a CLUE... Command Line User Environment. (seen in a posting in comp.software.testing) signature.asc Description: Digital signature
Re: Question to all candidates: DPL's role in important package maintenance
On Sun, Mar 28, 2010 at 09:59:08AM -0500, Kumar Appaiah wrote:
The method adopted for resolution of this conflict has, for better or
for worse, happened behind-the-scenes. Now, some in the project feel
that this is the best way to avoid a conflagration of sorts, but
others feel that this back channel approach does not augur well for
a project which strives to adopt open procedures.
I absolutely agree with this concern of yours (well, of the others
mentioned, not sure if you're among them or not :-P).
Would you, as DPL, facilitate such negotiations in the open (for
instance, on a publicly viewable mailing list), or under wraps?
Negotiations should happen in the open. That is the case not only
because we are meant to be an open project, but also because when they
are not, the disruptures in the community they will cause later on are
unbearable (as some of ours most typical flame patterns show).
I concede that in some cases there might be some under wraps mails,
but the only justification I can imagine for that right now is when
there are personal feelings or other personal information at stake
(which, I think, can be censored somehow to not let the project in the
dark).
I also understand that in some cases there can be exchanges which are
not immediately available (e.g. if a meeting it set up to solve the
issue, I don't necessarily expect the meeting to be in streaming).
Nevertheless they should be planned in the open a priori, and promptly
summarized a posteriori to let the rest of the project know and possibly
contribute.
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: Questions for all candidates: decentralization of power
On Wed, Mar 24, 2010 at 01:51:45PM -0300, Margarita Manterola wrote: I'd very much like to know how _you_ think that it should be done, because even if I don't like the We have to like you in order for you to work with us clause, I don't think it would be productive if the DPL, or someone in a similar role, started appointing new members to the teams and forcing people that don't like each other to work together. Well, in the paid employment part of my life, I have been put in positions where I have needed to work with people I disliked, and it is not considered professional to refuse on those grounds. In Debian I receive bug reports from people I might dislike, but I treat those just the same as I do from anyone else. Would you consider it appropriate me to refuse to acknowledge bugs or patches from anyone I consider to be a bad person? If not, why would it be appropriate for someone to refuse to collaborate in other ways? We theoretically all want good things for Debian here, even if we disagree on most of the details. Letting groups of people with privileged access maintain their own membership creates a power imbalance that I believe has led to much trouble in the past. I think it forms cliques and cabals, and encourages territoriality. Do you disagree? -- 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/20100328184107.ga21...@scru.org
Re: Question for all candidates: Release process
Le Sat, Mar 27, 2010 at 01:15:47PM +0100, Stefano Zacchiroli a écrit : I don't understand what cloud computing has to do with your idea of using package priorities to release differently different sub-systems within Debian. I'm well aware that we are currently lagging behind in the race for OS for the cloud (and we should really catch up, at least in terms of visibility), but what it has to do with your idea? Hi Stefano, I think that cloud computing participates to create the demand for a Debian system that offers not only a stable release that lasts years, but also updated packages that are built or collected for being used with the stable release. A mirror containing stable, backports, and snapshots is a good first step in that direction. The problem of having all backports in one single repostitory is of course that not all packages have the same needs, which creates incoordinations or conflicts of interest. Again, I am not saying that it will be the silver bullet, but a refactored priority and sections system would allow to easily identify subsets that could have a common policy and an increased effort for coordination, or in contrary a more unsupervised mode of operation when it comes to leaf packages (trust the maintainers!). I do not pretend to offer a complete and robust solution in my platform or the emails discussed on this list. But I ask the question to the DDs: would you like to distribute your work differently? If yes, vote for me as a DPL, and will spend time and energy to help the Project go that way. (And to answer to the comment ‘you do not need to be DPL for doing this’, that is true, but if I make a bad score at this election, I will conclude that there are not many persons interested in what I propose anyway, and will save everybody's time by not discussing them further in the short term.) Cheers, -- Charles -- 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/20100329015024.gb4...@kunpuu.plessy.org
Re: Question for all candidates: Release process
On Mon, Mar 29, 2010 at 9:50 AM, Charles Plessy ple...@debian.org wrote: (And to answer to the comment ‘you do not need to be DPL for doing this’, that is true, but if I make a bad score at this election, I will conclude that there are not many persons interested in what I propose anyway, and will save everybody's time by not discussing them further in the short term.) I find that attitude problematic. When electing a DPL we get a package deal. Some of each candidates ideas are liked by some/many, others disliked by some/many. It would be a shame to throw out good ideas with bad ones. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/e13a36b31003282003r60f47ee4n69a459f9606b0...@mail.gmail.com
