As you have noted I have avoided to the DVCS matter because I knew it is a slippery slope and because it don't really matter. Launchpad allows you to import branch from many of the popular VCS [1] cvs, svn, git, hg. The documentation mention that drupal is using this feature to import on a regular basis their "trunk" which is control in a CVS repository. This import capability is the reason I kept the DVCS aspect out of my initial post my understanding was that nothing describes before would require a move from svn to bzr for django's "canonical trunk".
I am adding a link to the "Karma calculation" [2]. Regards, --yml [1] https://help.launchpad.net/Code/Imports [2] https://help.launchpad.net/YourAccount/Karma?action=show&redirect=KarmaCalculation On Apr 25, 11:15 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sun, Apr 25, 2010 at 10:54 PM, yml <yann.ma...@gmail.com> wrote: > > Hello, > > > On Apr 23, 12:32 pm, Russell Keith-Magee <freakboy3...@gmail.com> > > wrote: > >> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck <jdu...@gmail.com> wrote: > >> > Commiters and triagers, > >> > I've gone through the contributing doc and tried to identify places > >> > that tickets might get stuck (or other places that automation might > >> > smooth the process). > >> > If you could take a few minutes to give feedback on the list, > >> > hopefully prioritizing in your named column with +/- 0/1, it'd help me > >> > focus effort. > > >> Comments by row number from the spreadsheet: > > >> 2: Would be useful as a work list for people looking for. It would > >> also be useful if tickets could be auto-disowned; i.e., if there's no > >> activity from the owner after a month, post a comment asking for a > >> status update; if no activity after another month, remove the > >> ownership. This might get annoying for long-lived tickets with an > >> owner that has a vested interest, though. > > >> 3: That's essentially just a list of people who can't (or won't) read > >> the contribution guide. I'm not sure tracking that stat would help. > > >> 4: Is essentially a list of 'active tickets'. I keep track of that by > >> manually eyeballing Trac updates; it might be a useful stat to have > >> exposed for people who don't watch Trac as much as I do. > > >> 5-10: The most useful of the lot for me personally. An automated > >> process that applies patches and runs tests would be nice; if it can > >> autocheck the appropriate flags ("patch needs improvement", "needs > >> tests" etc) that would be even better. > > >> There are edge cases that will make this difficult; e.g., patches that > >> span multiple diffs, or tickets where the submitter provides multiple > >> alternative patches. > > >> I would also add to this list checks that the test is actually a > >> regression test - that is, that the contributed test fails unless the > >> rest of the patch is applied. > > >> I'm also not sure if a direct email or adding a comment to the ticket > >> in trac would be the best approach. I suspect a comment would be > >> better, since it provides a public record of the automated reporting > >> activity. > > >> 11: Useful as a working list for someone looking for something to do. > > >> 12-14: Nifty stats, but I'm not sure they would help much > > >> 15-17 would be useful if we wanted to audit the work of volunteers, > >> but that's not really something we do. I keep a rough eye on every > >> ticket change as they come in; if something looks way off, I'll jump > >> on it, but otherwise I just live and let live and let the crowd sort > >> it out. > > >> 18: I'd be interested to see what this produces. My gut tells me that > >> tags aren't used often enough (or consistently enough) for this to > >> provide any real patterns. However I might be wrong. If it works, it > >> might be a handy way to work out common themes that need a broader > >> approach. > > >> 19: Again, like 3; this is just a list of people who don't follow process. > > >> > Also, I'm planning on building the tool using the XMLRPC trac plugin > >> > (I'm assuming the live app can't easily have access to the DB, or that > >> > the RPC API's abstractions are useful at the app level). Correct me > >> > if I'm wrong. > > >> If you're looking to implement this as a standalone thing, it probably > >> *could* access the Trac DB directly, but in the interests of > >> everyone's sanity (including Trac's) it's probably best to keep to > >> public interfaces like XMLRPC. > > >> However, it's also possible that some of these features would best be > >> implemented as a Trac plugin. > > >> I'd also suggest that before you embark on a big Trac-specific > >> tool-building exercise that we investigate what we could gain by > >> moving to another bug tracking tool. I'm not a huge fan of Trac - it's > >> got lots of quirks and bugs that annoy the bejezus out of me, and > >> there are many aspects of Django's development process that aren't > >> well suited to Trac's model (as the recent discussions about process > >> have indicated). If there are tools out there that are better suited > >> to our needs, I'm interested in hearing options. > > >> Caveat: This isn't an invitation for people to just start listing Trac > >> alternatives. If we're going to change, we're going to change because > >> of a compelling reason, not just so we can change the color of the > >> furniture. If you want to propose an alternative, you need to provide > >> a list of features that Trac doesn't have, but are well aligned to > >> Django's development process. > > > I have been thinking about this for a while and since launchpad [0] > > has been drastically improving its usability recently. It is now > > reasonably fast ... Launchpad.net provides a set of features that are > > well aligned with django development process and not supported by > > Trac. > > > * It has a built in notion of reputation "karma" which get credited > > each time a user interact with the project on launchpad (Translation, > > bug, code) > > * It has a python api [2] to crunch the data > > * There is a built in code review [3] mechanism that links on a single > > page the diff the comments and the original branch and the > > destination. More explanation about the process can be found here : > > [4]. It is worth mentioning that the code review process provide a > > simple UI to spot the merge proposal that "needs review" [6]. The > > "code that failed to merge" is segregated in its own category. > > * Anybody who is interested can contribute code to your project, in a > > simple way, with full version control. They got offered the same set > > of tool than the core developer to cook their proposal (Blueprint, > > dvcs, code review, ...) once they think they their code is ready they > > can propose it via the code review process. > > * it has a web based translation interface [5] > > > Something which is orthogonal to the development process is that it is > > hosted so it might reduce the workload on the Trac admin (disk full, > > diff to big, spam, ...). I hope that this will not trigger a flame > > war with this kind of assertion: github is better because it supports > > git .... I try to keep this post on the macro feature that could > > improve the community involvement and I understand that launchpad will > > not be the silver bullet that will solve all the issues. From all the > > bullet point above IMHO, an integrated code review process would be > > one that could have the bigger impact because it could solve several > > issues that the community have expressed recently : > > * Educate the community : Subscribing to the code review would be an > > extraordinary tool to get up to speed, to understand what is required > > to get a modification (bug fixes, enhancements) in. The step to start > > to becomes active on django-dev is too big, this could help to make it > > more accessible. > > * Open discussion : On the modification, the advantage there is that > > on a single page we have all the information needed to understand the > > context the 2 branches, the diff, and the comments > > * We could eventually add a bot to that review in order to make sure > > that the proposed branch passes all the tests with several > > configuration: multiple db backend, multiple OS, ... . > > > There might be other advantages/inconvenients that I have not listed > > so I would be glad to hear them from you. > > I'm glad to hear that Launchpad's UI has been improved recently, > because the last time I played with it... well... I wasn't impressed. > > UI issues aside, you raise some interesting features. I can see how > builtin translation and code review interfaces could be very useful; I > would be interested to see how they have implemented their karma > system. > > However, the *huge* impediment that you have avoided mentioning is > that moving to Launchpad would require moving Django to using Bazaar > for version control. Moving to a DVCS has been proposed many times in > the past, and rejected. The reasons for this have been well > documented. I don't see the benefits of a bug tracking system > providing a compelling reason to override the existing arguments. > > Even if we were to adopt a DVCS, given the popularity of Git and Hg in > the Django community, adopting Bazaar would be a strange choice for us > to make at a project level. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
