I think we ask webmaster so that we can make sure things are tidy and organized.
Tyler Jewell // CEO // tyler@codenvy.com // 978.884.5355 On Wed, Apr 19, 2017 at 6:25 AM, Rémi Druilhe <[email protected]> wrote: > Hello, > > Thanks for the answers. Thus, I assume we will use multiple GIT > repositories. It will help us for the management of the subprojects. > > This lead me to my next question, according to > https://wiki.eclipse.org/Git#Creating_a_new_repository, we can ask for > others repositories or create a new one by ourself. I am able to connect to > the GIT server using SSH. Do I have the rights to create a new repository > or should I ask it to a webmaster? I haven't tried it yet because I don't > want to broke the Eclipse process with forbidden shell request. > > Thanks. > > -- > Rémi DRUILHE > Phone: +33 (0) 6 87 17 93 77 <+33%206%2087%2017%2093%2077> > > 2017-04-19 14:38 GMT+02:00 Tyler Jewell <[email protected]>: > >> The Eclipse Che project spans 6 or 7 repositories now. We do it for a >> couple reasons: >> 1. Dependency management for assemblies that combine many pieces together >> 2. Size management for git cloning operations. Specifically our >> customizations to Tomcat and our documentation are sizable. >> 3. Components that are part of the product, but release on a different >> cycle than the product. For example, Che has a library of stacks which are >> Dockerfiles compiled into images and pushed onto DockerHub in an eclipse >> organization. These stacks are referenced by and loaded by Che, but we >> version and release them on a different timetable. >> >> Tyler >> >> >> Tyler Jewell // CEO // tyler@codenvy.com // 978.884.5355 >> <(978)%20884-5355> >> >> >> On Wed, Apr 19, 2017 at 4:07 AM, Ed Willink <[email protected]> wrote: >> >>> Hi >>> >>> I don't think distinct technologies is a justification for distinct >>> repositories, however: >>> >>> When my projects moved to GIT, I wondered whether one large repo per >>> project was a good idea, or whether modules would improve performance. At >>> that time there was a strong recommendation for a single repository. A few >>> years later I see the time to clone an ever increasing GIT repo as >>> unwelcome and notice that some projects such as Xtext seem to be >>> refactoring. I suspect that multiple modules would be a good idea, but do >>> not have time/inclination to reorganise my own repos. Arguably CVS had each >>> file as a distinct module and so communication was much smaller. >>> >>> Regards >>> >>> Ed Willink >>> On 19/04/2017 09:15, Rémi Druilhe wrote: >>> >>> Hello, >>> >>> We received the first commiters status on the newly created sensiNact >>> project. We sh=ould soon provide the initial contribution for IP review. We >>> just had a small meeting with the team and we have some questions. >>> >>> Our project is mainly composed of, at least, 2 larges subprojects, i.e., >>> a client and a server. Thus, we would like to know what is the better way >>> to proceed for the IP review. Should we submit the two subprojects or >>> should we do it incrementally (the server and then the client). I know >>> there is the parallel IP process >>> <https://wiki.eclipse.org/Development_Resources/HOWTO/Parallel_IP_Process> >>> we could ask for but I don't know if this is relevant for this case. >>> >>> To accelerate the IP review, we are not going to submit all the modules >>> in the initial contribution. It will also let us put in the right format >>> our existing code and still start the IP review process. Is a new module >>> (or in the future a new feature) must always be sent for IP review? >>> According to the Eclipse Legal Process >>> <https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf>, we could >>> just submit a minimal set of code of the project (initial commit on page 2) >>> and then commit everything else using the normal process (page 1, Figure 1). >>> >>> And the last question. We have at least 2 subprojects. We saw that it is >>> possible to create new repositories (cf. https://wiki.eclipse.org/Git#C >>> reating_a_new_repository). Can we ask for others repositories to host >>> subprojects (e.g., the client, the server, etc.)? It will ease the project >>> management because we are not using the same technologies on the >>> subprojects. Or should we request for a new Eclipse project in order to >>> have a separated GIT repository? >>> >>> Thanks, >>> >>> Best regards. >>> -- >>> Rémi DRUILHE >>> Phone: +33 (0) 6 87 17 93 77 <+33%206%2087%2017%2093%2077> >>> >>> >>> _______________________________________________ >>> incubation mailing [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visithttps://dev.eclipse.org/mailman/listinfo/incubation >>> >>> >>> >>> >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >>> Virus-free. >>> www.avast.com >>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >>> <#m_-6690652832600963903_m_1293976017159313200_m_3427375925841205274_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >>> >>> _______________________________________________ >>> incubation mailing list >>> [email protected] >>> To change your delivery options, retrieve your password, or unsubscribe >>> from this list, visit >>> https://dev.eclipse.org/mailman/listinfo/incubation >>> >>> >> >> _______________________________________________ >> incubation mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >> from this list, visit >> https://dev.eclipse.org/mailman/listinfo/incubation >> >> > > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation > >
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
