[aur-general] TU application from graysky
xyne at archlinux.ca
Mon Mar 11 22:08:05 EDT 2013
Dave Reisner wrote:
I'd like to address a few points.
>I'm replying to the rest of this with full disclosure: graysky asked me
>to sponsor him first, and I've declined based on a lack of skill and
>what I feel isn't necessarily the correct attitude for an Arch TU.
I was not aware of this and I admit that my enthusiasm for the application was
slightly diminished, but I stand by my sponsorship.
>I have strong feelings against even the concept of profile-sync-daemon,
>and transitively (although moreso), anything-sync-daemon.
>1) You, as a user, cannot possibly manage memory more effectively than
>the kernel. Do not intentionally thwart the page cache.
>2) To claim that you're saving your precious SSD "unnecessary writes" is
>advanced silliness. Recent controllers don't have nearly the same
>problems early SSDs had.
Phrases such as "advanced silliness" have no place in a serious technical
discussion and only ratchet up tensions. Please avoid them.
I expect that there are many older SSDs out there (although that is debatable
as early adopters of SSDs are likely people who update often, but maybe not).
Even if you have a newer SSD that will likely never reach its read-write death,
some people simply like knowing that they are squeezing everything they can out
of their disks. Call them whatever name you want, but please realize that
simply because you see no value in something it does not follow that the thing
must have no value. Given the popularity of these apps there are clearly users
who think differently than you do.
>3) The only conceivable "benefit" is to move the startup time to bootup,
>rather than to when you first run the program.
Again, subjective value. For someone who doesn't sit around in front of the
screen while the system boots up, there is a clear value.
>4) Shell is inherently dangerous. If you're bent on writing something
>dangerous, you'd better know all the pitfalls of shell and what will
>eventually go wrong in your script. To wit, reading the bbs threads
>about these daemons will show at least 1 user who has suffered data loss
>simply by upgrading the profile-sync-daemon package.
How does an apparently one-off upstream mistake have any bearing on his ability
to package software? They are two different things. If your argument is that he
lacks skill then I could dig up quite a few examples of respected developers
who have released software with bugs. It happens and each incident should be
considered on its own to determine if the dev was just lazy or if it was a
mistake that others would likely make.
>...and in some cases, the program you're running this on top of is simply
>misconfigured for your needs. Firefox, for example, can be forced to use
>more RAM before switching to disk cache.
>> *Active contributor to Arch bugs.
>I find that your bug reports routinely lack effort on your part in
>deciphering the root of the problem leading to the bugs eventually being
>discarded. I'd expect a lot more effort from someone interested in being
>more than just an end user. Examples:
Posted in 2011, with ample information and active replies.
Reporting bugs for critical system packages while running [testing]... and
you're complaining about what exactly?
Fair enough, could have done more research.
The internal compiler errors may be obvious to C/C++ coders but not to everyone
else. Most users likely expect that running makepkg on ABS PKGBUILDs will
compile the package.
I agree that he should have done more research here, but I doubt that he is
likely to repeat this mistake.
>And some your feature requests are fairly misguided, often going against
>Arch's patching policy:
Difference of opinion. He came to the conclusion that there was an overall
benefit to most users and recommended changing package configuration options
because of it. I do not see how that it misguided simply because you
subjectively disagree with the evaluation of the purported benefit.
(I honestly have no opinion about the proposed change.)
Proposing the incorporation of a patch that has been submitted upstream and that
might avoid data loss is not misguided. I also find it contradictory that you
would consider this misguided yet cite one user's data loss due to a bug in his
software as a real concern, because here he is attempting to prevent data loss
for even a small set of users
This was a trivial request that could have waited for upstream, but I am under
the impression that Arch does accept patches that have been accepted upstream,
so it wasn't completely misguided. But yeah, this was obviously a case for ABS
and just a bit of noise on the bug tracker.
In this case upstream broke something, realized it and reversed itself but due
to an apparently slow release cycle it was going to take time to get back to
the users. I don't see how submitting a patch is misguided in this case.
>In short, this isn't the kind of attitude or skill level I'd expect from
>a trusted user.
I think we have different interpretations of his attitude and skill level. For
the former I see someone who is enthusiastic about Arch and who actively tries
to contribute. He replies are always cordial and responsive on the bug tracker
and forum. I admit that he sometimes is a bit quick to open a ticket and I
understand that it just creates unnecessary noise for you, but overall I think
you are interpreting his actions with unmerited negativity.
As far as skill goes, he maintains the linux-ck repo and many AUR packages. I
have not found anything to indicate a lack of packaging skills there. He is
also able to fix bugs in upstream software and will hopefully direct his
patches there in the future.
Considering his overall activity in the community I think he wants to do more
than just "maintain a few packages", but I cannot speak for him on that point.
In summary, I think he has what it take to be a good TU despite a few rough
But yeah, it would have been nice to get a full disclosure directly.
More information about the aur-general