Just a quick update: I haven't abandoned the patches, but I'm currently with our main team in Mountain View, and swamped with work. Since gpylint is 'only' a 20% project for me, my time to work on this is a little bit short.
// Torsten On Fri, Sep 23, 2011 at 08:41, Sylvain Thénault <[email protected] > wrote: > On 23 septembre 14:57, Torsten Marek wrote: > > I don't know why this was marked private, maybe that's the default and I > > didn't change it. > > Fixed. > > It works. So let's move on :) > > If you look at the 'patches' tab of https://www.logilab.org/project/pylint > , > you'll see your patches (actually at time where you'll look at it you'll > see only one of them since I've applied the other one, which you can see at > https://www.logilab.org/patch/76928). > > I've made a few cosmetic changes to the first one, I'll let you do most > of them on the second one :) > > * patch names should end with the .diff extension, that ease proper > display of the patch in the web ui > * add a ticket in the tracker describing the issue/evolution > * set a commit message using -m/-e option of hg qnew/qrecord/qref > * this commit message should somewhat contains 'closes #1234' where > 1234 is the number of the ticket > > The later point will help by automatically linking the patch to the ticket, > which will also be closed when the patch will be applied. > > Also, notice patches have a state in the tracker, telling if it's > in-progress, > being reviewed or applied (or rejected or...). Beside that a logilab guy > has > to pull from your repo first to get your changes in the pylint main patches > repo, > you can ask for review of a patch using the web ui or by having > "<the name of your patch> ready for review" in the commit message of the > patches > repo (I know having two repository makes things harder to grasp ;) > > More on those magic words on https://www.logilab.org/doc/vcreview_dailyuse > , > though you should need almost only that one. > > So now we have a workflow around your patches: > > * you can ask for review of a patch > > * we can discuss using comments/tasks that may be added on the patch > and/or > its revisions > > * we can apply it, or ask for rework > > For instance let's see the second patch: > > https://www.logilab.org/patch/76927 > > You'll see two revisions, because I've commited slight modifications on it. > Also you'll see in the workflow history I did change its state to 'pending > review' as you would have done. Now if you look at the 'tip' tab you'll > see the content of the patch, with some tasks and comments I added. > Hence I've 'ask rework' on the patch by rechanging its state. > > Now discussion should be around the patch instead of on the list. Don't > hesitate > to ask or comments or tell about things you think you should be able to do > but > you can't. We use this review system mainly internally and there may be > some > bugs or misconfiguration for external contributors. > > Hope you don't bother that long mail! I'll grab this to a card on > logilab.org > for other contributors :) > > Many thanks for your patches and for taking time to try this out. > Regards, > -- > Sylvain Thénault LOGILAB, Paris (France) > Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations > Développement logiciel sur mesure: http://www.logilab.fr/services > CubicWeb, the semantic web framework: http://www.cubicweb.org > > -- Site Reliability Engineer ∘ Google ✚ ∘ ⬕
_______________________________________________ Python-Projects mailing list [email protected] http://lists.logilab.org/mailman/listinfo/python-projects
