[pacman-dev] command line arguments

[Aaron Griffin]

On 10/2/07, Nagy Gabor <ngaba at bibl.u-szeged.hu> wrote:
> > On 9/29/07, Xavier <shiningxc at gmail.com> wrote:
> > > On Sat, Sep 29, 2007 at 01:48:29PM +0200, Nagy Gabor wrote:
> > > > A bit off in this thread, but the current command-line handling of pacman
> > is
> > > > chaotic, for example the bahaviour of -Quil is not defined. We should
> > > > restructure a bit, we should categorize options: (my example assumes -S)
> > > > -operation: -l, -i, -c, -l, -p, -s, -y ... <- more than one allowed
> > (pacman try
> > > > to do all requested operations)
> > > > -loadtarget/targettype-modifier options, -g, (--provider), -u (!!) ... <-
> > only
> > > > one allowed
> > > > -trans_prepare/new-target-pull options: -d, (--noconflict option), -e ...
> > <-
> > > > more than one allowed
> > > > -trans_commit options: -f, --asdeps, -w (do nothing) ... <- more than one
> > allowed
> > > > As an example, I explain what should pacman -Quetcl do:
> > > > List all explicitly installed outdated not-a-dependency-of-other packages
> > and
> > > > show their changlogs and filelists ;-)
> > > >
> > >
> > > I think that's a good idea, but a lot of work again :)
> >
> > It's always "a lot of work". C'est la vie.
> >
> > This is why Dan and I like to harp on people for patches. We're just
> > two guys, and we both have full time jobs (ok, I now have a second job
> > if you look at the main Arch page) and social lives.
> >
> > It's hard to do everything everyone wants.
> >
> > That's also why I love when people run their own git branches. I don't
> > have to do much extra. I remote update and voila! I have all your work
> > to import.
> >
> > It's amazing.
> >
> > Keep up good the work guys.
>
> OK, I will explain a viewpoint of a patch-sender ;-)
>
> First of all, all of us have few freetime.
>
> To tell the truth I would radically rewrite some parts of pacman. This could be
> done at one night (in one-person hobby-projects (unlike pacman) the maintainer
> can do this easily ;-). But I cannot do that, because:
> -if I send a huge patch, you may not like the result and reject my patch, so I
> wasted a lot time [so I won't send huge patches]
> -if I send smaller patches depending on each other (to prevent myself from
> useless work) I have to wait a lot for your review/apply, and the one-night-work
>  may become a six-months-work ... [my deps.c and sync.c patches were sent about
> 2 months ago, and I'm waiting now for your apply/reject, I cannot continue my
> work until your decision...]
>
> So patch-senders cannot help more, we just send patches... Please don't ask us
> to create a git repo etc., that is needless, if you can _easily_ "decode" our
> patches, that should be enough. I appreciate your work on pacman as a developer
> (!many thanks, again!), but you should see that sometimes you and Dan slow down
> the development (by sitting on patches).
>
> I didn't want to hurt anybody, this was a criticism of a development _model_.
> However, I cannot suggest better... but I would give git access to some
> talented&enthusiastic guys <- not me;-). Because if I have not enough time for a
> project, I will search for other guys, who will enjoy help me <- Aaron: cf. mc
> Arch package bugs ;-). Note: English is not my native language, so I cannot
> express myself as clearly as I could in Hungarian, so my e-mail may be hurtful
> or whatever, sry.


No no, hey - don't get me wrong. I totally "get" where you're coming
from, BUT, the real issue here is not "will this get accepted or not"
but "how much more work do I have to do".

The simple fact is this. We have a lot of work to do. If you have
idea, and don't want to submit patches for them, then there's not much
we can do. So what we have to do instead is read through this email,
think "that's a good idea", respond, try and figure out how much work
it would take, and fit it into all the other crap we should be doing.

Not only does sending patches help us in that we don't have to do the
actual work, but it helps us with all the mental administrava we'd
have to do to figure out if we should or shouldn't do what you
suggest.

The comment you made about big patches is important too. If you make
big changes and they get rejected it's a lot of lost work... so submit
smaller changesets.

"One patch per feature" is the adage.

The more and more ideas that are pumped out to this list, the more
confused we get, and the harder it is to keep up. It's like.... if I
throw a baseball at you, you might catch it, but if I throw 50, you
won't catch them all.

This is open source. Ideas are cheap. EVERYONE has ideas. Everything
thinks something should be changed. Most of these ideas aren't
original either.

What gets you recognized in open source is NOT ideas and talk. It's work.