Stephen Lau wrote: > Garrett D'Amore wrote: >> Stephen Lau wrote: >>> As Shawn noticed... the open-sourcing of the e1000g driver yesterday >>> contained proprietary source code headers in the diff. This was a >>> mistake by the engineer moving the code, and needs to be re-bridged. >>> We can't have proprietary source code headers in public open source >>> code, no matter how minor and trivial the code is. >>> >>> I've re-bridged the putback in onnv/onnv-gate, which means you will >>> need to roll your repositories back to revision 3567:6d1c4dd92b63, or >>> else your repositories will grow a new head. >>> >>> Thanks, and sorry for the inconvenience. >>> cheers, >>> steve >> >> Events like this are confusing to me. Please bear with me. >> >> Maybe I'm just naive in my dealings with Hg, but is the need for this >> kind of special attention a result of Hg itself, an artifact of the >> current Hg bridge, or the result of rolling back a repository instead of >> just "patching forward" (i.e. not treating the backout as 2nd update, >> but instead actually "undoing" the original commit?) >> >> I'm not sure this is the same kind of Hg snafu in the past, but the >> upshot is that I'm not sure whether I should be using Hg at this time, >> or should I be sticking with SVN? (I don't work on my ON clone every >> day; the last couple of times this happened I just deleted my old >> workspace and started with a fresh one.) >> >> Again, I apologize if I sound confused -- but I am. I'd like to hear >> some "official" word on what those of us on the outside _should_ be >> using as the most up-to-date source for Solaris. > > Hi Garrett, > It's an artifact of rolling back a repository, and is not an > artifact of Hg in any way. The point of an SCM is to make sure no > history is ever lost - correct? The problem is, due to the legal > aspect of this, we need to make the repository "forget" that it ever > happened - so it's going counter to what an SCM should be doing. We > would have this exact same issue whether it was CVS, SVN, or even good > old Teamware/SCCS. > The problem with "patching forward" is that the mistake is still > in the history.. > onnv/onnv-gate continues to be the most up-to-date source for > Solaris. > > cheers, > steve
Thanks. Given that part of the point of the putback for e1000g was to open source it, I would have expected the reviewers to carefully checked for coverage before it was released. (Both technical and legal reviewers.) I would try to emphasize to the individuals involved that: a) failure to catch this ahead of time has placed the company at risk b) it cannot be undone (see Keith's message) -- please explain to lawyers, etc. involved automatic mirroring c) backing out like this has a distinctly negative impact on the entire OpenSolaris community This doesn't mean that it won't happen again, but it does reduce the likelihood by making folks aware of the impact. When I have open sourced stuff that I developed for another company I have always had to jump thru hoops to get permission for everything -- but those hoops have prevented me from exposing anything without explicit approval from the stake holders (cf. NetBSD's radeonfb, which I had to get permission from both Tadpole/General Dynamics and ATI. If ATI changes their mind, too bad. The source is already released, and cannot ever be "taken back".) -- Garrett D'Amore, Principal Software Engineer Tadpole Computer / Computing Technologies Division, General Dynamics C4 Systems http://www.tadpolecomputer.com/ Phone: 951 325-2134 Fax: 951 325-2191 _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
