Ok, I'm taking it offline for later perusal I'll send through track changes when I have some
cheers L. On Thu, Dec 20, 2012 at 5:19 AM, Roberto Rosario <[email protected]> wrote: > Getting started on organizing all the topics discussed, first step the Mayan > EDMS design doc, here is the links: > > https://docs.google.com/document/d/1TUwWFW5d9lZcoHBKNjdkVwqrqiO1zJhtFDOUU9Tvaf8/edit > > On Tuesday, December 18, 2012 5:40:08 PM UTC-4, Lachlan Musicman wrote: >> >> <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 > > -- > > > -- ...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 --
