On 13 April 2013 09:10, Olemis Lang <[email protected]> wrote: > 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.
I raised these ideas. Yes, that's what I meant: Embedding Bloodhound content into external sites. I agree that those ideas individually may be too small, depending on how ambitious you want to be with tackling them, so you could combine several ideas into one proposal instead: https://issues.apache.org/jira/browse/COMDEV-85 https://issues.apache.org/jira/browse/COMDEV-90 https://issues.apache.org/jira/browse/COMDEV-91 Cheers, Joe > 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. > -- Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/> @jdreimann <https://twitter.com/jdreimann> * * *Join one of our free daily demo sessions on* *Scaling Subversion for the Enterprise <http://www.wandisco.com/training/webinars>* THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. If you are not the intended recipient, please notify us immediately and destroy the message without disclosing its contents to anyone. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. The views and opinions expressed in this e-mail message are the author's own and may not reflect the views and opinions of WANdisco, unless the author is authorized by WANdisco to express such views or opinions on its behalf. All email sent to or from this address is subject to electronic storage and review by WANdisco. Although WANdisco operates anti-virus programs, it does not accept responsibility for any damage whatsoever caused by viruses being passed.
