Announcement

Collapse
No announcement yet.

There are many more readers than members

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #71
    Originally posted by HokTar View Post
    Obviously these were not direct questions, anyway. Some heads up are always appreciated, though.

    On the other hand I think we all know the answers which are "not yet" for all questions. Please reread my previous post to understand my point!
    I guess what I'm saying is that everything we know *has* been communicated, and that you're asking for a concise summary of plans which have not been made yet...

    ... and as a result you ain't gettin' them

    Comment


    • #72
      Originally posted by bridgman View Post
      I guess what I'm saying is that everything we know *has* been communicated, and that you're asking for a concise summary of plans which have not been made yet...

      ... and as a result you ain't gettin' them

      You know that my only problem is that you say nothing about the plan which we discussed in February and I referred to that in my first post in this thread. Back then you said (or wrote actually) that it is on your todo list.

      I might have made one mistake: I mentioned the (almost) banned word "ETA".

      Could you please just ignore that and outline a "roadmap"?

      I tried to give an example of what I mean but maybe that is not a good/feasible one. As an engineer I trust other engineers (at least those who proved themselves worthy of it ) so I think you can figure out an intermediate solution.

      Thanks for your time, anyway. I really appreciate it.

      Comment


      • #73
        Edit: I tried...

        I might be in a misunderstanding. Are you really saying that there is no such roadmap? So everyone is just "cluelessly" developing what he feels a good next step?
        (I might exaggerate here a bit but I hope those involved get my point.)

        Comment


        • #74
          Sorry, I'm drawing a blank on what that plan was. Or did we just discuss the need for a plan ?

          You mentioned in your first post from this thread that the order of implementation was essential, but that is going to become increasingly hard to provide now that the re-architecture work (which enforced a degree of sequentiality on the deliverables) is largely completed.

          A year ago I was able to give you a pretty good summary of the sequence in which work would be done, but that sequence was determined by architectural constraints ("first you pillage, *then* you burn") not because I could control (or even predict) what the community developers would be doing.

          Now that the transition from "old stack" to "new stack" is largely completed, we're back to the normal style of open source development, where new features and initiatives are largely independent of each other and progress depending on the degree of interest each developer has in a given area.

          I can tell you the priorities that AMD is setting for the short term (Evergreen, getting ready for Fusion, supporting the other devs which probably touches on all the areas a bit) but that's really the only things we can predict with any confidence.

          Put differently, the roadmap now has a lot of parallel lines with little arrows heading off to the right, all running more or less independently.

          Comment


          • #75
            What I'm saying is that there are far fewer dependencies between areas than there was during the last two years, so the *rate* of progress of each area is much harder to predict.

            Back when everyone agreed that A had to be implemented and working before it made sense to spend much time on B you could count on most of the devs helping with A.

            Now that D, E and F are all independent there's no reason for everyone to work on D first, and the allocation of time between D, E and F will be largely determined by "what the developers feel like working on".

            So... the *design* aspects are still as coordinated as ever, there's just less need for coordination because invasive work on the really interdependent parts of the stack has largely been completed.

            Comment


            • #76
              Hmmm, interesting. Now I can see your dilemma and how my questions were "wrong". So yeah, you gave me the answer I was looking for.

              On the other hand, if this is the case than probably the devs themselves should take their time and write a blog post every (other) week shortly describing what they are working on and what is the purpose/aim of that. I mean really, 5-10 sentences wouldn't hurt and take away the time from coding!
              I try to give an example: Marek has submitted a lot of code recently for the r300g driver as git shows. But I'm an end user so the git commits don't give me much information on the benefits of the commits. They shouldn't either as that is not the purpose of them. But still, some more insight on a less techie level to what is going would be nice.

              Just writing this stuff I realised that most probably it is Phoronix which I am wishing for. Maybe I just got dragged in too deeply into these matters that the flow of information from Michael is not enough...

              As a sidenote it is good to be back on the interesting stuff!

              Comment


              • #77
                Sounds to me like you guys need a much better development framework. I have mentioned Launchpad before, but there are other good ones such as GNU Savannah, GitHub, and Google Code.

                In order to reap the full benefits of open source development, you must have a clear roadmap and development structure. It seems like you are reaching the limits of git and mailing lists. People need to know what to code and what to test in order to contribute and your current system makes it exceedingly hard to do so.

                Perhaps look into putting each of these features (such as KMS, DRM and Mesa) onto different branches and split up the development tree among them. Periodically merge the braches to creaste new builds.

                The Radeon drivers are also seriously lacking in end-user documentation. Perhaps put up a FAQ for users to read and list all the problems and pitfalls they may encounter. Distributions are great, but they can't do all the documentation and testing for you. You have to put a system in place to allow your end users and testers to contribute as well. And right now, frankly there isn't much of one.

                Comment


                • #78
                  "That, detective, is the right question. Program terminated."

                  It sounds as if maybe it's time for TIRDC (The Irregular Radeon Development Companion) to come back to life now that the Great Architectural Transition is largely done and everything is kinda going back to normal development again.

                  I'm guessing that you're looking for something like :

                  http://tirdc.livejournal.com/21826.html

                  Does that seem about right ?

                  Comment


                  • #79
                    About there. Maybe make up a proper web page for the drivers to. Modern CMS frameworks make it stupidly easy to make and maintain complex websites. I can and will be willing to help out.

                    I highly recommend Drupal as it is the most configurable and flexible of the frameworks, but it is a bitch to learn. Huge websites such as http://www.whitehouse.gov , http://www.economist.com , and http://www.ubuntu.com all use it.

                    If you want a tech demo, check out http://infinityos.net . I basically made that web page in three days. I've honestly barely scratched the surface of what is possible with Drupal. Hell, I got lazy and just used the default theme.

                    Comment


                    • #80
                      Originally posted by darkphoenix22 View Post
                      Sounds to me like you guys need a much better development framework. I have mentioned Launchpad before, but there are other good ones such as GNU Savannah, GitHub, and Google Code.

                      In order to reap the full benefits of open source development, you must have a clear roadmap and development structure. It seems like you are reaching the limits of git and mailing lists. People need to know what to code and what to test in order to contribute and your current system makes it exceedingly hard to do so.

                      Perhaps look into putting each of these features (such as KMS, DRM and Mesa) onto different branches and split up the development tree among them. Periodically merge the braches to creaste new builds.
                      Not sure I agree there. You are describing systems to let large numbers of developers collaborate efficiently on large projects without getting in each others way. Graphics driver development is more like the opposite situation - 20 or 30 projects that need to be done, each with a fraction of a developer at best.

                      IMO the top priority is documentation and infrastructure which could help potential new developers decide if this is an area where they could enjoy working. If we can double or triple the number of active developers then we might get to the point where co-ordinating their activities made a difference, but I think we have a long way to go before we even get to having 1/2 a part time developer for each initiative.

                      Originally posted by darkphoenix22 View Post
                      The Radeon drivers are also seriously lacking in end-user documentation. Perhaps put up a FAQ for users to read and list all the problems and pitfalls they may encounter. Distributions are great, but they can't do all the documentation and testing for you. You have to put a system in place to allow your end users and testers to contribute as well. And right now, frankly there isn't much of one.
                      I do agree with this one, although with a twist. There are already dozens of these systems in place, one for each distro, all active but all imperfect in their own way (mostly out of date info). I do think users would be better served by a single system with sections for distro-independent and distro-specific information.

                      Comment

                      Working...
                      X