Re: Standardization, large scale changes, innovations
Le mardi 30 mars 2010 à 15:42 -0700, Manoj Srivastava a écrit :
I might agree that maintenance of my packages might raise a
competence bar for the would-be-maintainer, and some people might fail
to meet that bar.
Let’s say we find this in a package:
define create_md5sum
create_md5sums_fn () { \
cd $$1 ; \
find . -type f \
! -regex './DEBIAN/.*' \
! -regex './var/.*' $(EXTRA_MD5SUM_EXCLUDE) \
-printf '%P\0' | xargs -r0 md5sum DEBIAN/md5sums ; \
if [ -z DEBIAN/md5sums ] ; then \
rm -f DEBIAN/md5sums ;\
fi ;\
} ;\
create_md5sums_fn
endef
Of course it doesn’t take long for a long-term developer to understand
this is a reimplementation of dh_md5sums. However a newcomer not aware
of your fanatic rejection of any kind of standard tools would absolutely
not understand what this is about. And the same goes about everything
else in the package.
Now when we upgrade our policies and/or infrastructures, like what was
recently proposed for sha1sums instead, this requires manual updating of
all our packages for no good reason.
This doesn’t raise questions about the competence of the newcomer. This
raises questions about the competence of the person who designed the
package.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `' “A handshake with whitnesses is the same
`- as a signed contact.” -- Jörg Schilling
--
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/1270030083.18218.5.ca...@meh
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Josselin Mouette wrote:
Le mardi 30 mars 2010 à 15:42 -0700, Manoj Srivastava a écrit :
I might agree that maintenance of my packages might raise a
competence bar for the would-be-maintainer, and some people might fail
to meet that bar.
Let’s say we find this in a package:
define create_md5sum
create_md5sums_fn () { \
cd $$1 ; \
find . -type f \
! -regex './DEBIAN/.*' \
! -regex './var/.*' $(EXTRA_MD5SUM_EXCLUDE) \
-printf '%P\0' | xargs -r0 md5sum DEBIAN/md5sums ; \
if [ -z DEBIAN/md5sums ] ; then \
rm -f DEBIAN/md5sums ;\
fi ;\
} ;\
create_md5sums_fn
endef
Of course it doesn’t take long for a long-term developer to understand
this is a reimplementation of dh_md5sums. However a newcomer not aware
of your fanatic rejection of any kind of standard tools would absolutely
not understand what this is about. And the same goes about everything
else in the package.
Abillity to understand fairly simple shell script is not a
matter of tenure. It is a matter of competence. I am dismayed that a
fairly bland invocation of find seems opaque, in your opinion, to
people coming into the project today. I hope that is not indeed
true. Personally, I find a small shell snippet to be clearer than a
reference to a external program, and when finding myself stuck in
RHEL-land, my packages build, and would have caused more pain were they
dependent on helper packages. I find that justification enough.
Now when we upgrade our policies and/or infrastructures, like what was
recently proposed for sha1sums instead, this requires manual updating of
all our packages for no good reason.
That would be the naive way to implement things. And yes, that
would be sillly.
I just update code in one place, test it, and then run a script
that does a git pull for all my packages. The next time I build the
package, it will pull in the change.
This doesn’t raise questions about the competence of the newcomer. This
raises questions about the competence of the person who designed the
package.
I am happy you have an opinion. I don't think much of it, but
you are indeed entitled to it.
manoj
--
How untasteful can you get?
Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C
--
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/87hbnwzoj5@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
Le mercredi 31 mars 2010 à 05:03 -0700, Manoj Srivastava a écrit : I just update code in one place, test it, and then run a script that does a git pull for all my packages. The next time I build the package, it will pull in the change. Which is what I already explained in other terms: Your packages are absolutely impossible to maintain by anyone but yourself. This doesn’t raise questions about the competence of the newcomer. This raises questions about the competence of the person who designed the package. I am happy you have an opinion. I don't think much of it, but you are indeed entitled to it. I wouldn’t expect you to be able to question your own choices anyway. Actually, I shouldn’t be discussing this with you, this is pointless as always. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1270038146.18218.10.ca...@meh
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Josselin Mouette wrote: However a newcomer not aware of your fanatic rejection of any kind of standard tools would absolutely not understand what this is about. And the same goes about everything else in the package. Manoj Srivastava wrote: I just update code in one place, test it, and then run a script that does a git pull for all my packages. The next time I build the package, it will pull in the change. So you are indeed using package helpers. Those are just yours and not anyone else's… Personally, I find a small shell snippet to be clearer than a reference to a external program, and when finding myself stuck in RHEL- land, my packages build, and would have caused more pain were they dependent on helper packages. Hmm… So a shell snippet is clearer than a manpage [debhelper's not a GUI…] ? Are those helpers not installable/available on RHEL ? Maybe they should… OdyX -- 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/hovf0u$1v...@dough.gmane.org
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Josselin Mouette wrote: Le mercredi 31 mars 2010 à 05:03 -0700, Manoj Srivastava a écrit : I just update code in one place, test it, and then run a script that does a git pull for all my packages. The next time I build the package, it will pull in the change. Which is what I already explained in other terms: Your packages are absolutely impossible to maintain by anyone but yourself. I am not sure that follows. I think that if you want to maintain my packages you need to actually be comfortable with shell scripting and make. There is documentation lying around (./debian/common/README, debian/common/targets.dot). For normal NMU's and all, all the NMUerr does see is: create_md5sum which seems fairly self explanatory. At least as clear as dh_md5sum. This doesn’t raise questions about the competence of the newcomer. This raises questions about the competence of the person who designed the package. I am happy you have an opinion. I don't think much of it, but you are indeed entitled to it. I wouldn’t expect you to be able to question your own choices anyway. I personally think that would apply to present company as well. Actually, I shouldn’t be discussing this with you, this is pointless as always. I truly appreciate that. On Wed, Mar 31 2010, Didier 'OdyX' Raboud wrote: On Wed, Mar 31 2010, Josselin Mouette wrote: However a newcomer not aware of your fanatic rejection of any kind of standard tools would absolutely not understand what this is about. And the same goes about everything else in the package. Manoj Srivastava wrote: I just update code in one place, test it, and then run a script that does a git pull for all my packages. The next time I build the package, it will pull in the change. So you are indeed using package helpers. Those are just yours and not anyone else's… I am using a build system that comes with the package source. You may label it a helper if you so desire. Personally, I find a small shell snippet to be clearer than a reference to a external program, and when finding myself stuck in RHEL- land, my packages build, and would have caused more pain were they dependent on helper packages. Hmm… So a shell snippet is clearer than a manpage [debhelper's not a GUI…] ? Well, I find man pages are sometimes not to be trusted. I don't have debhelper around, so I can't say how clear the man page is. Knowing Joey, it is likely to be very clear. But for something as simple as this, I prfer actually looking at the code to be executed, and this is likely to be more sumple than dh_md5sum, since I do not have to provide a UI. Are those helpers not installable/available on RHEL ? Maybe they should… They are certainly not available here. I have not looked into installing them, to tell you the truth --- departure from the blessed image should be minimized, I thought, and it was not worth it for the few packages Ineeded. Did appreciate packages that build on non-debian bxes, at least until the build stage. manoj -- Ships don't come in, they're built. anon Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87aatozm8a@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
Le mercredi 31 mars 2010 à 05:53 -0700, Manoj Srivastava a écrit : I wouldn’t expect you to be able to question your own choices anyway. I personally think that would apply to present company as well. Wow. -- .''`. Josselin Mouette : :' : `. `' “A handshake with whitnesses is the same `- as a signed contact.” -- Jörg Schilling -- 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/1270040782.18218.22.ca...@meh
Re: Question to all candidates: DPL's role in important package maintenance
Dear Margarita and Stefano, On Mon, Mar 29, 2010 at 04:03:00PM -0300, Margarita Manterola wrote: [snip] On Sun, Mar 28, 2010 at 05:30:50PM +0200, Stefano Zacchiroli wrote: [snip] Thank you for your replies. I am glad that you care about this issue, and have voiced your opinion on how to handle it. Kumar -- posix this guy _is_ crazy stargazer posix: from the looks of Enlightenment he's on LSD posix LSD is nothing compared to what this guy's on.. -- Seen on #Unix signature.asc Description: Digital signature
Re: Question for DD candidates: The race against NOTA
Le Tue, Mar 16, 2010 at 10:32:22PM -0600, Gunnar Wolf a écrit : What would be different if there was no leader? Where would the project lose more? Would it gain in some aspect? Hello Gunnar, Biology shows that complex systems often evolved “leaders”, even when they are selected or take their actions randomly. In Debian as well, I think that a DPL or an equivalent function is necessary, not as a position of power, an official face or a model to follow, but as a piece of the machine that makes a coordinated project, as opposed to a fruitful but ephemeral collaboration of independant entities. Have a nice day, -- 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/20100331153540.ga15...@kunpuu.plessy.org
Re: Question to the candidates
Le Tue, Mar 23, 2010 at 11:49:53PM -0700, Steve Langasek a écrit : As a developer, how do you embody the spirit and culture that has made Debian a great operating system? If elected DPL, how will you inspire the same in others? Hi Steve, we have to inspire each other and the DPL does not make exception. But if the spirit and culture that has made Debian a great operating system is universality, one single individual can not impersonate every facets. Nevertheless, in addition to universality, I think that one major element of Debian's culture is to aim at excellence, and that a DPL should be careful of being clear and accurate in his work and communication. I will do my best to inspire others by doing what I say and saying what I do, staying neutral and humble, and not engage into or provoke conflicts. Have a nice day, -- 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/20100331155255.gb15...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
On Sun, Mar 21, 2010 at 12:46:44AM +0900, Charles Plessy wrote: Dear Clint, I also think that there are many restricted operations that should be opened. Write access to our website, chosing the priority and section of our pacakges, triggering bin-NMUs, designating new members, inspecting new packages submitted to our archive, ??? You do get to choose the priority and section which your packages belong to, though the ftp team can override your choice. When we do override your choice, you get an email inviting discussion about it. I can't think of any instance where the ftp team and maintainers haven't been able to come to an agreement about where the packages belong. The alternative option, where DDs are given write access to the dak database doesn't seem worth the security issues for the small benefit(?) of avoiding having this discussion with the ftp team. Inspecting new packages which haven't cleared NEW has potential legal problems. We don't want to be in the position where we are distributing software that might not be legal for us to distribute. Our trend has been to increase the amount of info about the packages we make available on http://ftp-master.debian.org/new.html (currently down), but we have to stop short of potentially illegally distributing software. For people that want to help with the process of auditing packages in NEW, The ftp team is looking for new members, our most recent solicitation being here: http://lists.debian.org/debian-devel-announce/2010/03/msg3.html stew signature.asc Description: Digital signature
Re: Standardization, large scale changes, innovations
Manoj Srivastava wrote: Now when we upgrade our policies and/or infrastructures, like what was recently proposed for sha1sums instead, this requires manual updating of all our packages for no good reason. That would be the naive way to implement things. And yes, that would be sillly. I just update code in one place, test it, and then run a script that does a git pull for all my packages. The next time I build the package, it will pull in the change. Exactly there is the problem. If you'd use dh_md5sums, a binNMU would be all that is needed to update your packages (yes, I know that is not yet possible for arch:all, but I guess the time will come...). In your case we have to wait until you've decided to upload all of your packages... -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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/4bb37e2c.5080...@bzed.de
Re: Standardization, large scale changes, innovations
On Wed, Mar 31 2010, Joey Hess wrote: Manoj Srivastava wrote: Abillity to understand fairly simple shell script is not a matter of tenure. It is a matter of competence. I am dismayed that a fairly bland invocation of find seems opaque, in your opinion, to people coming into the project today. I hope that is not indeed true. Personally, I find a small shell snippet to be clearer than a reference to a external program So, when I looked at your shell script, the problem was not in understanding it, it was in convincing myself that none of the 2 or 3 possible bugs I saw in it affected it in the way it was currently used in your packages, or could cause a surprise later. For example, it hardcodes excluding anything in /var from the md5sums. At the same time, it does not exclude conffiles, or anything in /etc. make has neither, but how, I wondered, could this code be used for something like tome, that does have files in /var, that need to be md5summed, as well as conffiles, which should not? Ah, turns out you have a different version there, that removes the /var exclude, and excludes /etc instead. Part of the simplicity of some of the constructs is that unlike helper tools, they do not have to be really all that generic. Though in this particular case,perhaps it is time to revisit my packages and see how I can improve the md5sum generation. Oh, I'd appreciate you pointing out the other bugs (perhaps in private email), now that you have looked at it enough to notice them. I'm always happy to improve my packages. (BTW, tome's use of /var/games for static game data smells of a FHS violation to me.) Hmm. Perhaps. Apex, bone, and save seem OK, the other directories could arguably be moved to /usr/share/tome. I'll think about that. manoj -- Aliquid melius quam pessimum optimum non est. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/878w98xn3q@anzu.internal.golden-gryphon.com
Re: Question to all candidates: DPL's role in important package maintenance
Le Sat, Mar 27, 2010 at 06:27:00PM -0500, Kumar Appaiah a écrit : My question to you is, do you envision a role for the DPL in fixing such inadequate maintenance of important packages. Hello Kumar, for the moment, you have taken the way of the Technical Comitee, and this does not require the intervention of the DPL. Asking the TC to solve a disagreement between two parties should be the occasion to write down the problem in a clear and concise way. In the case of Python, I think that it is really problematic that the maintainer did not give his point of view in public yet; I hope that it is only a question of time. Without interfering with the TC, as a DPL I would ask to the python's maintainer to explain himself on our mailing lists (this can be as simple as CCing the summary he has to send to the TC), and in return would make sure that he will not him regret this concession, by discuss in preliminary with the listmasters about the possiblity of limiting or delaying messages in case of a momentary lapse of self-control (the big red button that I proposed in another email). More in general, the DPL could be proactive. When a package or a service becomes very popular and interdependant with the rest, I would contact the responsible person or team and propose them to become more formal via a DPL delegation. Have a nice day, -- 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/20100401002325.ga16...@kunpuu.plessy.org
Re: Standardization, large scale changes, innovations
On Wed, Mar 31, 2010 at 09:48:56PM +0200, Frank Lin PIAT wrote: Doesn't the Unix philosophy implies that I should reuse tools and code, rather than re-writing my's own? No. The Unix philosophy is do one thing, and do it well. It implies that there's a useful toolbox from which you can use things. But you don't have to. My father, for instance, often drives a screw into a piece of wood with a chisel when he doesn't have a screwdriver around. And I've also seen him chop off bits of wood with a screwdriver, on occasion. Of course doing so is not at all the most efficient way of performing the task at hand; and if you're not careful, using a chisel as a screwdriver or a screwdriver as a chisel is a very good way to break either tool. And then you get to keep the pieces -- literally. When I was a bit younger, I used to think that my dad was a bit silly for doing this. It's not the most efficient way, and when (not if) he breaks something again, he'll have to go buy new stuff. A waste of money. But eventually, I realized that it just doesn't matter. What really matters is the result, not the way in which you get to that result. If he doesn't mind paying for extra tools when he broke them again, that's his problem, not mine. If he doesn't mind having to spend more time in getting to the result, that too is his problem, not mine. I'm not his boss, I don't pay him, so I don't get to order him around; and if he rather walks to the shop because he broke his tools again rather than spend some more time trying to find the right tool for the job, that's his problem. As long as the result is good -- and it usually is -- how he gets that result is not my business. The same is true with Manoj. You may think debhelper is the best thing since sliced bread (it might be), but Manoj just disagrees. And as long as Policy does not specify that debhelper is to be used, it's perfectly within his right to not use it. As long as the result is good -- a working, policy-compliant package -- how he gets that result is not your business. If you think otherwise, you should first get Policy changed, and then complain to Manoj. -- 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: Question to all candidates: DPL's role in important package maintenance
Hi Kumar, On Sat, Mar 27, 2010 at 06:27:00PM -0500, Kumar Appaiah wrote: Dear Candidates, First of all, I wish you all the very best for the elections! At the outset, this question is not meant to be inflammatory or to express ire at a particular individual or set of individuals involved; I have great respect for the contributions of all involved in the community. One of the questions which I've not yet seen exactly in the discussions is on the transparency in the maintenance of non-core but important packages, such as python, wherein the maintenance of the package and policy (till a short while ago) has been, poor at best, and we've had near zero communication from the maintainer(s) for over a year. 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 don't wish to comment on the specific case of python packaging. There's been lots of things going on there, and though some of it was in public, the thread you point to clearly states that some things were not discussed in public, but were instead only done through private mail between some of the people involved. As such, it's impossible for me to build a clear picture on what has been going on, which would be a prerequisite for commenting on this. 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? In the general case, I believe that when there are issues with important packages involving technical and social difficulties that apparently cannot be solved easily by the people involved, it is indeed the DPL's duty to step in and discuss the problems at hand in as open a manner as possible with all people involved, and to try to come to a solution. This may not be easy, and a solution that makes all people involved happy may be impossible. Such is life. But if such an option exists, we should seek it. -- 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: Question to all candidates: DPL's role in important package maintenance
On Thu, Apr 01, 2010 at 02:57:59AM +0200, Wouter Verhelst wrote: One of the questions which I've not yet seen exactly in the discussions is on the transparency in the maintenance of non-core but important packages, such as python, wherein the maintenance of the package and policy (till a short while ago) has been, poor at best, and we've had near zero communication from the maintainer(s) for over a year. 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 don't wish to comment on the specific case of python packaging. There's been lots of things going on there, and though some of it was in public, the thread you point to clearly states that some things were not discussed in public, but were instead only done through private mail between some of the people involved. As such, it's impossible for me to build a clear picture on what has been going on, which would be a prerequisite for commenting on this. Isn't this, by itself, a problem? Shouldn't it be very easy to find out what the discussions were, rather than have to ask those who discussed behind closed doors as to wha t the current situation is? I wish to draw your attention more towards this issue, rather than the particular case of python packaging. 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? In the general case, I believe that when there are issues with important packages involving technical and social difficulties that apparently cannot be solved easily by the people involved, it is indeed the DPL's duty to step in and discuss the problems at hand in as open a manner as possible with all people involved, and to try to come to a solution. This may not be easy, and a solution that makes all people involved happy may be impossible. Such is life. But if such an option exists, we should seek it. Thank you for this opinion. Kumar -- rm_-rf_ The real value of KDE is that they inspired and push the development of GNOME :-) -- #Debian signature.asc Description: Digital signature
Re: Question to all candidates: DPL's role in important package maintenance
Dear Charles, On Thu, Apr 01, 2010 at 09:23:25AM +0900, Charles Plessy wrote: for the moment, you have taken the way of the Technical Comitee, and this does not require the intervention of the DPL. Asking the TC to solve a disagreement between two parties should be the occasion to write down the problem in a clear and concise way. In the case of Python, I think that it is really problematic that the maintainer did not give his point of view in public yet; I hope that it is only a question of time. Without interfering with the TC, as a DPL I would ask to the python's maintainer to explain himself on our mailing lists (this can be as simple as CCing the summary he has to send to the TC), and in return would make sure that he will not him regret this concession, by discuss in preliminary with the listmasters about the possiblity of limiting or delaying messages in case of a momentary lapse of self-control (the big red button that I proposed in another email). More in general, the DPL could be proactive. When a package or a service becomes very popular and interdependant with the rest, I would contact the responsible person or team and propose them to become more formal via a DPL delegation. Thank you for sharing your opinion on this issue. Kumar -- What is the status of Linux' Unicode implementation. Will Linux be prepared for the first contact? We have full klingon console support just in case -- Alan Cox on linux-kernel signature.asc Description: Digital signature
Re: Standardization, large scale changes, innovations
Wouter Verhelst wou...@debian.org writes: The same is true with Manoj. You may think debhelper is the best thing since sliced bread (it might be), but Manoj just disagrees. And as long as Policy does not specify that debhelper is to be used, it's perfectly within his right to not use it. As long as the result is good -- a working, policy-compliant package -- how he gets that result is not your business. If you think otherwise, you should first get Policy changed, and then complain to Manoj. Also, as a general rule of thumb, Policy should be about standardizing interfaces, not about standardizing tools. What matters from a Policy perspective is what ends up on the system, what ends up in the package, and how the packages interoperate for the end-user, not how you create them. So from that direction, I'm not sure it would ever make sense for Policy to require debhelper. To the extent that Policy already does this in a few places, I think it's a bug, since among other things it makes it much harder to figure out what's really going on and it makes it harder for subsequent tool authors. If someone thought there was some much better design for how debhelper does things and wanted to start from scracth writing a new helper, they should be able to find documentation explaining what interfaces they need to satisfy, ideally. The major exception to this right now is that Policy assumes dpkg and the core dpkg tools (not the dpkg-dev tools necessarily) like dpkg-divert. I personally think this is a bug and I'd like to see the low-level documentation of the exact deb format, for instance, in Policy, but it's a very low priority compared to lots of other Policy work. Now of course if one orphans one's package or can't maintain it properly (lots of RC bugs, etc.), then I think redoing the packaging design is fair game once QA comes into play. Were Manoj to orphan a package, I suspect it's quite likely that whoever picked it up would convert it to debhelper, and that's fine. If I adopted a package maintained in bzr, one of the first things I'd do is convert the VCS repository to Git. But as long as the package is staying with its current maintainer and that maintainer is doing a good job, I think the obligation of that maintainer is to satisfy the interfaces, and what tools they use to do that is their business. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87tyrwrn4e@windlord.stanford.edu
Re: Question to all candidates: DPL's role in important package maintenance
Kumar Appaiah a.ku...@alumni.iitm.ac.in writes: On Thu, Apr 01, 2010 at 02:57:59AM +0200, Wouter Verhelst wrote: I don't wish to comment on the specific case of python packaging. There's been lots of things going on there, and though some of it was in public, the thread you point to clearly states that some things were not discussed in public, but were instead only done through private mail between some of the people involved. As such, it's impossible for me to build a clear picture on what has been going on, which would be a prerequisite for commenting on this. Isn't this, by itself, a problem? Shouldn't it be very easy to find out what the discussions were, rather than have to ask those who discussed behind closed doors as to wha t the current situation is? I wish to draw your attention more towards this issue, rather than the particular case of python packaging. Insofar as disagreements are technical, I think they need to become public. As with anything else about free software, more eyes are better; plus, we have as a project goal to not hide our problems and to discuss them in public. Insofar as disagreements are personal, I think requiring that they always be discussed in public has some implications that I'm not sure everyone realizes. By requiring that all personal disagreements be exercised in public, we would effectively be selecting for project contributors who can hold their own in vituperative public flamewars. I'm not sure that's actually a criteria that we should be selecting for. Obvious, in many cases, the two get intermingled badly, and I think that's probably the case here. In that case, it's often useful to bring in a third party to untangle the personal from the technical so that the technical can be discussed in public and we can reach a technical decision. But I would be very leery of applying the same problem resolution mechanism to all interpersonal problems that we want to apply to all technical problems. In general, and not here speaking about any specific case, I think that approach would drive away a fair number of people who would otherwise be valuable assets to the project. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87pr2krmum@windlord.stanford.edu
Re: Question to all candidates: DPL's role in important package maintenance
On Wed, Mar 31, 2010 at 08:05:40PM -0500, Kumar Appaiah wrote: On Thu, Apr 01, 2010 at 02:57:59AM +0200, Wouter Verhelst wrote: One of the questions which I've not yet seen exactly in the discussions is on the transparency in the maintenance of non-core but important packages, such as python, wherein the maintenance of the package and policy (till a short while ago) has been, poor at best, and we've had near zero communication from the maintainer(s) for over a year. 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 don't wish to comment on the specific case of python packaging. There's been lots of things going on there, and though some of it was in public, the thread you point to clearly states that some things were not discussed in public, but were instead only done through private mail between some of the people involved. As such, it's impossible for me to build a clear picture on what has been going on, which would be a prerequisite for commenting on this. Isn't this, by itself, a problem? Not necessarily. Shouldn't it be very easy to find out what the discussions were, rather than have to ask those who discussed behind closed doors as to wha t the current situation is? It depends on what the problem is. If the problems are purely of a technical nature, then sure, things should be discussed in the open. But it is my experience that often, problems that keep dragging on for months on end are /not/ purely of a technical nature. When the problem at hand is basically I think $FOO is an arse, but I don't want to say this in front of everyone, then it does make sense to discuss things behind closed doors. It doesn't even have to be purely emotional like that. $FOO thinks the right solution is to do this. I've explained several times now that that won't work, because of some particular cornercase that he dismisses out of hand, but which actually does happen. Every time I bring it up, the same arguments are rehashed over and over again, and I'm sick of them. I'll fix it, eventually, but he should stop nagging, and no, I'm not going to talk to him anymore. Discussing problems in public works very well if two people like eachother. If they don't, however, you get two people cursing at eachother. Now there are some people who really don't mind doing that in public; but when things get messy, not being messy out in the open actually makes a whole lot of sense. I think it's much more important that the problem at hand is solved. How this is done is less so. The technical arguments for why things are done in one way or another should be as public as possible; but if there are personal problems involved, smearing them out in the open should not be necessary, and it should be fine to have a private discussion so that the mediator can find out what the actual problems are. Of course that shouldn't be the principle; but we should not be afraid of discussing things in private, either. -- 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: Questions for all candidates: decentralization of power
Le Wed, Mar 31, 2010 at 12:00:05PM -0400, Mike O'Connor a écrit : You do get to choose the priority and section which your packages belong to, though the ftp team can override your choice. When we do override your choice, you get an email inviting discussion about it. I can't think of any instance where the ftp team and maintainers haven't been able to come to an agreement about where the packages belong. The alternative option, where DDs are given write access to the dak database doesn't seem worth the security issues for the small benefit(?) of avoiding having this discussion with the ftp team. Inspecting new packages which haven't cleared NEW has potential legal problems. We don't want to be in the position where we are distributing software that might not be legal for us to distribute. Our trend has been to increase the amount of info about the packages we make available on http://ftp-master.debian.org/new.html (currently down), but we have to stop short of potentially illegally distributing software. For people that want to help with the process of auditing packages in NEW, The ftp team is looking for new members, our most recent solicitation being here: http://lists.debian.org/debian-devel-announce/2010/03/msg3.html Hi Mike, you give three interesting examples on how the FTP team is isolating itself. 1) By a combination of (self-appointed?) authority and technical design, the package section splitting becomes a private tool of the FTP team. Apart from a couple of usual examples, sections are not much useful nowardays, and they are getting reimplemented in parallel through debtags, tasks, or meta-packages (just like our website is being reimplemented on wiki.d.o or alioth.d.o, etc.). I think that one of the causes is that it is not directly under the project's responsibility. What is your vision of the package sections? Where is the big picture? Why the maintainers should even care about them if everything in the design reminds them that sections are not their business, except for saving a bit of your time at the first upload? 2) We can not export software without doing some procedures, but what is the definition of an export? If it is not an export when a DD appointed by a DD delegated by the DPL logs in from outside the USA to inspect a package, then I think that the DPL or the Project can delegate all DDs equally the possibility to do this inspection and write in a NEW package's ITP bug what they think about its copyright and how it is summarised for Debian. Again, the line is currently drawn in a way that increases your workload. That is your choice. 3) The FTP team is looking for people, but you left my propositions to help with the NEW queue unanswered. Whatever your opinion on me as a person, you choice was to discard some help with no justification. In my opinion, the perimeter of the FTP team is not well defined, and has a tendency grow with self-appointed new responsibilities (like the lintian checks at upload for instance). I am not surprised that your team is running out of manpower frequently. Debian needs to trust more its maintainers, and shift from control to resilience over errors. This requires some infrastructural work, but I think that it is worth the effort. 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/20100401015807.gb16...@kunpuu.plessy.org
Re: Questions for all candidates: decentralization of power
On Thu, Apr 01, 2010 at 10:58:07AM +0900, Charles Plessy wrote: Hi Mike, you give three interesting examples on how the FTP team is isolating itself. 1) By a combination of (self-appointed?) authority and technical design, the package section splitting becomes a private tool of the FTP team. I'm not familiar with how the package sections came to be. I'll reluctantly take your word for it. Apart from a couple of usual examples, sections are not much useful nowardays, and they are getting reimplemented in parallel through debtags, tasks, or meta-packages Agreed. (just like our website is being reimplemented on wiki.d.o or alioth.d.o, etc.). I didn't know about this. I think that one of the causes is that it is not directly under the project's responsibility. I'm not sure what you mean by this. Having the packages in the distro grouped by secitions isn't the repsonsibility of the distro? What is your vision of the package sections? Where is the big picture? Its a way of categorizing packages to facilitate browsing through or searching for packages in debian. Its not much more than this. I think that once debtags is farther along, they could replace sections completely. Why the maintainers should even care about them if everything in the design reminds them that sections are not their business, except for saving a bit of your time at the first upload? I don't understand what you mean here at all. I'm not sure what time is being saved. If you don't want to care about them, you can probably ignore them. Some people don't, the ftp team makes sure there are sane choices being made in the cases where maintainers haven't cared enough. IfIf there is a package in an incorrect section or with the wrong priority, please just file a bug against ftp.debian.org and it will get fixed. Opening up write access to the database that maintains the archive to all developers just so that they can change sections (something that you yourself characterize as not much useful anyway) seems like something that is not worth the security risk. 2) We can not export software without doing some procedures, but what is the definition of an export? If it is not an export when a DD appointed by a DD delegated by the DPL logs in from outside the USA to inspect a package, then I think that the DPL or the Project can delegate all DDs equally the possibility to do this inspection and write in a NEW package's ITP bug what they think about its copyright and how it is summarised for Debian. Again, the line is currently drawn in a way that increases your workload. That is your choice. The issue I was talking about had nothing to do with software crossing state lines. It had to do with violating license agreements. I'm not familiar with any procedures we must do before exporting software that you are alluding to. The issue that I was talking about would be when the license of a piece of software prohibits us from legally distributing the software at all, or if distributing the software might include a legal burden we don't want to carry. For instance, if someone were to upload software such as opera or adobe flash or skype which has explicit licenses which prohibit any redistribution, we cannot allow the ftp-master machine to become a point of redistribution. For this reason, we don't allow the software to be copied off of the ftp-master machine until we've audited it with respect to software licenses. If we were to do what it seems like you want (correct me if I'm wrong about what you'd want). We'd have to either open up the ftp-master machine to all developers, which worries me from a security standpoint, or we'd have to be willing to distribute potentially non-redistributable software off the machine to developers, which would worry me from a legal standoint. 3) The FTP team is looking for people, but you left my propositions to help with the NEW queue unanswered. If there were propositions that we aren't already discussing. I missed them. I'm sorry. Whatever your opinion on me as a person, you choice was to discard some help with no justification. Sorry. I mussed have missed something. I don't think there is any reason to discuss my opinion of you as a person, lets please drop that, its irrelevant. I don't know what help you are offering that I'm discarding with no justification. The ONLY thing I've done so far was to justify. In my opinion, the perimeter of the FTP team is not well defined, and has a tendency grow with self-appointed new responsibilities (like the lintian checks at upload for instance). How do you think it should be defined then? I am not surprised that your team is running out of manpower frequently. I'm not either. But I get the feeling that we have differing opinions about why that is. It seems to me that we don't retain members becuase there is a lot of very very tedious, often thankless work that often puts you in the position
Re: Questions for all candidates: decentralization of power
Le Wed, Mar 31, 2010 at 11:24:50PM -0400, Mike O'Connor a écrit : The issue I was talking about had nothing to do with software crossing state lines. It had to do with violating license agreements. I'm not familiar with any procedures we must do before exporting software that you are alluding to. If we were to do what it seems like you want (correct me if I'm wrong about what you'd want). We'd have to either open up the ftp-master machine to all developers, which worries me from a security standpoint, or we'd have to be willing to distribute potentially non-redistributable software off the machine to developers, which would worry me from a legal standoint. What I would like is at least read access of the NEW queue in the mirror of ftp-master, and to my knowledge the last reason that was given to deny it is the USA crypto export rules: http://lists.debian.org/20090308040721.ga16...@dario.dodds.net If it is not an export or a license violation that a member of the FTP team inspects a package, then I do not think it is for any other member of the project. I am not proposing to give a read access to the NEW queue for any other purpose. In the past I have tried to seed a peer review process of the packages in NEW (http://wiki.debian.org/CopyrightReview), when the backlog was of hundreds of packages. I detected some problems, which were corrected before the FTP team processed the package. In one case, the maintainer even completely retracted the package. I hope that all of this saved some of your time. But I could only do this of packages that were available on mentors.d.n or in a VCS, because of the restriction on the read access to the NEW queue on the ftpmaster mirror. If because you do not trust the other DDs to respect the rules, that packages in the NEW queue must not be resdistributed before they are accepted, then yes, you have to do the work alone. If we do not think that the DDs respect the rules (http://www.debian.org/devel/dmup, in which we could add a note about NEW packages before opening up the mirror), how can we tell our users that our system is secure? Have a nice day, -- 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/20100401044545.ga17...@kunpuu.plessy.org
Re: Question to all candidates: DPL's role in important package maintenance
Wouter Verhelst wrote: Discussing problems in public works very well if two people like eachother. If they don't, however, you get two people cursing at eachother. Now there are some people who really don't mind doing that in public; but when things get messy, not being messy out in the open actually makes a whole lot of sense. Agreed, but would you agree that it is a core part of the role of the DPL/2IC, or indeed any mediator, to provide at least basic status and progress info to the project as a whole? What we've been seeing with this issue is that there has been complete silence for over three months. I think that a lot of the (heated) public discussion could have avoided if some progress/status info would have been provided at regular intervals. In fact, I think that a lot of the public discussion was as direct result of the total lack of such information. What are the thoughts of candidates on that? Also, it has been claimed we cannot provide any information because discussions are in private [1]. Do candidates agree to that, or do they think that a DPL should make clear to parties in advance that the project will be kept informed of status and progress (but of course not of specifics). Thanks, FJP [1] References: - http://lists.debian.org/debian-devel/2009/12/msg00078.html (+ following) - http://lists.debian.org/debian-project/2010/03/msg00032.html (last para) -- 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/201004010647.54249.elen...@planet.nl
Re: Question to all candidates: DPL's role in important package maintenance
Le Thu, Apr 01, 2010 at 06:47:53AM +0200, Frans Pop a écrit : Also, it has been claimed we cannot provide any information because discussions are in private [1]. Do candidates agree to that, or do they think that a DPL should make clear to parties in advance that the project will be kept informed of status and progress (but of course not of specifics). Hi Frans and everybody, Rants are better to go in private or not be sent at all, and it may be better to keep tractations private as well as long as they are speculative, to avoid fueling misunderstandings. But I think that a clear, emotion-neutral, and synthethic summary of what each party wants and what they disagree with the other is essential and has to be public. 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/20100401050137.gb17...@kunpuu.plessy.org
