Re: [Bash-completion-devel] roadmap ?
David Paleino a écrit : Agreed, go change the wiki now! ;) Done, according to various replies. -- BOFH excuse #443: Zombie processes detected, machine is haunted. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
On Thu, Jun 11, 2009 at 10:05 PM, Guillaume Rousseguillaume.rou...@inria.fr wrote: David Paleino a écrit : Agreed, go change the wiki now! ;) Done, according to various replies. I'll keep on working on the test suite in the mean time, supposing the `test' `doc' directories are not standing in the way of releasing 1.1 without them? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
Freddy Vulto a écrit : On Mon, Jun 8, 2009 at 8:01 PM, Ville Skyttäville.sky...@iki.fi wrote: I have no problems with this plan (although I have a pile of fairly innocent patches that I'd like to see go in the next release, more on that in a separate mail). But the test suite sure would be nice to have, and I have no idea how much work adopting that would be - if not too long, stick with the plan to include it in the next release. Freddy? +1 to include the test suite in the next release. That is, the test suite is only necessary for development so we might only include the test suite in a bash-completion *source* package (or even just in git) and omit the test suite in a bash-completion 'binary' package? Yes, but that's a secondary issue. I've been anticipating and adopting/improving the bash-completion-lib test suite already. Current state is I've taken `ssh' and `_known_hosts' as first examples. The tests are running (although the tests show ssh and _known_hosts need fixing ;-). Latest accomplishment is that the tests show if variables are not cleaned up, i.e. if the environment is modified! All tests of bash_completion_lib need adjusting to the latest improvements, but that should be no big deal. I think putting them in a `to_review' directory would be a good starting point. What's also desired is passing the location of `bash' to the test suite so we can automatically test bash versions 2, 3 and 4. Right now the test suite is taking just /bin/bash. Also should be noticed that the test suite can be made as infinite or as small as one desires. One can always 'release' bash-completion while being aware the test suite isn't covering anything... because the test suite is never going to cover anything! The test suite is just sitting aside, helping us guide against degrading and assuring us specifications are met. Keep in mind the tests should execute quick because they're gonna be run often! And keep the tests clear and simple because we want to fix bugs in bash-completion, not in the tests ;-) So I'm eager to know what you think of the current test suite and if you all find it workable. I think we should start using the test suite better sooner than later. Shall I upload/push the test suite? Yes, please. I thought the work didn't even started on this point. -- BOFH excuse #68: only available on a need to know basis ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
Guillaume Rousse a écrit : Hello list. According to our roadmap, http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap, we still have to finish splitting completions in individual files, and also to review existing completions. We finished 2.b (rewieving), and we almost finished 2.a (splitting). We just have the following completions to split: - freebsd kldload and kldunload - freebsd portinstall and portupgrade - slackware removepkg - look - contrib/util-linux-ng - id - contrib/coreutils I'd like to finish it, but I don't know how to name the file for the fist ones... The actual question, however, is: what's next ? On our agenda, the point 3 is to merge bash-completion-lib's test suite. However, I feel like it's gonna take some time, and will only concerns a few people here. I'd rather have a release right now (bash-completion 2.0), and insert into our calendar shorter developement steps: - drop bash 2.0 compatibility stuff - adopt a new setup (installing stuff somewhere, parsing them elsewhere) - adopt a new syntax policy (I really feel tab-based indentation is way to cumbersome, see contrib/openssl for instance) Basically, it means re-ordering points 3, 4 and 5 in our current roadmap, and expanding point 5. -- BOFH excuse #51: Cosmic ray particles crashed through the hard disk platter ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
On Monday 08 June 2009, Guillaume Rousse wrote: Guillaume Rousse a écrit : Hello list. According to our roadmap, http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap, we still have to finish splitting completions in individual files, and also to review existing completions. We finished 2.b (rewieving), and we almost finished 2.a (splitting). We just have the following completions to split: - freebsd kldload and kldunload - freebsd portinstall and portupgrade - slackware removepkg - look - contrib/util-linux-ng - id - contrib/coreutils I'd like to finish it, but I don't know how to name the file for the fist ones... I dug up some info from http://www.freshports.org/ and http://packages.slackware.it/ and split the FreeBSD and Slackware things based on those findings. Go ahead with look and id when you feel like it. On our agenda, the point 3 is to merge bash-completion-lib's test suite. However, I feel like it's gonna take some time, and will only concerns a few people here. I'd rather have a release right now (bash-completion 2.0), and insert into our calendar shorter developement steps: - drop bash 2.0 compatibility stuff - adopt a new setup (installing stuff somewhere, parsing them elsewhere) - adopt a new syntax policy (I really feel tab-based indentation is way to cumbersome, see contrib/openssl for instance) Basically, it means re-ordering points 3, 4 and 5 in our current roadmap, and expanding point 5. I have no problems with this plan (although I have a pile of fairly innocent patches that I'd like to see go in the next release, more on that in a separate mail). But the test suite sure would be nice to have, and I have no idea how much work adopting that would be - if not too long, stick with the plan to include it in the next release. Freddy? Regarding syntax/indentation policy, I think it'd be good to just do a poll like with the SCM choice. David? (Can't help plugging my favourite here, sorry ;): indent step 4, tab width 8, mixed spaces/tabs; or indent step 4, spaces only.) ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
On Sunday 17 May 2009, Guillaume Rousse wrote: Hello list. According to our roadmap, http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap, we still have to finish splitting completions in individual files, and also to review existing completions. I did a first pass on first task, Entries for these changes seem to be missing from CHANGES and Makefile.am, please add them. but as the second mostly concerns completions I submitted myself, I'd like someone else to do it :P Well, as I suggested earlier, I think post-commit rather than pre-commit reviews would be a better process for bash-completion. I have some completions stuck in to_review/ as well. Now that the completions under review are committed in to_review/, those terms no longer capture too well what I meant, so here's another proposal: completions that have been in to_review/ for two weeks or more without pending TODO items (i.e. if all issues pointed out by reviewers have been sorted out or if nobody has posted any review comments) may be moved to contrib/ by their submitter without explicit review pass notice if the submitter considers them ready for general consumption. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
Ville Skyttä a écrit : On Sunday 17 May 2009, Guillaume Rousse wrote: Hello list. According to our roadmap, http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap, we still have to finish splitting completions in individual files, and also to review existing completions. I did a first pass on first task, Entries for these changes seem to be missing from CHANGES and Makefile.am, please add them. I just fixed Makefile.am, I'll insert a unique entry in Changes when finishing to split all remaining completions. but as the second mostly concerns completions I submitted myself, I'd like someone else to do it :P Well, as I suggested earlier, I think post-commit rather than pre-commit reviews would be a better process for bash-completion. I have some completions stuck in to_review/ as well. Now that the completions under review are committed in to_review/, those terms no longer capture too well what I meant, so here's another proposal: completions that have been in to_review/ for two weeks or more without pending TODO items (i.e. if all issues pointed out by reviewers have been sorted out or if nobody has posted any review comments) may be moved to contrib/ by their submitter without explicit review pass notice if the submitter considers them ready for general consumption. I also transfered everything from review directory to contrib directory. We may as well fix there directly (and most of them have been in use in mandriva for years anyway...). -- BOFH excuse #215: High nuclear activity in your area. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] roadmap ?
Hello list. According to our roadmap, http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap, we still have to finish splitting completions in individual files, and also to review existing completions. I did a first pass on first task, but as the second mostly concerns completions I submitted myself, I'd like someone else to do it :P -- BOFH excuse #284: Electrons on a bender ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
On Sun, 15 Feb 2009 10:27:48 +0100 David Paleino d.pale...@gmail.com wrote: dunno about other package formats but I suppose they have similar mechanisms. I have no problem with that, it's obviously doable, just thought I'd mention it in case someone didn't think of it. I already thought at that. Do other distributions have mechanisms to handle this? RPM is ok, Deb is ok -- what about Gentoo's/Exherbo's ebuilds? We don't really have the same sort of mechanism -- we tend to try to have our package versions match the upstream version as much as possible. I think the way this was handled in Gentoo, when Wine made the same transition from date-based releases to numbered ones, was to do what is called a 'package.mask' at some point, basically telling users' package managers the the old, date-based versions are no longer suitable for use -- they would then simply see the new numbered version ones as best available version, and install them instead. So, it's doable, just a bit icky. There might be a slightly cleaner way to handle this, but I'm unsure of it right now. -- Mike Kelly ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
On Friday 13 February 2009, Freddy Vulto wrote: David Paleino d.paleino at gmail.com writes: On Fri, 13 Feb 2009 00:11:41 +0200, Ville Skyttä wrote: On Wednesday 04 February 2009, David Paleino wrote: On Wed, 04 Feb 2009 21:59:25 +0100, Guillaume Rousse wrote: I'd insert the following items between 1 and 2, or between 2 and 3: - finish splitting every command into its own file - finish reviewing new completions Agreed. I'd rather see a real release being made before split every command takes place, no objections otherwise. Well, releasing another headache-making bash-completion doesn't really sound good to me :) Isn't there a concern that splitting every command into its own file is going to make bash_completion slower? If so, maybe we'd better release bash_completion-2 (or ..200902xx) with the improvements made so far, stop supporting bash-2, branch and make the splitting every command into its own file part of the new branch: bash_completion-3? +1 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
On Fri, 13 Feb 2009 14:14:29 + (UTC), Freddy Vulto wrote: [..] maybe we'd better release bash_completion-2 (or ..200902xx) [..] I was starting a branch for the release process... what version number you believe is sane? I'd start at 1.0, (so as not to be necessarily linked to the bash version), and the date format is kinda weird to me. Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
David Paleino d.paleino at gmail.com writes: On Fri, 13 Feb 2009 14:14:29 + (UTC), Freddy Vulto wrote: [..] maybe we'd better release bash_completion-2 (or ..200902xx) [..] I was starting a branch for the release process... what version number you believe is sane? I'd start at 1.0, (so as not to be necessarily linked to the bash version), and the date format is kinda weird to me. 1.0 is fine with me too - better than date format, as long as the major number is going to be increased once we drop bash-2 support. Can you elaborate on which releases you have in mind? Regards, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
On Sat, 14 Feb 2009 11:25:08 + (UTC), Freddy Vulto wrote: David Paleino d.paleino at gmail.com writes: On Fri, 13 Feb 2009 14:14:29 + (UTC), Freddy Vulto wrote: [..] maybe we'd better release bash_completion-2 (or ..200902xx) [..] I was starting a branch for the release process... what version number you believe is sane? I'd start at 1.0, (so as not to be necessarily linked to the bash version), and the date format is kinda weird to me. 1.0 is fine with me too - better than date format, as long as the major number is going to be increased once we drop bash-2 support. Sure it will. Can you elaborate on which releases you have in mind? Well, let me elaborate on the release process I have in mind first. 1.0 is what we have now (master). As soon as other people reply with ok (I won't wait for everyone to reply, but just two people out of 7 isn't fair), I will: 1) branch bash-completion-version, that's feature-frozen. Only bugfixes go there (cherry-picked from master). 2) we establish a freeze period. Let's say two-three days? Up to a week, however, just to find bugs and fix them on time. 3) we release the tarball, update the webpage, put it on Alioth, [..]. Maybe a make-tarball script would be good (i.e. copying debian/changelog to CHANGES, removing debian/, fixing things, using sed to dynamically substitute version number, ...) The releases I have in mind are: 1.0: first (well, second) official release from the new upstream team. New directory layout here? 1.x: bugfixes, completions split, ... -- merging bash-completion-lib here? 2.0: new major release: drop bash-2 features. 2.x: bugfixes [..] Obviously, major version numbers change for major changes. For example, the bash-completion-lib merge would deserve a 2.0 to me, but we can discuss version numbering anytime. /me wishes we move to Launchpad for bugtracking, so we can set blueprints, milestones, ... Ciao, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
David Paleino d.paleino at gmail.com writes: On Fri, 13 Feb 2009 00:11:41 +0200, Ville Skyttä wrote: On Wednesday 04 February 2009, David Paleino wrote: On Wed, 04 Feb 2009 21:59:25 +0100, Guillaume Rousse wrote: I'd insert the following items between 1 and 2, or between 2 and 3: - finish splitting every command into its own file - finish reviewing new completions Agreed. I'd rather see a real release being made before split every command takes place, no objections otherwise. Well, releasing another headache-making bash-completion doesn't really sound good to me :) Isn't there a concern that splitting every command into its own file is going to make bash_completion slower? If so, maybe we'd better release bash_completion-2 (or ..200902xx) with the improvements made so far, stop supporting bash-2, branch and make the splitting every command into its own file part of the new branch: bash_completion-3? Regards, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
