Paul Kocialkowski PaulK

PaulK commented on issue libreboot/libreboot#196

remove all photo/pics and other binary files from the git repository, rewrite history, move binary files to the rsync repo

Why are you even asking if you're not going to provide any feedback on my answer and act as if I had agreed with the proposal?

6 years ago

PaulK commented on issue libreboot/libreboot#196

remove all photo/pics and other binary files from the git repository, rewrite history, move binary files to the rsync repo

I'm in a favour of a separate git repo, but I think it would make more sense to have all the docs there, not only the binaries.

6 years ago

PaulK commented on issue libreboot/libreboot#183

general website cleanup

Less is more! LGTM.

6 years ago

PaulK closed issue libreboot/libreboot#161

Libreboot's relationship with Paper

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

I think everyone had a chance to provide feedback about this and we've come to an agreement, so I think it's time to close it.

7 years ago

PaulK commented on issue libreboot/libreboot#168

tidy up suppliers page: remove redundant headers and paragraphs

LGTM, even though I don't really understand the motivation for the change.

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

> I think we should stop calling it Paper.

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

I agree that decisions should be based on technical grounds and I also agree that anyone else on the team should take the decision away from me if I want to make a decision based on other criteria.

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

> However, the principle of Paul being "the maintainer" should be rejected. If someone wants to contribute to it and work on it, they should be able to do so without going through Paul. Paul should not "own" any part of Libreboot (the same also applies to me, and others).

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

Either way, it seems pretty clear that my first proposal is not welcome by Leah. Let's see what others think and note that I'd be fine with my 2nd proposal too.

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

> Paul, GNU is irrelevant in this discussion (and what you wrote is not true).

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

> The build system is a major part of Libreboot. It is Libreboot.

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

It doesn't really matter what we call upstream or downstream IMO. Let's just say both project diverged from libettereboot and thus have a common ancestor.

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

> No half ways.

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

> > To clarify things, here is the current status of the paper implementations:

7 years ago

PaulK commented on issue libreboot/libreboot#161

Libreboot's relationship with Paper

Another proposition, that would be half-way between the two previous propositions, follow:

7 years ago

PaulK commented on issue libreboot/libreboot#157

Proposal for Cleaning Paper Build Scripts

> Paul, I think ${VAR} is OK

7 years ago

PaulK opened issue libreboot/libreboot#161

Libreboot's relationship with Paper

7 years ago

PaulK commented on issue libreboot/libreboot#157

Proposal for Cleaning Paper Build Scripts

Andrew, it seems that we had rushed into the decision of this organization without fully understanding the implications of libreboot being a paper downstream version.

7 years ago

PaulK commented on issue libreboot/libreboot#157

Proposal for Cleaning Paper Build Scripts

> Paul, having a coding style for contributors to stick to isn't superfluous as you seem to imply; it's to keep the code from looking like a patchwork quilt when multiple contributors are working on the code, which makes it quite important.

7 years ago