[pacman-dev] New Guy Wants to Change Everything

[Dan McGee]

Please put your replies in context so people can more easily follow
(and reply) to what you have to say. I've moved your responses so
people like me, who haven't been on the list in a few days, can
actually continue the conversation.

On Mon, Jan 17, 2011 at 2:27 AM, Westley Martínez <anikom15 at gmail.com> wrote:
> On Mon, 2011-01-17 at 17:03 +1000, Allan McRae wrote:
>
>> On 17/01/11 16:23, Westley Martínez wrote:
>> > Hello I'm Anikom15 and I'm new. You might know me from the Arch Linux
>> > forums but whatever.
>>
>> I have seen you there in between your repeated bannings...
>>
>> > I'm interested in helping develop pacman considering the fact I've been
>> > using the program for so long I figure I should give something back, and
>> > maybe get better at C coding, too.
>> >
>> > Okay, one question: why does the source code use tabs instead of spaces?
>> > Is there a specific reason as to why? In my experience spaces makes
>> > everything easier because tabs can mess up alignment if the editor isn't
>> > set properly.
>>
>> How?   As long as you stick with the coding standards and always use
>> tabs there can be no issue.
>>
>> > I know what you're thinking, "These new people they come
>> > in and wanna change everything and then leave".
>>
>> I was thinking you need to get a better editor...
> My editor's fine.
>
> I'm being paranoid. In this age the whitespace problem tends to occur
> for cross-platform programs. And by "problem" I mean the code not
> looking right. (For C anyways....)

It looks fine for everyone here, so clearly your editor is not fine.
There is zero reason to make every form of history harder to
understand and follow (git annotate, for example) by changing
whitespace standards, nor is there any good reason to. Every person
currently working on the code has figured out how to deal with it, and
if you can point out a specific problem where the code doesn't look
right, I'm all eyes.

>> > I don't wanna change
>> > anything unnecessarily, I'd just like an explanation. Now just between
>> > you and me I think some other conventions the code is using like return
>> > statements being written like a function call are stupid as well, but
>> > those don't have dire consequences like the tabs can potentially have.
>>
>> White space issues having dire consequences?  It is normally the
>> non-whitespace issues that you need to worry about.

White space is not dire, but that is just repeating what Allan said.

Return statements, I tend to agree with you, but once again- the
standard was established, we follow it for sake of consistency, and
making this your first change is not the best of ways to get yourself
established. Contribute some other work, and then point out the
problem with our coding standards and why we should change it, and an
easy way to do so.

>> > Sorry if I sound a little invasive, I don't collaborate much.
>>
>> As with any project, if you want to contribute you need to stick to the
>> established coding standards.  These are unlikely to change unless there
>> is a very good reason to do so.
>>
> As  for developing this thing I was wondering what the preferred method
> for testing was. I mean, how do I use the development pacman without
> interfering with Arch's pacman? Also, are there ways to test
> installation/removal without writing to disk (there's probably a dry run
> option, better check the man page)?

$ make check

And take a look at Makefile.am to see what that rule does; we have an
extremely large test suite for most pacman operations and you
shouldn't ever need to risk your live system.

With that said, several people on this list run the latest code from
git as their system pacman, but it isn't recommended unless you follow
the ML to keep up with the latest changes and how they might affect
your system.

-Dan