Re: Getting stuck into apps-team and modules-team
On Thu, Aug 13, 2009 at 04:23:29PM +0200, Piotr Ożarowski wrote: > feel free to commit your changes, we can always revert it ;-) > (you'll get private replies from those subscribed to -commits if > there's something wrong) Just call me cautious :) > > I'd like to contribute to both teams (so by all means say 'please do this > > for us') but not at the risk of disrupting their workflow. > > see this thread: > http://lists.debian.org/debian-python/2008/03/msg00014.html > > my reply (and I still use these rules when I do changes in team packages > or when I sponsor team uploads) is here: > http://lists.debian.org/debian-python/2008/03/msg00016.html Aha, thanks. > -- > -=[ Piotr Ożarowski ]=- > -=[ http://www.ozarowski.pl ]=- > > Cheers, -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: Getting stuck into apps-team and modules-team
On Thu, Aug 13, 2009 at 04:14:30PM +0200, Sandro Tosi wrote: > check with the current "real" guy behind the package, it's the safest way. Of course. > > like (examples) dpatch/quilt, > > I'd say dpatch - it's easier to use it in SVN > > > cdbs/debhelper/dh, > > I strongly encourage to use debhelper, and others do the same Any (team) thoughts on debhelper vs dh's autosequencer? Personally, I like dh in simple cases and with overrides, but it makes backporting trickier because the support hasn't been in a stable release (AFAIK). > > python-central/python-support and so on? > > python-support is what we're standardizing on, so feel free to migrate > to pysupport is you stumble upon a pycentral package. Right. > Ah, a nice communication medium is IRC: if you like, you can find us > at #debian-python on irc.debian.org OFTC network. Ok. I'm often not near IRC, but I drop in from time to time. Cheers, -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: Getting stuck into apps-team and modules-team
Hi Dne Thu, 13 Aug 2009 15:00:15 +0100 Jonathan Wiltshire napsal(a): > Where the team is just an uploader, I'm inclined to leave the maintainer to > ask for help when s/he needs it. But where packages are fully under the team's > scope, is there any protocol for starting work on an oustanding package? Well the packages are team maintained so I really do not object anybody to fix problems in packages where I'm maintainer and team is a uploader. However you should avoid some disruptive changes in this case (like changing build system). For things where team is a maintainer, you can probably do anything you want with that. But asking other involved people might be still nice to avoid duplicating the work. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Getting stuck into apps-team and modules-team
[Jonathan Wiltshire, 2009-08-13] > I've looked at a few packages in the repositories for these teams, but I'm > reluctant to start making changes without making sure it's not going to > upset anybody :) feel free to commit your changes, we can always revert it ;-) (you'll get private replies from those subscribed to -commits if there's something wrong) > Where the team is just an uploader, I'm inclined to leave the maintainer to > ask for help when s/he needs it. But where packages are fully under the team's > scope, is there any protocol for starting work on an oustanding package? > > Particularly where there are bugs or new upstreams available, is it acceptable > to just get stuck in, or is wise to contact the last changer (I found little > evidence of this on lists, but I may have been looking in the wrong > places)? I usually ask via IRC or in private mails > I'd like to contribute to both teams (so by all means say 'please do this > for us') but not at the risk of disrupting their workflow. see this thread: http://lists.debian.org/debian-python/2008/03/msg00014.html my reply (and I still use these rules when I do changes in team packages or when I sponsor team uploads) is here: http://lists.debian.org/debian-python/2008/03/msg00016.html -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Getting stuck into apps-team and modules-team
On Thu, Aug 13, 2009 at 16:09, Jonathan Wiltshire wrote: > On Thu, Aug 13, 2009 at 03:00:15PM +0100, Jonathan Wiltshire wrote: >> I've looked at a few packages in the repositories for these teams, but I'm >> reluctant to start making changes without making sure it's not going to >> upset anybody :) > > And of course, I was bound to forget something. Last question: what is the > consensus on deep packaging changes, check with the current "real" guy behind the package, it's the safest way. > like (examples) dpatch/quilt, I'd say dpatch - it's easier to use it in SVN > cdbs/debhelper/dh, I strongly encourage to use debhelper, and others do the same > python-central/python-support and so on? python-support is what we're standardizing on, so feel free to migrate to pysupport is you stumble upon a pycentral package. > -BEGIN PGP SIGNATURE- (+ 18 others line of signature) ditto. Ah, a nice communication medium is IRC: if you like, you can find us at #debian-python on irc.debian.org OFTC network. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Getting stuck into apps-team and modules-team
Hi Jonathan, first of all, thanks for your interest in helping the teams! On Thu, Aug 13, 2009 at 16:00, Jonathan Wiltshire wrote: > Hi, > > I've looked at a few packages in the repositories for these teams, but I'm > reluctant to start making changes without making sure it's not going to > upset anybody :) > > Where the team is just an uploader, I'm inclined to leave the maintainer to > ask for help when s/he needs it. But where packages are fully under the team's > scope, is there any protocol for starting work on an oustanding package? Unwritten policy (or maybe it's written and I don't remember where ;) ) says: if the team is in Maintainer field, any member can do changes and upload the package; if the team is in the Uploaders field, any member can do changes but an upload is to be ack'ed by the maintainer. > Particularly where there are bugs or new upstreams available, is it acceptable > to just get stuck in, or is wise to contact the last changer (I found little > evidence of this on lists, but I may have been looking in the wrong > places)? Well, our course it would be nice to contact the current "real" person behind a package, but it's not strictly needed, see above :) Some things you might work on: - bug fixing - bug forwarding upstream - general cleanup of packages - review of packages in need for a sponsor (you can't sponsor, but you can screen the package to spot something wrong) - (cautious) upgrade to now upstream releases. have fun BTW: please do something for your signature: is as long as this email, and this a long mail of yours - it only adds confusion in the text. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Getting stuck into apps-team and modules-team
On Thu, Aug 13, 2009 at 03:00:15PM +0100, Jonathan Wiltshire wrote: > I've looked at a few packages in the repositories for these teams, but I'm > reluctant to start making changes without making sure it's not going to > upset anybody :) And of course, I was bound to forget something. Last question: what is the consensus on deep packaging changes, like (examples) dpatch/quilt, cdbs/debhelper/dh, python-central/python-support and so on? -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: Getting stuck into apps-team and modules-team
On Thu, Aug 13, 2009 at 03:00:15PM +0100, Jonathan Wiltshire wrote: > I've looked at a few packages in the repositories for these teams, but I'm > reluctant to start making changes without making sure it's not going to > upset anybody :) If I am the sole maintainer/uploader, feel free to make changes and (even) upload my packages. You can also ask me for sponsorship. :-) As for others, you would want to just check with them to be sure, though I doubt that most people would really mind accepting help... Thanks. Kumar -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Getting stuck into apps-team and modules-team
Hi, I've looked at a few packages in the repositories for these teams, but I'm reluctant to start making changes without making sure it's not going to upset anybody :) Where the team is just an uploader, I'm inclined to leave the maintainer to ask for help when s/he needs it. But where packages are fully under the team's scope, is there any protocol for starting work on an oustanding package? Particularly where there are bugs or new upstreams available, is it acceptable to just get stuck in, or is wise to contact the last changer (I found little evidence of this on lists, but I may have been looking in the wrong places)? I'd like to contribute to both teams (so by all means say 'please do this for us') but not at the risk of disrupting their workflow. Thanks for your advice. -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature