I think what matters is that the purpose of the "blessed" or "release" repo is only to track history for released stuff. So it doesn't actually affect community or any of core devs. It would be mostly a responsibility of Julien and me (if we decide to go this way) to keep it in sync. So I don't think it is worth to argue too much around this stuff. The main thing to decide is around the dev repo - "https://github.com/gatein" - who has push access and who needs to ask core devs for merge or pass pull request. Additionally how we should handle commit history. Also I think that in natural way a lot of dev will be happening in private forks anyway as this is "the git" way of working. Just wanted to clarify this as from my previous email it may look as something that we want to avoid. We don't want to develop different git workflow. Bolek On Jul 19, 2011, at 7:13 PM, Boleslaw Dawidowicz wrote: > Hi > > We were recently brainstorming a bit with Julien around Git usage for GateIn and here is a draft of the doc: > > https://docs.google.com/document/pub?id=1dp3QODiZDG3KbolnBsCkjZWwYtIvCaQv... > > I would like all of you to read it and comment. > > The main concern is around having two spaces in github. Let me clarify reasoning about this part a bit. If you look at how Infinispan uses git: > > https://docs.jboss.org/author/display/ISPN/Contributing+to+Infinispan#Con... > > you will notice that in the end there are few people acting as "Project Admin" and everything goes via them as a pull request. This means that all development is being performed in private clones and forks and only code in clean state hits the repo. It also means that few people have a lot on their shoulders to handle pull requests. > > Julien proposed to have common more open space at "https://github.com/gatein". We would be able to collaborate more on common branches. It would be also more easy to track all development work that is going on in the project in one place. We would be able to also give push/pull access to guys from QA and Support. > > Separately we would have something aka "blessed" repo (https://github.com/gateinportal). Only few people have access there, and everytime we tag, release we push clean code with clean history there. Community doesn't really need to be aware of it and we don't need to advertise it too much. It is more also for safety reasons as git allows destructive operations so when more people can push things into "gatein" space we can end up with losing some important history there. > > Personally I still have a bit mixed feelings around this two places idea and thats partly why I'm asking for feedback. I assume that we would like to commit directly into "gatein" space repos for feature requests, bugs and etc. We would still use private forks for prototyping, experimenting or dirty commits but it would be advised to push things to gatein space on regular bases for other work. > > The goal is to prepare some kind of public doc like infinispan wiki. > > Bolek > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

My take on this: GIT has already well defined and globally understood processes (for people using GIT daily). And the example below of Infinispan seems to match it. -> 1 official repo -> GateIn/portal -> For development people fork the repo into their own account -> metacosm/portal -> When developers are ready they do a pull request to the guardians of "Gatein/portal" -> The guardians approve/deny the pull request. You add a process such as git-flow for working on various branches, and on releases in QA ready to be tagged: http://nvie.com/posts/a-successful-git-branching-model/ You add a regular backup script on a different machine than github (for when github is down or some guardian screwed up) And: 1) You follow a process well established and not confuse people with 2 repositories that seem official 2) You simplify the approach for contributors (in general, including support, QA) as: a) they would be familiar with such a procedure b) can easily and quickly do minor changes right from GitHub (typos) c) don't need account setup (SSH key + someone to authorize them) unless they have to do a pull request on the dev repo d) can follow more easily where their code is going (which release of the gateinportal repo vs gatein repo) 3) You simplify the life of the guardians as there are not 2 promotions, you also reduce the risk of having code change stuck in dev. And then you reduce the time between the code being written and the code available in a release. 4) You don't need to pay for 2 GitHub accounts if both are on GitHub Now this is my feedback on something that I find overengineered and confusing, I may not be the one who will suffer most about this, so will leave the decision to you and Julien Thomas On 07/19/2011 07:13 PM, Boleslaw Dawidowicz wrote: > Hi > > We were recently brainstorming a bit with Julien around Git usage for GateIn and here is a draft of the doc: > > https://docs.google.com/document/pub?id=1dp3QODiZDG3KbolnBsCkjZWwYtIvCaQv... > > I would like all of you to read it and comment. > > The main concern is around having two spaces in github. Let me clarify reasoning about this part a bit. If you look at how Infinispan uses git: > > https://docs.jboss.org/author/display/ISPN/Contributing+to+Infinispan#Con... > > you will notice that in the end there are few people acting as "Project Admin" and everything goes via them as a pull request. This means that all development is being performed in private clones and forks and only code in clean state hits the repo. It also means that few people have a lot on their shoulders to handle pull requests. > > Julien proposed to have common more open space at "https://github.com/gatein". We would be able to collaborate more on common branches. It would be also more easy to track all development work that is going on in the project in one place. We would be able to also give push/pull access to guys from QA and Support. > > Separately we would have something aka "blessed" repo (https://github.com/gateinportal). Only few people have access there, and everytime we tag, release we push clean code with clean history there. Community doesn't really need to be aware of it and we don't need to advertise it too much. It is more also for safety reasons as git allows destructive operations so when more people can push things into "gatein" space we can end up with losing some important history there. > > Personally I still have a bit mixed feelings around this two places idea and thats partly why I'm asking for feedback. I assume that we would like to commit directly into "gatein" space repos for feature requests, bugs and etc. We would still use private forks for prototyping, experimenting or dirty commits but it would be advised to push things to gatein space on regular bases for other work. > > The goal is to prepare some kind of public doc like infinispan wiki. > > Bolek > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev

I had more brainstorming with Julien, Marko and Thomas on IRC and would like to share some updated thoughts :) I'm trying to look a bit on what JBoss AS is doing and there is quite good wiki about the pull request process: http://community.jboss.org/wiki/HackingonAS7 I think that for now lets leave the topic of the separate blessed/release repo aside and discuss only how to go with the "gatein" space on github in similar direction. 1) We define a set of "core guardians" with push/pull access to any repo in "gatein" space. For the start it would be 2 persons from each company - for example Me/Thomas/Julien/Trong 2) Core guardians are the only ones who can push to gatein/gatein-portal/master (what would be current svn gatein/portal/trunk). This way a small set of persons have good control on what gets commited Question: Will it scale? Should we allow more people to push? My Anwser: I think we could just start like that and see how it goes. It is always possible to quickly add more people in charge 3) For other component additionally we add separate guardians who are in charge of pushing changes. For example - WSRP - Chris - PC - Marko/Julien - WCI - Matt/someone - Management - Nick - etc. 4) We use mailing like like gatein-pull-request (http://lists.jboss.org/pipermail/jbossas-pull-requests/2011-July/thread.html) Q: Should component Guardians also follow the same process for pull request even if they will be the ones to push it in the end? The benefit is the notification of what is going on. Also when there are few guardians for each repo it will ease open communication. MA: I have a mixed feelings - trying to seek others experience atm. I think the reality would be that most of work will happen in personal forks anyway and bigger chunks of work pushed into the repo. Then sending pull request even by repo guardians may make sense. 5) What about collaboration when few people need to sync during development? It can still happen in personal forks as someone always need to be a lead of specific feature development and his repo can add as a central collaboration space. Exo can sync things in exoportal space before pushing to gatein master also. Additionally for specific needs we can still create additional repo. 6) What about tracking work that is going on in the project? Core team is not that big so it is possible to follow all devs and developement of specific features on github. There are also possible hooks to have email/iphone/irc... notifications. There are quite a few additional concerns around how to mark JIRA resolution across many commits or how do handle history rewrite in case of amended fixes. However I would like to start with points above to agree on common ground. Any concerns or comments? Bolek On Jul 20, 2011, at 10:00 AM, Julien Viet wrote: > thanks for providing feedback, we'll discuss it again with Bolek during the coming days. > > On Jul 20, 2011, at 9:35 AM, Thomas Heute wrote: > >> >> My take on this: >> >> GIT has already well defined and globally understood processes (for >> people using GIT daily). >> And the example below of Infinispan seems to match it. >> >> -> 1 official repo -> GateIn/portal >> -> For development people fork the repo into their own account -> >> metacosm/portal >> -> When developers are ready they do a pull request to the >> guardians of "Gatein/portal" >> -> The guardians approve/deny the pull request. >> >> You add a process such as git-flow for working on various branches, and >> on releases in QA ready to be tagged: >> http://nvie.com/posts/a-successful-git-branching-model/ >> >> You add a regular backup script on a different machine than github (for >> when github is down or some guardian screwed up) >> >> And: >> 1) You follow a process well established and not confuse people >> with 2 repositories that seem official >> 2) You simplify the approach for contributors (in general, >> including support, QA) as: >> a) they would be familiar with such a procedure >> b) can easily and quickly do minor changes right from GitHub >> (typos) >> c) don't need account setup (SSH key + someone to authorize >> them) unless they have to do a pull request on the dev repo >> d) can follow more easily where their code is going (which >> release of the gateinportal repo vs gatein repo) >> 3) You simplify the life of the guardians as there are not 2 >> promotions, you also reduce the risk of having code change stuck in dev. >> And then you reduce the time between the code being written and the code >> available in a release. >> 4) You don't need to pay for 2 GitHub accounts if both are on GitHub >> >> Now this is my feedback on something that I find overengineered and >> confusing, I may not be the one who will suffer most about this, so will >> leave the decision to you and Julien >> >> Thomas >> >> >> On 07/19/2011 07:13 PM, Boleslaw Dawidowicz wrote: >>> Hi >>> >>> We were recently brainstorming a bit with Julien around Git usage for GateIn and here is a draft of the doc: >>> >>> https://docs.google.com/document/pub?id=1dp3QODiZDG3KbolnBsCkjZWwYtIvCaQv... >>> >>> I would like all of you to read it and comment. >>> >>> The main concern is around having two spaces in github. Let me clarify reasoning about this part a bit. If you look at how Infinispan uses git: >>> >>> https://docs.jboss.org/author/display/ISPN/Contributing+to+Infinispan#Con... >>> >>> you will notice that in the end there are few people acting as "Project Admin" and everything goes via them as a pull request. This means that all development is being performed in private clones and forks and only code in clean state hits the repo. It also means that few people have a lot on their shoulders to handle pull requests. >>> >>> Julien proposed to have common more open space at "https://github.com/gatein". We would be able to collaborate more on common branches. It would be also more easy to track all development work that is going on in the project in one place. We would be able to also give push/pull access to guys from QA and Support. >>> >>> Separately we would have something aka "blessed" repo (https://github.com/gateinportal). Only few people have access there, and everytime we tag, release we push clean code with clean history there. Community doesn't really need to be aware of it and we don't need to advertise it too much. It is more also for safety reasons as git allows destructive operations so when more people can push things into "gatein" space we can end up with losing some important history there. >>> >>> Personally I still have a bit mixed feelings around this two places idea and thats partly why I'm asking for feedback. I assume that we would like to commit directly into "gatein" space repos for feature requests, bugs and etc. We would still use private forks for prototyping, experimenting or dirty commits but it would be advised to push things to gatein space on regular bases for other work. >>> >>> The goal is to prepare some kind of public doc like infinispan wiki. >>> >>> Bolek >>> _______________________________________________ >>> gatein-dev mailing list >>> gatein-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/gatein-dev >> >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev