Find out about your late relative
Dear debian-devel@lists.debian.org, I received your file from Mr. Maurice Moreau a genealogical surveys. It's about an estate of your late relative I would like us to discuss about it. Regards. John Lea.
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Fri, May 19, 2017 at 01:56:17PM +0200, Andreas Tille wrote: > If (and only if) there would be some momentum for a move to Git neither > I nor any other member of the Debian Med team will block this. But for > the moment I keep on failing to see an advantage only out of the fact > that "it is possible". I think the key advantage is lowering the barrier of contribution. Which is a bit funny how we ended up so - as git is the most painful to use VCS after tla. But for better or worse, there is now a generation that has become used to github style use. And if we want avoid Debian becoming an old grumpy mens club, we have cater for them. Right now, if you have a minor change - such fixing Homepage: or typo on definition, it's not as straitforward as submitting a pull request. And it gets much worse if you want to patch against upstream or build a new upstream version. Every maintainer has their own preferred workflow which a new contributor needs to adapt to. Consolodating around git/pagure could help here. Riku
infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 07:52:34AM +, Riku Voipio wrote: > Right now, if you have a minor change - such fixing Homepage: or typo on > definition, it's not as straitforward as submitting a pull request. And > it gets much worse if you want to patch against upstream or build a new > upstream version. Every maintainer has their own preferred workflow which > a new contributor needs to adapt to. _this_! I can totally confirm this. When people ask me how to get foo fixed in Debian and I start explaining the above, people role their eyes and point to this: > [...] But for better or worse, there is now a generation that has > become used to github style use. And if we want avoid Debian becoming an > old grumpy mens club, we have cater for them. and then most of these people move on without bothering trying to fix it. there have been a few trying to stick around but often they dont know where to move on, as there is no "Debian workflow", no "Debian manual", there's just a hundred Debian workflows to maintain a package and 200 manuals for that. The nice thing about standards is *not* that there are so many to choose from. -- cheers, Holger signature.asc Description: Digital signature
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
I often think about this problem, and I start to wonder if step 0 is to try and enumerate it properly. That is: I picture in my mind some kind of huge diagram (perhaps generated from more structured data, I dunno, something into a graphviz) of a landscape of debian developer tools, grouped by some kind of categorisation that might overlap (venn diagram style), so you'd have dh and cmake in one place, git-buildpackage, dgit, possibly others in another; and also our documentation: not just maint-guide but developers-reference, wiki pages, etc. Such a thing could potentially be annotated with relevant statistics (number of source packages in archive using dh; cmake; etc.; number with Vcs headers, pointing at git or svn or ... repos;) I'm inspired by the Debian Women wiki's diagrams of packaging workflows which took existing flows and presented them in a way that made them much easier to understand as a whole (and also made it clearer how complex they are, or aren't) Then we could look to see what should be eliminated in order to make the diagram simpler. We could re-calculate/draw the diagram on a regular basis: annually (or even monthly if we had much movement behind this idea of simplifying the landscape) to see what the current state of the art is, and compare it to the case last time. We could even attempt to formulate the 'ideal picture' diagram, as something to work towards, although we would not likely get a complete consensus on any one version of that. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#863121: ITP: ayatana-ido -- Widgets and other objects used for Ayatana Indicators
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: ayatana-ido Version : 0.4.0 Upstream Author : Mike Gabriel Canonical Ltd. * URL : https://github.com/ArcticaProject/aytana-ido * License : GPL, LGPL Programming Lang: C, C++ Description : Widgets and other objects used for Ayatana Indicators Shared library providing extra gtk menu items for display in system indicators. . The ayatana-ido is a fork of https://launchpad.net/ido that has been stripped-off of all Ubuntu-specific elements. It builds against and runs on top of a vanilla GTK-3, no Ubuntu-specific patches in GTK-3 are required. . The ayatana-ido widget library allows menubar providers like e.g. Arctica Greeter to render tray icons and their menus based on menu information provided over DBus for various indicator applets.
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On 22/05/17 11:29, Jonathan Dowland wrote: > I often think about this problem, and I start to wonder if step 0 is to try > and > enumerate it properly. That is: I picture in my mind some kind of huge diagram > (perhaps generated from more structured data, I dunno, something into a > graphviz) > of a landscape of debian developer tools, grouped by some kind of > categorisation that might overlap (venn diagram style), so you'd have dh and > cmake in one place, git-buildpackage, dgit, possibly others in another; and > also our documentation: not just maint-guide but developers-reference, wiki > pages, etc. > > Such a thing could potentially be annotated with relevant statistics (number > of source packages in archive using dh; cmake; etc.; number with Vcs headers, > pointing at git or svn or ... repos;) Do you mean cdbs rather than cmake? I'm struggling to make a connection between dh and cmake. Cheers, Emilio
Bug#863122: ITP: lua-argparse -- feature-rich command line parser for Lua language
Package: wnpp Severity: wishlist Owner: Victor Seva * Package name: lua-argparse Version : 0.5.0 Upstream Author : Peter Melnichenko * URL : https://github.com/mpeterv/argparse * License : Expat Programming Lang: Lua Description : feature-rich command line parser for Lua language Argparse is a feature-rich command line parser for Lua inspired by argparse for Python. Argparse supports positional arguments, options, flags, optional arguments, subcommands and more. Argparse automatically generates usage, help and error messages. It will be maintained under pkg-lua team
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 10:29:24AM +0100, Jonathan Dowland wrote: > I often think about this problem, and I start to wonder if step 0 is to try > and > enumerate it properly. That is: I picture in my mind some kind of huge diagram > (perhaps generated from more structured data, I dunno, something into a > graphviz) > of a landscape of debian developer tools, grouped by some kind of > categorisation that might overlap (venn diagram style), so you'd have dh and > cmake in one place, git-buildpackage, dgit, possibly others in another; and > also our documentation: not just maint-guide but developers-reference, wiki > pages, etc. Someone else already had this idea: https://people.debian.org/~stapelberg//2016/11/25/build-tools.html -- Sean Whitton signature.asc Description: PGP signature
Bug#863134: ITP: libayatana-indicator -- Ayatana Indicators panel applets shared library
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: libayatana-indicator Version : 0.6.0 Upstream Author : Mike Gabriel Ted Gould * URL : https://github.com/ArcticaProject/libayatana-indicator * License : GPL Programming Lang: C Description : Ayatana Indicators panel applets shared library This library contains information to build indicators to go into the Ayatana Indicator based panel applets. . The libayatana-indicator project is a fork of https://launchpad.net/libindicator that has been stripped-off of all Ubuntu-specific elements. It builds against and runs on top of a vanilla GTK-3 (or GTK-2), no Ubuntu-specific patches in GTK-3 are required. Ubuntu and Canonical namespaces (e.g. in DBus) have been fully dropped. . With this shared library, developers can code indicator based applets (GTK-2 and GTK-3 are supported currently) for modern desktop integration.
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 12:28:01PM +0200, Emilio Pozuelo Monfort wrote: > Do you mean cdbs rather than cmake? I'm struggling to make a connection > between > dh and cmake. Yes, I do; thanks for the correction. (although it does remind me that this issue of more-than-one-way-to-do-it extends up to upstreams, too) -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote: > Someone else already had this idea: > > https://people.debian.org/~stapelberg//2016/11/25/build-tools.html Excellent, this is a great start, and seeing "Michael Stapelberg" for me is an indication of quality. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away
from (unsupportable) FusionForge on Alioth?)"):
> I can totally confirm this. When people ask me how to get foo fixed in Debian
> and I start explaining the above, people role their eyes and point to this:
Yes.
> there have been a few trying to stick around but often they dont
> know where to move on, as there is no "Debian workflow", no "Debian
> manual", there's just a hundred Debian workflows to maintain a
> package and 200 manuals for that.
I would encourage anyone who has effort to work on this end of the
contributor experience to consider what dgit has to offer. dgit
provides a single git workflow for all Debian packages.
Depending on the maintainer's workflow practices, the history may be
poor, but the code is there in your git tree just like a non-Debian
git user would expect, and patches can be cherry-picked straight onto
it off upstream branches.
The dgit user does not need to know anything about the Debian
packaging teams or workflow rules or to read package-specific
documentation from the maintainer; nor do they need to know anything
about Debian source *packages* (as opposed to source *trees*).
To do a test build and install the user does need to know
some runes, and they do need to mess with the changelog:
https://manpages.debian.org/jessie-backports/dgit/dgit-user.7.en.html
(And of course if they want to change packaging they will need to know
or learn about whatever it is they're changing.)
Areas of work that could do with attention from people with relevant
expertise and effort:
* Getting rid of the need to mess with the changelog. That might
involve changes to Debian changelog practice, or better tooling (eg
yet another wrapper around dpkg-buildpackage - maybe a way to set
the version without committing? - etc. etc.)
* Pull request workflow for submitting changes. This should
eventually turn into a bug submission to the Debian BTS.
This sounds to me like it probabl needs to be a web service, but
perhaps some local client utility that looked enough like a web
page would do.
* User/contributor testing to discover other roadblocks that make
contribution tricky.
An area that I am working on myself is:
* A way to do a new upstream version that does not involve the user
having to mess with Debian source packages. Sadly I can't see how
to do this in a reasonable way without interacting with the
maintainers' git workflows; for now, I am working on a way for
maintainer(s) to cooperate using git branches as the interchange
format, with the patch stacks on upstream worked on as a rebasing
git branch.
Ian.
Bug#863136: ITP: sphinx-autorun -- code execution extension for Sphinx
Package: wnpp Severity: wishlist Owner: =?utf-8?q?F=C3=A9lix_Sipma?= * Package name: sphinx-autorun Version : 1.0.1 Upstream Author : Hugo Osvaldo Barrera * URL : https://github.com/hobarrera/sphinx-autorun/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Programming Lang: Python Description : Code execution extension for Sphinx This extension for Sphinx that can execute the code from a runblock directive and attach the output of the execution to the document. This package is a build dependency of todoman, another ITP of mine. I'd like to maintain it in the python modules team. I've sent a request to join the team, but did not get any answer yet. signature.asc Description: PGP signature
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote: > On Mon, May 22, 2017 at 12:47:51PM +0100, Sean Whitton wrote: > > Someone else already had this idea: > > > > https://people.debian.org/~stapelberg//2016/11/25/build-tools.html > > Excellent, this is a great start, and seeing "Michael Stapelberg" for me is an > indication of quality. You say that, but this is incredibly biased. Even he admits that in the colour choice. Disclaimer: as the cowbuilder maintainer (which comes from the cow*dancer* source package, for historical reasons, despite what the diagram may tell you) I am of course also biased. But I notice that for the sbuild path, schroot is completely missing, which is implemented in C++ and therefore probably deserves a bright red colour just like cowbuilder in his second picture (or maybe even something worse, depending on your views of C++). Then there's the extremely unhelfpul, hostile comment at the end: > I propose to eliminate complexity in Debian by deprecating the > pbuilder toolchain in favor of sbuild. Now, I am not necessarily against simplifying workflows, but choosing one to rule the all arbitrarily because you prefer the language it's written in is not the way to go about it. There are also benefits to having a variety of implementations; they behave slightly differently, sometimes not implementing policy in the same way, and this can be a good thing, allowing policy to be clarified, or finding mistakes in the other builder, or just exposing flaws in your package. For example, pbuilder will by default use a new isolated network namespace for the build, whereas sbuild won't, so if you just use sbuild you may not be aware of violating policy (4.9). I'm not trying to sell pbuilder over sbuild here though; there are also many ways in which sbuild is better than pbuilder. James
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote: > On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote: > > Excellent, this is a great start, and seeing "Michael Stapelberg" for me is > > an ^^^ > > indication of quality. emphasis on *start* > You say that, but this is incredibly biased. Even he admits that in the > colour choice. I was completely ignoring the colour choices and implementation language. > that for the sbuild path, schroot is completely missing Indeed there are a lot of omissions. I think the next step, whether this is the basis for what goes next, or not, would be to get the source of this picture (or another) into a version control system so it can be iteratively and collaboratively improved. [ Stapelberg via James Clarke ] > > I propose to eliminate complexity in Debian by deprecating the > > pbuilder toolchain in favor of sbuild. > > Now, I am not necessarily against simplifying workflows, but choosing > one to rule the all arbitrarily because you prefer the language it's > written in is not the way to go about it. Language should be a factor, as there are practical considerations that can't be avoided, independent of personal preferences – but I got the impression that he was not coming to this conclusion soley on the basis of implementation language anyway, nor soley in terms of his own preferences for implementation language. > There are also benefits to having a variety of implementations; they behave > slightly differently, sometimes not implementing policy in the same way, and > this can be a good thing, allowing policy to be clarified, or finding > mistakes in the other builder, or just exposing flaws in your package. These are good points. However, considering just these points in isolation, the "secondary" implementation(s) would not need to be something that was actually geared towards real users, or advertised as such. > I'm not trying to sell pbuilder over sbuild here though; there are also many > ways in which sbuild is better than pbuilder. I am not (yet) familiar enough with either of them (or the other dozen or so similar tools for the same job) to come to a conclusion on what I think would be the correct number/recommendations for Debian contributors, but I am of the initial opinion that there are too many. I've heard a lot of good things about sbuild. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 10:07 AM, Ian Jackson
wrote:
> Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away
> from (unsupportable) FusionForge on Alioth?)"):
> I would encourage anyone who has effort to work on this end of the
> contributor experience to consider what dgit has to offer. dgit
> provides a single git workflow for all Debian packages.
Of course, dgit is yet another workflow and my understanding is that
git-buildpackage (without dgit) is far more commonly used in Debian.
Thanks,
Jeremy Bicha
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote: > there's just a hundred Debian workflows to maintain a package and 200 > manuals for that. No, no, there are more workflows than manuals for them. -- WBR, wRAR signature.asc Description: PGP signature
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On 05/22/2017 07:42 PM, Jeremy Bicha wrote:
> On Mon, May 22, 2017 at 10:07 AM, Ian Jackson
> wrote:
>> Holger Levsen writes ("infinite number of Debian workflows (Re: Moving away
>> from (unsupportable) FusionForge on Alioth?)"):
>> I would encourage anyone who has effort to work on this end of the
>> contributor experience to consider what dgit has to offer. dgit
>> provides a single git workflow for all Debian packages.
> Of course, dgit is yet another workflow and my understanding is that
> git-buildpackage (without dgit) is far more commonly used in Debian.
>
> Thanks,
> Jeremy Bicha
>
https://xkcd.com/927/
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 10:46:59PM +0500, Andrey Rahmatullin wrote: > On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote: > > there's just a hundred Debian workflows to maintain a package and 200 > > manuals for that. > No, no, there are more workflows than manuals for them. For instance there is no manual for cdbs (at least I have not yet found one that helps you over the real hurdles). SCNR Andreas. -- http://fam-tille.de
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 01:42:54PM -0400, Jeremy Bicha wrote: > Of course, dgit is yet another workflow and my understanding is that > git-buildpackage (without dgit) is far more commonly used in Debian. This isn't fair to dgit. While it does impose some minimal requirements upon git trees, it is otherwise workflow neutral. This is evidenced by the fact that there are already several distinct dgit-compatible workflows documented in the dgit-maint-*(7) namespace. -- Sean Whitton signature.asc Description: PGP signature
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 03:07:42PM +0100, Ian Jackson wrote: > Areas of work that could do with attention from people with relevant > expertise and effort: > > * Getting rid of the need to mess with the changelog. That might >involve changes to Debian changelog practice, or better tooling (eg >yet another wrapper around dpkg-buildpackage - maybe a way to set >the version without committing? - etc. etc.) A way to set the version during the build, as you suggest, would be sufficient to cover this. It is hard to see how we could relieve the user of the need to understand how to choose a version number for a .deb for testing. An option to set the version in the build command line would remove the need for Debian source package knowledge. > * Pull request workflow for submitting changes. This should >eventually turn into a bug submission to the Debian BTS. >This sounds to me like it probabl needs to be a web service, but >perhaps some local client utility that looked enough like a web >page would do. We basically already have all the pieces: - git-request-pull(1) - reportbug(1) - git hosting on alioth / our shiny pagure git hosting (coming soon) dgit could ship a script that ties these together. (The reason I suggest using our own git hosting is so that the branch doesn't disappear -- one advantage of patches in the BTS is that they can't 404.) -- Sean Whitton signature.asc Description: PGP signature
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, May 22, 2017 at 05:10:26PM +0100, Jonathan Dowland wrote: > On Mon, May 22, 2017 at 03:25:38PM +0100, James Clarke wrote: > > On Mon, May 22, 2017 at 03:06:48PM +0100, Jonathan Dowland wrote: > > > Excellent, this is a great start, and seeing "Michael Stapelberg" for me > > > is an >^^^ > > > indication of quality. > > emphasis on *start* To qualify as "great" I think you should be accurate, but hey, maybe I have too high standards. Anyway the main point wasn't to attack you but to provide another side to that blog post. > > You say that, but this is incredibly biased. Even he admits that in the > > colour choice. > > I was completely ignoring the colour choices and implementation language. > > > that for the sbuild path, schroot is completely missing > > Indeed there are a lot of omissions. I think the next step, whether this > is the basis for what goes next, or not, would be to get the source of > this picture (or another) into a version control system so it can be > iteratively and collaboratively improved. That sounds sensible (for the uncoloured version). > [ Stapelberg via James Clarke ] > > > I propose to eliminate complexity in Debian by deprecating the > > > pbuilder toolchain in favor of sbuild. > > > > Now, I am not necessarily against simplifying workflows, but choosing > > one to rule the all arbitrarily because you prefer the language it's > > written in is not the way to go about it. > > Language should be a factor, as there are practical considerations that can't > be avoided, independent of personal preferences – but I got the impression > that he was not coming to this conclusion soley on the basis of implementation > language anyway, nor soley in terms of his own preferences for implementation > language. Sure, language can be important, but I would say Bash and C are *more* accessible to the average developer these days than Perl, and that's only going to become more true over time. He didn't give any other reasons, but if there are, these would be welcome in the form of constructive bug reports so we can address them and make the situation better for everyone. > > There are also benefits to having a variety of implementations; they behave > > slightly differently, sometimes not implementing policy in the same way, and > > this can be a good thing, allowing policy to be clarified, or finding > > mistakes in the other builder, or just exposing flaws in your package. > > These are good points. However, considering just these points in isolation, > the "secondary" implementation(s) would not need to be something that was > actually geared towards real users, or advertised as such. There already effectively is a semi-"primary" implementation given that sbuild is used on the buildds. And as for making these "secondary" implementations not geared for real users, for whom would they then be? Designating a certain tool as "primary" will just lead its behaviour becoming the de facto policy, so everyone will be required to build with it locally, and so nobody would even consider using a secondary alternative. > > I'm not trying to sell pbuilder over sbuild here though; there are also many > > ways in which sbuild is better than pbuilder. > > I am not (yet) familiar enough with either of them (or the other dozen or so > similar tools for the same job) to come to a conclusion on what I think would > be the correct number/recommendations for Debian contributors, but I am of the > initial opinion that there are too many. I've heard a lot of good things about > sbuild. There are lots of areas where Debian has far too many tools to accomplish the same thing, but I don't think this is one of them; there are only two main tools for building in chroots (sbuild and pbuilder[0]), both of which have significant user bases. Anyway, I'm done with this debate; it's clear I have very different views from some on this matter. James [0] cowbuilder is a thin wrapper that behaves (almost) identically, so it doesn't really count as something different
Bug#863170: ITP: libayatana-appindicator -- Ayatana Application Indicators
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: libayatana-appindicator Version : 0.5.0 Upstream Author : Mike Gabriel Ted Gould Cody Russel * URL : https://github.com/ArcticaProject/libayatana-appindicator * License : GPL, LGPL Programming Lang: C Description : Ayatana Application Indicators With Aytana Application Indicators you can build indicator applets for modern desktops. . The upstream project has been formed from Ubuntu's libappindicator project in order to make it available on Ubuntu and non-Ubuntu platforms alike. Thus, all Ubuntu-specfic patches have been removed/replaced. . The purpose of Ayatana Indicators is providing a generic approach for indicator support, so that all available Linux distributions can benefit from the indicators concept.
Re: Moving away from (unsupportable) FusionForge on Alioth?
Hi Andreas, On Thu, May 18, 2017 at 09:07:53AM +0200, Andreas Tille wrote: > > I think that in the mid-term (probably even in short term) you'll *save* > > developer time by switching to git, > And your thinking is based on what arguments? a.) git is a lot faster than svn on most operations, which btw does not allow one to get things done faster, but also enables one to do things which one would never do with svn… (because its just so damn slow…) b.) if one needs to know and use several scm tools, one will make more mistakes using those tools (as you explained in the mail I'm replying to…) > > I'd be happy if Debian would enforce git for every source package now! > > I'm willing to adapt to such decision but I feel my time totally wasted > to do a SVN versus Git flamewar (and this is my last mail regarding > this). oh, yes, surely a flamewar helps noone. just to make a good decision one needs to discuss, and again, best without flamewars! :) > I fully agree and I'm known for team highjacking packages into Git > repositories in several cases (and was also critizised about doing so). I applaud you for doing so. > > And probably we should all just use git. > If we really could agree upon a common workflow I will definitely adapt. > But there is no such agreement as far as I can see. quite probably there will always be some with who will not use debhelper, not use version control, ignore bugs in stable, dont tests their uploads, doing foo, but that shouldnt stop everybody else from agreeing on things. > Please take my > previous mail rather as an explanation for the current state than my > definite wish to keep the status quo under any circumstance. happily noted. also noted that half of the packages you're uploading to main *are* maintained in git :) (and the other half svn… /me likes stats too much :) -- cheers, Holger signature.asc Description: Digital signature
Bug#863189: ITP: ert-expectations-el -- very simple unit test framework for Emacs Lisp
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: ert-expectations-el Version : 0.2 Upstream Author : rubikitch * URL or Web page : https://www.emacswiki.org/emacs/download/ert-expectations.el * License : GPL-3+ Programming Lang: Emacs Lisp Description : very simple unit test framework for Emacs Lisp The package provides a very simple unit test framework using `ert'. It is thought to be a successor of el-expectations. With Emacs Lisp Mock, `el-mock.el', Emacs Lisp Expectations supports mock and stub (behavior-based testing). The package uses `ert' feature to display test result, so it is quite easy to understand why a test failed.
Re: infinite number of Debian workflows (Re: Moving away from (unsupportable) FusionForge on Alioth?)
On Mon, 22 May 2017 22:20:29 +0200, Andreas Tille wrote: >On Mon, May 22, 2017 at 10:46:59PM +0500, Andrey Rahmatullin wrote: >> On Mon, May 22, 2017 at 09:07:52AM +, Holger Levsen wrote: >> > there's just a hundred Debian workflows to maintain a package and 200 >> > manuals for that. >> No, no, there are more workflows than manuals for them. > >For instance there is no manual for cdbs (at least I have not yet found >one that helps you over the real hurdles). cdbs docs used to be pretty good. Or at least I remember them to be that way before I switched to dh. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#863190: ITP: el-mock-el -- tiny mock and stub framework for Emacs Lisp
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: el-mock-el Version : 1.25.1 Upstream Author : rubikitch , Johan Andersson * URL or Web page : https://github.com/rejeep/el-mock.el * License : GPL-2+ Programming Lang: Emacs Lisp Description : tiny mock and stub framework for Emacs Lisp Emacs Lisp Mock is a library for mocking and stubbing using readable syntax. Most commonly Emacs Lisp Mock is used in conjunction with Emacs Lisp Expectations, but it can be used in other contexts.
