[Xenomai-core] Unstable driver integration policy

[Xenomai-core] Unstable driver integration policy

[Alexis Berlemont]

Hi,

I would like to find a way to populate the Comedi drivers set.

However, I am stuck by a simple fact: I have no acquisition board to validate 
a least driver...

Starting from here, I am trying to find out what should be the proper method 
to provide non-validated drivers to anybody inclined to test them. 

Do you think creating a specific subversion branch for this stuff would be a 
good idea ?

Alexis.

Re: [Xenomai-core] Unstable driver integration policy

[Jan Kiszka]

Hi Alexis,

Alexis Berlemont wrote:
> Hi,
> 
> I would like to find a way to populate the Comedi drivers set.
> 
> However, I am stuck by a simple fact: I have no acquisition board to validate 
> a least driver...
> 
> Starting from here, I am trying to find out what should be the proper method 
> to provide non-validated drivers to anybody inclined to test them. 
> 
> Do you think creating a specific subversion branch for this stuff would be a 
> good idea ?

Given the well-known fact that (too) few people look beyond what we
deliver as releases and also assuming that your drivers should have no
side-effects (unless when actually used), I would rather suggest to
develop for SVN head, merge and deliver, but mark each driver
"experimental" until people with real hw confirm that it works as expected.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2 ES-OS
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] Unstable driver integration policy

[Philippe Gerum]

Alex,

Alexis Berlemont wrote:
> Hi,
> 
> I would like to find a way to populate the Comedi drivers set.
> 
> However, I am stuck by a simple fact: I have no acquisition board to validate 
> a least driver...
> 
> Starting from here, I am trying to find out what should be the proper method 
> to provide non-validated drivers to anybody inclined to test them. 
> 
> Do you think creating a specific subversion branch for this stuff would be a 
> good idea ?
>

I don't think so. Moving that code away from the focal point where people are
expected to find new code to test and work with won't help.

You could decide instead to implement drivers for a small set of very popular
acquisition cards; whether that implementation is eventually fully validated or
not depends on other people to have enough interest in that work to give you
access to some hw, or to validate the driver themselves. As Jan pointed out,
"experimental" is a convenient sticker to tell people about the exact state of
this work.

You spark the effort (this is _always_ the hardest and most demanding part of
the job), they help finalize it if they want to get serious about this.

> Alexis.
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 
Philippe.

Re: [Xenomai-core] Unstable driver integration policy

[Alexis Berlemont]

Hi Philippe,
Hi Jan,

Many thanks for your answers.

> > I would like to find a way to populate the Comedi drivers set.
> >
> > However, I am stuck by a simple fact: I have no acquisition board to
> > validate a least driver...
> >
> > Starting from here, I am trying to find out what should be the proper
> > method to provide non-validated drivers to anybody inclined to test them.
> >
> > Do you think creating a specific subversion branch for this stuff would
> > be a good idea ?
>
> I don't think so. Moving that code away from the focal point where people
> are expected to find new code to test and work with won't help.
>
> You could decide instead to implement drivers for a small set of very
> popular acquisition cards; whether that implementation is eventually fully
> validated or not depends on other people to have enough interest in that
> work to give you access to some hw, or to validate the driver themselves.
> As Jan pointed out, "experimental" is a convenient sticker to tell people
> about the exact state of this work.
>
> You spark the effort (this is _always_ the hardest and most demanding part
> of the job), they help finalize it if they want to get serious about this.

OK. I thought adding unstable drivers into the trunk was too risky. I forgot 
about using the experimental flag.

Regards,

Alexis.