Roberto, Hey thanks for the big reply. Ok, I understand more now, and I spent an hour or two last night trawling the git logs (offline), the file tree and trying to get dev to run.
I submitted a pull request late last week but removed it Monday morning after I read the in docs (I only remembered I had sphinx installed on Sunday night...) about the gitflow/git branching model. I think a shared doc might be a good idea, can I give a little direction? Obviously Mayan is now quite massive in terms of files and apps. It's quite hard to get a full picture or holistic view of the software apart from the broad "Document Management System" description. I am also somewhat unfortunate in that I don't have a use for it at the moment nor have access to a large install to readily see workflows, errors and obvious needs. So I think a design document of sorts will be handy, so there can be an understanding of what the project is aiming for, and how it's going to get there. This will be the pinnacle of the documentation, since from it all else flows. It will be significantly easier for others like myself to help if we have a guiding light (for want of a better term) showing us the way. For instance, can I recommend/request a UML or mind map diagram of how all the apps inter-relate? You may find that there are too many for a single diagram and that it needs to be broken up a little bit - maybe even one diagram per app. For most apps, it's obvious, ocr for instance. But the subtleties of how each app interacts with other apps is not immediately obvious for all of them, and would be a great help. Obvious examples are the Singleton model - what uses it? Why has it been abstracted? etc. Registration - what is it used for? Is it part of the auth/perms structure? Then there are other factors - like where do you imagine a major refactoring to take place? Is the new User model available in Django 1.5 worth utilising? Should we aim to refactor into Dj1.5 to use it, then drag the rest of the code kicking and screaming into line? My initial thoughts when trying to get Master to run were: 1. - let's clean up the easy pickings: updating all the non-Django requirements, like djangorestframework->rest_framework is a good/easy example. 2. - let's move the code to Django 1.4+, probably worth going to 1.5 since it's almost out and this might take some time 2.a. -- in particular: whenever possible, move function based views to class based view. This is one good reason for the design doc - there are a lot of abstracted ideas (eg, in documents.models) that aren't easy to quickly unravel, but could probably be moved to class based views very easily. 3. Start implementing new features. By definition a new feature is something that currently doesn't exist or doesn't work. IE get the basics working on up to date software, documenting as we go, then push forward with greater understanding. I am aware that none of this is easy or quick, and that people have jobs, families and lives to live. But at the moment "what to do next" is quite opaque. For the record, I'm not so good at testing, and since I find the code base so large and difficult to follow, it's hard to know what behaviour to expect (and hence to test for) - another reason for some good design documents. Anyway, let's start a Gdoc and get started? cheers L. On Tue, Dec 18, 2012 at 7:36 AM, Roberto Rosario <[email protected]> wrote: > Yeah, this is my first attempt at using Haystack and I'm a bit lost at the > moment, thinking about adding back the direct to database search method > until I'm more familiar with Haystack. I also don't like the idea of having > to schedule a job just index the search file, and the default Python based > search backend for Haystack is not cluster friendly. > > There was a rough roadmap online for a while but other commercial software > were using it to get ideas for improvements on their products and not > contributing back in any way to Mayan, so I took it down, and instead > working on features directly requested by users of Mayan. > > I could really use help with documentation and unit tests. > > My initial plan was to keep all the improvements on the development branch, > and work only on bug fixes for the master branch (the stable version). But > since the development and master branch have diverged so much and since the > development branch is still to unstable to call it Mayan 1.0, my new > approach is going to be to bridge the gap by moving code from development to > master. If you or anybody else wants to dig deep into the code, the new > priority is getting as much code moved to the master branch starting with > the navigation, icon rendering and app registration code; code cleanup and > organization (moving links to a links.py file as well as an icon.py file, > remove isolated functions and turn them into simple classes with contextual > methods) is also a big priority to make it easier for developers writing 3rd > party apps for Mayan. > > The changes you noted are a good example of the kind of clean ups taking > place: the api.py file was removed from most apps and is only present if the > app exposes an API for external use by other apps; the register_links method > was removed as links are now a classes (instead of simple non contextual > dictionaries) and registered as soon as they are created only bound to a > view or object class later on with the bind_link function; icons are also a > class, this allows for switching icon sets very easily instead of depending > on the Silk icon set text names. > > If there is interest I can write a shared GDrive document to coordinate > efforts. > > --Roberto > > On Sunday, December 16, 2012 11:57:07 PM UTC-4, Lachlan Musicman wrote: >> >> Hola, >> >> I've forked the dev branch to start working on the code base, and was >> after a few tips: >> >> 1. When running ./manage syncdb --migrate --noinput to get started with >> testing, I'm getting Haystack errors. I've managed to squash a couple, but I >> don't want to stray too far from the herd - there seems to be a missing >> HAYSTACK_SITECONF file? should it be >> HAYSTACK_SITECONF='apps.dynamic_search.search_index' >> >> 2. Is there a roadmap that is being followed or a list of "TODOs" that I >> could use for guidance on what to do next? I've got a couple of ideas, but >> don't want to tread on toes... >> >> cheers >> L. >> >> >> -- >> ...we look at the present day through a rear-view mirror. This is >> something Marshall McLuhan said back in the Sixties, when the world was in >> the grip of authentic-seeming future narratives. He said, “We look at the >> present through a rear-view mirror. We march backwards into the future.” >> >> http://www.warrenellis.com/?p=14314 > > -- > > > -- ...we look at the present day through a rear-view mirror. This is something Marshall McLuhan said back in the Sixties, when the world was in the grip of authentic-seeming future narratives. He said, “We look at the present through a rear-view mirror. We march backwards into the future.” http://www.warrenellis.com/?p=14314 --
