Bug 95020

Created attachment 123054 [details]
SSH public key

Name, email and account name are provided in the GPG public key. Account name is  in parentheses.

Thanks.

Hi Zak,

In general commit access isn't given to people without a good patch history. Please work on that first - send your patches to the mailing list, get them reviewed/accepted.

Once things are looking good please reopen the bug and attach a valid gpg public key, visible in public key servers (like pgp.mit.edu). That way admins can set you up.

Thanks

(In reply to Emil Velikov from comment #3)
> Hi Zak,

I find it fascinating that https://www.freedesktop.org/wiki/AccountRequests/ is saying "You MUST include your real name" and you are unable to properly spell my real name.

> In general commit access isn't given to people without a good patch history.

This requirement isn't written on https://www.freedesktop.org/wiki/AccountRequests/. Your demand is therefore void.

> Please work on that first

Your request has been denied.

> - send your patches to the mailing list, get them reviewed/accepted.

They won't be accepted.

> Once things are looking good please reopen the bug and attach a valid gpg
> public key, visible in public key servers (like pgp.mit.edu).

https://www.freedesktop.org/wiki/AccountRequests/ is mentioning subkeys.pgp.net, not pgp.mit.edu, and it does not contain the text "for example subkeys.pgp.net". 

The wiki page overrides your recommendation.

> That way admins can set you up.

Which admin? Emol Velukov?

> Thanks

No.

Created attachment 123060 [details]
GPG public key (ASCII "armored")

The AccountRequests page describes the mechanics of how to sign up for a freedesktop.org account.  As Emil said, these aren't usually granted without a project lead granting you commit access to their repository.

freedesktop.org hosts gstreamer, libreoffice, pulseaudio, spice, telepathy, vaapi, wayland, xorg, and many others.  Each project has their own criteria for granting commit access.

For Mesa, this means participating on the mailing list (and ideally IRC), and sending and reviewing patches.  Once new contributors have established themselves as contributors, people are generally more than happy to provide commit access.  Many major free software projects work this way.

I don't understand the basis for saying "My patches will not be accepted" - it doesn't look like you've tried to submit any yet :)  So, how do you know?

Perhaps more to the point: why do you want an account?  What do you need it for?

(In reply to Emil Velikov from comment #3)
> In general commit access isn't given to people without a good patch history.
> Please work on that first - send your patches to the mailing list, get them
> reviewed/accepted.

Nanley Chery (nanleychery@gmail.com) obtained an account without prior submission of good patches:

https://bugs.freedesktop.org/show_bug.cgi?id=90457#c3

(In reply to Kenneth Graunke from comment #6)
> Perhaps more to the point: why do you want an account?  What do you need it
> for?

The only answer to that question would be in the form of C/C++ code.



A new "atomsymbol" branch in mesa-git could be created.

The code could be reviewed from there, using whatever tool the reviewer prefers to do so.

The code in the branch could be merged into mesa-git-master at any point in time you prefer.

(In reply to Jan Ziak from comment #4)
> (In reply to Emil Velikov from comment #3)
> > Hi Zak,
> 
> I find it fascinating that https://www.freedesktop.org/wiki/AccountRequests/
> is saying "You MUST include your real name" and you are unable to properly
> spell my real name.
> 
I'm not sure how that simple of a mistake can cause such issue. Note that some of us are dyslexic :-)

> > In general commit access isn't given to people without a good patch history.
> 
> This requirement isn't written on
> https://www.freedesktop.org/wiki/AccountRequests/. Your demand is therefore
> void.
> 
I don't demand anything. Just reiterating what was said by Brian Paul (the person who started the Mesa project) in bug#91783, bug#94194 and a few others.

> > Please work on that first
> 
> Your request has been denied.
> 
> > - send your patches to the mailing list, get them reviewed/accepted.
> 
> They won't be accepted.
> 
So if people feel so strongly against them, your goal is to override them and push directly ? I'm afraid that's not going to go nicely.

Then again please send some patches, people might like them quite a bit.

> > Once things are looking good please reopen the bug and attach a valid gpg
> > public key, visible in public key servers (like pgp.mit.edu).
> 
> https://www.freedesktop.org/wiki/AccountRequests/ is mentioning
> subkeys.pgp.net, not pgp.mit.edu, and it does not contain the text "for
> example subkeys.pgp.net". 
> 
> The wiki page overrides your recommendation.
> 
Check again ;-) Also, thanks for reminding me that we need to update it.

> > That way admins can set you up.
> 
> Which admin? Emol Velukov?
> 
This is the first time I've heard this permutations. Thanks it brought a smile on my face.

> > Thanks
> 
> No.

All if all you seem rather hostile and/or agitated. Not sure if that's due to my unintentional misspelling of your name. If so apologies, I never meant to offend.

If you just want to have an argument this might not be the best one.

(In reply to Kenneth Graunke from comment #6)
> I don't understand the basis for saying "My patches will not be accepted" -

I have a different style of thinking about code. I have a hunch it will cause some issues.

> it doesn't look like you've tried to submit any yet :)

Submitting patches indirectly through bugs.freedesktop.org is an unnecessary slowdown, in my opinion.

Why would I accept a slower way if there exists a faster way?

(In reply to Jan Ziak from comment #10)
> (In reply to Kenneth Graunke from comment #6)
> > I don't understand the basis for saying "My patches will not be accepted" -
> 
> I have a different style of thinking about code. I have a hunch it will
> cause some issues.
> 
> > it doesn't look like you've tried to submit any yet :)
> 
> Submitting patches indirectly through bugs.freedesktop.org is an unnecessary
> slowdown, in my opinion.
> 
> Why would I accept a slower way if there exists a faster way?

Note that patches are normally submitted and reviewed via the mesa-dev list.  Even for those who have fd.o accounts.

If you just need a git tree, there is github and various other git hosting sites..  fd.o is not a github.

(In reply to Jan Ziak from comment #4)
> (In reply to Emil Velikov from comment #3)
> > In general commit access isn't given to people without a good patch history.
> 
> This requirement isn't written on
> https://www.freedesktop.org/wiki/AccountRequests/. Your demand is therefore
> void.

It does mention that requests must be approved by the project. Part of Mesa's criteria for gaining access to be able to commit to the Mesa tree is that you have a good track record of contributions, in the form of patches which are accepted, and a willingness to work with the community.

This is part of building the trust required in order to have the privilege of being able to commit to a repository which is widely used and trusted within the open-source community.

> > - send your patches to the mailing list, get them reviewed/accepted.
> 
> They won't be accepted.

If you don't believe your patches will be accepted, then commit access to the repository is not going to further your goals.

Getting an account is part of the process of being able to commit code directly. In order to do so, the requirement is to proceed as a normal community member and build trust. If you are unwilling to do this, or do not wish to integrate your code but simply wish to host a separate external fork of code, there are many other hosting services such as GitHub, or thanks to Git's distributed nature, you can even host your own repository.

Created attachment 123210 [details]
attachment-24439-0.html

Just a note: I resolved the situation by Q1.A4 in
http://github.com/tul-project/tul/blob/0ebe302b0c0d8f81d50c5303506f95a96b353846/FAQ.md

Comment on attachment 123210 [details]
attachment-24439-0.html

><div dir="ltr"><div class="gmail_extra">Just a note: I resolved the situation by Q0.A4 in <a href="http://github.com/tul-project/tul/blob/0ebe302b0c0d8f81d50c5303506f95a96b353846/FAQ.md">http://github.com/tul-project/tul/blob/0ebe302b0c0d8f81d50c5303506f95a96b353846/FAQ.md</a></div></div>

The Mesa docs regarding getting a git account are out of date.  I'm posting update to the docs for review.