[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT and GitHub (was: RE: Unit testing support for Eclipse CDT)

Well, no. There already is a model for collaborating on github involving forks and pull requests. It's documented there somewhere I believe. I'll see if I can dig it up.

Doug.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Marc Khouzam
> Sent: Wednesday, August 31, 2011 11:06 AM
> To: 'CDT General developers list.'; elaskavaia.cdt@xxxxxxxxx
> Subject: [cdt-dev] CDT and GitHub (was: RE: Unit testing support for Eclipse
> CDT)
> 
> Can you give an idea of the process to follow to collaborate on CDT via
> GitHub?
> Here is what my initial impression is:
> 
> 1- create GitHub account if you don't have one https://github.com/
> 2- probably setup ssh key on GitHub if not done already
> 3- on GitHub, one collaborator creates a clone of
> https://github.com/eclipse/cdt
>    This existing clone is automatically being mirrored on eclipse.org.
>    This new clone will be the repo that all collaborators will pull from and push
> to.
>    Let's call it MyClonedCDT
> 4- each collaborator clones the new MyClonedCDT from GitHub on their own
> machine
> 5- as collaboration progresses, the collaborators push and pull from
> MyCloneCDT
> 6- once in a while (as often as desired) MyClonedCDT pulls (manually) from
>    https://github.com/eclipse/cdt to get the changes coming from eclipse.org
> 7- once the work is ready to be contributed, how will we create a patch of
> changes?
> 
> Is this somewhat correct?
> 
> Thanks
> 
> Marc
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
> > Sent: Wednesday, August 31, 2011 9:40 AM
> > To: elaskavaia.cdt@xxxxxxxxx; CDT General developers list.
> > Subject: Re: [cdt-dev] Unit testing support for Eclipse CDT
> >
> > I agree we should bring this in a feature for CDT 9. I'm also looking
> > at the pkg-config work that Petri did as another candidate. And we
> > have the Tilera Visualizer View as a third.
> >
> > We must however bring it through IP review, and I would feel much
> > better about the contribution if we had it checked anyway. Size
> > shouldn't matter, especially as we have 9 months left in the release
> > cycle. I will certainly help if we need things expedited.
> >
> > Contributions like this came up at the multi-core call. As I stated
> > there, this is why we moved to git. We can get larger contributions
> > developed in the open at Github, EclipseLabs, Google Code, where have
> > you, by a team of contributors and tested before bringing it in
> > through the IP review. That way the review is done once and hopefully
> > the contribution is large enough that we should feel comfortable
> > holding the committer elections as soon as that contribution is merged
> > into our master repo. This is how Linux is done, we can do the same.
> >
> > Other thoughts?
> > Doug.
> >
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > > On Behalf Of Alena Laskavaia
> > > Sent: Tuesday, August 30, 2011 8:20 PM
> > > To: CDT General developers list.
> > > Subject: Re: [cdt-dev] Unit testing support for Eclipse CDT
> > >
> > > Doug I think we should include this in CDT 9 as optional
> > feature, easiest way
> > > would be to make Anton a committer, and then we don't need
> > contribution
> > > review, because I suspect it is massive code
> > >
> > > On Fri, Aug 26, 2011 at 4:19 PM, xgsa <xgsa@xxxxxxxxx> wrote:
> > > > Unit Test Support plugin was updated (feature version 3.0.1). New
> > > features:
> > > >
> > > > Rerunning of the selected tests or test suites was done
> > (via context
> > > > menu of testing hierarchy). Multiple selection for rerun
> > is supported
> > > > for Qt.Test & Google Test (Boost.Test does not support
> > this feature).
> > > > Test runs history was implemented (running testing sessions in
> > > > parallel mode is also supported).
> > > > Message filters by level were supported.
> > > > Error handling was improved if a test module terminated
> > unexpectedly.
> > > >
> > > > I have updated the project wiki, so you can take a look at new
> > > > screenshots here.
> > > >
> > > > It seems, the last major feature that is missing yet, is debug
> > > > support. I will try to implement it for the next update.
> > Certainly, a
> > > > lot of small features (for example, UI performance should
> > be improved)
> > > > should be added too, so any feedback on my work will be
> > appreciated. Stay
> > > tuned!
> > > >
> > > > Anton
> > > >
> > > > -------- Original message --------
> > > >
> > > > Unit Test Support plugin was updated (feature version
> > 2.0.1). The most
> > > > important:
> > > >
> > > > Google Testing Framework support;
> > > > show failed only filters;
> > > > plain view of testing hierarchy;
> > > >
> > > > A few important bugs were fixed (in particular, failure messages
> > > > reset, reported by Axel Müller).
> > > >
> > > > Anton
> > > >
> > > > -------- Original message --------
> > > >
> > > > Hi,
> > > >
> > > > I am working on the unit testing support for Eclipse CDT. It means
> > > > integration of existing C/C++ unit testing frameworks (such as
> > > > Boost.Test, Qt Test, Google Testing framework, CPPUnit, ...) into
> > > > Eclipse like JUnit support is done. I want to contribute
> > it to the CDT
> > > > repository at one point, so I need your feedback.
> > > >
> > > > Currently, these features are supported:
> > > >
> > > > Tests running with support of the following frameworks:
> > > >
> > > > Boost.Test;
> > > > Qt Test;
> > > >
> > > > Tests hierarchy browsing in a separate view.
> > > > Test messages viewing, filtering by test case or test
> > suite. Source
> > > > lookup is also supported.
> > > > Testing statistics (total/failed/aborted tests count,
> > red/green bar).
> > > > Testing time measurement.
> > > > The list of provided tests runners may be easily extended
> > writing a
> > > > new Tests Runner Plugin.
> > > >
> > > > If you want to try it yourself, here is an instruction
> > how to do it (a
> > > > few screenshots are also there). You can also see known problems &
> > > > planned features here. Here is a git repository (synchronized with
> > > > yours), that contains 3 new projects and a few changes in
> > CDT sources.
> > > >
> > > > So I want to know your opinion about current
> > functionality features,
> > > > what is missing and should be implemented. Comments about
> > source code
> > > > are also appreciated. If you have any questions - feel
> > free to ask.
> > > >
> > > > Anton.
> > > >
> > > > _______________________________________________
> > > > cdt-dev mailing list
> > > > cdt-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > cdt-dev mailing list
> > > > cdt-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > cdt-dev mailing list
> > > > cdt-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > >
> > > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev