Re: [ANNOUNCE] git tree repositories

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Bob,

Am Dienstag, den 19.01.2010, 13:21 -0800 schrieb Bob Cunningham:
> On 01/19/2010 04:16 AM, Mauro Carvalho Chehab wrote:
> > Devin Heitmueller wrote:
> >> Hello Mauro,
> >>
> >> I find it somewhat unfortunate that this is labeled "ANNOUNCE" instead
> >> of "RFC".  It shows how little you care about soliciting the opinions
> >> of the other developers.  Rather than making a proposal for how the
> >> process can be improved and soliciting feedback, you have chosen to
> >> decide for all of us what the best approach is and how all of us will
> >> develop in the future.
> >
> > The announcement by purpose doesn't contain any changes on the process,
> > since it requires some discussions before we go there. It is just the
> > first step, where -git tree support were created. It also announces
> > that I personally won't keep maintaining -hg, delegating its task
> > to Douglas.
> >
> >> The point I'm trying to make is that we need to be having a discussion
> >> about what we are optimizing for, and what are the costs to other
> >> developers.  This is why I'm perhaps a bit pissed to see an
> >> "announcement" declaring how development will be done in the future as
> >> opposed to a discussion of what we could be doing and what are the
> >> trade-offs.
> >
> > I fully understand that supporting the development and tests with an
> > out of tree building is important to everybody. So, the plans are
> > to keep the out-of-tree building system maintained, and even
> > improving it. I'd like to thank to Douglas for his help on making
> > this happen.
> >
> > Cheers,
> > Mauro.
> 
> I'm primarily a lurker on this list, generally content to wait for v4l driver updates until they appear in the Fedora 12 and Ubuntu 9.10 updates.
> 
> However, I also keep a v4l source tree around that I update and build whenever any significant changes occur that affect my HVR-950Q, so I can provide rapid feedback to the developers.  My process is to update my local tree, build the drivers. build the package, install the package, test it, then either revert immediately if there are problems (after posting to the list), or update again when the changes appear in the Fedora repositories.
> 
> Am I correct to believe my process will not be affected by the shift to git?  That is, will existing kernels will still have access to the current v4l code via hg?
> 
> I also hope to one day start working on an unsupported USB tuner I have laying around (should be simple, but after nearly a year I still haven't gotten to it).  Will I be permitted to do my development, and contribute changes, using hg and the current Fedora kernel?
> 
> Lurker testers and wannabe developers need to know!
> 
> -BobC

if you look at the history of v4l, you can be sure that we always tried
to have as much testers as possible.

During the 2.5.x development cycle, in fact all testing and development
was done on 2.4.x. We did not even have any SCM that time, but on 2.5.x
problems Devin is pointing to were enormous.

Mike Krufky and Mauro were always strong in defending backward compat,
also after taking over Gerd's cvs he later had.

Mauro, in the beginning, even always tried to keep usability back to
2.4.x kernels with v4l2 revision 1 and I did warn him, that this task is
quite impossible to satisfy, but we had developers on totally outdated
semi proprietary stuff, years in delay, asking exactly for that.

On latest discussions, how far we should keep backward compat after i2c
improvements, you saw Mauro again voting for as far as ever possible.

Be sure, we don't want to lose you guys!

Cheers,
Hermann




--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux