<Moved into this thread to provide clarity to those that come after us>
On Wed, Dec 19, 2012 at 8:21 AM, Roberto Rosario <[email protected]> wrote: > Thanks! I'm still going through your messages thinking how to best organize > all the topics mentioned in an open way. A Wiki on github or on > dev.mayan-edms.com comes to mind. And that's the rub - it's quite difficult to imagine where to start, how to go about it and what software is best to do it. They are quite difficult questions to answer correctly for any given project. I would suggest we run with your original idea of a GDoc. Then we do simple descriptions: A Document is a Model, it has fields x, y, z and methods a, b, c. I normally then describe the non-obvious fields ("this can be disability can be NullBoolean as people may choose not to answer the question") and the non obvious methods ("we override save to slugify the name for slug field") This way we can see the obvious weirdnesses - like what is the mark_indexable()? etc... It can be a slog, but will be well worth it, especially for clarifying ideas in your own head, and making an easier pathway into the code for others. cheers L. On Tue, Dec 18, 2012 at 1:41 PM, Lachlan Musicman <[email protected]> wrote: > Of course, I've managed to skip over some other initial thoughts I've > had as well: > > - I think that the best thing to do will be to move the dev branch to > dev-old and start a new dev based on the current master > - that way people can start by doing small tasks almost immediately - > as I was reading through the code I noticed some quick fixes that I > could have done but didn't > - regards the haystack/search: 1. Why must the search solution be > python? I set up Solr (cluster friendly) quickly and easily using > haystack. Is search something that we don't integrate, but instead > provide "easy documentation on how to set up for Solr/Whoosh"? Also, > since you are using pbs anyway, surely a cron job is easy enough to > automate? > - moving to newer Django has other possibilities and advantages than > just CBV. New layouts (and therefore paths) is quite handy. Plus, the > deprecated stuff.... > > - Why a design doc? The first thing I wanted to work on was updating > the requirements, and for some reason I started with > djangorestframework -> rest_framework. Which I did. But without being > able to see where the serialisation was meant to work or what it was > used for, there was no way to test if I'd broken something.... > > Anyway, just a bunch more thoughts - cheers > L. > > On Tue, Dec 18, 2012 at 10:23 AM, Lachlan Musicman <[email protected]> wrote: >> 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 > > > > -- > ...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 --
