Re: Change in the Mentoring program
> > I would additionally like to propose that assigned mentors not sponsor > > changes by their mentees. This will better integrate mentees with the MOTU > > community, reduce montor worloak, and expose hopefuls to more diverse > > inputs from more MOTUs. > > > [..] > Hm... I like the goal, but I don't see particular harm being done if a mentor > sponsors a mentee, as long as the goal is actually still met. +1 I live the idea of Stage 1 and Stage 2 separation and am willing to shift me efforts to the Stage 1 needs of mentees ( I have no current mentee's ) But not sponsoring a mentee's patches I think ads just a little too much red tape into the program for my taste, I see no problem with it as MOTU should know when they are comfortable uploading a given patch/change , that is of course why they were given upload privileges in the first place. I agree that a Mentor should work to integrate the mentee into the MOTU Community. -- Brandon Holtsclaw [EMAIL PROTECTED] http://www.imbrandon.com signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: postgrey broken in gutsy
Going strong for a week now. As someone not familiar with the review/release process, is there something more I/we can do to get the fixed package approved? This is the only showstopper keeping me from upgrading my mail servers to gutsy. I've also recently begun having problems with clamav under feisty (another story), so the sooner the better as far as I'm concerned. On Nov 8, 2007 2:52 PM, Cyber Dog <[EMAIL PROTECTED]> wrote: > > On 11/5/07, dAniel hAhler <[EMAIL PROTECTED]> wrote: > > Cyber Dog wrote: > > > > > Now, unfortunately, reclassifying the bug seems to have equally failed > > > at getting it any attention. I've gotten several "me too" updates > > > over the past couple weeks, but no updates from developers. It > > > appears most users are resorting to mixing Debian packages into their > > > systems to resolve this issue. I find it hard to believe that > > > importing an existing Debian patch could be so complicated for the > > > maintainers to do, but then again I'm not involved in the process > > > either. The bottom line is, this bug seems to be fairly popular, and > > > rather severe, but apparently we still haven't gotten the attention of > > > the right people. Ideas? > > > > I've looked into it, triaged the bugs around it (it affects subversion, > > too), documented the ways to reproduce the bugs and attached patches for > > hardy and gutsy-proposed. > > > > See https://launchpad.net/bugs/153996. > > > > Unfortunately, quite a lot of programs depend on libdb4.4 (and other > > packages from db4.4), which I have not tested/looked into (see > > "apt-cache rdepends libdb4.4"). > > > > I've documented everything I've found out at the above bug, you may want > > to test the patch (see > > https://wiki.ubuntu.com/UbuntuPackagingGuide/BuildFromDebdiff for > > building fixed packages yourself). > > > > Hope this helps. I'm not really sure about the fix, but it reverts > > something from 8.1ubuntu2 - and the bug in Debian did something similar > > from 8.1 to 9 - and reverted it in version 10 (IIRC). > > > > Thanks for taking up this issue! I've tested your ppa build, and all > the results seem good thus far... postgrey is finally stable, and I've > noted no new problems. Hopefully this fix can get approved for > release. > > > > > -- > > http://daniel.hahler.de/ > > > -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Change in the Mentoring program
> I would additionally like to propose that assigned mentors not sponsor > changes by their mentees. Can you tell me where in the proposal it is said that mentors are required to sponsor mentorees? > I would be willing to sponsor hopefuls if we could make this additional > change. Since the change is there already, how many slots can I consider? Cesare -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Change in the Mentoring program
On Thu, 15 Nov 2007 Cesare Tirabassi wrote: > Before adopting this change, we would like to know how many developers would > be willing to change to this scheme, and how many would be available to help > out with either stage 1, stage 2 or both of them. I'd be willing to help with stage 1: I find that when someone wants to help, and doesn't know how, providing them with links, and answering simple questions isn't that difficult. I try not to do the work, but more provide guidance. On the other hand, if someone doesn't have the technical skills to reproduce a bug from a clear description (and I can reproduce easily), cannot generate a patch file, or the like, I'd be likely to suggest that they might want to work on bug triage for a while, as I don't think they are ready for stage 1. I'm also happy to look at stage 2, although I'd prefer to work with someone whose interests didn't match mine very closely: it's a lot easier to help prepare a plan for work to be done and sponsor arrangement when I am not distracted by attempting to pass my work to the mentee. My current mentee falls between these stages: quite capable of working via email, LP, and IRC; has connections with at least active one team; but is not yet either active enough nor reknowned enough in the community to apply for MOTU. On Nov 16, 2007 Scott Kitterman wrote: > I would additionally like to propose that assigned mentors not sponsor > changes by their mentees. This will better integrate mentees with the MOTU > community, reduce montor worloak, and expose hopefuls to more diverse > inputs from more MOTUs. I'm not opposed to this, but use a different set of criteria: when I've been involved in the production of a patch prior to it reaching the sponsors queue: I consider it a conflict of interest to sponsor. If someone I'm mentoring is generating a lot of patches for sponsorship, many of which are good (my example would be a student on break early this summer), and for which my guidance has been limited to process instruction and encouragements to subscribe to the right mailing lists and join IRC, I don't see an issue with sponsoring the patch. On the other hand, if such a rule is adopted, it makes a lot more sense to impose as a general rule "Do not upload for your mentees" than something like "if you worked on this patch, you shouldn't upload", or "please be sure to apply the same sponsoring guidelines to your mentees as for anyone else", as both the latter are far too subjective. -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Change in the Mentoring program
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 16, 2007 at 05:45:23AM EST, Scott Kitterman wrote: > I would additionally like to propose that assigned mentors not sponsor > changes by their mentees. This will better integrate mentees with the MOTU > community, reduce montor worloak, and expose hopefuls to more diverse > inputs from more MOTUs. I'd just like to say that I do this already. I absolutely refuse to sponsor any work that my mentorees do, for this very reason. - -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email & MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPLQbjVefwtBjIM4RAtGqAKCkie2nsQae/PL6UylQ+mAuNDWQkACfUUIL okRCImV/e9gw6qkdJ2WVgls= =kXuS -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Change in the Mentoring program
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 16, 2007 at 05:08:37AM EST, Cesare Tirabassi wrote: > Before adopting this change, we would like to know how many developers would > be willing to change to this scheme, and how many would be available to help > out with either stage 1, stage 2 or both of them. I'd be for this change, and I'd help with only stage 2, as I find it easier to work with people who know what they are doing for the most part. Yes I can help newbies, but sometimes I find it difficult to explain things that I understand myself, and seem easy to me, but often newcomers don't always understand what I'm saying. I wouldn't say my current mentorees are stage 2, but they are mostly past stage 1, so until they are ready to apply for MOTU, I am happy to continue working with them. After that, as above, I'd be glad to work with stage 2. - -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email & MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHPLPUjVefwtBjIM4RAsmgAJ9n1JafxxUmndHcdVym78tVdnrSBgCfQGcm MW4SNQrMJH+7Buf8YStdb3I= =rKU7 -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Change in the Mentoring program
On Thu, 15 Nov 2007 20:02:42 +0100 Cesare Tirabassi <[EMAIL PROTECTED]> wrote: >> I would additionally like to propose that assigned mentors not sponsor >> changes by their mentees. > >Can you tell me where in the proposal it is said that mentors are required to >sponsor mentorees? You misundertand me. I'm not saying that mentors are required to sponsor changes. I'm proposing mentors be required to not sponsor their mentees changes and that mentees be required to seek sponsorship from others. >> I would be willing to sponsor hopefuls if we could make this additional >> change. > >Since the change is there already, how many slots can I consider? > I'm saying I'd work on sponsoring their changes, not that I'd take on dedicated mentorship. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Change in the Mentoring program
Dear all, as you may know we have been discussing possible ways to make the Mentoring program even more efficient. One possibility raised by Emmet [1] is to split the current program in two stages, not directly linked to each other: Stage 1 would be directed towards newcomers and is meant as an introduction to the Ubuntu development, in particular about the methods, tools and processes that we use. At the end of stage 1 a contributor is supposedly able to actively contribute to the community through sponsoring. Stage 2 is instead mainly meant to prepare already active contributors to become MOTUs. Before adopting this change, we would like to know how many developers would be willing to change to this scheme, and how many would be available to help out with either stage 1, stage 2 or both of them. In light of an adoption of this scheme, Mentors which are already active are kindly requested to communicate to us under which stage would their mentoree fall. Please raise your hand! Cesare MOTU Mentoring reception [1] https://lists.ubuntu.com/archives/ubuntu-motu-mentors/2007-October/000153.html -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: removal of bitchx
Hi, Am Thu, 15 Nov 2007 14:35:58 +0100 schrieb Reinhard Tartler <[EMAIL PROTECTED]>: > Stephan Hermann <[EMAIL PROTECTED]> writes: > > > Dear Colleagues, > > > > I need some advice: > > > > there are least 2 CVEs for bitchx (source ircii-pana) but upstream > > seems to be dead. > > I would like to request a removal of this package. > > > > Why? > > > > First, we have (as console replacement) irssi in our archives, > > which is quite active, secondly for the X fanatics we have several > > other irc clients in our archives. > > Third, dead upstream is not ok for a package in debian and ubuntu. > > > > > > Some random thoughts, or should I file a removal request via LP and > > DBTS? > > AFAIUI, we have the policy not remove packages from universe just > because nobody cares for this. This topic and similar questions have > been raised before at least by Lucas and me, but the answer was that > we in general don't remove broken packages. Well, the package itself is not broken (ok, for hardy it's just not secure and righ now it ftbfs but that's something different). > I'm not too happy with that course, but I don't have a really strong > opinion on this. If someone in the future wants to care for the > package, he can just start to work on it. I filed a removal request on LP and for debian. It's attached to the LP bug and nion (Nico Golde) just fixed a bug for me with the DBTS ;) He agrees (he wrote at least one patch for bitchx) with me, that a removal is the best we can do security wise. > > OTOH, we do remove packages from universe if they are removed from > debian. So the current process would be to get it removed from debian > first and then from ubuntu. And I'm sure we can do case-by-case > decisions as well. I'm just saying that we don't have a real process > for this. That's what we try. > > In any case, filing a LP Bug where the status of the case of bitchx > can be tracked is IMO a good idea! > Done. Regards, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: removal of bitchx
Stephan Hermann <[EMAIL PROTECTED]> writes: > Dear Colleagues, > > I need some advice: > > there are least 2 CVEs for bitchx (source ircii-pana) but upstream seems > to be dead. > I would like to request a removal of this package. > > Why? > > First, we have (as console replacement) irssi in our archives, which is > quite active, secondly for the X fanatics we have several other irc > clients in our archives. > Third, dead upstream is not ok for a package in debian and ubuntu. > > > Some random thoughts, or should I file a removal request via LP and DBTS? AFAIUI, we have the policy not remove packages from universe just because nobody cares for this. This topic and similar questions have been raised before at least by Lucas and me, but the answer was that we in general don't remove broken packages. I'm not too happy with that course, but I don't have a really strong opinion on this. If someone in the future wants to care for the package, he can just start to work on it. OTOH, we do remove packages from universe if they are removed from debian. So the current process would be to get it removed from debian first and then from ubuntu. And I'm sure we can do case-by-case decisions as well. I'm just saying that we don't have a real process for this. In any case, filing a LP Bug where the status of the case of bitchx can be tracked is IMO a good idea! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
removal of bitchx
Dear Colleagues, I need some advice: there are least 2 CVEs for bitchx (source ircii-pana) but upstream seems to be dead. I would like to request a removal of this package. Why? First, we have (as console replacement) irssi in our archives, which is quite active, secondly for the X fanatics we have several other irc clients in our archives. Third, dead upstream is not ok for a package in debian and ubuntu. Some random thoughts, or should I file a removal request via LP and DBTS? Regards, \sh -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
