Re: Multiarch support in dpkg — really in time for wheezy?
On Sat, Mar 03, 2012 at 03:58:42AM +0100, Guillem Jover wrote:
> [ Replying to this now, because it appears some people seem to think
> mails that go unanswered are considered as accepted facts... ]
So be it.
> > work is also considered ready enough by other dpkg co-maintainers, by
> > the Release Team, and by various porters, which have all asked multiple
> > times to have that work in the Debian archive.
>
> Claims by people who during all this time, when this has supposedly been
> considered such a priority and so important to the point of bringing
> it to a confrontational body like the tech-ctte, have been either
> unable or unwilling to review that code and find the problems it had.
> I still have to see a single code review on the list...
The accusation part of this is not for me to be picked up.
But that's not the point. The point is whether you did get to decide
that thorough code review had to be completed before uploading, even
only to experimental. Code review is *a* way to achieve code quality, it
is not the *only* way. User testing is another one.
> You keep mentioning this ralatively new “Debian is a do-ocracy” (which
> I think it's been promoted mostly by you?) when it seems to me the
> commonly held motto has always been “Debian is a meritocracy”. In any
> case, more often than not whenever I've seen that being used, it seems
> like an excuse to justify unsound technical decisions, or poor work.
I've used the term a lot, yes. But I don't think I've invented it in the
first place. Anyhow the difference among the two is crucial here. The
way I see it --- and you're free to disregard of course, we're entirely
in the realm of opinions here --- is that in a meritocracy you get to
"command" on the basis of past, acquired rights. In a do-ocracy you
need to keep on maintaining those rights by showing you're doing
something. Blocking others is not enough to maintain the right to
"command".
> > [...] (And TBH the thought of you hurrying up now in doing such a
> > work is worrisome in its own right.)
>
> So, you mean that doing code review and cleanup is worse than not doing
> any at all... ok.
Uh? Non sequitur. My quoted text above meant that the idea one is doing
code review in a hurry is not as reassuring as the idea of one doing
code review more calmly.
> If rushing things out and being sloppy or merging technically unsound
> code is being a team player, then count me out.
I think Debian has now decided, using the most appropriate means, that
uploading to experimental at this stage wasn't really "rushing things
out". So let's agree to disagree.
On Sat, Mar 03, 2012 at 04:05:44AM +0100, Guillem Jover wrote:
> > I'm convinced that such an attitude actively harms Debian and as such
> > should not be tolerated. That's why I've asked for tech-ctte technical
> > judgement on your decision to postpone the upload in wait of full code
> > review.
>
> If by stalling you mean, having to work on an unpleasant, distressful
> and annoying environment, when supposedly doing it for fun, while still
> managing to motivate myself enough to make progress by doing design,
> implementation, review and cleanup work; not merging code I deem
> technically not acceptable, regardless of the provenance (for which I
> don't think I've ever discriminated on, as can be seen from the amount
> of unmerged branches on my own repo, because they are not ready yet...)
> on a project like dpkg, which has far reaching repercusion compatibility
> wise, where we might have to live with issues forever or where package
> maintainers might need to do useless fixup work due to the consequences
> of those issues, on the whole distribution, then I guess, sure, guilty
> as charged...
I'm sorry Guillem, but you will not convince me with this side argument.
I'm terribly sorry for the stress you went through, I really am and I
wish nobody in Debian goes through something like that due to Debian
every again. But the above is not the point. The point is that you
picked the rules of the game ("code review must be") and actively
blocked others to participate in the game.
You may even pretend, here and now, that you would have welcomed others
to participate in the code review, but that is not the impression that
you gave for the past year. You've frequently worked on a private branch
and referring on -dpkg to changes made in it that have not been pushed
to any public place for a long time. This seems to have happened also
for the last "code review" after the experimental upload. How could you
possibly expect that attitude to encourage other to participate in code
review?
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences .. http://upsilon.cc/zack .. . . o
Debian Project Leader... @zack on identi.ca ...o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Re: Upcoming dpkg 1.16.2 upload
Quoting Guillem Jover (guil...@debian.org): > On the other hand I've also become disappointed after possibly realizing > that Debian's culture seems to have been shifting into something different > than what it was when I joined, where technical excellence seems to be > less important than rushing things out, patience is not considered an > important virtue anymore, but being pushy and demanding are, etc. > Which means I've been and will be reconsidering what my involvment in > the project should be. I'm not sure that this list is the right place for that discussion, but I see too much generalization in this statement. From what I've witnessed, the apparent "rush" has been quite soft and most people involved in this multi-arch stuff much more deeply than I am have refrained from pushing things too hard for a very long time before becoming more insisting (and I think it wouldn't be fair to translate "people" to "Raphaël", here). A *lot* of care has been taken to respect your very obvious commitment to technical excellence and will to "do the right thing" and I don't think that the TC people fit the definition you give above. I think that everybody agrees that multi-arch changes are, in some way, risky changes and this, particularly in the core package that dpkg is. But I also think that, after a few weeks, we see that we needed that release to unveil all consequences that, indeed, no human could anticipate. Nobody wants to repeat the 3-year release cycle of sarge, I'm afraid. I'm sure this won't convince you more than you are now, but I also think it's really unfair to conclude that the Debian culture has changed because of that. And, frankly, from what I have witnessed over the years, we already had many disruptive innovations happening in our core packages in that past and probably not all of them were as prepared as the multi-arch thing has been Again, I think that some words had to be said about all this and, as I can't speak about technical issues that are flying miles over my headI then focus on the social issues. Nobody can't really prevent me from doing so..:-) So, well, in short, keep up with the good work and please don't give up...neither now or in a near future. signature.asc Description: Digital signature
Re: Multiarch support in dpkg — really in time for wheezy?
On Sat, 03 Mar 2012, Guillem Jover wrote: > [ Replying to this now, because it appears some people seem to think > mails that go unanswered are considered as accepted facts... ] Answering mails (when the other side is expecting an answer) is important when you want to assume the leadership on dpkg maintenance. It has been one of the major problems between us, and between you and the release team. > > Please be a team player. If you can make it, that's great, we will all > > benefit from extra eyes on the code, especially if they are experienced > > eyes as yours. But if you cannot make it, please step back and allow for > > uploads to happen. In case you are not willing to do that, I'd be in > > favor of having other dpkg co-maintainers doing the uploads the Release > > Team is asking for. After all, there is nothing that cannot be fixed > > later in subsequent uploads. > > If rushing things out and being sloppy or merging technically unsound > code is being a team player, then count me out. Also who do you think > would have had to cleanup that code afterwards anyway, if it had been > merged as it was at the time? (no one else has either been able or > willing to do it up to now...) 1/ Nobody rushed anything. The code has been available since march last year. 2/ I have offered multiple times to fixup any problem that your code review would have unveiled. So it's not true to claim that all the responsibilities land on you. The real problem is that you have taken multiarch under your umbrella as your own pet project, completely ignoring me and my offers of help. You have claimed numerous times that the branch was "unsound, buggy" (implying that I'm crappy coder, etc.) and I would not take offense on this if you were at the same time pointing out concreate real problems and if we could have a sane discussion on how to fix them. But we had nothing like this... don't be surprised then if everybody is watching you. You have created yourself the conditions that lead to this pression on your shoulders. Working in the open and giving clear directives so that other can step in relieves that pression. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120303141416.ga12...@rivendell.home.ouaza.com
Re: Git-Wrapper no longer working?
Hello, On Sat, 03 Mar 2012, Helge Kreutzmann wrote: > Hello, > after the recent git update in testing the wrapper stopped working: > > ~/skripte/git-wrapper udpate > /home/helge/skripte/git-wrapper: invalid syntax > /home/helge/skripte/git-wrapper update: update the current branch of the > repository > /home/helge/skripte/git-wrapper commit: commit and push the changes to the > remote repository > > Could you check and update the script? I no longer have a copy of the script. Can you attach it? In any case, Git has improved since then and it's probably not very useful anymore. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120303141907.ga12...@rivendell.home.ouaza.com
Re: Git-Wrapper no longer working?
Hello Raphaël,
On Sat, Mar 03, 2012 at 03:19:07PM +0100, Raphael Hertzog wrote:
> On Sat, 03 Mar 2012, Helge Kreutzmann wrote:
> > after the recent git update in testing the wrapper stopped working:
> >
> > ~/skripte/git-wrapper udpate
> > /home/helge/skripte/git-wrapper: invalid syntax
> > /home/helge/skripte/git-wrapper update: update the current branch of the
> > repository
> > /home/helge/skripte/git-wrapper commit: commit and push the changes to the
> > remote repository
> >
> > Could you check and update the script?
>
> I no longer have a copy of the script. Can you attach it?
It is attached.
> In any case, Git has improved since then and it's probably not very
> useful anymore.
If I should simply "git push" and "git pull" thats fine with me as
well, just last time this was not desired.
Thanks!
Greetings
Helge
--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
#!/bin/sh
# Copyright 2007-2008 Raphael Hertzog
#
# This program is free software; you may redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This is distributed in the hope that it will be useful, but without
# any warranty; without even the implied warranty of merchantability or
# fitness for a particular purpose. See the GNU General Public License
# for more details.
#
# A copy of the GNU General Public License is available as
# /usr/share/common-licenses/GPL in the Debian GNU/Linux distribution
# or on the World Wide Web at http://www.gnu.org/copyleft/gpl.html.
# You can also obtain it by writing to the Free Software Foundation, Inc.,
# 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
# This script is only meant to be used in the master branch of dpkg
# This branch is created by default by a git clone
# ssh://git.debian.org/git/dpkg/dpkg.git
# Git 1.5.3 is required (for git-stash)
has_changes_in_index() {
# git-diff --quiet returns 1 when there are changes
if git diff --quiet --cached; then
return 1
else
return 0
fi
}
has_changes_in_working_tree() {
# git-diff --quiet returns 1 when there are changes
if git diff --quiet; then
return 1
else
return 0
fi
}
is_uptodate() {
unmerged=`git rev-list origin/$branch ^HEAD`
if test -z "$unmerged"; then
return 0
else
return 1
fi
}
has_unpushed_commits() {
unpushed=`git rev-list HEAD ^origin/$branch`
if test -n "$unpushed"; then
return 0
else
return 1
fi
}
test -d .git || {
echo "This script must be called from the root of dpkg's git repository."
>&2
exit
}
branch=`git branch | grep ^* | awk '{print $2}'`
if ! git branch -r | grep -q " origin/$branch$"; then
echo "This script must be called from a branch which also exist on the
remote side." >&2
echo "The current branch is '$branch' but 'origin/$branch' doesn't exist."
>&2
exit
fi
case $1 in
update)
git fetch --quiet origin
if has_unpushed_commits; then
echo "** You have local commits that were not pushed to the remote
repository."
if is_uptodate; then
echo "** They are still OK to be pushed."
else
echo "** The remote repository has evolved. Rebasing your work."
$0 rebase
fi
else
if ! is_uptodate; then
echo "** The remote repository has changed. Trying to update."
git merge origin/$branch
result=$?
if [ $result -eq 0 ]; then
echo "** The repository has been updated."
elif [ $result -eq 1 ]; then
echo "** The repository has been updated but there have
been conflicts:"
git ls-files --unmerged | awk '{print $4}' | uniq -c
else
echo "** The automatic merge failed. Trying another
strategy."
echo "** Pushing local changes aside with git stash."
git stash save "WIP saved by dpkg-vcs"
echo "** Merging remote changes, should result in
fast-forward."
git merge origin/$branch
echo "** Reapplying local changes with git stash apply."
git stash apply
result=$?
if [ $result -eq 0 ]; then
echo "** Local changes have been merged."
elif [ $result -eq 1 ]; then
echo "** Local changes have been merged but there have
been conflicts:"
git ls-files --unmerged |
Re: Upcoming dpkg 1.16.2 upload
Thank you Christian, My opion is ... As to new developers rushing? Mark pkgs as "conflicts" or "alpha / beta" and major minor versions correctly and you are fine :) a much bigger / free-er to submit contrib/ section would be nice. I DEFINITELY have the option (1) DMs and DDs are PREVENTING new submissions (contrib/ wise) with too many rules and this frustrates fresh meat. (2) but at the same time they are allowing massive breaking by ignoring to force use "conflicts/alpha beta/major version bump" where it belongs. (ie, i copy from host a new lib same major version and stuff not requiring minor improvements breaks) My feeling? If a "new stable" isn't? People will use the old stable until it is good. In general it's gotten better and more and better pkgs than ever are running. Way better than buzz and with allot more "hardware" challenges to overcome ! :) Thanks all --John Christian PERRIER wrote: bubu...@debian.org -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f523079.4040...@cox.net
Re: Multiarch support in dpkg — really in time for wheezy?
On Sat, 2012-03-03 at 15:14:16 +0100, Raphael Hertzog wrote: > On Sat, 03 Mar 2012, Guillem Jover wrote: > > [ Replying to this now, because it appears some people seem to think > > mails that go unanswered are considered as accepted facts... ] > > Answering mails (when the other side is expecting an answer) is important > when you want to assume the leadership on dpkg maintenance. It has been > one of the major problems between us, and between you and the release > team. I've already said elsewhere why I didn't reply to the RT mail, and while obviously I'm not them, I'd venture to say their (IMO unjustified) angry reaction has been (partially) due to your campaign of fear mongering... I did not find your previous preventive involvement and the later on “escalation” to the DPL (as if the supposed weight of that role would be useful somehow) to be appropriate, and I didn't find replying to a mail supposedly aimed at “mediation”, when I had already been condemned, worth the energy. Usually if I've nothing good to say, I'd rather not say anything. But then you both keep mischaracterizing the situation, at least the “leader” has the partial excuse of being misinformed, OTOH you've been directly involved and we have had personal discussions about all this, so after this mail I'm not sure I can be bothered to repeat myself to discuss this matter again any further, more so when your stance seems to me to change between public and private communications. > > If rushing things out and being sloppy or merging technically unsound > > code is being a team player, then count me out. Also who do you think > > would have had to cleanup that code afterwards anyway, if it had been > > merged as it was at the time? (no one else has either been able or > > willing to do it up to now...) > > 1/ Nobody rushed anything. The code has been available since march last > year. Obviously not for lack of trying. That paragraph was replying to what the “leader” thinks should have happened. If it had been for you, the code would had been merged long time ago, as it was, with all its problems... > 2/ I have offered multiple times to fixup any problem that your code > review would have unveiled. So it's not true to claim that all the > responsibilities land on you. The real problem is that you have taken > multiarch under your umbrella as your own pet project, completely > ignoring me and my offers of help. So one gets pressured, pestered, annoyed and as a consequence drained of all fun and motivation, while somehow managing to keep going with a civil tone, and is expected to still have to deal closely with the offender... It's also interesteing how the reality about the “real problem” changed with time... > You have claimed numerous times that the branch was "unsound, buggy" > (implying that I'm crappy coder, etc.) and I would not take offense on > this if you were at the same time pointing out concreate real problems and > if we could have a sane discussion on how to fix them. I guess we have either not been looking at the same mailing list or code base then, it's been a *fact*. > But we had nothing like this... don't be surprised then if everybody > is watching you. You have created yourself the conditions that lead > to this pression on your shoulders. Working in the open and giving > clear directives so that other can step in relieves that pression. Oh, because that pressure, present already more than one year ago, did not start instead from say, contractual obligations... guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120303222509.ga...@gaara.hadrons.org
Re: Git-Wrapper no longer working?
Hi, On Sat, 03 Mar 2012, Helge Kreutzmann wrote: > Hello, > after the recent git update in testing the wrapper stopped working: > > ~/skripte/git-wrapper udpate > /home/helge/skripte/git-wrapper: invalid syntax It turns out the problem is not in the script, it's in what you typed. "udpate" instead of "update". Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120303232022.gc15...@rivendell.home.ouaza.com
Re: Git-Wrapper no longer working?
Hi, On Sat, 03 Mar 2012, Helge Kreutzmann wrote: > If I should simply "git push" and "git pull" thats fine with me as > well, just last time this was not desired. If you use "git pull --rebase" instead of "git pull", it should be mostly fine. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120303232156.gd15...@rivendell.home.ouaza.com
Re: Upcoming dpkg 1.16.2 upload
Guillem Jover writes: > On the other hand I've also become disappointed after possibly realizing > that Debian's culture seems to have been shifting into something different > than what it was when I joined, where technical excellence seems to be > less important than rushing things out, patience is not considered an > important virtue anymore, but being pushy and demanding are, etc. > Which means I've been and will be reconsidering what my involvment in > the project should be. You are kind of implying that you are the only one with technical excellence and that all the people that designed, wrote and send you multiarch stuff do not. It saddens me too that Debian's culture seem to have changed to where a single person things he has the only technical excellence on a subject. Please do not quit but maybe stop putting it all on just your shoulders. There must be someone else out there that you consider to have sufficient technical experteese to work with you. And if not then it would be even more important to bring someone else up to code. Having such a central component as dpkg rely on just one person is a disaster and the 10 month delay to review the multiarch patches will be the least of the problems over time. Say next year you do quit or something happens to you where would dpkg and Debian stand then. MfG Goswin PS: having someone else on the team can also mean you can offload more stuff you don't like on them and do more of the stuff you do like in dpkg. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87eht8khu4.fsf@frosties.localnet
Re: Multiarch file overlap summary and proposal
m...@linux.it (Marco d'Itri) writes: > On Mar 01, Russ Allbery wrote: > >> The situation with refcounting seems much less fragile than the situation >> without refcounting to me. > I totally agree. > > Also, why does refcounting have to be "perfect"? > What would break if it did not actually check that the two files > provided by the same package for different architectures are identical? Everything that can go wrong when splitting packages. You would loose the stability advantage. MfG Goswin -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa3wkhpv.fsf@frosties.localnet
Re: Multiarch file overlap summary and proposal
Guillem Jover writes: > On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote: >> Guillem Jover writes: >> > If packages have to be split anyway to cope with the other cases, then >> > the number of new packages which might not be needed otherwise will be >> > even smaller than the predicted amount, at which point it makes even >> > less sense to support refcnt'ing. >> >> I don't think the package count is really the interesting metric here, >> unless the number of introduced packages is very large (see below about >> -dev packages). I'm more concerned with maintainer time and with >> dependency complexity, and with the known problems that we introduce >> whenever we take tightly-coupled files and separate them into independent >> packages. > > Well, people have been using the amount of packages as a metric, I've > just been trying to counter it. It also in a way represents the amount > of work needed. > > About tightly-coupled files, they can cause serious issues also with > refcounting, consider that there's always going to be a point when > unpacking one of the new instances will have a completely different > vesion than the other already unpacked instance(s). So packages could > stop working for a long time if say unpacked libfoo0:i386 1.0 has > file-format-0, but new libfoo0:amd64 4.0 has file-format-2, and the > file didn't change name (arguably this could be considered an upstream > problem, depending on the situation), this would be particularly > problematic for pseudo-essential packages. That is not an argument for or against refcounting. If at all it would be marginally for refcounting: The same situation would occur with libfoo0:i386 1.0, libfoo0:amd64 4.0 and libfoo0-common:all 2.0. But now even worse because you have 3 versions that can be out-of-sync. Actualy if the file is shipped in the package then ref counting would automatically detect the difference in contents and fail to install the new libfoo0:amd64 4.0. And if the file is not shipped in the package then ref counting has no effect on it. Again ref counting comes out better. Ref counting would catch some of those cases but not all and it never makes it worse. What solves this problem is the same version requirement or simply adding Breaks: libfoo0 (<< 4.0~) to libfoo0:* 4.0. The only point you've made is that ref counting isn't a magic bullet that brings us world peace. MfG Goswin -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762ekkh3g.fsf@frosties.localnet
