From cesare.falco at gmail.com Mon Jul 12 11:57:56 2010 From: cesare.falco at gmail.com (Cesare Falco) Date: Mon, 12 Jul 2010 11:57:56 +0200 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> <20100613173053.GA28268@yelena.nicm.ath.cx> Message-ID: Hi folks, any news about project move? Cesare. 2010/6/16, Florian Stinglmayr : > Hello List, > > I sadly don't have the time on my hands to run another FOSS project at > the moment. But I'd gladly support the project further by providing a > download mirror, patches, documentation and perhaps bigger code > contributions here and there. > > Regards, > Florian > _______________________________________________ > btpd-users mailing list > btpd-users at murmeldjur.se > http://lists.stargirl.org/listinfo/btpd-users > From queueram at gmail.com Mon Jul 12 20:23:59 2010 From: queueram at gmail.com (Marq Schneider) Date: Mon, 12 Jul 2010 13:23:59 -0500 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: <20100613163606.GA29454@biocontact.org> References: <20100613163606.GA29454@biocontact.org> Message-ID: Hi all, I have given this some serious thought and have decided that I'm willing to step up here and take the reins, if I can get everyone's approval. I feel inexperienced with leading an open source project, so I would like to fully disclose my experience here: 2005-2007: Submitted a few patches to the pidgin project (then gaim) 2008: Worked Google Summer of Code for pidgin (developing enhancements to finch, the terminal-based IM client) 2009-present: Submitted patches here and there for various projects: WxHexEditor [0], KiCad [1], btpd [2], cope [3], ack [4] I am a regular btpd user. My experience with the code base is lacking though. I think I've only submitted a couple patches. I use git regularly for my own personally projects, so I have some experience with it. However, my remote and cooperative usage of it has been limited to my brief work with 'cope' and 'ack' using GitHub and a couple projects with a small group. On Sun, Jun 13, 2010 at 11:36, Jonathan Dugan wrote: > To move forward, we first need 2 things: > > (1) A new repository. ?Since the code is already in git, I'd strongly > suggest GitHub. ?Ideally we can save the revision history the project > already has. It has a lot of interested developers, and great tools > for exactly this kind of project. ?Since mid 2009, they have > integrated issue tracking built in, and mailing lists, etc. For practice/fun/starters, I have started a new project under GitHub appropriately named "btpd" [5]. I have imported Richard's git repository into it, preserving its history. If everyone who has contributed here agrees that this is the way to go, we can proceed with the next steps. I did not want to get too carried away if there were some details that I missed. If acceptable, these are the next steps I want to take: 1. Incorporating pending patches 2. Adding more collaborators (all of you who are looking to regularly contribute) 3. Ironing out a release plan 4. Testing! 5-100. Whatever else i missed. > (2) A group of at least 3 project admins who are willing to put in the > work (time and technical effort) to review patches, write tests, build > and clearly explain development milestones and steer progress of the > project to meet their needs and the needs of the current userbase. I'm willing to volunteer myself for these duties, with all of your permission. > Stepping up as an admin means "I'm willing to take responsibility." > > Admin'ing an open source project can be a *lot* of work, and can be > thankless at times, as mostly all you get are a steady stream of > complaints and issues. ?The pay sucks: it's zero, usually. I'm only willing to do this if you double that pay! Seriously though, if you have any questions, comments, or doubts, please send them my way or to the list. Also, if you want to chat about this in an informal setting, I'm idling in #btpd on irc.freenode.net . Let's get this rolling again. -Marq Schneider [0] http://wxhexeditor.sourceforge.net/ [1] http://www.lis.inpg.fr/realise_au_lis/kicad/ [2] http://www.murmeldjur.se/btpd/ [3] http://github.com/cytzol/cope [4] http://github.com/petdance/ack [5] http://github.com/queueRAM/btpd From cesare.falco at gmail.com Mon Jul 12 21:46:10 2010 From: cesare.falco at gmail.com (Cesare Falco) Date: Mon, 12 Jul 2010 21:46:10 +0200 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: <1278963970.2012.1.camel@beltade.wallyweek.org> Il giorno lun, 12/07/2010 alle 13.23 -0500, Marq Schneider ha scritto: > Hi all, > > I have given this some serious thought and have decided that I'm > willing to step up here and take the reins, if I can get everyone's > approval. +1 Welcome aboard, Captain! :) Cesare. From cesare.falco at gmail.com Mon Jul 12 21:46:10 2010 From: cesare.falco at gmail.com (Cesare Falco) Date: Mon, 12 Jul 2010 21:46:10 +0200 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: <1278963970.2012.1.camel@beltade.wallyweek.org> Il giorno lun, 12/07/2010 alle 13.23 -0500, Marq Schneider ha scritto: > Hi all, > > I have given this some serious thought and have decided that I'm > willing to step up here and take the reins, if I can get everyone's > approval. +1 Welcome aboard, Captain! :) Cesare. From goatspice at gmail.com Mon Jul 12 21:57:38 2010 From: goatspice at gmail.com (Yassen Roussev) Date: Mon, 12 Jul 2010 20:57:38 +0100 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: <1278963970.2012.1.camel@beltade.wallyweek.org> References: <20100613163606.GA29454@biocontact.org> <1278963970.2012.1.camel@beltade.wallyweek.org> Message-ID: Great news indeed! Y. On 12 July 2010 20:46, Cesare Falco wrote: > Il giorno lun, 12/07/2010 alle 13.23 -0500, Marq Schneider ha scritto: > > Hi all, > > > > I have given this some serious thought and have decided that I'm > > willing to step up here and take the reins, if I can get everyone's > > approval. > +1 > > Welcome aboard, Captain! :) > > Cesare. > > > _______________________________________________ > btpd-users mailing list > btpd-users at murmeldjur.se > http://lists.stargirl.org/listinfo/btpd-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.stargirl.org/pipermail/btpd-users/attachments/20100712/0c5bab98/attachment.htm From logicloop at gmail.com Tue Jul 13 17:52:26 2010 From: logicloop at gmail.com (Cedric Tefft) Date: Tue, 13 Jul 2010 08:52:26 -0700 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: On Mon, Jul 12, 2010 at 11:23 AM, Marq Schneider wrote: > Hi all, > > I have given this some serious thought and have decided that I'm > willing to step up here and take the reins, if I can get everyone's > approval. I feel inexperienced with leading an open source project, > so I would like to fully disclose my experience here: > 2005-2007: Submitted a few patches to the pidgin project (then gaim) > 2008: Worked Google Summer of Code for pidgin (developing enhancements > to finch, the terminal-based IM client) > 2009-present: Submitted patches here and there for various projects: > WxHexEditor [0], KiCad [1], btpd [2], cope [3], ack [4] > Works for me. Also, at this point, I think anybody willing to step up gets the job by default. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.stargirl.org/pipermail/btpd-users/attachments/20100713/f3558308/attachment.htm From queueram at gmail.com Wed Jul 14 04:46:35 2010 From: queueram at gmail.com (Marq Schneider) Date: Tue, 13 Jul 2010 21:46:35 -0500 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: I'm glad to receive everyone's (de facto) support. I would still like to hear from Alessandro Calor?, Florian Stinglmayr, and it would sure be nice to receive official blessings from Richard Nyberg before calling it official. However, I am feeling more confident here, so I will continue moving forward until I hear otherwise. In case you missed it in my last burst of info, the new home of btpd for the moment will be here: http://github.com/queueRAM/btpd My reasoning for choosing GitHub is simple: I prefer git for SCM and GitHub makes it convenient to host, fork, and reference. Now, let's talk progress. Here are the tasks that are now complete: 1. Imported Richard's git repository into GitHub 2. Tagged previous (3) releases in git 3. Imported all the issues reported on mailing list to GitHub issue tracker As #3 states, I combed through the mailing list trying to pull out any problems, enhancements, and requests which we still need to attend to. If there is anything you strongly care about, please ensure that I have added it to the list of issues on GitHub. If I have not, feel free to add it yourself or email me with the issue and I will post it there. This leads me to the future tasks: 4. Comment/decide on Issues List - I need your input here! Please vote on and post comments on the issues. 5. Incorporating pending patches - I will try to do my best with these, but any help would be appreciated. 6. Adding more collaborators - This is kind of part of #5. GitHub makes it easy to fork a project and issue pull requests 7. Ironing out a release plan - Let's get some idea of what we'd like to see in the next release If you think I missed anything or have any ideas to make this process better, please feel free to post them here. Regards, Marq From lars.curator at gmail.com Wed Jul 14 10:56:25 2010 From: lars.curator at gmail.com (Lars Nooden) Date: Wed, 14 Jul 2010 11:56:25 +0300 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: <4C3D7BB9.7080207@gmail.com> Marq, Thanks for picking up btpd, and thanks again to Richard for all his work. On 07/14/2010 05:46 AM, Marq Schneider wrote: > 3. Imported all the issues reported on mailing list to GitHub issue tracker > > As #3 states, I combed through the mailing list trying to pull out any > problems, enhancements, and requests which we still need to attend to. > If there is anything you strongly care about, please ensure that I > have added it to the list of issues on GitHub. It would be nice to have manuals with the package. Here are three, if no better ones are already there: http://www-personal.umich.edu/~lars/OpenBSD/btcli.1.gz http://www-personal.umich.edu/~lars/OpenBSD/btinfo.1.gz http://www-personal.umich.edu/~lars/OpenBSD/btpd.1.gz Regards, /Lars PS. The address http://github.com/queueRAM/btpd seems to have some kind of flash affliction. Could that please be removed? /Lars From nicholas.marriott at gmail.com Wed Jul 14 11:32:18 2010 From: nicholas.marriott at gmail.com (Nicholas Marriott) Date: Wed, 14 Jul 2010 10:32:18 +0100 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: <20100714093218.GD2574@yelena.nicm.ath.cx> Thanks for picking this up, I recommend you apply the man pages, add any outstanding patches/simple fixes and make a release as soon as possible, so that the world at large is aware btpd is alive again. Releases are what attract attention to a project outside of existing users. Set up an account on freshmeat if there isn't one already, it has its problems but it is a good way of making the project more visible. On Tue, Jul 13, 2010 at 09:46:35PM -0500, Marq Schneider wrote: > I'm glad to receive everyone's (de facto) support. I would still like > to hear from Alessandro Calor?, Florian Stinglmayr, and it would sure > be nice to receive official blessings from Richard Nyberg before > calling it official. However, I am feeling more confident here, so I > will continue moving forward until I hear otherwise. > > In case you missed it in my last burst of info, the new home of btpd > for the moment will be here: > http://github.com/queueRAM/btpd > My reasoning for choosing GitHub is simple: I prefer git for SCM and > GitHub makes it convenient to host, fork, and reference. > > Now, let's talk progress. Here are the tasks that are now complete: > 1. Imported Richard's git repository into GitHub > 2. Tagged previous (3) releases in git > 3. Imported all the issues reported on mailing list to GitHub issue tracker > > As #3 states, I combed through the mailing list trying to pull out any > problems, enhancements, and requests which we still need to attend to. > If there is anything you strongly care about, please ensure that I > have added it to the list of issues on GitHub. If I have not, feel > free to add it yourself or email me with the issue and I will post it > there. > > This leads me to the future tasks: > 4. Comment/decide on Issues List > - I need your input here! Please vote on and post comments on the issues. > 5. Incorporating pending patches > - I will try to do my best with these, but any help would be appreciated. > 6. Adding more collaborators > - This is kind of part of #5. GitHub makes it easy to fork a > project and issue pull requests > 7. Ironing out a release plan > - Let's get some idea of what we'd like to see in the next release > > If you think I missed anything or have any ideas to make this process > better, please feel free to post them here. > > Regards, > Marq > _______________________________________________ > btpd-users mailing list > btpd-users at murmeldjur.se > http://lists.stargirl.org/listinfo/btpd-users From queueram at gmail.com Wed Jul 14 15:55:17 2010 From: queueram at gmail.com (Marq Schneider) Date: Wed, 14 Jul 2010 08:55:17 -0500 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: <4C3D7BB9.7080207@gmail.com> References: <20100613163606.GA29454@biocontact.org> <4C3D7BB9.7080207@gmail.com> Message-ID: On Wed, Jul 14, 2010 at 03:56, Lars Nooden wrote: > It would be nice to have manuals with the package. ?Here are three, if > no better ones are already there: > > ?http://www-personal.umich.edu/~lars/OpenBSD/btcli.1.gz > ?http://www-personal.umich.edu/~lars/OpenBSD/btinfo.1.gz > ?http://www-personal.umich.edu/~lars/OpenBSD/btpd.1.gz Yup, I've already added yours to the list and plan on using those as a basis. Thanks! http://github.com/queueRAM/btpd/issues#issue/9 > PS. ?The address ?http://github.com/queueRAM/btpd ?seems to have some > kind of flash affliction. ?Could that please be removed? I'm not sure what "flash affliction" means. Can you elaborate? In any case, I don't have much control over what GitHub. Thanks, Marq From queueram at gmail.com Wed Jul 14 16:11:26 2010 From: queueram at gmail.com (Marq Schneider) Date: Wed, 14 Jul 2010 09:11:26 -0500 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: <20100714093218.GD2574@yelena.nicm.ath.cx> References: <20100613163606.GA29454@biocontact.org> <20100714093218.GD2574@yelena.nicm.ath.cx> Message-ID: On Wed, Jul 14, 2010 at 04:32, Nicholas Marriott wrote: > I recommend you apply the man pages, add any outstanding patches/simple > fixes and make a release as soon as possible, so that the world at large > is aware btpd is alive again. Releases are what attract attention to a > project outside of existing users. > > Set up an account on freshmeat if there isn't one already, it has its > problems but it is a good way of making the project more visible. The man pages will definitely be there. I agree, putting together a release with some of the fixes and patches already supported sounds like the right thing to do. I'm not too concerned about user base at this point, but it couldn't hurt to put us out there. I created a freshmeat project page [0] (pending approval) since I do enjoy watching projects progress through that. [0] http://freshmeat.net/projects/btpd -Marq From fstinglmayr at gmail.com Wed Jul 14 17:35:47 2010 From: fstinglmayr at gmail.com (Florian Stinglmayr) Date: Wed, 14 Jul 2010 17:35:47 +0200 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: On Mon, Jul 12, 2010 at 8:23 PM, Marq Schneider wrote: > Hi all, > > I have given this some serious thought and have decided that I'm > willing to step up here and take the reins, if I can get everyone's > approval. ?I feel inexperienced with leading an open source project, > so I would like to fully disclose my experience here: > 2005-2007: Submitted a few patches to the pidgin project (then gaim) > 2008: Worked Google Summer of Code for pidgin (developing enhancements > to finch, the terminal-based IM client) > 2009-present: Submitted patches here and there for various projects: > WxHexEditor [0], KiCad [1], btpd [2], cope [3], ack [4] > You have my approval and support, and thanks for stepping up! And I am pretty confident that you'll do a great job! Congratulations! Florian From queueram at gmail.com Fri Jul 16 06:00:23 2010 From: queueram at gmail.com (Marq Schneider) Date: Thu, 15 Jul 2010 23:00:23 -0500 Subject: On the topic of mailing lists Message-ID: With Richard relinquishing control of btpd, I think we should also consider switching to a mailing list system that we can control so we don't unexpectedly get the plug pulled on us. GitHub does not provide any mailing list services, so we must look elsewhere. A common system used for this purpose is Google Groups [0]. There are others out there, but in my experience, Google Groups is the least intrusive and easiest to use. The one downside is that it doesn't look like we'll be able to transfer the old mailing list's archived messages to the Google Group [1]. Does anyone have any objections with a switch to Google Groups or know of a better mailing list provider that we can use? I plan to make the transition this weekend, unless I hear any objections. [0] http://groups.google.com [1] http://groups.google.com/support/bin/answer.py?hl=en&answer=46387 Regards, Marq From cesare.falco at gmail.com Fri Jul 16 08:50:32 2010 From: cesare.falco at gmail.com (Cesare Falco) Date: Fri, 16 Jul 2010 08:50:32 +0200 Subject: On the topic of mailing lists In-Reply-To: References: Message-ID: 2010/7/16, Marq Schneider : > Does anyone have any objections with a switch to Google Groups or know > of a better mailing list provider that we can use? We could also consider Freelists: http://www.freelists.org/ No objecton with GG anyway, it's fine for me. Cheers, Cesare. From fstinglmayr at gmail.com Fri Jul 16 14:03:30 2010 From: fstinglmayr at gmail.com (Florian Stinglmayr) Date: Fri, 16 Jul 2010 14:03:30 +0200 Subject: On the topic of mailing lists In-Reply-To: References: Message-ID: On Fri, Jul 16, 2010 at 6:00 AM, Marq Schneider wrote: > Does anyone have any objections with a switch to Google Groups or know > of a better mailing list provider that we can use? > > I plan to make the transition this weekend, unless I hear any objections. > I have my personal root server (kxd.cc) which can virtually run anything. But GG is fine aswell. Regards, Florian From queueram at gmail.com Mon Jul 19 07:43:16 2010 From: queueram at gmail.com (Marq Schneider) Date: Mon, 19 Jul 2010 00:43:16 -0500 Subject: On the topic of mailing lists In-Reply-To: References: Message-ID: On Fri, Jul 16, 2010 at 07:03, Florian Stinglmayr wrote: > On Fri, Jul 16, 2010 at 6:00 AM, Marq Schneider wrote: >> Does anyone have any objections with a switch to Google Groups or know >> of a better mailing list provider that we can use? >> >> I plan to make the transition this weekend, unless I hear any objections. >> > > I have my personal root server (kxd.cc) which can virtually run > anything. But GG is fine aswell. Thanks for the offer, but I'd prefer to keep it something that several "owners" of the project can control. Consider it bus factor mitigation [0]. I've taken a closer look at Google Groups and Freelists. While Freelists has a longer history, it's mailing list support seems more primitive than our current one running mailman. A mailing list doesn't need to be too fancy, however, i find Google's search interface to be much more convenient than Freelists'. Neither GG nor Freelists supports and mailing list archive import, so that is going to present a problem. GG supports uploading files, so i've started uploading the archives downloaded from the current btpd-users mailing list. However, searching the group does not also return search results from these files. One other idea i had which looks like it will work is i can write a script to parse through the old logs and retransmit the messages to the GG mailing list with semi-forged email headers using sendmail or something. This will look like the original messages, except all will be sent from one SMTP server. I manually tested this out with one message and it looks like a viable option. It will just take some work to construct the In-Reply-To: headers and much time to go through all the messages at a pace that Google won't interpret as spamming. I'm going to hold off one more week while i contemplate this. [0] http://en.wikipedia.org/wiki/Bus_factor -Marq From nicholas.marriott at gmail.com Mon Jul 19 10:22:19 2010 From: nicholas.marriott at gmail.com (Nicholas Marriott) Date: Mon, 19 Jul 2010 09:22:19 +0100 Subject: On the topic of mailing lists In-Reply-To: References: Message-ID: <20100719082219.GC17272@yelena.nicm.ath.cx> Personally I wouldn't worry about mailing list archives, if someone has them as an mbox or something just put it in git so they are around if necessary, but even if not I wouldn't spend too much time on it. On Mon, Jul 19, 2010 at 12:43:16AM -0500, Marq Schneider wrote: > On Fri, Jul 16, 2010 at 07:03, Florian Stinglmayr wrote: > > On Fri, Jul 16, 2010 at 6:00 AM, Marq Schneider wrote: > >> Does anyone have any objections with a switch to Google Groups or know > >> of a better mailing list provider that we can use? > >> > >> I plan to make the transition this weekend, unless I hear any objections. > >> > > > > I have my personal root server (kxd.cc) which can virtually run > > anything. But GG is fine aswell. > > Thanks for the offer, but I'd prefer to keep it something that several > "owners" of the project can control. Consider it bus factor > mitigation [0]. > > I've taken a closer look at Google Groups and Freelists. While > Freelists has a longer history, it's mailing list support seems more > primitive than our current one running mailman. A mailing list > doesn't need to be too fancy, however, i find Google's search > interface to be much more convenient than Freelists'. > > Neither GG nor Freelists supports and mailing list archive import, so > that is going to present a problem. GG supports uploading files, so > i've started uploading the archives downloaded from the current > btpd-users mailing list. However, searching the group does not also > return search results from these files. One other idea i had which > looks like it will work is i can write a script to parse through the > old logs and retransmit the messages to the GG mailing list with > semi-forged email headers using sendmail or something. This will look > like the original messages, except all will be sent from one SMTP > server. I manually tested this out with one message and it looks like > a viable option. It will just take some work to construct the > In-Reply-To: headers and much time to go through all the messages at a > pace that Google won't interpret as spamming. > > I'm going to hold off one more week while i contemplate this. > > [0] http://en.wikipedia.org/wiki/Bus_factor > > -Marq > _______________________________________________ > btpd-users mailing list > btpd-users at murmeldjur.se > http://lists.stargirl.org/listinfo/btpd-users From queueram at gmail.com Fri Jul 23 00:09:21 2010 From: queueram at gmail.com (Marq Schneider) Date: Thu, 22 Jul 2010 17:09:21 -0500 Subject: On the topic of mailing lists In-Reply-To: <20100719082219.GC17272@yelena.nicm.ath.cx> References: <20100719082219.GC17272@yelena.nicm.ath.cx> Message-ID: On Mon, Jul 19, 2010 at 03:22, Nicholas Marriott wrote: > Personally I wouldn't worry about mailing list archives, if someone has > them as an mbox or something just put it in git so they are around if > necessary, but even if not I wouldn't spend too much time on it. Initially, i shared these same thoughts. However, after some debate, i decided it was worth keeping the history around since others can use it to find answers to questions and obtain a better understanding of the evolution of the project. It has been really enlightening for me to read through the emails from 2006 and i expect to learn more as i make it through the mailing list archives to the present. Also, i already have the script running and populating the new mailing list with the old messages. 100 down, and only 600 or so to go! Also, i added the group to our current mailing list so it has been saving all new emails since then and will continue to do so in case anyone mistakenly uses the old list. I expect the script to finish some time over the weekend at which point i will invite everyone who has emailed the list to the new list and you can opt-out from there. I won't add you until the spamming script is done. If you haven't emailed the list, well, you'll just have to add yourself. More details will follow. -Marq From queueram at gmail.com Fri Jul 23 00:27:21 2010 From: queueram at gmail.com (Marq Schneider) Date: Thu, 22 Jul 2010 17:27:21 -0500 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: On Tue, Jul 13, 2010 at 21:46, Marq Schneider wrote: > In case you missed it in my last burst of info, the new home of btpd > for the moment will be here: > http://github.com/queueRAM/btpd I just learned about GitHub organizations [0] and decided this would fit the project better to host the repository under an organization rather than under myself. Therefore, I have created a 'btpd' organization and moved the btpd repository under it: http://github.com/btpd/btpd I have copied all the Issues over to the issue tracker there. I tried to copy over your comments, but obviously couldn't post as you, so feel free to re-post your comments there. Sorry for the inconvenience, but this will (hopefully) be the last time it is moved. I also have some status updates for those interested: > 5. Incorporating pending patches I have already fixed some of the issues, but there are plenty to go. Check progress on the issue tracker. > 6. Adding more collaborators With GitHub organizations, we can add developers or admins to the project. Is anyone interested on collaborating on the project with me? Anyone interested in helping with some of the admin responsibilities (and take over in case i get hit by a bus)? > 7. Ironing out a release plan Tentatively, here are my plans: a. Draw an arbitrary line in the sand of the issues list and mark those issues for the next release. - Done. See issue tracker. b. Fix all those issues - 50% or so complete c. Perform my own and email list asking for help testing - TODO d. If no new issues arise, release - TODO [0] http://github.com/blog/674-introducing-organizations -Marq From nicholas.marriott at gmail.com Fri Jul 23 00:43:18 2010 From: nicholas.marriott at gmail.com (Nicholas Marriott) Date: Thu, 22 Jul 2010 23:43:18 +0100 Subject: next steps- picking a new repo, selecting new project admins In-Reply-To: References: <20100613163606.GA29454@biocontact.org> Message-ID: <20100722224318.GA22766@yelena.nicm.ath.cx> On Thu, Jul 22, 2010 at 05:27:21PM -0500, Marq Schneider wrote: > On Tue, Jul 13, 2010 at 21:46, Marq Schneider wrote: > > In case you missed it in my last burst of info, the new home of btpd > > for the moment will be here: > > http://github.com/queueRAM/btpd > > I just learned about GitHub organizations [0] and decided this would > fit the project better to host the repository under an organization > rather than under myself. Therefore, I have created a 'btpd' > organization and moved the btpd repository under it: > http://github.com/btpd/btpd nice > I have copied all the Issues over to the issue tracker there. I tried > to copy over your comments, but obviously couldn't post as you, so > feel free to re-post your comments there. Sorry for the > inconvenience, but this will (hopefully) be the last time it is moved. > > I also have some status updates for those interested: > > 5. Incorporating pending patches > I have already fixed some of the issues, but there are plenty to go. > Check progress on the issue tracker. > > > 6. Adding more collaborators > With GitHub organizations, we can add developers or admins to the > project. Is anyone interested on collaborating on the project with > me? Anyone interested in helping with some of the admin > responsibilities (and take over in case i get hit by a bus)? yes sure, both, but i am busy right now so it will be as and when for a bit anyone to save me looking know can i get commits to the src tree and changes to issues by email from github? > > > 7. Ironing out a release plan > Tentatively, here are my plans: > a. Draw an arbitrary line in the sand of the issues list and mark > those issues for the next release. - Done. See issue tracker. > b. Fix all those issues - 50% or so complete > c. Perform my own and email list asking for help testing - TODO > d. If no new issues arise, release - TODO sure, do what you like :-) > > [0] http://github.com/blog/674-introducing-organizations > > -Marq > _______________________________________________ > btpd-users mailing list > btpd-users at murmeldjur.se > http://lists.stargirl.org/listinfo/btpd-users From queueram at gmail.com Fri Jul 23 07:38:03 2010 From: queueram at gmail.com (Marq Schneider) Date: Fri, 23 Jul 2010 00:38:03 -0500 Subject: On the topic of release version numbering Message-ID: This is an often debated topic. Many version numbers are arbitrarily chosen (AOL 9.0!!!). Some just increment at each change (btpd more or less falls in this category). Others have milestone meanings (start with 0.0.0, bugfix += x.x.1, minor milestone += x.1.x, major milestone += 1.x.x). While others yet have meaning regarding APIs (no API modifications += x.x.1, new API additions += x.1.x, breakage of API += 1.x.x). Milestone versioning is geared more toward users and API versioning is geared toward developers. While i can see going either with milestone or API, i think i would prefer the API method. Going with API would allow external tools to be able to clearly identify if the API has changed. I would be interested in hearing your opinions though. Regardless of which way we go, my plan is to perform the following: 1. Make the next release 0.16 since this is basically 0.15 with bugfixes and a couple enhancements 2. Decide on a release process and designate the following release to be 1.0.0. This will be the first release under the new version numbering. 3. Follow the version number rules decided for subsequent releases Questions? Thoughts? Concerns? -Marq From nicholas.marriott at gmail.com Fri Jul 23 10:11:27 2010 From: nicholas.marriott at gmail.com (Nicholas Marriott) Date: Fri, 23 Jul 2010 09:11:27 +0100 Subject: On the topic of release version numbering In-Reply-To: References: Message-ID: <20100723081127.GC30464@yelena.nicm.ath.cx> i think the minor/major milestone thing is vaguely silly and arbitrary, and bug fix numbering tends to encourage too much effort to be wasted on backporting trivial bug fixes. who has time to maintain old releases? it just holds things up and makes developers bored. on a small project you want development and testing and (importantly) documentation focus to be as close to the latest version as possible. most people can figure out how to use a VCS and for a project with few dependencies, asking people who hit bugs to checkout and run the latest git is not a big burden. and it gets it tested for the next release :-). i usually drop the third number and just do a.b, incrementing b every release until it hits 9 then going to (b + 1).0. if i need a bug fix release (very rare and only if it is seriously critical, ie a security problem or it cores when doing something that can't be avoided) i do eg 0.3a. with a release every month or so (i tend to release when i have something to release and if the project is alive 1-2 months tends to be enough to have a good few changes) this keep version numbers in the vaguely sane and meaningful range (eg after 2 years you'd expect the project to be in the 1.5-3.0 range). releasing much more often makes people confused and makes both users and packagers (who tend to have lots to do) skip versions. i have enough problems with people running old versions of ubuntu using releases from 5 versions ago, let alone if i had 20 releases in the time to worry about... or if you want a third number, i would make it mostly zero, so most releases are a.b.0, a.(b + 1).0 etc except in the rare cases you need a bug fix release then you do a.b.1. generally, do what you like, but do please avoid the awful -alpha, -beta, -rc1, -rc2, -rc3 nonsense :-). if you are doing shared libraries, then it is important that their major and minor reflect ABI (not just API!) changes, but there is no reason that version has to be tied to the main package version and in projects with mixed shared libraries/binaries it is sometimes hard to achieve that anyway (you end up with either bumps or releases you don't need). On Fri, Jul 23, 2010 at 12:38:03AM -0500, Marq Schneider wrote: > This is an often debated topic. Many version numbers are arbitrarily > chosen (AOL 9.0!!!). Some just increment at each change (btpd more or > less falls in this category). Others have milestone meanings (start > with 0.0.0, bugfix += x.x.1, minor milestone += x.1.x, major milestone > += 1.x.x). While others yet have meaning regarding APIs (no API > modifications += x.x.1, new API additions += x.1.x, breakage of API += > 1.x.x). > > Milestone versioning is geared more toward users and API versioning is > geared toward developers. While i can see going either with milestone > or API, i think i would prefer the API method. Going with API would > allow external tools to be able to clearly identify if the API has > changed. I would be interested in hearing your opinions though. > > Regardless of which way we go, my plan is to perform the following: > 1. Make the next release 0.16 since this is basically 0.15 with > bugfixes and a couple enhancements > 2. Decide on a release process and designate the following release to > be 1.0.0. This will be the first release under the new version > numbering. > 3. Follow the version number rules decided for subsequent releases > > Questions? Thoughts? Concerns? > > -Marq > _______________________________________________ > btpd-users mailing list > btpd-users at murmeldjur.se > http://lists.stargirl.org/listinfo/btpd-users From fstinglmayr at gmail.com Fri Jul 23 10:18:48 2010 From: fstinglmayr at gmail.com (Florian Stinglmayr) Date: Fri, 23 Jul 2010 10:18:48 +0200 Subject: On the topic of release version numbering In-Reply-To: References: Message-ID: I'm personally in favour of the X.Y method: Increase Y as long as you improve the version X of the software. Should bigger changes come along that completely change how the software works or even break API increase X. Then perhaps keep branches (or however git calls them) of each X so in case we would like to fix an important bug in an given release. And I always tend to use 0.Y for versions that are not yet ready for a release. Because some important feature is missing or, documentation is not yet good enough; etc. etc. Then once 1.0 goes live, new features are being added and bugs are being fixed steadily increasing Y. And should all those changes become too hackish; and major rewrites happen I'd increase X. I personally just don't want to have an excessive amount of branches for all sorts of X.Y.Z variants and then have a real hard time getting bug fixes into each and every one of them. It just makes people bored. my ?0.02 Regards, Florian From cesare.falco at gmail.com Fri Jul 23 12:42:24 2010 From: cesare.falco at gmail.com (Cesare Falco) Date: Fri, 23 Jul 2010 12:42:24 +0200 Subject: ubtpd: a fork? Message-ID: <1279881744.3001.4.camel@beltade.wallyweek.org> I've just registered on github, so I was looking through the repos, and here it is, a fork supporting UTF: http://github.com/KblCb/ubtpd Maybe we can contact the author and merge the projects. Cesare. From queueram at gmail.com Fri Jul 23 16:00:26 2010 From: queueram at gmail.com (Marq Schneider) Date: Fri, 23 Jul 2010 09:00:26 -0500 Subject: ubtpd: a fork? In-Reply-To: <1279881744.3001.4.camel@beltade.wallyweek.org> References: <1279881744.3001.4.camel@beltade.wallyweek.org> Message-ID: On Fri, Jul 23, 2010 at 05:42, Cesare Falco wrote: > I've just registered on github, so I was looking through the repos, > and here it is, a fork supporting UTF: > > http://github.com/KblCb/ubtpd Yeah, i saw this too. However, if you look at the repository, no source changes have actually been made from the 0.15 release. That's why i didn't even bother to mention it. -Marq From jonathan at clearbits.net Fri Jul 23 16:34:53 2010 From: jonathan at clearbits.net (Jonathan Dugan) Date: Fri, 23 Jul 2010 07:34:53 -0700 Subject: On the topic of release version numbering In-Reply-To: References: Message-ID: <20100723143453.GB31602@biocontact.org> In the case of BTPD, stable running over long periods of time is a critical priority of the product. The only other consideration on numbering I want to see is a reflection of reliable stability, and the process we have in place to ensure stability before release. Even with an excellent testing framework, and with early testing before releases, all feature additions have the expectation and high probability to reduce stability in some way. I'd like to see us have a process for ensuring stability of releases that includes clear divisions into (for example): A (feature additions and unit tests creation/iterative dev) -> (HEAD) B (users in the wild/early feedback) -> latest stable feature set, numbered C (stable release) -> stable B after X months or Y torrent*users*hours Whatever we come up with for A->B->C -like processes used to release the code, or whatever we call them, I feel strongly that having the numbering reflect the process makes things a lot clearer. For example, I think calling the next release 1.0 is not the best way to do it. We take the existing patches, do a quick set of tests, and call it 0.9 (basically put it into "B"), and get the existing possible users on this list to production test as hard as possible. No new feature additions then go into "B" - only bugfixes and stability improvements. After we have clear evidence that "B" is stable, we only then call that 1.0. Concurrent to this, we put all the new features and development into the repo, and once we get to a feature milestone, we call it 1.1, package/tag it and it becomes "B". This process will give us the familiar "odds are development, evens are stable". If we have any emergencies, security issues, melting down some ISP from a runaway network issue, we can then issue 0.9.1 or 0.9.2, etc. Regards, Jonathan 650 799 5369 On Fri, Jul 23, 2010 at 12:38:03AM -0500, Marq Schneider wrote: > This is an often debated topic. Many version numbers are arbitrarily > chosen (AOL 9.0!!!). Some just increment at each change (btpd more or > less falls in this category). Others have milestone meanings (start > with 0.0.0, bugfix += x.x.1, minor milestone += x.1.x, major milestone > += 1.x.x). While others yet have meaning regarding APIs (no API > modifications += x.x.1, new API additions += x.1.x, breakage of API += > 1.x.x). > > Milestone versioning is geared more toward users and API versioning is > geared toward developers. While i can see going either with milestone > or API, i think i would prefer the API method. Going with API would > allow external tools to be able to clearly identify if the API has > changed. I would be interested in hearing your opinions though. > > Regardless of which way we go, my plan is to perform the following: > 1. Make the next release 0.16 since this is basically 0.15 with > bugfixes and a couple enhancements > 2. Decide on a release process and designate the following release to > be 1.0.0. This will be the first release under the new version > numbering. > 3. Follow the version number rules decided for subsequent releases > > Questions? Thoughts? Concerns? > > -Marq > _______________________________________________ > btpd-users mailing list > btpd-users at murmeldjur.se > http://lists.stargirl.org/listinfo/btpd-users From queueram at gmail.com Sun Jul 25 23:59:56 2010 From: queueram at gmail.com (Marq Schneider) Date: Sun, 25 Jul 2010 16:59:56 -0500 Subject: On the topic of mailing lists In-Reply-To: References: <20100719082219.GC17272@yelena.nicm.ath.cx> Message-ID: On Thu, Jul 22, 2010 at 17:09, Marq Schneider wrote: > I expect the script to finish some time over the weekend at which > point i will invite everyone who has emailed the list to the new list > and you can opt-out from there. ?I won't add you until the spamming > script is done. ?If you haven't emailed the list, well, you'll just > have to add yourself. ?More details will follow. And here are the more details. I just sent out an invitation from the new btpd Google Group to the list of active btpd-users subscribers. If you did not get an invite, it is because you either have not sent a message to the list in the past year or you do not permit Google Group mailing list managers to send you invites. You will have to manually follow the link below [0] and subscribe yourself to the group. The new mailing list address btpd-users at googlegroups.com . Please use this address for all future discussions. This new list is subscribed to the old mailing list, but I don't think those messages get forwarded on the new subscribers. Messages sent to the old list will still be archived on the new one. In addition, all old mailing list archives have been saved to the new list. It was a painful procedure, of which the details I will save for a rainy day. [0] http://groups.google.com/group/btpd-users Now back to real work on btpd. -Marq From nemosoft at smcc.demon.nl Mon Jul 26 15:41:35 2010 From: nemosoft at smcc.demon.nl (Nemosoft Unv.) Date: Mon, 26 Jul 2010 15:41:35 +0200 Subject: On the topic of mailing lists In-Reply-To: References: Message-ID: <201007261541.35751.nemosoft@smcc.demon.nl> Hello, On Sunday 25 July 2010 23:59:56 Marq Schneider wrote: > And here are the more details. I just sent out an invitation from the > new btpd Google Group to the list of active btpd-users subscribers. > If you did not get an invite, it is because you either have not sent a > message to the list in the past year or you do not permit Google Group > mailing list managers to send you invites. You will have to manually > follow the link below [0] and subscribe yourself to the group. I got the invitation, but now there's a catch: I am supposed to sign in with a Google account. Which I have, but do not wish to use it for btpd or anything of a personal/hobby nature. I also do not wish to create another Google account (which is probably a violation of their Terms and Conditions too). I didn't realize this when Google Groups was mentioned. I thought it was okay to use GG until I clicked the link :-( Perhaps others will be put off by this as well, since as far as I can see, the only way to join the mailinglist is by creating/having a Google account. - Nemosoft From queueram at gmail.com Mon Jul 26 15:56:13 2010 From: queueram at gmail.com (Marq Schneider) Date: Mon, 26 Jul 2010 08:56:13 -0500 Subject: On the topic of mailing lists In-Reply-To: <201007261541.35751.nemosoft@smcc.demon.nl> References: <201007261541.35751.nemosoft@smcc.demon.nl> Message-ID: > On Sunday 25 July 2010 23:59:56 Marq Schneider wrote: > >> And here are the more details. ?I just sent out an invitation from the >> new btpd Google Group to the list of active btpd-users subscribers. >> If you did not get an invite, it is because you either have not sent a >> message to the list in the past year or you do not permit Google Group >> mailing list managers to send you invites. ?You will have to manually >> follow the link below [0] and subscribe yourself to the group. On Mon, Jul 26, 2010 at 08:41, Nemosoft Unv. wrote: > I got the invitation, but now there's a catch: I am supposed to sign in with a > Google account. Which I have, but do not wish to use it for btpd or anything > of a personal/hobby nature. I also do not wish to create another Google > account (which is probably a violation of their Terms and Conditions too). > > I didn't realize this when Google Groups was mentioned. I thought it was okay > to use GG until I clicked the link :-( Perhaps others will be put off by this > as well, since as far as I can see, the only way to join the mailinglist is by > creating/having a Google account. I guess i don't really see the issue with creating a new Google account. I did this with an @yahoo email address while testing the new list. You just need to create it but don't need to keep it logged in if you choose one of the email subscription options. This is really no different than the old mailman mailing list where you provide it an email address and subscription password. Regarding your concern about violation of Google's ToC, i have not fully read into the matter. However, i can tell you that the Google Police have not come knocking on my door yet. -Marq From ludde at ludde.net Mon Jul 26 18:23:03 2010 From: ludde at ludde.net (Ludvig Omholt) Date: Mon, 26 Jul 2010 18:23:03 +0200 Subject: On the topic of mailing lists In-Reply-To: <201007261541.35751.nemosoft@smcc.demon.nl> References: <201007261541.35751.nemosoft@smcc.demon.nl> Message-ID: On Mon, Jul 26, 2010 at 15:41, Nemosoft Unv. wrote: > Hello, > > On Sunday 25 July 2010 23:59:56 Marq Schneider wrote: > >> And here are the more details. ?I just sent out an invitation from the >> new btpd Google Group to the list of active btpd-users subscribers. >> If you did not get an invite, it is because you either have not sent a >> message to the list in the past year or you do not permit Google Group >> mailing list managers to send you invites. ?You will have to manually >> follow the link below [0] and subscribe yourself to the group. > > I got the invitation, but now there's a catch: I am supposed to sign in with a > Google account. Which I have, but do not wish to use it for btpd or anything > of a personal/hobby nature. I also do not wish to create another Google > account (which is probably a violation of their Terms and Conditions too). > > I didn't realize this when Google Groups was mentioned. I thought it was okay > to use GG until I clicked the link :-( Perhaps others will be put off by this > as well, since as far as I can see, the only way to join the mailinglist is by > creating/having a Google account. > > ?- Nemosoft There's a less obvious way to subscribe a non-google address: Send an empty message to btpd-users+subscribe at googlegroups.com from the address you wish to subscribe. /Ludde