Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
On Fri, May 19, 2006 at 02:44:14PM +0200, Turbo Fredriksson wrote: > Quoting Stephen Frost <[EMAIL PROTECTED]>: > > > * Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > >> But regarding the build system, I REALLY object to any major changes! > >> Fixes yes, > >> but not REPLACEMENT!! > > > > Uhh, or, not... Sorry, but the build system was terrible and is > > certainly something which should not be encouraged. > > Rubish! There is nothing (major) wrong with it as it is now. Yes, hardcoding > isn't good, but neither is 'an-hour-build'. Which you'd get if you do three > full builds after each other... I suggest you look at ccache. This will take care of avoiding spurious recompilation without changing the build system. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > You keep saying that, without showing the problems. From what I can see, > all you say is "it's wrong", "it's very wrong" and "there's major problems > with it". John pointed out the issues to it earlier in this thread, which you said you had followed so I expected you to be familiar with his complaints already.. I also asked you to *look* at the new build system he's using instead of making assumptions about it. > I (and more) have stated that the previos (and now yours?) build system was > WAY to expensive. Improving things, for whatever reason, is a good thing. It's certainly not too expensive for our users. It's not even too expensive for our buildds. > You on the other hand, went the OTHER way, you WORSENED the build. I wish I could take credit for it, but John is the one doing all the improvements to bacula. > And throwing CPU time out the window with the excuse "if you can't keep up, > get out" is in _MY_ opinion STUPID. That's nice, but maintainability is more important that the speed of the build. The prior build system wasn't maintainable and was clearly rather fragile. > The ONLY problem with the current (partial) build system is that part of (!!) > the build is hardcoded. Where libs are, and the name of the MySQL/PgSQL libs > will rarely (if ever) change so this is not a PROBLEM, it's only a > 'nitpicking'. Which makes it fragile and much more difficult to maintain than it has any need or right to be. This also makes it more difficult on anyone else having to use or deal with the packaging including porters, the secruity team, and others. That's not acceptable when all it does is speed things up a bit. Please, go look at John's build system and *try it* before complaining that it's too slow. It's also certainly not out of the question to work with upstream to improve the speed of building for multiple subsystems *without* having to resort to hard-codeing things into the build system. Work *with* the upstream build system, don't try to hack around it. Thanks, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
On Fri, May 19, 2006 at 03:29:55PM +0200, Turbo Fredriksson wrote: > The ONLY problem with the current (partial) build system is that part of (!!) > the build is hardcoded. Where libs are, and the name of the MySQL/PgSQL libs > will rarely (if ever) change so this is not a PROBLEM, it's only a > 'nitpicking'. Actually, it changed between sarge and etch, due to differences in the Kerberos libraries that are required. Also the hacks to configure broke between 1.36 and 1.38. What's more, co-opting the use of DEBUG for all this is just wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
On Fri, May 19, 2006 at 02:44:14PM +0200, Turbo Fredriksson wrote: > Quoting Stephen Frost <[EMAIL PROTECTED]>: > > Honestly, though, I'm much more concerned about maintainability than > > speed of the build. > > It's not especially problematic to maintain as it is now, and I ask you > to recognize the fact that we don't only ship amd64 or (fast) i386... > Some of the arch's isn't that fast. Don't know how the m68k port is going > or if it's still alive, but that would be a major point in getting speed > increases in the build. Wearing my m68k porter's hat... Seriously, if the choice is between 'fast builds' or 'reliable builds that will not fuck themselves up', then my choice is clearly for the latter. If there are ways to avoid stuff being rebuilt over and over again, then that's nice. But it's not so much of an issue if you can't do that. It's easier for us to add another machine to the buildd pool if we can't keep up anymore than it is to start debugging weird and unusual runtime errors. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
On Fri, May 19, 2006 at 09:35:57AM +0200, Turbo Fredriksson wrote: > But regarding the build system, I REALLY object to any major changes! Fixes > yes, > but not REPLACEMENT!! Well, it's a little late for that. ;-) > The first build system really sucked. It took AGES to build, and that I have no idea what the first build system was. I also don't really care. > on a 'not-so-slow' machine (2x750MHz Ultra SPARC III, 2Gb mem and FC disks). My current system takes less than 10 minutes on my machine, a single-CPU Athlon64 with plain IDE disks and 1GB RAM. On the autobuilder, build times for the current version of Bacula ranged from 8 minutes on amd64 to 14 hours on m68k. In contrast, here are some other build times, on amd64 and m68k: vim: 20m - 25h amanda: 2m - 2.75h (no GUI code) xorg: 14m - 31h linux-2.6: 6.5h - ?? (no successful build in logs for m68k) So I'd say bacula is quite reasonably middle of the pack, at less than half the build time of vim even. There are probably additional optimizations possible with the current build system as well. We don't have amd64 logs from the old build system of Bacula, but on m68k, it took 11.85 hours. In other words, hacking up the build system so much saved only 15%, and I haven't even tried to make optimizations on the current one yet. > A better, more dynamic way of building was needed. The simplest way of doing > this was just build it ONCE and then only compile and link that stuff that > was 'flavored'. I don't think that was simplest. That involved all sorts of fragile library lines. It involved setting the DEBUG environment variable to link in specific libraries. It required hacks to configure, hacks to m4 macros, and broke whenever Bacula, any database, GUI toolkits, or Kerberos revved. The package in sid couldn't build on sarge, and vice-versa. Not only that, but when new binaries were introduced upstream, it had to be hacked. It didn't clean up after itself well, and was so convoluted that I was never sure that it actually did the right thing. In short, it was a maintenance nightmare. This is a backup program. If it is not readily apparent that we are building it correctly, we have a bug. I don't care if it takes 4 times longer to build this way. We stand a much better chance of getting it to build correctly, and of not introducing subtle bugs on each new upstream revision or change on Debian. Here's another interesting metric: -rw-r--r-- 1 jgoerzen jgoerzen55954 May 11 08:15 bacula_1.36.3-2.diff.gz -rw-r--r-- 1 jgoerzen jgoerzen40554 May 16 21:32 bacula_1.38.9-9.diff.gz The current diff.gz is 28% smaller than the previous diff.gz, and that's in spite of a large increase in the size of debian/changelog, more comments in the debian code, AND the introduction of a fourth backend (sqlite3). What's more, the way I build it is the way that is recommended by the Developer's Reference, and the way that is used by vim. I say that a 28% reduction in the size of the diff.gz, and a tremendous gain in maintainability and correctness, more than makes up for a 15% increase in build time. I'd say it more than makes up for a 400% increase in build time, if that was the tradeoff. > Yes, the 'hardcoded' library stuff isn't the most perfect, but paying > attention I'd rather not risk someone, even myself, failing to pay attention to something if I can have it work correctly -- as upstream intended -- to start with. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Quoting Stephen Frost <[EMAIL PROTECTED]>: > * Turbo Fredriksson ([EMAIL PROTECTED]) wrote: >> Quoting Stephen Frost <[EMAIL PROTECTED]>: >> > * Turbo Fredriksson ([EMAIL PROTECTED]) wrote: >> >> But regarding the build system, I REALLY object to any major changes! >> >> Fixes yes, >> >> but not REPLACEMENT!! >> > >> > Uhh, or, not... Sorry, but the build system was terrible and is >> > certainly something which should not be encouraged. >> >> Rubish! There is nothing (major) wrong with it as it is now. Yes, hardcoding >> isn't good, but neither is 'an-hour-build'. Which you'd get if you do three >> full builds after each other... > > There was quite a bit majorly wrong with it. You keep saying that, without showing the problems. From what I can see, all you say is "it's wrong", "it's very wrong" and "there's major problems with it". I (and more) have stated that the previos (and now yours?) build system was WAY to expensive. Improving things, for whatever reason, is a good thing. You on the other hand, went the OTHER way, you WORSENED the build. And throwing CPU time out the window with the excuse "if you can't keep up, get out" is in _MY_ opinion STUPID. The ONLY problem with the current (partial) build system is that part of (!!) the build is hardcoded. Where libs are, and the name of the MySQL/PgSQL libs will rarely (if ever) change so this is not a PROBLEM, it's only a 'nitpicking'. -- 767 Noriega Iran North Korea domestic disruption DES Khaddafi pits security plutonium Ortega Cuba kibo Soviet Peking [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > Quoting Stephen Frost <[EMAIL PROTECTED]>: > > * Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > >> But regarding the build system, I REALLY object to any major changes! > >> Fixes yes, > >> but not REPLACEMENT!! > > > > Uhh, or, not... Sorry, but the build system was terrible and is > > certainly something which should not be encouraged. > > Rubish! There is nothing (major) wrong with it as it is now. Yes, hardcoding > isn't good, but neither is 'an-hour-build'. Which you'd get if you do three > full builds after each other... There was quite a bit majorly wrong with it. > > Honestly, though, I'm much more concerned about maintainability than speed > > of the > > build. > > It's not especially problematic to maintain as it is now, and I ask you > to recognize the fact that we don't only ship amd64 or (fast) i386... > Some of the arch's isn't that fast. Don't know how the m68k port is going > or if it's still alive, but that would be a major point in getting speed > increases in the build. I DO know that _I_ have been 'slapped around' for > doing to extensive builds... Sorry, but software is only going to continue to get larger and take longer to compile. Either the architectures need to find a way to handle that (more buildds, distributed builds, whatever) or the architecture it going to have to give up the ghost. My understanding is that the m68k folks have figured out some ways to improve things for themselves such that they can handle larger builds, which makes me even less inclined to hack up an unnecessairly complex build system. No, "we have slow archs" is *not* an excuse for an overly complicated and fragile build system. Thanks, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Quoting Stephen Frost <[EMAIL PROTECTED]>: > * Turbo Fredriksson ([EMAIL PROTECTED]) wrote: >> But regarding the build system, I REALLY object to any major changes! Fixes >> yes, >> but not REPLACEMENT!! > > Uhh, or, not... Sorry, but the build system was terrible and is > certainly something which should not be encouraged. Rubish! There is nothing (major) wrong with it as it is now. Yes, hardcoding isn't good, but neither is 'an-hour-build'. Which you'd get if you do three full builds after each other... > Honestly, though, I'm much more concerned about maintainability than speed of > the > build. It's not especially problematic to maintain as it is now, and I ask you to recognize the fact that we don't only ship amd64 or (fast) i386... Some of the arch's isn't that fast. Don't know how the m68k port is going or if it's still alive, but that would be a major point in getting speed increases in the build. I DO know that _I_ have been 'slapped around' for doing to extensive builds... -- Semtex strategic killed Uzi plutonium Treasury attack Panama Ortega Ft. Bragg critical assassination Marxist Nazi smuggle [See http://www.aclu.org/echelonwatch/index.html for more about this] [Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf] If neither of these works, try http://www.aclu.org and search for echelon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
* Turbo Fredriksson ([EMAIL PROTECTED]) wrote: > But regarding the build system, I REALLY object to any major changes! Fixes > yes, > but not REPLACEMENT!! Uhh, or, not... Sorry, but the build system was terrible and is certainly something which should not be encouraged. I'd encourage you to look at John's packaging and try building it and see how it goes. If you still have complaints about the speed of the build then bring them up with some timing information. Honestly, though, I'm much more concerned about maintainability than speed of the build. There's a reason we build debs and don't just ship source- so our users don't have to deal with the build time. Thanks, Stephen signature.asc Description: Digital signature
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Quoting =?UTF-8?B?Sm9zw6kgTHVpcyBUYWxsw7Nu?= <[EMAIL PROTECTED]>: > John Goerzen wrote: > JLT>I was "reprehended" by Turbo Fredriksson due to the amount of > CPU wasted. He cared to contribute some patches which, after being > integrated and enhanced --as much as i could-- by me, form the current > build system. > > My original build approach (in 1.32f6) used the method you suggest. That > means that I can do it "properly" (using your own terms). > However, Turbo and PMHahn (and some others, too), advised me to change > everything. > Turbo himself warned me of a better way to do it on March 2nd/3rd 2004, and > pointed me to #196802 > > I completely rewrote the build system based on their input and got it > working. My sponsor, rover, also appreciated it (its speed, mostly). > > This means that there are DDs which approve of this approach as well as there > are some who disprove of it. It can't be that bad, then. My 2 euro cent here. Sorry for not showing interest sooner (I HAVE followed the thread from start!), but it's been a little to much ... flaming. I have no objections to the policy complains. If they are there, they should be fixed. They aren't that difficult to fix and wouldn't take to long... But regarding the build system, I REALLY object to any major changes! Fixes yes, but not REPLACEMENT!! The first build system really sucked. It took AGES to build, and that on a 'not-so-slow' machine (2x750MHz Ultra SPARC III, 2Gb mem and FC disks). A better, more dynamic way of building was needed. The simplest way of doing this was just build it ONCE and then only compile and link that stuff that was 'flavored'. Yes, the 'hardcoded' library stuff isn't the most perfect, but paying attention to this when a new version is out, it will work. If one could come up with a way of automatically detecting this WITHOUT running 'configure' from scratch, that would be NEAT! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
John Goerzen <[EMAIL PROTECTED]> writes: > I would do this regardless of who the maintainer was. I seem to recall > possibly doing it for some Perl HTML package that was in a similar > situation to Bacula in the late 90s, but I can't really remember. I'm > sure you could dig up links. It was the URI package, and you were totally justified. As, from what I see, you are in this case---not that my opinion should carry much weight other than in the "takes a (former) derelict maintainer to know one". :) Mike -- A steeple full of swallows that could never ring the bell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Josselin Mouette wrote: > Le vendredi 12 mai 2006 à 03:13 +0200, José Luis Tallón a écrit : > >> Please tell me how in hell can you justify accusing me of not testing my >> packages, when you have obviously not done so. >> You seem to have some fixation with uploading, don't you?? Six versions >> in 24h ? >> Instead of uploading many half-baked packages, you could try getting one >> right before uploading. >> It is hardly justifiable to build and upload that many packages if you >> already foresee many more fixes needing to go in. >> > > I don't want to comment on the rest, as you are turning ridiculous, but > let me just give you this advice: release early, release often. > If that was easy for me, I would (I mean in Debian) It should have been as easy as for John and yourself since late 2004. But it still isn't. Nothing more to say on this. J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
Le vendredi 12 mai 2006 à 03:13 +0200, José Luis Tallón a écrit : > Please tell me how in hell can you justify accusing me of not testing my > packages, when you have obviously not done so. > You seem to have some fixation with uploading, don't you?? Six versions > in 24h ? > Instead of uploading many half-baked packages, you could try getting one > right before uploading. > It is hardly justifiable to build and upload that many packages if you > already foresee many more fixes needing to go in. I don't want to comment on the rest, as you are turning ridiculous, but let me just give you this advice: release early, release often. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
On Fri, May 12, 2006 at 03:13:31AM +0200, José Luis Tallón wrote: Jose, Before I comment on a few things, I want to make something clear to you. You have repeatedly accused me of having something personal against you, both in public and in private. I cannot recall ever having even *heard* of your existance prior to looking at Bacula, and didn't know a thing about you until later yet. I would do this regardless of who the maintainer was. I seem to recall possibly doing it for some Perl HTML package that was in a similar situation to Bacula in the late 90s, but I can't really remember. I'm sure you could dig up links. What's more, I WOULD HOPE PEOPLE WOULD DO IT FOR ME. I have maintained my fair share of packages over the years, and I have also orphaned or given up packages for adoption over the years. I've been NMU'd, even recently. I am not mad at that. In fact, I am glad that these things have happened. (I wish it hadn't been necessary, but I'm glad that people have stepped up to do it when it was.) A key difference is that I recognized when someone else would be better able to take care of a package, and amicably arranged with them to do so. I am proud and happy to see things that I once maintained go farther than I could have taken them. It's neat to see updates to rdiff-backup, lincity, or even mgetty come across. I was very pleased to see recently that the descendent of the "pure64" amd64 archive I created (which was itself a descendent of the one Goswin created) has been accepted into Debian. That's not thanks to me; I put in a week or two to bootstrap it but many others have done far more than I ever did, both before and after. I am not even a footnote in the amd64 project, nor do I deserve to be. I am just glad to have been able to have a part in it -- it really was a FUN project. I don't say this to try to prove that I'm some mighty Debian developer. I'm not, and I know it. I say this because I want you to understand something that you may not have had a chance to experience yet -- that is, that there is more to getting satisfaction from a project than doing everything yourself. The best compliment for a Debian developer is not, in my opinion, "Wow, you maintain a lot of packages!" (Though Joey Hess certainly is a wonderful developer.) I think the best compliment for a Debian developer is for a *user* of Debian to say, "Wow, *Debian* is a solid OS that Just Works." NMUs make Debian better. Hijacking of packages, as in this case, can make Debian better too. Remember, from the Social Contract, that Debian's priorities are its users and Free Software. Now then, there is not much new in your message, but I'd like to address a few points. > > * Bacula's current maintainer is not a Debian Developer and has been > >in NM since 2003. > > > So what? If only the "elite" can contribute to Debian say so. Then, all I already told you in private, when I informed you that this thread existed (since you didn't seem to have noticed it, I thought the polite thing was to make you aware), that it was an error on my part to make it look like this was part of the case for removing your package. Someone -- I forget who just now -- had rightly pointed that out to me. So you know that I do not hold the attitude that you claim I do. I would also point out that I contributed to Debian prior to becoming a Debian Developer. > There is still half a year left until Etch is released. Attitudes like this will ensure that there is always half a year left until Etch is released. > Still much more than two months left for the base freeze. A transition > takes 10 days at most. If you get the package right to start with, and uploaded on time. Which history indicates is not likely. > > * The last upload for Bacula was almost a year ago. > > > There were no upstream releases for over six months, either. But there were RC bugs against it in Debian for over a year. You needed to make a new upload. > > * The maintainer has repeatedly, over the last year, said he's working > >on this but hasn't made much real progress, and has made no upload to > >Debian. > > > And I have. Prove otherwise if you can. I have my testing standards, and http://packages.qa.debian.org/bacula The last activity from you was: [2005-07-14] Accepted 1.36.3-2 in unstable (low) (Jose Luis Tallon) Followed by: [2006-02-14] bacula REMOVED from testing (Britney) > never upload anything without testing. Then your testing standards are insufficient for an upload to sid. You have uploaded packages that would not even *install from scratch* on most machines. > > * The current maintainer does respond to pings, but has a long record > >of problems getting bugs (even RC bugs) fixed in a timely fashion. > > > I assume you meant "not fixed"... No, the problem is that you haven't fixed them in a timely fashion. > > I have already prepared an NMU that fixes 22 bugs, including all four RC > > bugs.
Re: Intent to hijack Bacula (Heads up, Get The Facts!) (long)
John Goerzen wrote: > Hello, > > I intend to take over the Bacula package. I would first like to say > thanks to Jose Luis Tallon for initially packaging it for Debian and > maintaining it for these years. > You have a funny sense of time, don't you? This is true; Years. Since October 2003. > A brief history of why I intend to do this: > > * Bacula has had RC bugs open for more than a year. It was removed >from testing several months ago because of this. > > * Bacula's current maintainer is not a Debian Developer and has been >in NM since 2003. > So what? If only the "elite" can contribute to Debian say so. Then, all non-DD maintainers will quit; We might as well flee away to Ubuntu like many former Debian users have done and are doing. At least, they manage to get a distro out of the door every six months. Note, however, that I love Debian as a distro. I just hate the rudeness of some people here (and regret that most of the gentlemen DDs that I have encountered in these years very seldom raise their voices here -- I assume they are devoting that time to Debian in some other way) > * Bacula as it currently exists in sid is unbuildable and >uninstallable. Bacula will not be present in etch unless significant >problems are fixed. > There is still half a year left until Etch is released. Still much more than two months left for the base freeze. A transition takes 10 days at most. > * The last upload for Bacula was almost a year ago. > There were no upstream releases for over six months, either. > * The maintainer has repeatedly, over the last year, said he's working >on this but hasn't made much real progress, and has made no upload to >Debian. > And I have. Prove otherwise if you can. I have my testing standards, and never upload anything without testing. You blame me for "not testing packages and > * Several additional critical-level or grave-level unreported bugs >exist in the bacula Debian source tree (such as stopping database servers >without permission and deleting files un-owned by a particular >package) > Then report them. That's what the BTS is for. > * There are various policy compliance issues with the current packages. > So? report them. That's the procedure you are supposed to follow. > * The current maintainer does respond to pings, but has a long record >of problems getting bugs (even RC bugs) fixed in a timely fashion. > I assume you meant "not fixed"... > I have already prepared an NMU that fixes 22 bugs, including all four RC > bugs. I have tagged those bugs as pending. This release is currently > sitting in NEW. I also prepared subsequent NMUs that fix critical, but > unreported, bugs in the Debian Bacula packages. > The fact that you uploaded six versions of Bacula to NEW within one day gives an idea of the level of testing you give them. For those unaware of Bacula's packaging: there are several components, in three flavors (SQLite, MySQL, PostgreSQL). This means that John Goerzen uploads packages without testing them. Either that or he enjoys 48h-days and has ultra-fast machines (I have an AMD3GHz/1GB RAM/SCSI discs for development). JG>It is not your place to upload known-broken software to sid. It is also not your place to fail to test them before uploading. Please tell me how in hell can you justify accusing me of not testing my packages, when you have obviously not done so. You seem to have some fixation with uploading, don't you?? Six versions in 24h ? Instead of uploading many half-baked packages, you could try getting one right before uploading. It is hardly justifiable to build and upload that many packages if you already foresee many more fixes needing to go in. > Fixing the rest of the problems with Bacula requires a level of work > that is not really appropriate for an NMU. I have discussed the > situation with Jose's AM, Stephen Frost, who encouraged me to hijack the > package. Stephen Frost: Thank you for showing how an AM *should not* proceed. After neglecting me for several months, and failing to process my NM answers in due time, you have now joined John Goerzen in trying to discourage me from working for Debian. I had to publicly ping you several times on -devel (as well as doing so privately) before I could even get acknowledgement that you had received my answers. If you are that busy (as you have admitted on -devel), then step down as AM and leave space for others who will be able to do better. You didn't, yet you now blame me for not keeping up to my duties as a maintainer and not wanting to work on this. 'nuff said. (This doesn't feel impartial with me anymore -- that would disqualify you as able to evaluate my work) > I have also discussed the situation on #debian-devel, and consensus there > seemed to be that a hijack was warranted. > > In short, I will be maintaining working Bacula packages My users don't seem to agree with you (w.r.t. to "working" Bacula packages)... I
