based on our handbook [1]. I'd like to nominate Daniel for commit access to
the following repositories:
foreman-infra
foreman-installer
foreman-packaging ( to branch and cherry-pick to the release branch )
Daniel contributes to the project for a long time, also in this area [2][3][4]
and always has only the best intentions. He worked on 1.15 RC1 and I think
there's no reason why he shouldn't have access to places which are needed to
update during the release process.
Also I'd like to nominate him for the following.
access to deb.theforeman.org to change stable, clone repos, and
run freight cache
add tags and build targets in koji
access to koji.katello.org to copy the mash scripts and configuration
···
On Mon, Apr 24, 2017 at 2:59 PM, Marek Hulán wrote:
Hello devs,
based on our handbook [1]. I’d like to nominate Daniel for commit access to
the following repositories:
foreman-infra
foreman-installer
foreman-packaging ( to branch and cherry-pick to the release branch )
Daniel contributes to the project for a long time, also in this area
[2][3][4]
and always has only the best intentions. He worked on 1.15 RC1 and I think
there’s no reason why he shouldn’t have access to places which are needed
to
update during the release process.
Also I’d like to nominate him for the following.
access to deb.theforeman.org to change stable, clone repos, and
run freight cache
add tags and build targets in koji
access to koji.katello.org to copy the mash scripts and configuration
These repos all have active maintainers and so making a pull request (as
Daniel's done on two of them) is a better way to make changes. I don't
think commit access is necessary to submit updates to these repos and
shouldn't be encouraged here for Foreman releases.
Reviews have found a few issues, so I'd suggest continuing to submit
commits through pull requests.
···
On 24/04/17 12:59, Marek Hulán wrote:
> based on our handbook [1]. I'd like to nominate Daniel for commit access to
> the following repositories:
>
> - foreman-infra
> - foreman-installer
> - foreman-packaging ( to branch and cherry-pick to the release branch )
>
> Daniel contributes to the project for a long time, also in this area [2][3][4]
> and always has only the best intentions. He worked on 1.15 RC1 and I think
> there's no reason why he shouldn't have access to places which are needed to
> update during the release process.
> +1
>
>>
>> Hello devs,
>>
>> based on our handbook [1]. I'd like to nominate Daniel for commit access
>> to
>> the following repositories:
>>
>> - foreman-infra
>> - foreman-installer
>> - foreman-packaging ( to branch and cherry-pick to the release branch )
>>
>> Daniel contributes to the project for a long time, also in this area
>> [2][3][4]
>> and always has only the best intentions. He worked on 1.15 RC1 and I think
>> there's no reason why he shouldn't have access to places which are needed
>> to
>> update during the release process.
>>
>> Also I'd like to nominate him for the following.
>>
>> - access to deb.theforeman.org to change stable, clone repos, and
>> run freight cache
>> - add tags and build targets in koji
>> - access to koji.katello.org to copy the mash scripts and configuration
E-mail tmlcoch@redhat.com or jblazek@redhat.com to get Koji
certificates, and probably CC someone who already has Katello Koji
access so they can confirm? I don't see we have actual guidelines
about who should get access.
>> - access to downloads.theforeman.org to upload signed tarballs
>> - permission to set /topic on IRC
It would be really useful to have more people with access to IRC in
general. It's not frequent, but occasionally during non-emea hours
there's someone flooding the channel with join/quits or some other
behavior that might need an op to take care of. So +1 to Daniel but
it'd be nice if some people in North America had access too.
···
On Mon, Apr 24, 2017 at 8:47 AM, Tomer Brisker wrote:
> On Mon, Apr 24, 2017 at 2:59 PM, Marek Hulán wrote:
redmine permissions to modify fields http://projects.theforeman.org/
custom_fields/4/edit (I think administrator permission is required)
The process for getting this is not documented anywhere, but I think it’s
clear that Daniel would only use all of this to improve Foreman.
Please thumbs up in the thread. I’ll update the thread in one week in case
there were some private concerns.
On Mon, Apr 24, 2017 at 2:59 PM, Marek Hulán mhulan@redhat.com wrote:
Hello devs,
based on our handbook [1]. I’d like to nominate Daniel for commit access
to
the following repositories:
foreman-infra
foreman-installer
foreman-packaging ( to branch and cherry-pick to the release branch )
Daniel contributes to the project for a long time, also in this area
[2][3][4]
and always has only the best intentions. He worked on 1.15 RC1 and I
think
there’s no reason why he shouldn’t have access to places which are
needed
to
update during the release process.
Also I’d like to nominate him for the following.
access to deb.theforeman.org to change stable, clone repos, and
run freight cache
add tags and build targets in koji
access to koji.katello.org to copy the mash scripts and
configuration
E-mail tmlcoch@redhat.com or jblazek@redhat.com to get Koji
certificates, and probably CC someone who already has Katello Koji
access so they can confirm? I don’t see we have actual guidelines
about who should get access.
It would be really useful to have more people with access to IRC in
general. It’s not frequent, but occasionally during non-emea hours
there’s someone flooding the channel with join/quits or some other
behavior that might need an op to take care of. So +1 to Daniel but
it’d be nice if some people in North America had access too.
redmine permissions to modify fields http://projects.theforeman.org/
custom_fields/4/edit (I think administrator permission is required)
The process for getting this is not documented anywhere, but I think
it’s
clear that Daniel would only use all of this to improve Foreman.
Please thumbs up in the thread. I’ll update the thread in one week in
case
there were some private concerns.
> > based on our handbook [1]. I'd like to nominate Daniel for commit access
> > to
> >
> > the following repositories:
> > - foreman-infra
> > - foreman-installer
> > - foreman-packaging ( to branch and cherry-pick to the release branch )
> >
> > Daniel contributes to the project for a long time, also in this area
> > [2][3][4] and always has only the best intentions. He worked on 1.15 RC1
> > and I think there's no reason why he shouldn't have access to places
> > which are needed to update during the release process.
>
> These repos all have active maintainers and so making a pull request (as
> Daniel's done on two of them) is a better way to make changes. I don't
> think commit access is necessary to submit updates to these repos and
> shouldn't be encouraged here for Foreman releases.
I'm happy to hear that there are active maintainers. I'm not sure whether you
suggest that it is the reason why commit access should not be granted? I think
the more active committers the better. Doing this through PR is fine and as
you say, it can find issues. But if other devs send PRs, I think it makes
sense if Daniel can merge them. Commit access is also required to create
branches and tags which I don't think needs any form of reviewing.
I'm sorry if it seemed like I'm encouraging pushing commits directly without
PR during release process. That was not subject of this nomination.
> Reviews have found a few issues, so I'd suggest continuing to submit
> commits through pull requests.
I'm not sure how it worked for previous releases but I think that it should
not change and PRs are preferred way unless there's direct commit required in
rare situations. IMHO that does not change by Daniel becoming a committer.
···
On úterý 25. dubna 2017 9:19:40 CEST Dominic Cleal wrote:
> On 24/04/17 12:59, Marek Hulán wrote:
> +1, see other comments below
>
>
> > +1
> >
> >>
> >> Hello devs,
> >>
> >> based on our handbook [1]. I'd like to nominate Daniel for commit access
> >> to
> >> the following repositories:
> >>
> >> - foreman-infra
> >> - foreman-installer
> >> - foreman-packaging ( to branch and cherry-pick to the release branch )
> >>
> >> Daniel contributes to the project for a long time, also in this area
> >> [2][3][4]
> >> and always has only the best intentions. He worked on 1.15 RC1 and I think
> >> there's no reason why he shouldn't have access to places which are needed
> >> to
> >> update during the release process.
> >>
> >> Also I'd like to nominate him for the following.
> >>
> >> - access to deb.theforeman.org to change stable, clone repos, and
> >> run freight cache
> >> - add tags and build targets in koji
> >> - access to koji.katello.org to copy the mash scripts and configuration
>
> See: http://projects.theforeman.org/projects/foreman/wiki/Koji
>
> E-mail tmlcoch@redhat.com or jblazek@redhat.com to get Koji
> certificates, and probably CC someone who already has Katello Koji
> access so they can confirm? I don't see we have actual guidelines
> about who should get access.
I have access to add tags and build targets now in Koji (jsherril gave
me that IIRC). I don't have SSH access to the koji host, however. This
makes me have to ask people to do the steps here (I think only ehelms,
mcccune, jsherril & domcleal) have access to do it.
> >> - access to downloads.theforeman.org to upload signed tarballs
> >> - permission to set /topic on IRC
>
> It would be really useful to have more people with access to IRC in
> general. It's not frequent, but occasionally during non-emea hours
> there's someone flooding the channel with join/quits or some other
> behavior that might need an op to take care of. So +1 to Daniel but
> it'd be nice if some people in North America had access too.
The /topic permission (not sure if something so granular is
possible to grant) would be helpful to announce releases
···
On 04/24, Stephen Benjamin wrote:
> On Mon, Apr 24, 2017 at 8:47 AM, Tomer Brisker wrote:
> > On Mon, Apr 24, 2017 at 2:59 PM, Marek Hulán wrote:
redmine permissions to modify fields http://projects.theforeman.org/
custom_fields/4/edit (I think administrator permission is required)
The process for getting this is not documented anywhere, but I think it’s
clear that Daniel would only use all of this to improve Foreman.
Please thumbs up in the thread. I’ll update the thread in one week in case
there were some private concerns.
OK, sorry, that's what I thought you were suggesting. In that case, I
don't think Daniel's had much involvement with the foreman-infra or
foreman-installer projects to warrant commit access. He's opened a lot
of PRs against foreman-packaging, but I'd want to see fewer common
errors in recent PRs before seconding him for commit access.
···
On 25/04/17 12:45, Marek Hulán wrote:
> On úterý 25. dubna 2017 9:19:40 CEST Dominic Cleal wrote:
>> On 24/04/17 12:59, Marek Hulán wrote:
>>> based on our handbook [1]. I'd like to nominate Daniel for commit access
>>> to
>>>
>>> the following repositories:
>>> - foreman-infra
>>> - foreman-installer
>>> - foreman-packaging ( to branch and cherry-pick to the release branch )
>>>
>>> Daniel contributes to the project for a long time, also in this area
>>> [2][3][4] and always has only the best intentions. He worked on 1.15 RC1
>>> and I think there's no reason why he shouldn't have access to places
>>> which are needed to update during the release process.
>> These repos all have active maintainers and so making a pull request (as
>> Daniel's done on two of them) is a better way to make changes. I don't
>> think commit access is necessary to submit updates to these repos and
>> shouldn't be encouraged here for Foreman releases.
> I'm happy to hear that there are active maintainers. I'm not sure whether you
> suggest that it is the reason why commit access should not be granted? I think
> the more active committers the better. Doing this through PR is fine and as
> you say, it can find issues. But if other devs send PRs, I think it makes
> sense if Daniel can merge them. Commit access is also required to create
> branches and tags which I don't think needs any form of reviewing.
>
> I'm sorry if it seemed like I'm encouraging pushing commits directly without
> PR during release process. That was not subject of this nomination.
> >>> based on our handbook [1]. I'd like to nominate Daniel for commit access
> >>> to
> >>>
> >>> the following repositories:
> >>> - foreman-infra
> >>> - foreman-installer
> >>> - foreman-packaging ( to branch and cherry-pick to the release branch )
> >>>
> >>> Daniel contributes to the project for a long time, also in this area
> >>> [2][3][4] and always has only the best intentions. He worked on 1.15 RC1
> >>> and I think there's no reason why he shouldn't have access to places
> >>> which are needed to update during the release process.
> >> These repos all have active maintainers and so making a pull request (as
> >> Daniel's done on two of them) is a better way to make changes. I don't
> >> think commit access is necessary to submit updates to these repos and
> >> shouldn't be encouraged here for Foreman releases.
> > I'm happy to hear that there are active maintainers. I'm not sure whether you
> > suggest that it is the reason why commit access should not be granted? I think
> > the more active committers the better. Doing this through PR is fine and as
> > you say, it can find issues. But if other devs send PRs, I think it makes
> > sense if Daniel can merge them. Commit access is also required to create
> > branches and tags which I don't think needs any form of reviewing.
> >
> > I'm sorry if it seemed like I'm encouraging pushing commits directly without
> > PR during release process. That was not subject of this nomination.
>
> OK, sorry, that's what I thought you were suggesting. In that case, I
> don't think Daniel's had much involvement with the foreman-infra or
> foreman-installer projects to warrant commit access. He's opened a lot
> of PRs against foreman-packaging, but I'd want to see fewer common
> errors in recent PRs before seconding him for commit access.
It's true I've made sloppy mistakes on -packaging (especially recently).
I'm happy to pay more attention on future PRs to avoid having other
people (mostly you… though :/) have to double-check carefully my PRs.
For -infra I don't really need commit access, however you're the only
active maintainer, which is not an ideal situation in case something
needs to be done during holidays etc…
About -installer, I don't mean to update anything there, except for
tagging stuff for the releases. I'm not sure if there's a way to give
permission to just branch and tag but not commit to the develop branch.
···
On 04/26, Dominic Cleal wrote:
> On 25/04/17 12:45, Marek Hulán wrote:
> > On úterý 25. dubna 2017 9:19:40 CEST Dominic Cleal wrote:
> >> On 24/04/17 12:59, Marek Hulán wrote:
