Thanks Martin,
Yes, it looks like we are going to do something similar, if not identical, to what you propose.
We still have one last big git push to do (hopefully today) so that we can transfer what we have on our internal git into the Eclipse one. This time we’ll try to preserve the original authors in the commit and original dates (roughly this week work).
When that’s done, we’ll shutdown our git, and use the Eclipse one as main repository.
Thanks again for your help, we’ll ask if there are prb left unresolved or for impl. details if we cannot work it out.
Thanks,
Cuero
De : mihini-dev-bounces@xxxxxxxxxxx [mailto:mihini-dev-bounces@xxxxxxxxxxx] De la part de Oberhuber, Martin
Envoyé : mercredi 6 mars 2013 19:52
À : Wayne Beaton; mihini-dev@xxxxxxxxxxx
Cc : Chris Aniszczyk
Objet : Re: [mihini-dev] Questions regarding the Mihini development process
I’ll be happy to try and help the Mihini project as a mentor, if the team comes up with a question to me.
The current thread seems to lack some context for me so I’m not sure what to say at this point.
In case it helps : What we do at Wind River is make the Open Source Eclipse repositories our master for any Open Source code, then pull from the Open Source repos into proprietary ones for any bridge code / integrations. That “pull” from Eclipse.org master happens automated into a branch in the proprietary git; the branch gets merged manually when needed.
In case a non-committer provides a fix, that fix is typically contributed through Gerrit or the contributor asks a committer to pull from his repo (which may be proprietary). In case of such a pull request, it’s the committer’s responsibility to ensure that the respective contribution is clean and satisfies Eclipse.org due diligence guidelines.
It sounds complex but isn’t really that bad. Essentially, committers work on Eclipse.org repos most of the time, and non-committers ask committers to pull from their repos when needed. Do you think such a process would work for you ?
IP Due Diligence and keeping Eclipse.org repos filled with EPL code only is important.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Architect – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
Your project mentors (copied) are a good place to start with regard to the process.
Wayne
On 03/05/2013 05:51 AM, Cuero Bugot wrote:
Hi Wayne,
Thank you for the feedback.
> Can you describe the project's development process?
Well as you point out, our development process for Mihini is not totally clear, even for us. Let me give some explanation about that. As you may know, Mihini was an existing commercial product for some years now. Sierra Wireless found in its interests and for the interests of other parties to release this product as opensource. That at least explains why there is a ‘big’ chunk as initial contrib. Also because all our history does not pass Eclipse IP rules, and all our developers are not Eclipse committer, it was decided to flatten the initial chunks.
All that was done hastily, because we thought that releasing some code asap was important, and that we could sort out the details later on.
> Is the project operating in an open and transparent manner as required by the Eclipse Development Process [0]?
We make everything we can to make it that way!
> All of the commits in the repository [1] appear to be authored by a single individual. Is this correct?
See above comment.
>It seems a little odd to me that all of the commits appear to have been created in three separate chunks, and that two of those chunks occur on Fridays. Is all >development actually occurring on Friday, or is there something else happening?
See above comment. Yes it is weird, and yes we want to improve it!
>Can somebody describe for me what is happening in this commit: [2]? What is the "non-free" submodule?
Everything is public. It is in our own interest to *not* fork our commercial product and keep the same code base for both Mihini and our commercial product. We do not want to double the workload. The content of non-free module is actually opensource code as well ! Only it was refused by eclipse IP checking because of licensing issues, mainly. Retrospectively also the inclusion was indeed done in the wrong way.
In the end, not everybody in the team is proficient with the Eclipse way of doing things. But we want to improve! We do have constraints though, as I said before Mihini was an existing commercial product. We also are a small team of developers, and we need to organize in a way that it is fully compatible with Eclipse process, and still have the ability to have a commercial product. That include the git repository, but not only, we’ll have the same issues with the wiki, bug tracker, etc…
I am happy to have a chat with you or other people to help us organize in a proper Eclipse manner. But in the end, be convinced that the team here is composed of individual that are OpenSource enthusiasts and that we make everything we can to make that project work !
Cuero
Cuero Bugot :: Embedded R&D Manager
SIERRA WIRELESS :: AirLink Business Unit
Main +33 (0)5 61 00 52 90 :: Direct +33 (0)5 61 00 06 53 :: Mobile +33 (0)7 61 79 01 45 :: Fax +33 (0)5 61 00 51 46
Lake Park - Zac de l'Hers - Allée du Lac - BP 87216 :: 31672 Labège Cedex, France
cbugot@xxxxxxxxxxxxxxxxxx :: www.sierrawireless.com
__________________________________________________________________________
This message and any attachments (the "Message") are confidential and intended solely
for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited.
Neither Sierra Wireless nor any of its subsidiaries shall be liable for the Message if altered,
changed, falsified or edited, diffused without authorization.
_______________________________________________
mihini-dev mailing list
mihini-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/mihini-dev
