You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2016/10/21 09:09:31 UTC
Git "temp" repository requested (was: Jenkins & Git @apache...)
Hi,
On Fri, Oct 21, 2016 at 10:49 AM, Geertjan Wielenga
<ge...@googlemail.com> wrote:
> ...where are the instructions needed for requesting or
> setting up a Git repo?...
I suppose you need to be a member of the Incubator PMC to use
https://reporeq.apache.org/ so mentors can do it.
I did just that, requesting the following repository:
incubator-netbeans-temp
Apache NetBeans (incubating) temporary repository
commits notifications to commits@netbeans.incubator.apache.org
Mirror to GitHub
Enable GitHub integrations
GitHub notifcations to dev@netbeans.incubator.apache.org
That should soon appear at
https://git-wip-us.apache.org/repos/asf/incubator-netbeans-temp.git -
within an hour says that form.
And then also under https://github.com/apache/
I suppose people listed as committers on "incubator" at
http://people.apache.org/phonebook.html should have write access, if
not ask mentors to fix it. I'll be offline for some time myself, might
not be able to help right away.
-Bertrand
Re: README & commit workflow was: Git "temp" repository requested
Posted by Wade Chandler <co...@wadechandler.com>.
> On Oct 22, 2016, at 12:31, Wade Chandler <co...@wadechandler.com> wrote:
>
> I’m not even sure if that is possible with GH (GitHub).
>
>
I mention this because even if we have infrastructure within ASF, aren’t GH mirrors 2 way streets where things can be merged to a master branch on GH and vice versa? i.e. we couldn’t exactly keep the master branch from getting changes over on GH, and then trying to sync up/fix issues, when that happens could be a PITA if hooks are some where else, and too, we probably definitely want to use GH mirrors as that is where we’d want to work as well as have visibility for others; popularity etc.
Wade
===================
Wade Chandler
e: consult@wadechandler.com
Re: README & commit workflow was: Git "temp" repository requested
Posted by Wade Chandler <co...@wadechandler.com>.
Generally in full on open processes it isn't exactly "locked down", but instead there is a methodology followed by all to commit to some personal branch, then use PRs to get to some develop/development branch, where automation takes over, and then merge to master in some way. Things can go directly and automatically from develop to master based on the automation, and we all agree not to work directly against develop/development unless it is to fix something simple for a broken build with all changes and features coming through PRs (whether from other repos or feature branches). Sometimes there is a need to touch master too, if something has gotten out of sync or broken, and here, all committers need to be able to fix things don’t they?
Are you thinking there needs to be some server side rule/hook that doesn't allow merging nor pushing to master at all? Most open github repositories aren’t exactly setup that way for committers; I’m not even sure if that is possible with GH.
http://stackoverflow.com/questions/10864903/does-github-allow-pre-receive-hooks <http://stackoverflow.com/questions/10864903/does-github-allow-pre-receive-hooks>
https://guides.github.com/introduction/flow/ <https://guides.github.com/introduction/flow/>
I’m not sure I agree with their version of “tested in production” from that last link, as that seems odd to me in various contexts other than full on CD versus CI, but some version of the gitflow seems legit for Apache NetBeans IMO.
Wade
On Oct 22, 2016 10:21 AM, "Jaroslav Tulach" <jaroslav.tulach@gmail.com <ma...@gmail.com>> wrote:
Hi,
I also made my first commit and described the setup steps in README:
https://git-wip-us.apache.org/repos/asf?p=incubator-netbeans-temp.git;a=commitdiff;h=9fbda90b2430a3a7cedbe7f855eb4cb9398e4513 <https://git-wip-us.apache.org/repos/asf?p=incubator-netbeans-temp.git;a=commitdiff;h=9fbda90b2430a3a7cedbe7f855eb4cb9398e4513>
However I don't think this is the workflow we want to use. Nobody should have
write access to the master branch, I assume. Each change should go in through
a GitHub-like Pull Request and only when the change passes all tests and is
approved, it should (automatically) be merged into the master branch.
OracleLabs teams use this workflow now when working on Graal and Truffle
repositories and I found the process great.
Is this the working style we want to use too? How does one realize it in
Apache infrastructure?
-jt
Re: README & commit workflow was: Git "temp" repository requested
Posted by Wade Chandler <co...@wadechandler.com>.
I don't see it as a way to keep people on the skirts. Any committer can
merge, but it allows for a review process by peers. In the case of
non-committers it becomes an easy reviewable way to pull in contributions
as well as communicate and review, and is necessarily heavier than
committer to committer. PRs can be denied too if not up to snuff (by
committers), but hopefully rare. It also makes a nice visible and packaged
trail.
We use PRs for commercial teams, and private repos, and it works out really
well. Sometimes due to time, the reviewers are the coders, which would be
the case for committers at times, so definitely more trust, but the norm is
to ask for a review, and to work up a feature in a branch or repo. This
allows backups of ongoing work, things not to be merged in until they are a
full idea, and a generally manageable process around it which to date has
been pretty fluid for various sized teams. So, all IMO, but based off years
of experience with the model.
Wade
On Oct 24, 2016 3:50 AM, "Emilian Bold" <em...@gmail.com> wrote:
I don't mind this as long as we use lazy consensus and any committer is
allowed to do a PR merge after a voting window.
But, we vote on committers because they get new rights. Obviously people
should treat this responsibly.
What I'm wondering is if you just want to fix some bugs or add some new
features -- why bother becoming a committer? Just do a PR from your own
GitHub fork. So this style also seems like a way to keep people on the
skirts of the community.
--emi
On Mon, Oct 24, 2016 at 3:41 AM, Wade Chandler <co...@wadechandler.com>
wrote:
> These processes are used all over OSS projects in GH and Bitbucket.
> Googling for them yields many results. One of my emails linked to the main
> GitHub page. See Ate's email on another thread for a link to how other
> Apache projects are using them. Development doesn't come to any form of a
> standstill in my experience, but rather is pretty fluid. If nothing else
it
> gives clear units of work, even if the reviewers are the coders, and
leaves
> a PR in a merged state which can even retrospectively be reviewed if
> needed.
>
> Wade
>
> On Oct 23, 2016 1:54 AM, "Emilian Bold" <em...@gmail.com> wrote:
>
> > You don't need to be a committer to do a PR. Development will come to a
> > standstill if all the main committers would have to go through this.
> >
> > Seems to me that if you trust somebody to vote her to be a committer you
> > trust her to actually commit code without being vetted by someone else.
> >
> > I know about the team repositories, main-golden and main-silver, the
> > releases/ repository with the version branches, the tags, etc.
> >
> > But now that I think about it, I kind of learned it in time, I haven't
> read
> > it all in one place.
> >
> > This workflow certainly is documented somewhere. Could we see it?
> >
> > Then we can judge if the Apache infra and usual processes are a good
> match.
> >
> >
> >
> >
> >
> > --emi
> >
> > On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler <consult@wadechandler.com
> >
> > wrote:
> >
> > > >
> > > > On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com>
> > wrote:
> > > >
> > > > I also wouldn't mind if we use code reviews.
> > > >
> > > > But code reviews don't make sense for every NetBeans commit.
> > > >
> > > > By definition a committer will not need approval to commit code.
> > >
> > > To me this is more of a community agreement, but one I’m in favor of.
> The
> > > projects I work on in both GH and Bitbucket use PRs, and that process
> > works
> > > out really well. I think it is fair that even committers come through
a
> > PR,
> > > and get a review. We should be able to find at least “1” other person
> > for a
> > > review. Otherwise what processes are we doing to use? There are going
> to
> > be
> > > N number of orgs and individuals coalescing here.
> > >
> > > Every commit doesn’t go through a PR either btw, but instead it is
> based
> > > on a feature branch, and thus it could be 1-N commits in a given PR.
> > > Personally I think the only direct “develop” or “development” branch
> > > commits should be to fix a broken build, if it is a couple lines, but
> > > otherwise, using PRs keeps things sane, and too, gives a nice historic
> > > record of sets of changes grouped as wholes, and that “whole” of a set
> of
> > > work is what is reviewed in a PR.
> > >
> > > Wade
> > >
> > > ===================
> > >
> > > Wade Chandler
> > > e: consult@wadechandler.com
> > >
> > >
> >
>
Re: README & commit workflow was: Git "temp" repository requested
Posted by Emilian Bold <em...@gmail.com>.
I don't mind this as long as we use lazy consensus and any committer is
allowed to do a PR merge after a voting window.
But, we vote on committers because they get new rights. Obviously people
should treat this responsibly.
What I'm wondering is if you just want to fix some bugs or add some new
features -- why bother becoming a committer? Just do a PR from your own
GitHub fork. So this style also seems like a way to keep people on the
skirts of the community.
--emi
On Mon, Oct 24, 2016 at 3:41 AM, Wade Chandler <co...@wadechandler.com>
wrote:
> These processes are used all over OSS projects in GH and Bitbucket.
> Googling for them yields many results. One of my emails linked to the main
> GitHub page. See Ate's email on another thread for a link to how other
> Apache projects are using them. Development doesn't come to any form of a
> standstill in my experience, but rather is pretty fluid. If nothing else it
> gives clear units of work, even if the reviewers are the coders, and leaves
> a PR in a merged state which can even retrospectively be reviewed if
> needed.
>
> Wade
>
> On Oct 23, 2016 1:54 AM, "Emilian Bold" <em...@gmail.com> wrote:
>
> > You don't need to be a committer to do a PR. Development will come to a
> > standstill if all the main committers would have to go through this.
> >
> > Seems to me that if you trust somebody to vote her to be a committer you
> > trust her to actually commit code without being vetted by someone else.
> >
> > I know about the team repositories, main-golden and main-silver, the
> > releases/ repository with the version branches, the tags, etc.
> >
> > But now that I think about it, I kind of learned it in time, I haven't
> read
> > it all in one place.
> >
> > This workflow certainly is documented somewhere. Could we see it?
> >
> > Then we can judge if the Apache infra and usual processes are a good
> match.
> >
> >
> >
> >
> >
> > --emi
> >
> > On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler <consult@wadechandler.com
> >
> > wrote:
> >
> > > >
> > > > On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com>
> > wrote:
> > > >
> > > > I also wouldn't mind if we use code reviews.
> > > >
> > > > But code reviews don't make sense for every NetBeans commit.
> > > >
> > > > By definition a committer will not need approval to commit code.
> > >
> > > To me this is more of a community agreement, but one I’m in favor of.
> The
> > > projects I work on in both GH and Bitbucket use PRs, and that process
> > works
> > > out really well. I think it is fair that even committers come through a
> > PR,
> > > and get a review. We should be able to find at least “1” other person
> > for a
> > > review. Otherwise what processes are we doing to use? There are going
> to
> > be
> > > N number of orgs and individuals coalescing here.
> > >
> > > Every commit doesn’t go through a PR either btw, but instead it is
> based
> > > on a feature branch, and thus it could be 1-N commits in a given PR.
> > > Personally I think the only direct “develop” or “development” branch
> > > commits should be to fix a broken build, if it is a couple lines, but
> > > otherwise, using PRs keeps things sane, and too, gives a nice historic
> > > record of sets of changes grouped as wholes, and that “whole” of a set
> of
> > > work is what is reviewed in a PR.
> > >
> > > Wade
> > >
> > > ===================
> > >
> > > Wade Chandler
> > > e: consult@wadechandler.com
> > >
> > >
> >
>
Re: README & commit workflow was: Git "temp" repository requested
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Indeed, we need to bring these email discussions to the surface, i.e.,
please create proposals on the Wiki within the one below.
https://cwiki.apache.org/confluence/display/NETBEANS/Apache+Transition
Gj
On Tue, Oct 25, 2016 at 5:16 AM, Wade Chandler <co...@wadechandler.com>
wrote:
> For me it is about the solid unit of work, not so much the tests, but they
> are a required piece of good development. Why keep so much locally until it
> is a full unit or commit a lot of less than finished yet testable thoughts?
> Many features take more than a day if not your day job.
>
> Too, it gives you the individual good visibility into the changes. It also
> makes working with another easy. The process is simple as well. I think
> probably where people get crazy is the squashing locally and not merging
> from the PR. The PR has a beginning and end hash code; a set. So, if it
> needs pulled out, it is able to be done, and it reduces some of the
> ceremony, but too, GitHub has solved the squashing problem I believe.
>
> https://github.com/blog/2141-squash-your-commits
>
> Either way, sure, the more process the more time, but a bunch of little
> commits to development or master with 2℅-N℅ baked ideas isn't great either
> IMO. At least using PRs, a full thought is baked into the merges, and to me
> is the benefit.
>
> NB dev had always used reviews where API changes are involved, so to me
> that part isn't new, but how branching is used as well as logical units
> being fully merged would be. They had team branches/repos before, and was
> essentially to limit collision. The same benefits come from feature
> branching and PRs, and is scalable to the whole community.
>
> My proposal would be to use PRs for everything, feature branches for
> committers, clones for non-committers, reviews happen there, as well as
> non-committers contributions, squash if desired, but let GitHub do it for
> you on PR merge, and then automation and test builds on development/develop
> (where work happens), with master getting auto merged based on automation
> results. Committers should be responsible enough to have already ran their
> tests before asking for PR review and merges, and of course committers
> should run tests from non-committers PRs to make sure things pass a sniff
> test as well as review expected tests exist.
>
> That matches a lot of various git flows out there.
>
> The release cycle, how we tag, etc needs hashed too.
>
> On that, I propose the dailies come from master, as a usable build, like
> the current main-golden, and then RCs are based on dailies which reach a
> point of maturity. During the release hardening phase, no new features or
> contributions are merged to development, but bug fixes etc are, a merge
> freeze for some things, we harden, vote on the release, tag, release, and
> roll it out. The merge freeze is released, and life continues on.
>
> That means the major branches are simply develop and master. There wouldn't
> be release branches with some merge freezing, the hardening and releasing
> would happen through the normal flow on develop and master respectively.
>
> We don't currently support multiple previous major release versions of the
> IDE or platform, so I think that suits it well. When we don't bump the
> major version, NB is rolling release capable per the update center. That
> model also suits that well.
>
> Hopefully that sets things up process wise for faster and smaller releases
> to get contributions into users (and contributors) hands sooner. Long
> release cycles make it hard to get good return on investment for committers
> without using dailies; which to me also favors feature branching and PRs
> for more fully baked merges. Which may not always be a bad thing, but
> probably not for users.
>
> I do wonder on the versioning however. Previously the major version bumped
> arbitrarily based on the Java version. Is that a strategy to keep, and why?
> On one hand, it has some cadence and nice tie into the Java ecosystem, but
> on the other, NB is a great IDE for other tech.
>
> I think there are a few topics here. Each one I think needs some discussion
> and voting. Do wiki documents facilitate comparing proposals for process,
> or should we use email?
>
> I see:
> 1. Git workflow
> 2. Continuous Integration and Daily builds
> 3. Release cycle management
> 4. Release cycle time
> 5. Release versioning
>
> If we setup some pages, then we can add proposals which can be compared,
> and commented on in the wiki. Those can be referenced for voting. Maybe
> these pages are already on the NB wiki, I haven't looked in a few days (day
> job has been slammed).
>
> Opinions?
>
> Thanks
>
> Wade
>
> On Oct 24, 2016 4:20 PM, "Mark Struberg" <st...@yahoo.de.invalid>
> wrote:
>
> > I’ve seen this being used in a very productive way utilizing Gerrit. But
> > apart from that it’s too error prone imo. What is the benefit of having a
> > temp branch which needs to get CI-ed + pulled over to master from just
> > running the tests locally?
> > Ofc I assume that most of the tests run in a decently well performing way
> > so everybody first runs the local tests before she commits. In most ASF
> > projects we use CTR (commit, then review) and people ship patches or push
> > their changes to github and send a mail to the list if they do changes
> > where they have a feeling that it might break something. Or if they just
> > need some feedback before they commit it.
> > Of course, each project has different requirements and maturity level.
> And
> > I know that there is currently probably only a hand full of people who
> can
> > judge whether a NetBeans commit is good or no - but this exactly what you
> > like to change, isn’t?
> > So in practice it really works well without any technical restrictions.
> > This is of course just my personal opinion without any impact on what you
> > going to pick.
> >
> > LieGrue,
> > strub
> >
> > > Am 24.10.2016 um 02:41 schrieb Wade Chandler <consult@wadechandler.com
> >:
> > >
> > > These processes are used all over OSS projects in GH and Bitbucket.
> > > Googling for them yields many results. One of my emails linked to the
> > main
> > > GitHub page. See Ate's email on another thread for a link to how other
> > > Apache projects are using them. Development doesn't come to any form
> of a
> > > standstill in my experience, but rather is pretty fluid. If nothing
> else
> > it
> > > gives clear units of work, even if the reviewers are the coders, and
> > leaves
> > > a PR in a merged state which can even retrospectively be reviewed if
> > needed.
> > >
> > > Wade
> > >
> > > On Oct 23, 2016 1:54 AM, "Emilian Bold" <em...@gmail.com>
> wrote:
> > >
> > >> You don't need to be a committer to do a PR. Development will come to
> a
> > >> standstill if all the main committers would have to go through this.
> > >>
> > >> Seems to me that if you trust somebody to vote her to be a committer
> you
> > >> trust her to actually commit code without being vetted by someone
> else.
> > >>
> > >> I know about the team repositories, main-golden and main-silver, the
> > >> releases/ repository with the version branches, the tags, etc.
> > >>
> > >> But now that I think about it, I kind of learned it in time, I haven't
> > read
> > >> it all in one place.
> > >>
> > >> This workflow certainly is documented somewhere. Could we see it?
> > >>
> > >> Then we can judge if the Apache infra and usual processes are a good
> > match.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> --emi
> > >>
> > >> On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler <
> > consult@wadechandler.com>
> > >> wrote:
> > >>
> > >>>>
> > >>>> On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com>
> > >> wrote:
> > >>>>
> > >>>> I also wouldn't mind if we use code reviews.
> > >>>>
> > >>>> But code reviews don't make sense for every NetBeans commit.
> > >>>>
> > >>>> By definition a committer will not need approval to commit code.
> > >>>
> > >>> To me this is more of a community agreement, but one I’m in favor of.
> > The
> > >>> projects I work on in both GH and Bitbucket use PRs, and that process
> > >> works
> > >>> out really well. I think it is fair that even committers come
> through a
> > >> PR,
> > >>> and get a review. We should be able to find at least “1” other person
> > >> for a
> > >>> review. Otherwise what processes are we doing to use? There are going
> > to
> > >> be
> > >>> N number of orgs and individuals coalescing here.
> > >>>
> > >>> Every commit doesn’t go through a PR either btw, but instead it is
> > based
> > >>> on a feature branch, and thus it could be 1-N commits in a given PR.
> > >>> Personally I think the only direct “develop” or “development” branch
> > >>> commits should be to fix a broken build, if it is a couple lines, but
> > >>> otherwise, using PRs keeps things sane, and too, gives a nice
> historic
> > >>> record of sets of changes grouped as wholes, and that “whole” of a
> set
> > of
> > >>> work is what is reviewed in a PR.
> > >>>
> > >>> Wade
> > >>>
> > >>> ===================
> > >>>
> > >>> Wade Chandler
> > >>> e: consult@wadechandler.com
> > >>>
> > >>>
> > >>
> >
> >
>
Re: README & commit workflow was: Git "temp" repository requested
Posted by Wade Chandler <co...@wadechandler.com>.
For me it is about the solid unit of work, not so much the tests, but they
are a required piece of good development. Why keep so much locally until it
is a full unit or commit a lot of less than finished yet testable thoughts?
Many features take more than a day if not your day job.
Too, it gives you the individual good visibility into the changes. It also
makes working with another easy. The process is simple as well. I think
probably where people get crazy is the squashing locally and not merging
from the PR. The PR has a beginning and end hash code; a set. So, if it
needs pulled out, it is able to be done, and it reduces some of the
ceremony, but too, GitHub has solved the squashing problem I believe.
https://github.com/blog/2141-squash-your-commits
Either way, sure, the more process the more time, but a bunch of little
commits to development or master with 2℅-N℅ baked ideas isn't great either
IMO. At least using PRs, a full thought is baked into the merges, and to me
is the benefit.
NB dev had always used reviews where API changes are involved, so to me
that part isn't new, but how branching is used as well as logical units
being fully merged would be. They had team branches/repos before, and was
essentially to limit collision. The same benefits come from feature
branching and PRs, and is scalable to the whole community.
My proposal would be to use PRs for everything, feature branches for
committers, clones for non-committers, reviews happen there, as well as
non-committers contributions, squash if desired, but let GitHub do it for
you on PR merge, and then automation and test builds on development/develop
(where work happens), with master getting auto merged based on automation
results. Committers should be responsible enough to have already ran their
tests before asking for PR review and merges, and of course committers
should run tests from non-committers PRs to make sure things pass a sniff
test as well as review expected tests exist.
That matches a lot of various git flows out there.
The release cycle, how we tag, etc needs hashed too.
On that, I propose the dailies come from master, as a usable build, like
the current main-golden, and then RCs are based on dailies which reach a
point of maturity. During the release hardening phase, no new features or
contributions are merged to development, but bug fixes etc are, a merge
freeze for some things, we harden, vote on the release, tag, release, and
roll it out. The merge freeze is released, and life continues on.
That means the major branches are simply develop and master. There wouldn't
be release branches with some merge freezing, the hardening and releasing
would happen through the normal flow on develop and master respectively.
We don't currently support multiple previous major release versions of the
IDE or platform, so I think that suits it well. When we don't bump the
major version, NB is rolling release capable per the update center. That
model also suits that well.
Hopefully that sets things up process wise for faster and smaller releases
to get contributions into users (and contributors) hands sooner. Long
release cycles make it hard to get good return on investment for committers
without using dailies; which to me also favors feature branching and PRs
for more fully baked merges. Which may not always be a bad thing, but
probably not for users.
I do wonder on the versioning however. Previously the major version bumped
arbitrarily based on the Java version. Is that a strategy to keep, and why?
On one hand, it has some cadence and nice tie into the Java ecosystem, but
on the other, NB is a great IDE for other tech.
I think there are a few topics here. Each one I think needs some discussion
and voting. Do wiki documents facilitate comparing proposals for process,
or should we use email?
I see:
1. Git workflow
2. Continuous Integration and Daily builds
3. Release cycle management
4. Release cycle time
5. Release versioning
If we setup some pages, then we can add proposals which can be compared,
and commented on in the wiki. Those can be referenced for voting. Maybe
these pages are already on the NB wiki, I haven't looked in a few days (day
job has been slammed).
Opinions?
Thanks
Wade
On Oct 24, 2016 4:20 PM, "Mark Struberg" <st...@yahoo.de.invalid> wrote:
> I’ve seen this being used in a very productive way utilizing Gerrit. But
> apart from that it’s too error prone imo. What is the benefit of having a
> temp branch which needs to get CI-ed + pulled over to master from just
> running the tests locally?
> Ofc I assume that most of the tests run in a decently well performing way
> so everybody first runs the local tests before she commits. In most ASF
> projects we use CTR (commit, then review) and people ship patches or push
> their changes to github and send a mail to the list if they do changes
> where they have a feeling that it might break something. Or if they just
> need some feedback before they commit it.
> Of course, each project has different requirements and maturity level. And
> I know that there is currently probably only a hand full of people who can
> judge whether a NetBeans commit is good or no - but this exactly what you
> like to change, isn’t?
> So in practice it really works well without any technical restrictions.
> This is of course just my personal opinion without any impact on what you
> going to pick.
>
> LieGrue,
> strub
>
> > Am 24.10.2016 um 02:41 schrieb Wade Chandler <co...@wadechandler.com>:
> >
> > These processes are used all over OSS projects in GH and Bitbucket.
> > Googling for them yields many results. One of my emails linked to the
> main
> > GitHub page. See Ate's email on another thread for a link to how other
> > Apache projects are using them. Development doesn't come to any form of a
> > standstill in my experience, but rather is pretty fluid. If nothing else
> it
> > gives clear units of work, even if the reviewers are the coders, and
> leaves
> > a PR in a merged state which can even retrospectively be reviewed if
> needed.
> >
> > Wade
> >
> > On Oct 23, 2016 1:54 AM, "Emilian Bold" <em...@gmail.com> wrote:
> >
> >> You don't need to be a committer to do a PR. Development will come to a
> >> standstill if all the main committers would have to go through this.
> >>
> >> Seems to me that if you trust somebody to vote her to be a committer you
> >> trust her to actually commit code without being vetted by someone else.
> >>
> >> I know about the team repositories, main-golden and main-silver, the
> >> releases/ repository with the version branches, the tags, etc.
> >>
> >> But now that I think about it, I kind of learned it in time, I haven't
> read
> >> it all in one place.
> >>
> >> This workflow certainly is documented somewhere. Could we see it?
> >>
> >> Then we can judge if the Apache infra and usual processes are a good
> match.
> >>
> >>
> >>
> >>
> >>
> >> --emi
> >>
> >> On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler <
> consult@wadechandler.com>
> >> wrote:
> >>
> >>>>
> >>>> On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com>
> >> wrote:
> >>>>
> >>>> I also wouldn't mind if we use code reviews.
> >>>>
> >>>> But code reviews don't make sense for every NetBeans commit.
> >>>>
> >>>> By definition a committer will not need approval to commit code.
> >>>
> >>> To me this is more of a community agreement, but one I’m in favor of.
> The
> >>> projects I work on in both GH and Bitbucket use PRs, and that process
> >> works
> >>> out really well. I think it is fair that even committers come through a
> >> PR,
> >>> and get a review. We should be able to find at least “1” other person
> >> for a
> >>> review. Otherwise what processes are we doing to use? There are going
> to
> >> be
> >>> N number of orgs and individuals coalescing here.
> >>>
> >>> Every commit doesn’t go through a PR either btw, but instead it is
> based
> >>> on a feature branch, and thus it could be 1-N commits in a given PR.
> >>> Personally I think the only direct “develop” or “development” branch
> >>> commits should be to fix a broken build, if it is a couple lines, but
> >>> otherwise, using PRs keeps things sane, and too, gives a nice historic
> >>> record of sets of changes grouped as wholes, and that “whole” of a set
> of
> >>> work is what is reviewed in a PR.
> >>>
> >>> Wade
> >>>
> >>> ===================
> >>>
> >>> Wade Chandler
> >>> e: consult@wadechandler.com
> >>>
> >>>
> >>
>
>
Re: README & commit workflow was: Git "temp" repository requested
Posted by Mark Struberg <st...@yahoo.de.INVALID>.
I’ve seen this being used in a very productive way utilizing Gerrit. But apart from that it’s too error prone imo. What is the benefit of having a temp branch which needs to get CI-ed + pulled over to master from just running the tests locally?
Ofc I assume that most of the tests run in a decently well performing way so everybody first runs the local tests before she commits. In most ASF projects we use CTR (commit, then review) and people ship patches or push their changes to github and send a mail to the list if they do changes where they have a feeling that it might break something. Or if they just need some feedback before they commit it.
Of course, each project has different requirements and maturity level. And I know that there is currently probably only a hand full of people who can judge whether a NetBeans commit is good or no - but this exactly what you like to change, isn’t?
So in practice it really works well without any technical restrictions.
This is of course just my personal opinion without any impact on what you going to pick.
LieGrue,
strub
> Am 24.10.2016 um 02:41 schrieb Wade Chandler <co...@wadechandler.com>:
>
> These processes are used all over OSS projects in GH and Bitbucket.
> Googling for them yields many results. One of my emails linked to the main
> GitHub page. See Ate's email on another thread for a link to how other
> Apache projects are using them. Development doesn't come to any form of a
> standstill in my experience, but rather is pretty fluid. If nothing else it
> gives clear units of work, even if the reviewers are the coders, and leaves
> a PR in a merged state which can even retrospectively be reviewed if needed.
>
> Wade
>
> On Oct 23, 2016 1:54 AM, "Emilian Bold" <em...@gmail.com> wrote:
>
>> You don't need to be a committer to do a PR. Development will come to a
>> standstill if all the main committers would have to go through this.
>>
>> Seems to me that if you trust somebody to vote her to be a committer you
>> trust her to actually commit code without being vetted by someone else.
>>
>> I know about the team repositories, main-golden and main-silver, the
>> releases/ repository with the version branches, the tags, etc.
>>
>> But now that I think about it, I kind of learned it in time, I haven't read
>> it all in one place.
>>
>> This workflow certainly is documented somewhere. Could we see it?
>>
>> Then we can judge if the Apache infra and usual processes are a good match.
>>
>>
>>
>>
>>
>> --emi
>>
>> On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler <co...@wadechandler.com>
>> wrote:
>>
>>>>
>>>> On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com>
>> wrote:
>>>>
>>>> I also wouldn't mind if we use code reviews.
>>>>
>>>> But code reviews don't make sense for every NetBeans commit.
>>>>
>>>> By definition a committer will not need approval to commit code.
>>>
>>> To me this is more of a community agreement, but one I’m in favor of. The
>>> projects I work on in both GH and Bitbucket use PRs, and that process
>> works
>>> out really well. I think it is fair that even committers come through a
>> PR,
>>> and get a review. We should be able to find at least “1” other person
>> for a
>>> review. Otherwise what processes are we doing to use? There are going to
>> be
>>> N number of orgs and individuals coalescing here.
>>>
>>> Every commit doesn’t go through a PR either btw, but instead it is based
>>> on a feature branch, and thus it could be 1-N commits in a given PR.
>>> Personally I think the only direct “develop” or “development” branch
>>> commits should be to fix a broken build, if it is a couple lines, but
>>> otherwise, using PRs keeps things sane, and too, gives a nice historic
>>> record of sets of changes grouped as wholes, and that “whole” of a set of
>>> work is what is reviewed in a PR.
>>>
>>> Wade
>>>
>>> ===================
>>>
>>> Wade Chandler
>>> e: consult@wadechandler.com
>>>
>>>
>>
Re: README & commit workflow was: Git "temp" repository requested
Posted by Wade Chandler <co...@wadechandler.com>.
These processes are used all over OSS projects in GH and Bitbucket.
Googling for them yields many results. One of my emails linked to the main
GitHub page. See Ate's email on another thread for a link to how other
Apache projects are using them. Development doesn't come to any form of a
standstill in my experience, but rather is pretty fluid. If nothing else it
gives clear units of work, even if the reviewers are the coders, and leaves
a PR in a merged state which can even retrospectively be reviewed if needed.
Wade
On Oct 23, 2016 1:54 AM, "Emilian Bold" <em...@gmail.com> wrote:
> You don't need to be a committer to do a PR. Development will come to a
> standstill if all the main committers would have to go through this.
>
> Seems to me that if you trust somebody to vote her to be a committer you
> trust her to actually commit code without being vetted by someone else.
>
> I know about the team repositories, main-golden and main-silver, the
> releases/ repository with the version branches, the tags, etc.
>
> But now that I think about it, I kind of learned it in time, I haven't read
> it all in one place.
>
> This workflow certainly is documented somewhere. Could we see it?
>
> Then we can judge if the Apache infra and usual processes are a good match.
>
>
>
>
>
> --emi
>
> On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler <co...@wadechandler.com>
> wrote:
>
> > >
> > > On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com>
> wrote:
> > >
> > > I also wouldn't mind if we use code reviews.
> > >
> > > But code reviews don't make sense for every NetBeans commit.
> > >
> > > By definition a committer will not need approval to commit code.
> >
> > To me this is more of a community agreement, but one I’m in favor of. The
> > projects I work on in both GH and Bitbucket use PRs, and that process
> works
> > out really well. I think it is fair that even committers come through a
> PR,
> > and get a review. We should be able to find at least “1” other person
> for a
> > review. Otherwise what processes are we doing to use? There are going to
> be
> > N number of orgs and individuals coalescing here.
> >
> > Every commit doesn’t go through a PR either btw, but instead it is based
> > on a feature branch, and thus it could be 1-N commits in a given PR.
> > Personally I think the only direct “develop” or “development” branch
> > commits should be to fix a broken build, if it is a couple lines, but
> > otherwise, using PRs keeps things sane, and too, gives a nice historic
> > record of sets of changes grouped as wholes, and that “whole” of a set of
> > work is what is reviewed in a PR.
> >
> > Wade
> >
> > ===================
> >
> > Wade Chandler
> > e: consult@wadechandler.com
> >
> >
>
Re: README & commit workflow was: Git "temp" repository requested
Posted by Emilian Bold <em...@gmail.com>.
You don't need to be a committer to do a PR. Development will come to a
standstill if all the main committers would have to go through this.
Seems to me that if you trust somebody to vote her to be a committer you
trust her to actually commit code without being vetted by someone else.
I know about the team repositories, main-golden and main-silver, the
releases/ repository with the version branches, the tags, etc.
But now that I think about it, I kind of learned it in time, I haven't read
it all in one place.
This workflow certainly is documented somewhere. Could we see it?
Then we can judge if the Apache infra and usual processes are a good match.
--emi
On Sat, Oct 22, 2016 at 7:37 PM, Wade Chandler <co...@wadechandler.com>
wrote:
> >
> > On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com> wrote:
> >
> > I also wouldn't mind if we use code reviews.
> >
> > But code reviews don't make sense for every NetBeans commit.
> >
> > By definition a committer will not need approval to commit code.
>
> To me this is more of a community agreement, but one I’m in favor of. The
> projects I work on in both GH and Bitbucket use PRs, and that process works
> out really well. I think it is fair that even committers come through a PR,
> and get a review. We should be able to find at least “1” other person for a
> review. Otherwise what processes are we doing to use? There are going to be
> N number of orgs and individuals coalescing here.
>
> Every commit doesn’t go through a PR either btw, but instead it is based
> on a feature branch, and thus it could be 1-N commits in a given PR.
> Personally I think the only direct “develop” or “development” branch
> commits should be to fix a broken build, if it is a couple lines, but
> otherwise, using PRs keeps things sane, and too, gives a nice historic
> record of sets of changes grouped as wholes, and that “whole” of a set of
> work is what is reviewed in a PR.
>
> Wade
>
> ===================
>
> Wade Chandler
> e: consult@wadechandler.com
>
>
Re: README & commit workflow was: Git "temp" repository requested
Posted by Wade Chandler <co...@wadechandler.com>.
>
> On Oct 22, 2016, at 12:21, Emilian Bold <em...@gmail.com> wrote:
>
> I also wouldn't mind if we use code reviews.
>
> But code reviews don't make sense for every NetBeans commit.
>
> By definition a committer will not need approval to commit code.
To me this is more of a community agreement, but one I’m in favor of. The projects I work on in both GH and Bitbucket use PRs, and that process works out really well. I think it is fair that even committers come through a PR, and get a review. We should be able to find at least “1” other person for a review. Otherwise what processes are we doing to use? There are going to be N number of orgs and individuals coalescing here.
Every commit doesn’t go through a PR either btw, but instead it is based on a feature branch, and thus it could be 1-N commits in a given PR. Personally I think the only direct “develop” or “development” branch commits should be to fix a broken build, if it is a couple lines, but otherwise, using PRs keeps things sane, and too, gives a nice historic record of sets of changes grouped as wholes, and that “whole” of a set of work is what is reviewed in a PR.
Wade
===================
Wade Chandler
e: consult@wadechandler.com
Re: README & commit workflow was: Git "temp" repository requested
Posted by Emilian Bold <em...@gmail.com>.
So the master branch is the new main-golden?
I agree that we should have some automatically managed branches where only
a bot/Jenkins task pushes after the tests have passed, etc.
I also wouldn't mind if we use code reviews.
But code reviews don't make sense for every NetBeans commit.
By definition a committer will not need approval to commit code.
--emi
Pe sâmbătă, 22 octombrie 2016, Jaroslav Tulach <ja...@gmail.com>
a scris:
> Hi,
> I also made my first commit and described the setup steps in README:
> https://git-wip-us.apache.org/repos/asf?p=incubator-netbeans-temp.git;a=
> commitdiff;h=9fbda90b2430a3a7cedbe7f855eb4cb9398e4513
>
> However I don't think this is the workflow we want to use. Nobody should
> have
> write access to the master branch, I assume. Each change should go in
> through
> a GitHub-like Pull Request and only when the change passes all tests and is
> approved, it should (automatically) be merged into the master branch.
>
> OracleLabs teams use this workflow now when working on Graal and Truffle
> repositories and I found the process great.
>
> Is this the working style we want to use too? How does one realize it in
> Apache infrastructure?
> -jt
>
>
--
--emi
Re: README & commit workflow was: Git "temp" repository requested
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Great, thanks for the exploratory steps you're doing already. Indeed, what
you describe sounds desirable -- let's see if someone can offer insight
into that approach here.
Gj
On Sat, Oct 22, 2016 at 4:21 PM, Jaroslav Tulach <ja...@gmail.com>
wrote:
> Hi,
> I also made my first commit and described the setup steps in README:
> https://git-wip-us.apache.org/repos/asf?p=incubator-netbeans-temp.git;a=
> commitdiff;h=9fbda90b2430a3a7cedbe7f855eb4cb9398e4513
>
> However I don't think this is the workflow we want to use. Nobody should
> have
> write access to the master branch, I assume. Each change should go in
> through
> a GitHub-like Pull Request and only when the change passes all tests and is
> approved, it should (automatically) be merged into the master branch.
>
> OracleLabs teams use this workflow now when working on Graal and Truffle
> repositories and I found the process great.
>
> Is this the working style we want to use too? How does one realize it in
> Apache infrastructure?
> -jt
>
>
README & commit workflow was: Git "temp" repository requested
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hi,
I also made my first commit and described the setup steps in README:
https://git-wip-us.apache.org/repos/asf?p=incubator-netbeans-temp.git;a=commitdiff;h=9fbda90b2430a3a7cedbe7f855eb4cb9398e4513
However I don't think this is the workflow we want to use. Nobody should have
write access to the master branch, I assume. Each change should go in through
a GitHub-like Pull Request and only when the change passes all tests and is
approved, it should (automatically) be merged into the master branch.
OracleLabs teams use this workflow now when working on Graal and Truffle
repositories and I found the process great.
Is this the working style we want to use too? How does one realize it in
Apache infrastructure?
-jt
Re: Git "temp" repository requested (was: Jenkins & Git @apache...)
Posted by Tushar Joshi <tu...@gmail.com>.
I was able to clone the repository and push a commit using my apache id
tusharjoshi@apache.org
with regards
Tushar
Re: Git "temp" repository requested (was: Jenkins & Git @apache...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Oct 21, 2016 at 11:09 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ...That should soon appear at
> https://git-wip-us.apache.org/repos/asf/incubator-netbeans-temp.git -
> within an hour says that form...
It's up now and I was able to commit:
https://git-wip-us.apache.org/repos/asf?p=incubator-netbeans-temp.git;a=tree
-Bertrand
Re: Git "temp" repository requested (was: Jenkins & Git @apache...)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Oct 21, 2016 at 11:13 AM, Geertjan Wielenga
<ge...@googlemail.com> wrote:
> ...how does Jenkins work with this and/or i.e., we'd like to work
> through the build and release management structure with the 'temp' repo....
https://builds.apache.org/ has basic info and you'll probably need
mentor help to be able to setup things there.
In Sling we recently started using generated Jenkins jobs for our many
modules, https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup
has more info.
-Bertrand
Re: Git "temp" repository requested (was: Jenkins & Git @apache...)
Posted by Geertjan Wielenga <ge...@googlemail.com>.
PS: And then how does Jenkins work with this and/or i.e., we'd like to work
through the build and release management structure with the 'temp' repo.
On Fri, Oct 21, 2016 at 11:12 AM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> Many thanks!
>
> Gj
>
> On Fri, Oct 21, 2016 at 11:09 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> Hi,
>>
>> On Fri, Oct 21, 2016 at 10:49 AM, Geertjan Wielenga
>> <ge...@googlemail.com> wrote:
>> > ...where are the instructions needed for requesting or
>> > setting up a Git repo?...
>>
>> I suppose you need to be a member of the Incubator PMC to use
>> https://reporeq.apache.org/ so mentors can do it.
>>
>> I did just that, requesting the following repository:
>>
>> incubator-netbeans-temp
>> Apache NetBeans (incubating) temporary repository
>> commits notifications to commits@netbeans.incubator.apache.org
>> Mirror to GitHub
>> Enable GitHub integrations
>> GitHub notifcations to dev@netbeans.incubator.apache.org
>>
>> That should soon appear at
>> https://git-wip-us.apache.org/repos/asf/incubator-netbeans-temp.git -
>> within an hour says that form.
>>
>> And then also under https://github.com/apache/
>>
>> I suppose people listed as committers on "incubator" at
>> http://people.apache.org/phonebook.html should have write access, if
>> not ask mentors to fix it. I'll be offline for some time myself, might
>> not be able to help right away.
>>
>> -Bertrand
>>
>
>
Re: Git "temp" repository requested (was: Jenkins & Git @apache...)
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Many thanks!
Gj
On Fri, Oct 21, 2016 at 11:09 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> Hi,
>
> On Fri, Oct 21, 2016 at 10:49 AM, Geertjan Wielenga
> <ge...@googlemail.com> wrote:
> > ...where are the instructions needed for requesting or
> > setting up a Git repo?...
>
> I suppose you need to be a member of the Incubator PMC to use
> https://reporeq.apache.org/ so mentors can do it.
>
> I did just that, requesting the following repository:
>
> incubator-netbeans-temp
> Apache NetBeans (incubating) temporary repository
> commits notifications to commits@netbeans.incubator.apache.org
> Mirror to GitHub
> Enable GitHub integrations
> GitHub notifcations to dev@netbeans.incubator.apache.org
>
> That should soon appear at
> https://git-wip-us.apache.org/repos/asf/incubator-netbeans-temp.git -
> within an hour says that form.
>
> And then also under https://github.com/apache/
>
> I suppose people listed as committers on "incubator" at
> http://people.apache.org/phonebook.html should have write access, if
> not ask mentors to fix it. I'll be offline for some time myself, might
> not be able to help right away.
>
> -Bertrand
>