[pacman-dev] abs split from pacman before release
See here: <http://projects.archlinux.org/git/?p=abs.git;a=summary> If there are no objections, I'm going to push my remove abs patch to pacman, and throw this abs package up in my [pacman-git] repository for some quick testing. We are close to release, folks. Anything else outstanding that is critical? -Dan
On Dec 19, 2007 11:53 PM, Dan McGee <dpmcgee@gmail.com> wrote:
See here: <http://projects.archlinux.org/git/?p=abs.git;a=summary>
If there are no objections, I'm going to push my remove abs patch to pacman, and throw this abs package up in my [pacman-git] repository for some quick testing.
We are close to release, folks. Anything else outstanding that is critical?
This is great. It will allow us to apply Eliott's rsync patch in there (yay). I say go for it. ABS is such a minor script in the grand scheme of things.
We are close to release, folks. Anything else outstanding that is critical?
Well, we have some serious failing pactests (my actual "top-list": I. trans001, II. fileconflict001), but these needs deep code rewrite, so we can fix these in 3.2. I mention FS#8899 and FS#8897 here, which show that the current conflict resolving is just ugly. These are not critical problems at all, but IMHO the current state of resolving code is almost critical, and I'm not sure that new (serious) conflict-resolving bugs won't appear after release <- When I've created those pactests I tried to understand the current code as deeply as possible, but maybe I've missed something. And he have a (regression?) patch for this in Xavier's sync branch. Summary: I don't see any reason which could delay this release, but I would happy if we didn't release that ugly sync_prepare code (without delay). Bye
On Dec 20, 2007 8:32 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
resolving is just ugly. These are not critical problems at all, but IMHO the current state of resolving code is almost critical, and I'm
Could you define "almost critical" for me? See, I look at this stuff and say "man, that sure does suck, but it works for the most part". I think you see it a different way, so could you help me understand why you feel this is "almost critical"?
On Dec 20, 2007 8:32 AM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
resolving is just ugly. These are not critical problems at all, but IMHO the current state of resolving code is almost critical, and I'm
Could you define "almost critical" for me? See, I look at this stuff and say "man, that sure does suck, but it works for the most part". I think you see it a different way, so could you help me understand why you feel this is "almost critical"?
I said "almost critical", because it is really hard to follow what is happening there (or maybe I'm just too stupid to clearly understand that), and I think "black boxes" in our code are dangerous and unwanted (anyway, that codepart is needlessly long). I show you an example: Every local package is listed in at most one target package's replaces list => you cannot remove target package after targetpkg<->localdb conflict resolving, because 'lpkg' localpkg can conflict with two targets in the target list, and only one of them replaces lpkg, so if we remove this replacer (in target<->target resolving) then the conflict will appear again. Fortunately after Xavier's patch target<->target conflicts are resolved first in conflict.c, so this is not a bug now (but I cannot see any comments in the _alpm_sync_prepare, which indicates that this behavior is assumed). Imho the example above shows that it is not easy to follow what happening when you remove a target from the target list (because of the replacer list -- and at most one replacer for lpkg), for example I could create the localdb breaker FS#8899 using this -- maybe one can find/run into real-life examples too. Summary: I cannot say signed-off for sync.c, but maybe others can. Bye
On Dec 20, 2007 12:10 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
I said "almost critical", because it is really hard to follow what is happening there (or maybe I'm just too stupid to clearly understand that), and I think "black boxes" in our code are dangerous and unwanted (anyway, that codepart is needlessly long).
Ok, then I think we need to make this clear. Dan, if I'm assuming too much, let me know. Something is _only_ a critical issue when it is broken. If it works, and is ugly, it's absolutely non-critical. fetchmail is some of the ugliest code I've seen anywhere. It's used on thousands of machines. While we care about code quality, it simple does not matter if it is ugly. So please, at least for my sake, can you not claim something is critical unless it is either broken or a regression. These are critical. Duping a string for no reason, not critical. Minor memory leak, important, but not critical. Typo in some out, not critical. Inability to install packages, critical. Do you see what I mean? This is to help us out here. Every time I see "oh man this is critical!" I have to go look at the code, and look at bug reports and realize... nothing is broken it's just ugly. I can either keep wasting hours lookup up unimportant issues, or I can ignore them and we fall into the "boy who cried wolf" rut.
Summary: I cannot say signed-off for sync.c, but maybe others can.
I don't think anyone has requested signoffs on specific source files My Summary: No one cares what your code looks like http://www.codinghorror.com/blog/archives/001022.html
On Dec 20, 2007 12:10 PM, Nagy Gabor <ngaba@bibl.u-szeged.hu> wrote:
I said "almost critical", because it is really hard to follow what is happening there (or maybe I'm just too stupid to clearly understand that), and I think "black boxes" in our code are dangerous and unwanted (anyway, that codepart is needlessly long).
Ok, then I think we need to make this clear. Dan, if I'm assuming too much, let me know.
Something is _only_ a critical issue when it is broken. If it works, and is ugly, it's absolutely non-critical. fetchmail is some of the ugliest code I've seen anywhere. It's used on thousands of machines. While we care about code quality, it simple does not matter if it is ugly.
So please, at least for my sake, can you not claim something is critical unless it is either broken or a regression. These are critical. Duping a string for no reason, not critical. Minor memory leak, important, but not critical. Typo in some out, not critical. Inability to install packages, critical. Do you see what I mean?
This is to help us out here. Every time I see "oh man this is critical!" I have to go look at the code, and look at bug reports and realize... nothing is broken it's just ugly. I can either keep wasting hours lookup up unimportant issues, or I can ignore them and we fall into the "boy who cried wolf" rut.
Summary: I cannot say signed-off for sync.c, but maybe others can.
I don't think anyone has requested signoffs on specific source files
My Summary: No one cares what your code looks like http://www.codinghorror.com/blog/archives/001022.html
Well, short answer (I don't want to create an off thread): My main problem is not the fact that the code ugly, my main problem was that I had the feeling that it is not well understood. But I interpret your answer as I was wrong (== good news), so I revert my complaint. Bye
On Wed, Dec 19, 2007 at 11:53:24PM -0600, Dan McGee wrote:
We are close to release, folks. Anything else outstanding that is critical?
Hm well, nothing critical, but I thought there were several things that needed to be taken care of before the release, and not much happened during these last two weeks (sorry, I didn't have much time). 1) not important, easy to fix: * -Ru patch from Nagy is ready for quite a while, and it doesn't change any existing behavior, it just adds a new feature (however, it adds a new message to be translated) -> my unneeded branch 2) more important, easy to fix: * testdb is broken I fixed this on my testdb branch, and also added conflicts checking. nothing intrusive. * one memleak from Nathan was apparently ignored : http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104 and also, a little and good patch for ignorepkg : http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104 both pushed to my working branch 3) important, hard to fix: * the backup handling is in a poor situation : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010439.html http://www.archlinux.org/pipermail/arch-dev-public/2007-December/003868.html (with 3.1 , reinstalling filesystem makes the .pacnew appear though) * another weird issue with directory symlinks http://www.archlinux.org/pipermail/pacman-dev/2007-December/010451.html these two areas are my favorites (read: this really pisses me off).
On Dec 21, 2007 5:12 AM, Xavier <shiningxc@gmail.com> wrote:
On Wed, Dec 19, 2007 at 11:53:24PM -0600, Dan McGee wrote:
We are close to release, folks. Anything else outstanding that is critical?
Hm well, nothing critical, but I thought there were several things that needed to be taken care of before the release, and not much happened during these last two weeks (sorry, I didn't have much time).
1) not important, easy to fix:
* -Ru patch from Nagy is ready for quite a while, and it doesn't change any existing behavior, it just adds a new feature (however, it adds a new message to be translated) -> my unneeded branch
I'll try to look at this the next few days, and plan accordingly. Maybe this would be better in a 3.1.1 release?
2) more important, easy to fix:
* testdb is broken I fixed this on my testdb branch, and also added conflicts checking. nothing intrusive.
I pulled the bugfix patch, and I'll consider the other stuff sometime as well.
* one memleak from Nathan was apparently ignored : http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104 and also, a little and good patch for ignorepkg : http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104
both pushed to my working branch
Both pulled to my working branch now (your links got cut off too btw).
3) important, hard to fix:
* the backup handling is in a poor situation : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010439.html
http://www.archlinux.org/pipermail/arch-dev-public/2007-December/003868.html (with 3.1 , reinstalling filesystem makes the .pacnew appear though)
* another weird issue with directory symlinks http://www.archlinux.org/pipermail/pacman-dev/2007-December/010451.html
these two areas are my favorites (read: this really pisses me off).
I know we have problems here, but as far as I can tell, we don't have regressions. Correct me if I'm wrong. Regressions are show-stoppers, but problems are not (if they were, we would never be able to release). -Dan
Dan McGee wrote:
On Dec 21, 2007 5:12 AM, Xavier <shiningxc@gmail.com> wrote:
1) not important, easy to fix:
* -Ru patch from Nagy is ready for quite a while, and it doesn't change any existing behavior, it just adds a new feature (however, it adds a new message to be translated) -> my unneeded branch
I'll try to look at this the next few days, and plan accordingly. Maybe this would be better in a 3.1.1 release?
Well, I guess it's alright if 3.1.1 is not too far away, and this patch is merged soon after 3.1 is released.
2) more important, easy to fix:
* testdb is broken I fixed this on my testdb branch, and also added conflicts checking. nothing intrusive.
I pulled the bugfix patch, and I'll consider the other stuff sometime as well.
Ok good. Well, the other stuff is not important, but it's a really simple patch, so I thought it could go in.
* one memleak from Nathan was apparently ignored : http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104 and also, a little and good patch for ignorepkg : http://www.archlinux.org/pipermail/pacman-dev/2007-December/0104
both pushed to my working branch
Both pulled to my working branch now (your links got cut off too btw).
Thanks, and sorry for the links. Just in case, here they are again : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010475.html http://www.archlinux.org/pipermail/pacman-dev/2007-December/010518.html
3) important, hard to fix:
* the backup handling is in a poor situation : http://www.archlinux.org/pipermail/pacman-dev/2007-December/010439.html
http://www.archlinux.org/pipermail/arch-dev-public/2007-December/003868.html (with 3.1 , reinstalling filesystem makes the .pacnew appear though)
* another weird issue with directory symlinks http://www.archlinux.org/pipermail/pacman-dev/2007-December/010451.html
these two areas are my favorites (read: this really pisses me off).
I know we have problems here, but as far as I can tell, we don't have regressions. Correct me if I'm wrong. Regressions are show-stoppers, but problems are not (if they were, we would never be able to release).
-Dan
What really bothers me is that there is a real bug in the code, which causes dead code, and this is not totally obvious. So maybe this dead code could just be removed. That is, revert the add.c patch from commit 843d368ef60 .
participants (4)
-
Aaron Griffin
-
Dan McGee
-
Nagy Gabor
-
Xavier