[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: [kde-community] Official KDE mirror on github
From:       Kevin Krammer <krammer () kde ! org>
Date:       2015-09-19 14:35:47
Message-ID: 25767046.DSsmzmSXh2 () persephone
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday, 2015-09-19, 16:26:04, Luigi Toscano wrote:
> Kevin Krammer ha scritto:
> > On Saturday, 2015-09-19, 12:29:31, Vishesh Handa wrote:
> >> On Sat, Sep 19, 2015 at 12:09 PM, Ivan Čukić <ivan.cukic@kde.org> wrote:
> >>> alternatives. Just as they do not have access to my personal inbox
> >>> 
> >>>> where much corresponse often happens, and patches are discussed.
> >>> 
> >>> Not sure that this is a statement you want to advertise, since it
> >>> implies that the development happens behind the closed doors. (yes, we
> >>> all do that sometimes, but is should not be a part of our workflow,
> >>> and not something we should be proud of)
> >>> 
> >>> Now, with GitHub, it would not be exactly 'development behind the
> >>> closed doors' but for a lot of us it would be basically the same. As
> >>> Martin mentioned, this would be hidden from his eyes since he has no
> >>> intention to follow development on GitHub.
> >> 
> >> Some development does happen behind closed doors. Someone sends me a
> >> patch, I commit it, and then point them towards reviewboard for the
> >> next time. Ditto with bugs actually. I get reports via IRC, emails,
> >> Google+ and even FB (once). If it is minor I act on it, if it isn't I
> >> point the user towards bugzilla or just file a bug myself so that I
> >> don't forget.
> > 
> > Right, this is also my understanding of what is proposed.
> > 
> > If you work on a project where you can push without review, it really
> > doesn't matter how you arrived at the commit, you would have pushed your
> > own version without review as well.
> > 
> > If you work on a project where you have to go through review, then again,
> > it really doesn't matter how the commit has been created, it is still
> > being reviewed.
> > The only difference is that the submitter of the review request is not the
> > author of the commit.
> 
> But that's not using the pull request. Such workflow would mean that the
> pull request is not accepted anyway, but the code is pushed through the
> infrastructure and not trough Github interface.

I though that a pull request was a way for one clone's owner to notify the 
main repo owner that the clone had a change they would like to propose for 
upstream.

The repo owner could then pull the clone at the given revision and then follow 
whatever workflow they would like to follow.

In a KDE project with mandatory review that would be uploading the change to 
reviewboard/gerrit/phabricator.

In a KDE project without mandatory review that could be uploading to KDE's 
review or pushing to the KDE git server.

> Just to be sure, question for Vishes, Albert Vaca, Jaroslaw: can you please
> explain exactly what is the meaning of "use Github"? Do we all agree that in
> any way pull requests will never be merged directly through Github
> interface?

What sense would that even make?
Then the mirror would have a different state than the repo it is mirroring.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]
[Attachment #6 (text/plain)]

_______________________________________________
kde-community mailing list
kde-community@kde.org
https://mail.kde.org/mailman/listinfo/kde-community

[prev in list] [next in list] [prev in thread] [next in thread]