Hello,
Duggan, the repository you organized is serving as the base to my work, I
am using your repo as the reference repo. So I would like you to keep it as
it is. I was learning how to go about the changes I need to make to the
dragonflyBSD's sources (mostly looking at hamishm's files and comparing
them to the dragonflyBSD's ones and rationalizing what changes he made and
why).
Kallisti5, yes I think that is very necessary, or else way down the road if
someone tells me to change something, that would be a problem.Thanks for
the suggestion. I'll start preparing the technical report right away.
Thank you
-----
Vivek
On 23 May 2017 6:20 a.m., "kallisti5" <kallisti5@xxxxxxxxxxx> wrote:
On 2017-05-22 17:41, James Taylor wrote:
Hey guys,
Apparently there's been an issue about how I organized the repo for
Vivek to work in for his project. I did so to try to make it as easy
for him to work in as possible, but apparently that was a bad idea. So
my question is, how would you suggest I roll back those changes?
Waddlesplash mentioned he helped you out via PM's.
It wasn't as much the layout for me, just it seemed like the goal
was to make every current graphics driver 'legacy' while intel
is the only target for the gsoc project.
Vivek, I think the missing piece is a rough technical write up
of what your plans are.
For example (don't use this as a roadmap, it's a nonsense example)
* I plan on moving the current drivers into a legacy subdirectory
* The driver API will be redesigned with a new interface for
DRM opcodes from the drm libraries.
* DRM injects the honey into the hive so the worker bees blah
This is a complex gsoc project. By voicing major architectural
changes to the mailing list, it gives the mentors time to give some
guidance and feedback. After the foundations are hammered out, the
feedback loop becomes less critical.
This goes to all GSOC students. Please spam this mailing list
(and IRC) to your heart's content if you have any question at all
about things. That's what it's here for :-)
No response after a day or so generally means everyone is ok with
the proposals.
Similar concept:
https://en.wikipedia.org/wiki/Rubber_duck_debugging
-- Alex
