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.
https://github.com/graysky2/profile-cleaner https://github.com/graysky2/backdrop-randomizer *Active contributor to Arch bugs.
Again, subjective.
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:
https://bugs.archlinux.org/task/24850 https://bugs.archlinux.org/task/26394
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 edges. But yeah, it would have been nice to get a full disclosure directly.