Re: Standardization, large scale changes, innovations
On Tue, Apr 6, 2010 at 18:46, Manoj Srivastava sriva...@debian.org wrote: Personally, I'd draw the line more at considering Manoj as someone who tends to his packages, and thus is someone worth talking to about them, but who doesn't have any authority over them beyond how well he can persuade other developers that his preferred course of action is the right one. But is this the model we have been following? Fundamentally, yes. For instance: (It might be entertaining to see a random developer going out and uploading, say, gnome, all converted to using yada and dbs). There are obvious consequences to doing this: - the current Gnome maintainers reupload the old packaging with a bumped version number, making the random developer's upload pointless - the random developer gets flamed on lists - the upload gets blocked before being included in the archive (eg [0]) - the random developer gets demoted to Debian Maintainer status (eg [1]) Those all tend to be persuasive reasons why some particular person wouldn't do that, and more generally I believe most Debian people find it pretty persuasive that having someone (or some people) who'll take responsibility for making decisions around particular areas (such as Gnome) is the most effective way we've got to get things done. [0] http://lists.debian.org/debian-x/2004/01/msg00759.html [1] http://lists.debian.org/debian-devel/2003/08/msg01625.html But yes, if someone's /not/ persuaded by those reasons, and nobody's persuaded to stop that someone, then NMUs, uploads changing Maintainer fields, and forks are entirely possible. So it boils down to social norms, Social norms are, in my opinion, another way of saying this is what most people already believe, without needing any further persuasion -- the social norm that whatever the maintainer says goes fits that well, eg. Not all social norms are good though; I'm sure debian-women folks could come up with some examples easily enough, for instance. etiquette, if you will, also codified in the NMU rules, tht says people listed in the maintainer or uploader fields are indee dgiven some authority over packages they work on, but that authority falls short of ownership. This happens orthogonal to how persuasive the maintainer is about their course of action; and usually it takes concerted effort (TC, GR, flammage) to override the maintainer decisions. On the contrary, I'd say most people have already been persuaded to trust the maintainer. But when someone comes up with a good reason not to, it's very important for the maintainer to be able to persuasively argue their case -- whether that be on -devel, -ctte, -vote, blogs, or elsewhere. Saying it's my package, my rules doesn't cut it. That doesn't mean being a professional debater, or even being particularly good at English -- technical analysis, humility, and just a willingness to discuss things can be important elements of being persuasive. Of course, it does depend on your audience. A rhetorical flourish, some good insults, sheer repetition, or making it appear that no one disagrees with you because they're not allowed to participate on the list/channel/forum or because they've just given up arguing can be more persuasive than some statistics from some newbie, eg. (Another example of not being convinced to trust the maintainer is in Ubuntu in the sense that they often avoid giving packages maintainers so there's no person to trust or not. Maybe that's a better way of doing things, or maybe it's not, and maybe it's better sometimes and worse at others. I think it's a shame if Debian's not open to being persuaded to change that policy if it results in better software; and I think it'd likewise be a shame if Ubuntu weren't) Of course, in my world, the same would be true of other people trying to convince Manoj that the best way to maintain his packages is with debhelper or similar. Sometimes I think the art of persuasion (or perhaps the art of be persuadable) is sadly underutilised. Based on one reading of what you wrote here, the take away I have is that no one has any authority apart from their ability to persuade people (persuade how many of the? All? Super majority? rough consensus?) People have legal authority over the things they own -- no persuasion required. That's what ownership means. But the fact is, most of the stuff people do within Debian isn't on stuff they own -- authority is delegated, servers are loaned, bandwidth is too, mirrors are other people's systems entirely, all the contributions to Debian whether infrastructure development and maintenance, package maintenance or upstream development is done by people volunteering their time and effort to Debian, funds for meetings are donated by people feeling charitable, and all of them can choose to stop at any moment, the instant they're persuaded that there's something better to do instead. For instance, nobody can stop you continuing
Re: Standardization, large scale changes, innovations
Hi, On Fri, Apr 2, 2010 at 18:54, Wouter Verhelst wou...@debian.org wrote: On Thu, Apr 01, 2010 at 09:57:35AM +0200, Frank Lin PIAT wrote: BTW, does Manoj own those package? Yes. Another word for something that's owned by someone is proprietary, so another way of saying the above in English is Manoj's packages are proprietary. I realise that's just playing with terminology, and isn't the same as saying Manoj's packages are not DFSG-free -- but saying Manoj owns the corner of the archive that allows uploads of packages named make, fvwm, angband, etc has problems, even if nowhere near as many as would saying Manoj owns the right to modify or redistribute this sequence of bytes wherever they may occur. Personally, I'd draw the line more at considering Manoj as someone who tends to his packages, and thus is someone worth talking to about them, but who doesn't have any authority over them beyond how well he can persuade other developers that his preferred course of action is the right one. Of course, in my world, the same would be true of other people trying to convince Manoj that the best way to maintain his packages is with debhelper or similar. Sometimes I think the art of persuasion (or perhaps the art of be persuadable) is sadly underutilised. (I think it'd be entertaining to have some debates where sides get randomly assigned, so you're obliged to defend ideas you personally think are wrong, and attack ones you personally think are right. Whether it would do any good, or if anyone would be willing to volunteer, on the other hand...) Cheers, aj -- Anthony Towns a...@erisian.com.au -- 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/k2w87b3a4191004060059ne7af3713t71fc8ea24fa1a...@mail.gmail.com
Re: Standardization, large scale changes, innovations
On Tue, Apr 06 2010, Anthony Towns wrote: Hi, On Fri, Apr 2, 2010 at 18:54, Wouter Verhelst wou...@debian.org wrote: On Thu, Apr 01, 2010 at 09:57:35AM +0200, Frank Lin PIAT wrote: BTW, does Manoj own those package? Yes. Another word for something that's owned by someone is proprietary, so another way of saying the above in English is Manoj's packages are proprietary. I realise that's just playing with terminology, and isn't the same as saying Manoj's packages are not DFSG-free -- but saying Manoj owns the corner of the archive that allows uploads of packages named make, fvwm, angband, etc has problems, even if nowhere near as many as would saying Manoj owns the right to modify or redistribute this sequence of bytes wherever they may occur. Personally, I'd draw the line more at considering Manoj as someone who tends to his packages, and thus is someone worth talking to about them, but who doesn't have any authority over them beyond how well he can persuade other developers that his preferred course of action is the right one. But is this the model we have been following? (It might be entertaining to see a random developer going out and uploading, say, gnome, all converted to using yada and dbs). In the past, we have managed to draw a fine line between these positions: We do have a concept of package maintainers, and give maintainers wide latitude over their packages, but we also allow NMU's, which implies the maintainer is not the absolute owner. So it boils down to social norms, etiquette, if you will, also codified in the NMU rules, tht says people listed in the maintainer or uploader fields are indee dgiven some authority over packages they work on, but that authority falls short of ownership. This happens orthogonal to how persuasive the maintainer is about their course of action; and usually it takes concerted effort (TC, GR, flammage) to override the maintainer decisions. Of course, in my world, the same would be true of other people trying to convince Manoj that the best way to maintain his packages is with debhelper or similar. Sometimes I think the art of persuasion (or perhaps the art of be persuadable) is sadly underutilised. Based on one reading of what you wrote here, the take away I have is that no one has any authority apart from their ability to persuade people (persuade how many of the? All? Super majority? rough consensus?) how a package should be maintained. I don't think that is how we have behaved, though, as a project. manoj -- I'm prepared for all emergencies but totally unprepared for everyday life. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 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/87sk79hstm@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Thu, Apr 01, 2010 at 09:57:35AM +0200, Frank Lin PIAT wrote: There isn't just Manoj that work on Manoj's packages (QA team, Security team, Derivative distro... and our users!) They can use standard interfaces to modify the package, should they want to. Manoj does the same. BTW, does Manoj own those package? Yes. As I wrote those lines, I wonder if some developer don't precisely use home made stuff to say keep out, this is my own package. If that were the case, that would be bad. But I don't think that Manoj is doing this; he's doing it because it works better for him. And that's fully his right. As long as the result is good -- a working, policy-compliant package -- how he gets that result is not your business. Isn't Debian an organisation (with 1000+ developers)? Yes, and? (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. What about Debian users who need to modify a package for special needs? What about peer review of the packages? What about other teams in Debian? (nmu, porters...) What about derivatives? What about upstream review of his packages? (there isn't just patches). That can all be done. There's nothing in Manoj's packages that makes it impossible to do so. -- 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: Standardization, large scale changes, innovations
On Wed, 2010-03-31 at 18:13 -0700, Russ Allbery wrote:
Wouter Verhelst wou...@debian.org writes:
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.
I like this example... If I were using a screw driver when I should use
a chisel, I would be rounding off the shaft of the screw driver, which
makes it unsuitable to screw at some point (and I am likely to hurt
myself too)
If I use a chisel to screw, I am spoiling the screw (and I am likely to
hurt myself too)
In both case:
1. I am shooting a bullet in my own feet, as I am making my futur
significantly tougher, just to a little bit lazy now.
(Also, this is really not nice if I am working with someone).
2. Not using the appropriate tool is amateurism. If you ever hire a
professional, which happens to do such thing, then just fire him off
before he makes a mess. (I am not suggesting to fire off any DD that
don't use dh ;-)
The same is true with Manoj. You may think debhelper is the best thing
[[[droping personal statements]]], 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.
I think you just overlooked my previous email, especially the part about
industrializing.
http://en.wikipedia.org/wiki/Not_Invented_Here -- replace here by ${me}
There isn't just Manoj that work on Manoj's packages (QA team, Security
team, Derivative distro... and our users!). BTW, does Manoj own those
package?. As I wrote those lines, I wonder if some developer don't
precisely use home made stuff to say keep out, this is my own package.
A best practice isn't a standard (or a policy), still most people follow
it.
As long as the result is good -- a working, policy-compliant package
-- how he gets that result is not your business.
Isn't Debian an organisation (with 1000+ developers)?
If you think otherwise, you should first get Policy changed, and then
complain to Manoj.
That's an easy move... (anyone who disagrees has to turn his proposal
into a policy!)
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.
I agree, the policy should not mandate a tool (because it would be
impossible to experiment *new* and *better* alternatives).
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.
debhelper has a standard interface quite documented in the manpages
(especially when using flat files as input). Anyone could provide an
alternative tool.
And this is a great feature. (anyone trying to do QA on the source will
agree).
The major exception to this right now is that Policy assumes dpkg and the
core dpkg tools
By standardizing more tools, we would be more efficient.
Those tools should be described by their interface, as you mentioned.
(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.
What about Debian users who need to modify a package for special needs?
What about peer review of the packages?
What about other teams in Debian? (nmu, porters...)
What about derivatives?
What about upstream review of his packages? (there isn't just patches).
Debian project raise it's expectation every year (cool). How do we face
the challenge to do more every year? (of course, you could do like the
[French]
Re: Standardization, large scale changes, innovations
Hi,
I think this discussion is beginning to veer off topic, since it
is far from figuring out who to vote for, etc. This is my last post on
ths topic here, if you want to covince me of the error of my ways,
please take it to private email. If you want to change how we do things
to prevent me from doing what I have been doing, please take your pick
-f -devel, -policy, or -ctte.
I also apologize in advance for this email.
On Thu, Apr 01 2010, Frank Lin PIAT wrote:
http://en.wikipedia.org/wiki/Not_Invented_Here -- replace here by ${me}
There isn't just Manoj that work on Manoj's packages (QA team, Security
team, Derivative distro... and our users!). BTW, does Manoj own those
package?. As I wrote those lines, I wonder if some developer don't
precisely use home made stuff to say keep out, this is my own package.
I posit that if you can't figure out my build system, you can't
be very effective about making changes to the package (which is usually
far more complex than my little make files).
A best practice isn't a standard (or a policy), still most people follow
it.
In your opinion, does best equate with popular?
The major exception to this right now is that Policy assumes dpkg and the
core dpkg tools
By standardizing more tools, we would be more efficient.
By that definition, should we not all be working on Windows?
Much more standard than Linux, neh?
What about Debian users who need to modify a package for special needs?
I think if they can modify the software for their needs, they
can modify the build system too. I think my stuff is easier to modify
and propagate than trying to modify debhelper and being able to
distribute the result and having it build on your friends computer
(they need the modified debhelper as well as your modified package, and
that might mess up other package builds for them)
What about peer review of the packages?
My *peers* have no problems dealing with the build system, IMO.
What about other teams in Debian? (nmu, porters...)
I have been packaging for Debian for 15 years now. I don't
recall a concrete instance where this has been an issue.
What about derivatives?
I have heard complaints here, yes, about SELinux packages. I
think the issue was resolved.
What about upstream review of his packages? (there isn't just
patches).
Most upstreams, if they don't use Debian, do not know about
debhelper. At least my packages try to be self contained, and most
upstreams know Make. I think I win this one.
manoj
--
baz bat bamus batis bant. James Troup
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
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/87hbnvweqd@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Thu, Apr 01, 2010 at 05:15:38AM -0700, Manoj Srivastava wrote: What about peer review of the packages? My *peers* have no problems dealing with the build system, IMO. As long as you tautologically define your *peers* as the set of people willing to tolerate the gratuitous overhead of learning an idiosyncratic build system when they could be getting on with the real work of fixing bugs instead, yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
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: 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: 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: 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: Standardization, large scale changes, innovations
On Thu, 25 Mar 2010, Manoj Srivastava wrote: This is great!! perhaps we can get rid of the abomination that is vi and get everyone to use the one true editor all at once. I suggest you change your tone. You have the right to not share my point of view, but there's no need to be sarcastic. What did you say? What difference does it make what tool is used when the result is equal? It doesn't make a difference for a the end-user, but it makes a difference to contributors who have to learn a set of tools in order to be able to contribute on a set of packages. If the set of tools to learn is smaller, it's easier for the contributor to contribute to more packages and he has to spend less time learning, time that can be better spent on improving the package and on fixing bugs. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100330091601.gh28...@rivendell
Re: Standardization, large scale changes, innovations
On Tue, Mar 30, 2010 at 11:16:01AM +0200, Raphael Hertzog wrote: On Thu, 25 Mar 2010, Manoj Srivastava wrote: What did you say? What difference does it make what tool is used when the result is equal? It doesn't make a difference for a the end-user, but it makes a difference to contributors who have to learn a set of tools in order to be able to contribute on a set of packages. If the set of tools to learn is smaller, it's easier for the contributor to contribute to more packages and he has to spend less time learning, time that can be better spent on improving the package and on fixing bugs. Is making things easy for newcomers or casual helpers really so important that we should risk scaring already active people away because they have to adapt their optimized workflow for newcomers? I can understand Manoj perfectly and would myself probably reduce my time spent on Debian even more if I were forced to do things more complicated (or even just different) because of some new policy. This is a first-class motivation killer for the people who are already there. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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/20100330130233.ga19...@torres.zugschlus.de
Re: Standardization, large scale changes, innovations
On Tue, Mar 30 2010, Marc Haber wrote: On Tue, Mar 30, 2010 at 11:16:01AM +0200, Raphael Hertzog wrote: On Thu, 25 Mar 2010, Manoj Srivastava wrote: What did you say? What difference does it make what tool is used when the result is equal? It doesn't make a difference for a the end-user, but it makes a difference to contributors who have to learn a set of tools in order to be able to contribute on a set of packages. If the set of tools to learn is smaller, it's easier for the contributor to contribute to more packages and he has to spend less time learning, time that can be better spent on improving the package and on fixing bugs. I am not sure that follows. How has my not using debhelper made it harder for newcomers? How many newcomers learn my build system? Or my git work-flow where I use submodules? There is a logical flaw in the assumption that not limiting the choices people have for packaging makes it a harder row to hoe for newbies. Is making things easy for newcomers or casual helpers really so important that we should risk scaring already active people away because they have to adapt their optimized workflow for newcomers? I can understand Manoj perfectly and would myself probably reduce my time spent on Debian even more if I were forced to do things more complicated (or even just different) because of some new policy. This is a first-class motivation killer for the people who are already there. I have a new job. It is sucking up more time from me, as I learn the ins and outs of how work gets done here. I also have a work-flow that is mostly automated, allowing me to concentrate on fixing bugs and integration issues. Any new complications added into the mix would be a major monkey wrench thrown into the cogs. I am not sure I would be able to give the packages the attention they deserve; I am already at the border line of what I consider adequate maintainership. So yes, busy work for a flawed and needless conformity would impact my contributions to Debian. I am not sure that the benefits of such conformity have been adequately demonstrated. manoj -- Humans are communications junkies. We just can't get enough. Alan Kay Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 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/87y6h928qh@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit : I am not sure that follows. How has my not using debhelper made it harder for newcomers? Your packages are absolutely impossible to maintain by anyone but yourself. And that in itself should be considered a bug. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Standardization, large scale changes, innovations
Josselin Mouette j...@debian.org writes: Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit : I am not sure that follows. How has my not using debhelper made it harder for newcomers? Your packages are absolutely impossible to maintain by anyone but yourself. I am an existence proof that the absoluteness of this statement is incorrect. -- 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/87y6h9k36j@windlord.stanford.edu
Re: Standardization, large scale changes, innovations
On Tue, Mar 30 2010, Russ Allbery wrote: Josselin Mouette j...@debian.org writes: Le mardi 30 mars 2010 à 07:18 -0700, Manoj Srivastava a écrit : I am not sure that follows. How has my not using debhelper made it harder for newcomers? Your packages are absolutely impossible to maintain by anyone but yourself. I am an existence proof that the absoluteness of this statement is incorrect. 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. At this point I am uncertain that I am not happy at the prospect, as long as I am the maintainer and have signed up to clean up the mess. manoj -- Feeling amorous, she looked under the sheets and cried, Oh, no, it's Microsoft! 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/874ojx1lec@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Thu, Mar 25 2010, Raphael Hertzog wrote: Hello, those questions are for all candidates. By standardization I mean that something should be used as default tool unless reasons exist to use something else This is great!! perhaps we can get rid of the abomination that is vi and get everyone to use the one true editor all at once. What did you say? What difference does it make what tool is used when the result is equal? What a silly idea. The concept that rules and policies dictate interfaces and standards rather than implementation seem so antiquated. In the name of standardization we can stifle all variation and innovation. Ah, needless conformity, the hobgoblin of ... manoj -- The Official Colorado State Vegetable is now the state legislator. 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/871vf7vf73@anzu.internal.golden-gryphon.com
Re: Standardization, large scale changes, innovations
On Thu, 25 Mar 2010, Joey Hess wrote: The exciting potential of dpkg source v3 to me is that it potentially opens an area that had stifled most innopvation, by allowing subtypes of the source format to be developed. But this area is still relatively closed to innovation; dpkg's maintainers still need to sign off on new formats, and the v3 source handling in dak is AIUI unneccessarily limited/hardcoded to only supporting certian subtypes. I am not opposed on merging code improvements concerning alternative source formats and I'm not opposed to adding support for new source formats either. While dak needs some modification for each alternative source format to allow, the code has been modified in ways that make it easy to add support of supplementary source formats. That said my personal opinion is however that we should be very cautious before deciding to allow those alternatives formats on ftp-master. I strongly believe that we should not have many source formats in Debian and that the right long term approach for VCS based maintainance is not to have the VCS in the source package but rather to generate the source package out of the VCS. And I would rather encourage people to work in that direction; I would like dpkg-dev to provide tools to do precisely this but it's still far from being at the top of my TODO list currently. Any help welcome as usual. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100326200913.ga10...@rivendell
Re: Standardization, large scale changes, innovations
Le Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog a écrit : those questions are for all candidates. By standardization I mean that something should be used as default tool unless reasons exist to use something else (I do not mean that we sould impose something to everybody for all cases, but it should still be what's used in 95% of the cases). Bonjour Raphaël, first of all, I would like to apologise in public for the the unkind comment I made about your work on debian-devel. I should have sticked to the facts instead of making a bad taste analogy. This said, I think that you guess the answer I will make to your question… I think that we should not standardise on tools, but on interfaces. To take the patch management systems as an example, there is a convergence on storing patches in debian/patch, and applying them through the ‘patch’ and ‘unpatch’ targets of debian/rules. I think that it is a good situation, and I recommend against making a particular implementation the standard. The debian/rules patching and unpatching targets were not unified at the beginning, so I think that it is a nice example of that such a convergence can be achieved in Debian. I would prefer that interfaces become codified when they attract independant implementations by their popularity. Let's take the git-core package for example. It uses files like debian/git-core.docs that have a similar function and mechanism that their similar counterparts in packages using Debhelper, but they are implemented via makefiles. If listing the files to be installed in /usr/share/doc/package/ in a debian/package.docs file is for instance getting standard by its popularity, then there will be an advantage to little by little make it more formal. I think that this example can be generalised. I maintain a lot of packages that are quite trivial, so I make a heavy use of helper tools. I find that one of CDBS and Debhelper (with or without dh) is often more useful than the other in a case-by-case basis, and would be quite annoyed if one of them were removed from my toolbox. I strongly share your feeling about innovation. Trust me, when I started to oppose the way you tie your patch system to the rest of the 3.0 source package implementation, I really balanced this with the fact that going for 3.0 (quilt) is anyway better than immobilism. I decided to confront your choices because what I am asking is not to withdraw your patch system, but to make it optional. This does not close the door, it just asks the people to make the step by themselves. You also described well the difficulty of introducing changes in our core package management system. I think that we can modify our release strategy in a way that would allow point updates to that part of our stable systems. A reorganisation of package priorities and sections would help to put a frame around this, and would allow other changes that I propose in my platform. To document and standardise interfaces is a good way to ease experimentation, and therefore innovation. Also, it would help to introduce changes in a way that is backward-compatible, and give more independance between developments on interacting tools, like dpkg and dak for instance. But there will always be situations in which people need to talk together and negociate reciprocal concessions. If I am elected DPL, I will ask the delegates to make sure that requests for coordination are not ignored, and that decisions are motivated. Not answering is the worse way to say no. Conversely, it may make sense to formalise the role of the maintainers of core tools like apt and dpkg by a DPL delegation. But this particular point is not listed in my platform, and I would not make it a priority. Of course, if maintainers sponaneously request to become delegates, I will consider their proposition very seriously :) 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/20100325134143.ga16...@kunpuu.plessy.org
Re: Standardization, large scale changes, innovations
Raphael Hertzog, 2010-03-25 11:22:36 +0100 : [...] 1/ Do you believe that it's a good move to standardize our packaging tools? (example: debhelper is almost standard, quilt is gaining status of the standard patch system thanks to the new source format) Please define “standardize” here. For the benefit of the candidates, let me say that if the meaning is “be allowed to shout at dissidents”, then in this case I don't believe it is a good move. [...] 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: [...] - you always have people that do not like the new thing and will try to make you feel miserable Fair's fair, you are also making them feel miserable. - you have lots of people not caring (for various reasons, not reading d-d-a or forgetting quickly, not willing to change something that works unless they are prodded, etc.) Unless there is a real benefit. Standardization for its own sake is *not* a real benefit. Please accept that there are cases where the v3 format brings absolutely nothing. Not to the packaging, not to the maintainer, and not to potential helpers because there are none. Case in point: the sourceforge/gforge/fusionforge package is coming close to nine years of existence, with zero NMU in the meantime, zero people working on the package on the Ubuntu side, and zero people complaining that adding a patch to their private copy is too hard. Where would be the advantage of switching to v3? Roland. -- Roland Mas Neko-no me-to, onna-gokoro-to, aki-no-sora. -- Proverbe japonais (« Souvent femme varie, bien fol est qui s'y fie. ») -- 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/87r5n8ears@mirexpress.internal.placard.fr.eu.org
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 11:22:36AM +0100, Raphael Hertzog wrote: Hello, those questions are for all candidates. By standardization I mean that something should be used as default tool unless reasons exist to use something else (I do not mean that we sould impose something to everybody for all cases, but it should still be what's used in 95% of the cases). 1/ Do you believe that it's a good move to standardize our packaging tools? (example: debhelper is almost standard, quilt is gaining status of the standard patch system thanks to the new source format) It has advantages and disadvantages. The major advantage of standardized tools is that anyone can look at a source package and immediately start working on it. The major disadvantage of standardized tools is that if someone's workflow, or their packages' upstream's way of distributing things, does not agree with a particular standardized toolset, they would have a harder time working on their packages; or they could disregard the standards and (eventually) be frowned upon. Since I got fed up with undocumented non-standardized tools a few years ago, I filed a bug against policy which eventually, after a lot of discussion, resulted in the README.source bit in policy. I think that 'documenting' can be a great help in alleviating the disadvantages of the absense of standardized tools, without imposing any workflow on anyone. So no, I don't think we should standardize too much. There are cases where it makes sense (e.g., I don't think anyone would suggest allowing uploads of RPM packages to the archive), but we shouldn't overdo it; people should have the freedom to work in whatever way works best for them. 2/ If yes, what would be the next thing that it would be good to try to standardize/uniformize? I don't, so nothing :-) 3/ Do you have any preference on the tools that we should try to standardize on (which source format/patch system, dh7/CDBS/yada/etc., VCS helper, etc.)? No. 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: Indeed. This is another reason why we should't overdo it; unless there is a substantial benefit that cannot be gotten at in other ways, I think the downsides of trying to move the whole of the archive to something new can far outweigh the benefits. [...] How can we change our processes so that doing/organizing such changes is less of a burden? They are not. Consider how debhelper became a standard within Debian. Nobody ever started filing bugs, asking people to use debhelper; rather, someone (Joey Hess) wrote something, and uploaded that something to the archive. People liked it, and started using it. Some filed bugs, or patches, and debhelper improved as a result. So more people started using it, and more bugs/patches got filed. Etcetera. Note that when debhelper was first written, it was by far not the only thing available to build packages; e.g., there was debmake, yada, and a bunch of other things. These aren't used anymore, because debhelper eclipsed them all -- not because anyone told anyone not to use them. I think the debhelper way is the best way to achieve standards within Debian: rather than trying to convince people through arguments, we convince people through technology. I also think that dpkg's current nagging about the 3.0 dpkg formats are a mistake, for precisely that reason. People who don't like the 3.0 formats will ignore the nagging, and get annoyed; people who do not dislike it don't need nagging to eventually migrate, anyway. 5/ I have the feeling that Debian is innovating less than it used to do. We are more often followers rather than leaders. Do you share that feeling? Yes, to some extent. But I'm not convinced that trying to standardize on anything will change that -- on the contrary. What shall we do to make that change? To encourage innovation, people must have the freedom to experiment. Innovation is impossible if too many standards are imposed on people. -- 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: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 7:22 AM, Raphael Hertzog hert...@debian.org wrote: 1/ Do you believe that it's a good move to standardize our packaging tools? (example: debhelper is almost standard, quilt is gaining status of the standard patch system thanks to the new source format) I do not think that we should force a standard. I think the best way to come to a standard is when the big majority chooses to go with it. What we may do is have clear documentation that state that there is a preferred way of doing things, and so new people will do them that way. However, imposing standards on people that are already working in some other way would only bring flamewars and frustration. The most important way of establishing standards is through common use, and then through policy. Many standards have been first introduced as a suggestion and then turned into an obligation in our policy, and that's how they become real standards. 2/ If yes, what would be the next thing that it would be good to try to standardize/uniformize? I think (hope) that in the future there's going to be some convergence regarding VCSs. However, it won't happen through someone deciding that one of them is the right one. It will happen when most of us decide to choose one in particular, and it will probably take some more years. 3/ Do you have any preference on the tools that we should try to standardize on (which source format/patch system, dh7/CDBS/yada/etc., VCS helper, etc.)? No. I don't think that we should _try_ to standardize. 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: [...] How can we change our processes so that doing/organizing such changes is less of a burden? The only way is to make it easy and rewarding for people to adopt new tools. I don't think there's any kind of bureaucracy that would make people more willing to change their way of working. Only technical advantages and easy migrations paths work. 5/ I have the feeling that Debian is innovating less than it used to do. We are more often followers rather than leaders. Do you share that feeling? What shall we do to make that change? I definitely share the feeling. I also definitely don't think that imposing standards is the way to become innovative. Now, I do find very interesting this question very interesting. One thing is to be more open to new ideas. Another thing is to encourage people to try new things. It's mostly a cultural thing, we used to have a culture of innovation and now we don't. We need to bring it back, but I don't see an easy way for this. I'll ponder some more about this. In any case, I think this question deserves its own thread. -- 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/e8bbf0361003250843g791611eem6f321c3dc81a1...@mail.gmail.com
Re: Standardization, large scale changes, innovations
On Thu, 25 Mar 2010, Wouter Verhelst wrote: How can we change our processes so that doing/organizing such changes is less of a burden? They are not. I can't accept the premise that we can't do better at this level. I managed to get my own project through the end (it's deployed, people can use the new source formats) but other worthwhile projects have not (or not yet) and I believe we should enhance our processes so that we can more effectively work _together_ on common goals (think of ddebs for example). Such projects are very difficult to do as one-man show in particular when you have no idea whether your work is going to used/deployed or not. I think the debhelper way is the best way to achieve standards within Debian: rather than trying to convince people through arguments, we convince people through technology. I try to convince through technology, I advertise the result through arguments. And I keep improving the formats based on the feedback that I explicitly request. 5/ I have the feeling that Debian is innovating less than it used to do. We are more often followers rather than leaders. Do you share that feeling? Yes, to some extent. But I'm not convinced that trying to standardize on anything will change that -- on the contrary. What shall we do to make that change? To encourage innovation, people must have the freedom to experiment. Innovation is impossible if too many standards are imposed on people. Please don't relate that question to the standardization question, it was not meant to. You answer is rather limited, I hope you can elaborate. We all have the freedom to experiment, we have all the sources, so why aren't we any longer innovating? And innovations only counts if it reaches a released product, otherwise it's only research. How can we go from successful experimentation to real innovations in our releases? Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100325170719.ga5...@rivendell
Re: Standardization, large scale changes, innovations
On Thu, 25 Mar 2010, Margarita Manterola wrote: 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: [...] How can we change our processes so that doing/organizing such changes is less of a burden? The only way is to make it easy and rewarding for people to adopt new tools. I don't think there's any kind of bureaucracy that would make people more willing to change their way of working. Only technical advantages and easy migrations paths work. You got me wrong. I don't want to change our processes to force people to adopt new tools. I want to change our processes so that it's easier to complete far-reaching projects: in my case, it includes everything from working on dpkg-source to ensuring that the new formats can be used in sid. In other cases, it can be modify our infrastructure to collect debug information and make it available as .ddebs, or maybe modify our infrastructure so that we can provide updated translations in point releases, etc. 5/ I have the feeling that Debian is innovating less than it used to do. We are more often followers rather than leaders. Do you share that feeling? What shall we do to make that change? I definitely share the feeling. I also definitely don't think that imposing standards is the way to become innovative. As I said to Wouter, the standardization question and this one are unrelated. Now, I do find very interesting this question very interesting. One thing is to be more open to new ideas. Another thing is to encourage people to try new things. It's mostly a cultural thing, we used to have a culture of innovation and now we don't. We need to bring it back, but I don't see an easy way for this. I'll ponder some more about this. Do you believe that our NM process could be responsible of this by unvoluntarily favoring packagers over developers? In any case, I think this question deserves its own thread. Agreed but too late. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100325171741.gb5...@rivendell
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 2:17 PM, Raphael Hertzog hert...@debian.org wrote: You got me wrong. I don't want to change our processes to force people to adopt new tools. I want to change our processes so that it's easier to complete far-reaching projects: in my case, it includes everything from working on dpkg-source to ensuring that the new formats can be used in sid. In other cases, it can be modify our infrastructure to collect debug information and make it available as .ddebs, or maybe modify our infrastructure so that we can provide updated translations in point releases, etc. Well, I really don't see a way. Take for example when the Homepage field was added as another field in the control file instead of being in the description. This is a very easy switch, and I guess most packages that have had an upload since then have updated that. This became a standard almost as soon as it was done, because it was easy to adopt and technically better. The change in dpkg is like the other extreme. It's something that implies a lot of things to take into account, a lot of changes, and the documentation is not clear enough (I've looked at the wiki and at the links in the wiki, but there's no simple centralized howto for people to follow). The processes are already established: when something useful is adopted by enough people, it enters policy, first as a should, then as a must. Meanwhile, lintian first informs and then warns about such situation. The problem with the dpkg example is that a lot of people are still not willing to do the migration, and I don't think this can be changed through processes. Now, I do find very interesting this question very interesting. One thing is to be more open to new ideas. Another thing is to encourage people to try new things. It's mostly a cultural thing, we used to have a culture of innovation and now we don't. We need to bring it back, but I don't see an easy way for this. I'll ponder some more about this. Do you believe that our NM process could be responsible of this by unvoluntarily favoring packagers over developers? Uhm, that's a very hard question. I do believe that the NM process favors patient people over brilliant people. But I'm not sure what you are referring to with developers. In any case, I wouldn't say that the NM process is the reason why we don't have a culture of innovation. I think there may have been too many flamewars about people introducing changes, so much that it could be that some developers don't like to introduce too innovative changes because they fear they'd be flamed for them. It could also be that other fronts have been better at attracting people with novel ideas than we have been. I find it very hard to find the reason for the situation and to propose changes. However, I think that in order to make Debian great we should fix this. -- 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/e8bbf0361003251039j32b973a8q6813484f00d79...@mail.gmail.com
Re: Standardization, large scale changes, innovations
On Thu, Mar 25, 2010 at 06:07:19PM +0100, Raphael Hertzog wrote: On Thu, 25 Mar 2010, Wouter Verhelst wrote: How can we change our processes so that doing/organizing such changes is less of a burden? They are not. I can't accept the premise that we can't do better at this level. I managed to get my own project through the end (it's deployed, people can use the new source formats) but other worthwhile projects have not (or not yet) and I believe we should enhance our processes so that we can more effectively work _together_ on common goals (think of ddebs for example). To be honest, I'm not sure I understand what the problem you're discussing here, is. Within Debian, and within the larger free/open source community, the most popular way to convince people that some code is a good idea, has always been to let the code speak for itself. If you want people to send patches your way, then write the nice and innovative ideas first; the grunt work will follow. If you want people to accept that something is a good idea, the best way to do that is to make sure it actually *is* a good idea. If enough people agree with you on that, the rest will go automatically. A very good example of that is debhelper; nobody ever told anyone to use it, yet most of our packages do, directly or otherwise. Common goals will be worked on by many people if they are, indeed, common goals. If someone does not believe ddebs are a worthy goal, it will be very hard to make him work on that. I believe that's a good thing, because it means that only those things which actually are found to be good ideas by most people will actually be worked on. Such projects are very difficult to do as one-man show in particular when you have no idea whether your work is going to used/deployed or not. That's normal in Free Software, and it's something we all have to live with. I've started working on ipcfg with the hope that someone would eventually use it, but I've so far not convinced many people yet. I can only assume this is because it's Not There Yet, and will have to continue working on it. Sure, that can be demotivating, but that doesn't mean I'm doing a bad job. I think the debhelper way is the best way to achieve standards within Debian: rather than trying to convince people through arguments, we convince people through technology. I try to convince through technology, I advertise the result through arguments. And I keep improving the formats based on the feedback that I explicitly request. I don't think there's any better procedure than that in convincing people to use your technology. 5/ I have the feeling that Debian is innovating less than it used to do. We are more often followers rather than leaders. Do you share that feeling? Yes, to some extent. But I'm not convinced that trying to standardize on anything will change that -- on the contrary. What shall we do to make that change? To encourage innovation, people must have the freedom to experiment. Innovation is impossible if too many standards are imposed on people. Please don't relate that question to the standardization question, it was not meant to. Okay; that wasn't clear. You answer is rather limited, I hope you can elaborate. Not sure I can. We all have the freedom to experiment, we have all the sources, so why aren't we any longer innovating? I'm afraid I don't have an answer to that one. Perhaps it's because there isn't much new that can be done anymore which lies strictly within the realm of what a distribution does? Or perhaps it's because we just don't attract the kind of people who would do innovative new ideas? I'm not sure either way. What I am sure of, however, is that the lack of current innovations don't necessarily mean that nothing is happening. After all, whether something is a good idea only becomes clear once several people have actually tried to use it, and were convinced. So that means that it takes a while before a new innovation is well-known within the community. And innovations only counts if it reaches a released product, otherwise it's only research. How can we go from successful experimentation to real innovations in our releases? Upload And Blog About It(TM). If it's a good idea, people will use it. If it's not a good idea, it will rot. Such is life. -- 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: Standardization, large scale changes, innovations
* Raphael Hertzog (hert...@debian.org) [100325 18:18]: On Thu, 25 Mar 2010, Margarita Manterola wrote: 4/ Organizing changes that have an impact on (a large part of|all) the archive is very difficult: [...] How can we change our processes so that doing/organizing such changes is less of a burden? The only way is to make it easy and rewarding for people to adopt new tools. I don't think there's any kind of bureaucracy that would make people more willing to change their way of working. Only technical advantages and easy migrations paths work. You got me wrong. I don't want to change our processes to force people to adopt new tools. Reading how you annoy people who don't use your new toy, this sounds different. Andi -- 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/20100325180225.gw19...@mails.so.argh.org
Re: Standardization, large scale changes, innovations
Wouter Verhelst wrote: A very good example of that is debhelper; nobody ever told anyone to use it, yet most of our packages do, directly or otherwise. Parts of Debian encourage experimentation, innovation, and evolution of better solutions: parts don't. That debian/rules is a flexible, standard interface, and the lack of any obstacles to providing code that hooks into it has allowed many approaches to be tried. Compare adding a new suite like testing. The barriers to innovation there are high, including needing set up a copy of the archive (or being one of the few trusted to work on the real one), but also one has to overcome collective innertia and convince everyone they should care about the new suite. I don't know if Debian has become more resistent to innovation. Could be that the easy areas are increasingly tapped out. The exciting potential of dpkg source v3 to me is that it potentially opens an area that had stifled most innopvation, by allowing subtypes of the source format to be developed. But this area is still relatively closed to innovation; dpkg's maintainers still need to sign off on new formats, and the v3 source handling in dak is AIUI unneccessarily limited/hardcoded to only supporting certian subtypes. -- see shy jo -- 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/20100325195143.ga4...@kitenet.net
