On Thu, 29 Sep 2005 14:59:17 -0500 Aaron Griffin <[EMAIL PROTECTED]> wrote:
> Well, it's not really that I don't think they're useful or anything, > and I do agree the -Qe flags need to do something different, I always > believe in prototyping. Oh, cool. > Let me explain. If we take the "remove all but installed packages" > suggestion, it seems simple enough, but it's yet another change that > has to be made to pacman and tested (though not *alot* of work, it's > still work). Now, lets say this change is made, and it takes two > hours of the developer's time, and then you are the only one who uses > it (a new -Sci flag or something). That's two hours pretty much > wasted, considering that there a few thousand people using pacman > right now, and one person using the new feature. OK. I admit that this wish probably isn't useful to that many people. It's probably because they don't understand what it does, because such behavior can be handy. On source tarballs I can't live without it. (Though it should be noted that this behaviour is found on FreeBSD using portsclean -DD, on Debian using apt-cache clean (IIRC - it's been a couple of years since I last used it) and there are numerous scripts available to do it on Gentoo.) However it does make the most sense on source archives as you are more likely to re-use a source tarball than a package tarball. I've requested rejection of the task on Flyspray. > With strong prototyping, one provides a > patch/script/workaround/whatever and says "hey guys try this out!" - > if it doesn't get used, then there's no point in implementing it in > the application proper - the handful of users wanting the feature can > just use the prototype. If it gets a large response and is used by > alot of people, then implementing it is warranted. Funny that you using the above suggestion as the example, as that's the only one of them where I actually have attached a script for people to use. > Just take a look at the pacman-optimize script. It began in the > forums, got a decent response, and was moved to the actual pacman > package, but still as a script. Now, ignoring the fact that DB > improvements have already been made for the next release, as time > progressed, eventually pacman-optimize could be moved into pacman's > innards. Wow, nice script. (Yes, I do get your point, but I didn't know the script :-)) > It's much like the AUR now that I think about it. Packages get moved > to [community] based on need. If there is no need, the TU wastes his > time perfecting a package (NOTE: in some cases people already maintain > things for personal use, and have uploaded the package to [community] > anyway - I have 3-4 packages like that). > But, going back on topic, you can't guage popularity in the AUR until > the PKGBUILD is there. You can't just put the name up there and say > "hey guys, how about package-xyz?" You have to do a bit of work, a > bit of prototyping. My knowledge of C is too limited to do any pacman hacking. > I deal with this stuff at work. > <hypothetical>"Hey can you add feature XYZ to the app?" Looks like I > have to this guy is upper management.....later on I check some log > files... in 6 months only the original guy has used this feature and > only 3 times. And I spent 3-4 days on it.... what a waste > </hypothetical> > > All of the open source world is based on contribution, not > suggestions. People make suggestions to *closed source* applications > too (Hey Cerulean Studios, feature X would be great in Trillian!). I think you're being wrong here. At least we have two terms: Developers and users. Developers are users who also do development. However, all users aren't necessarily developers (although probably a lot more of them are than in the closed source world.) You need to look at it at a larger perspective. I, as a user, am helping others by using the testing repo so I experience and report bugs that would otherwise have hit them, for example. I also help collecting funds for various projects. One of them are FreeBSD. I bet some of the Arch mirrors are running FreeBSD, providing fast and robust mirroring for the community. That being said, of course contributing code is the most direct way to help making the software better. > The difference is that in the OSS world, things get done because > people *can* do it and *want* to do it. Most of the time lead > developers of a project have thought of your idea before, but they > just didn't think it was a big deal. I don't think Judd thought of doing it the proposed way. At least I can't imagine that it's harder to implement than the current -Qe model, and I don't see any advantages in the current model over the proposed one. You can't think of it all at once, that's why developers are versioning their applications. _______________________________________________ arch mailing list [email protected] http://www.archlinux.org/mailman/listinfo/arch
