On 4/12/13, Shiva Teja <[email protected]> wrote: > Hello everyone. >
Hi ! Welcome to Bloodhound dev list :) > I am Shiva Teja, 2nd year CS undergrad, IIT Mandi, India. Nice to meet you . > I'll be > participating in GSoC 2013. I came to know about Apache Bloodhound today > and I've decided to work on it. Good ! Thanks for your interest in Bloodhound . [...] > > About > the WYSIWYG editor, I came across two of these recently on Hacker news. > http://imperavi.com/redactor/ and > http://jhollingworth.github.io/bootstrap-wysihtml5/ . Can we use something > like these ?. > I'll take the liberty of suggesting CKEditor . Mainly because it's well supported, stable and pluggable . I'm not the submission author though , so I might have misunderstood the goals and scope in this case . > 2. Twitter card integration(and other social tags): > So just add meta tags dynamically ? Looks easy. Is it worth working on this > project for 2 months ? I think this should not take much time. Correct me > if I am wrong. > Once again I'm not submission author in this case . I'm not sure of whether this is about incorporating external content in web sites powered by Apache™ Bloodhound or vice versa . Nonetheless I'll take the liberty of suggesting something related to the later case i.e. to create a generic solution to embed Bloodhound widgets in third-party sites . Adding a new UI item to easily retrieve embed code would be great too End-users would appreciate that . If you need any help I'll write documentation about Apache™ Bloodhound widgets architecture , and related subjects . [...] > > 4. Patch workflows tightly coupled to version control: > This one has my attention. I might get to learn a lot from this project > compared to others. > I submitted this one . The idea in this case was based on existing solutions e.g. Mercurial MQ extension (which I use quite often , even to submit patches for Bloodhound [1]_ ) . Nowadays patch submission works this way in practice : 1. Issue is detected and new ticket is created 2. Solution is developed against changeset R 3. Resulting diffs are attached to target ticket * in case of dealing with multiple patches there is no support to track neither patch order * ... nor qparent changeset (<= talking in terms of MQ extension ;) 4. Patch needs further improvements . Successive versions are handled mostly in two ways * patch attachment(s) are overwritten thus losing patch history * newer files are uploaded 5. By the time patch is finished more changesets were added in upstream repository . In order to keep history as clean as possible it has to be rebased against HEAD (svn, git) tip (hg) or ... 6. Finally apply the patch As can be seen all this process is not really well supported by tools . I'll explain how I develop patches (but beware of the fact that this is not the only way ;) a. I use patch queue repositories powered by Hg MQ extension branches , so initially we need hg init --mq b. In patch queue repository there is a branch for each ticket created in the issue tracker , which is needed to switch back and forth between tickets developed in parallel and still get consistent patch order (i.e. series in Hg MQ) c. in each ticket branch there's a folder e.g. t123 where patches for target ticket (123) are stored d. seldom patches for ticket T1 depend upon patches submitted for ticket T2 . That means merging branches for T1 and T2 in the patch queue repository. Considering (c) the only possible source of conflicts is patch order (e.g. series file in Hg MQ) e. Along the way patches are improved , rebased , changes may be reverted , etc ... f. hg qfinish patches when ready for commit Some steps in this approach are automated by Hg MQ itself . Another (incomplete) patch development workflow is offered by Bitbucket . To the point , initial goals we have in mind are the following : 1. Identify patch workflows and associated details that might be automated e.g. (a) , (b) , (c) , * In the case of (d) above ticket relationships (i.e. bep:0006) might serve as a reference to suggest merges * ... and vice versa , merges in patch queue might be interpreted as a relationship between tickets * in the case of (f) if patches are qfinished then patch order has to be updated accordingly e.g. [2]_ 2. Track patch metadata and display it in UI * Patch order * Latest changeset in upstream repository on top of which the whole patch queue could be applied successfully . * Test summary when applied against changeset above (see 3 below) 3. Assist users when performing simple steps e.g. * (a) , (d) above * ... and more ... ;) 4. Integrate patch workflow with continuous integration tools (preferably Jenkins ;) * Trigger build jobs on patch submission to check whether a queue will introduce regressions , etc ... 5. Integrate patch and ticket workflows * change state on patch submission (e.g. new => review) * close ticket-specific branch in patch queue repository if ticket is closed . + e.g. hg ci --mq --close-branch -m "..." Those are just ideas on how tools could work in harmony to support patch development workflows thus easing the process for users by providing constant feedback about patch state without almost no human intervention . All this would save a lot of time thus favoring patch acceptance . We are interested in using something like this in production . If it seems to be quite big in scope , any initial subset that could be developed in two months would be a successful (very welcome) GSoC contribution afaict . > > Are there any "must" do things like fixing a few bugs before I apply ? Or > can I just work on code samples for the project ? > I honestly do not know . > Any comments/suggestions ? > above ;) .. [1] https://bitbucket.org/olemis/bloodhound-mq .. [2] https://bitbucket.org/olemis/bloodhound-mq/commits/76e6b3863e59 -- Regards, Olemis.
