Proliferate your Business with Wordpress!!!
Hi, Greetings from Web Crayons Biz!!! It's been familiar to everyone that WordPress is a tool and a content management system based on PHP and MySQL. No doubt the CMS is used to create beautiful websites & blogs, but innovation & creativity differs from person to person. You don't need to think much because WordPress is having numerous features, flexibility and deflate coding system which attracts the clients enormously & helps in rising business precisely. It is open-source based which means an effective and pleasant publishing platform for users. This is impossible to imagine without the hands of experts. Well, we make it possible having over hundred IT professionals developing customize WordPress Platforms which will make your work easier & convenient. We will start from scratch & migrate you to the latest version of the WordPress. Business is itself inherited from trust & believes. We will not only set your wheels in motion, but also optimize effectively in maintaining your business website with our wide range of web development services. Some of our achievements which will develop confidence in choosing us for WordPress: * Done over 900 websites & portals in WordPress. * Having over 200 clients in WordPress * Recently won a web hosting support award for our outstanding work in WordPress. * A massive team runs this company and our product is getting the huge response in the market. We would love to work alongside you and help you deliver exquisite value to your clients. If you are interested, just reply back to this email and we will get back to you promptly. With Regards, Gurpreet Business Development Manager If you do not wish to receive any further email from me, please reply me "Delist".
Re: Moving away from (unsupportable) FusionForge on Alioth?
在 2017年5月14日星期日 +08 下午2:33:19，Pirate Praveen 写道： > On ഞായര് 14 മെയ് 2017 02:23 വൈകു, Boyuan Yang wrote: > > As a result, I'm writing to suggest we find an answer to such a problem > > soon. Migration to Jessie or Stretch with new FusionForge version might > > be possible. Or we should just drop outdated FusionForge and move to some > > modern platforms like GitLab (with an alternated workflow possibly). > > This is already planned (though pagure instead of gitlab). Anyone who > wish to see it happen faster can help with > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046 There are some pages about the alternative of FusionForge on Debian Wiki but they fail to describe the final decision: [1] https://wiki.debian.org/Alioth/GitNext [2] https://wiki.debian.org/Alioth/OtherForges [3] https://wiki.debian.org/Shukra (for GitLab) And I found a long thread on debian-devel saying GitLab won't be used due to controversy: [4] https://lists.debian.org/debian-devel/2016/07/msg00510.html If that's true, I will later update [1] according to [4], remove GitLab from the option list and describe pagure as the most possible sucessor of FusionForge. Tell me if that's not correct. However, note that pagure is lacking features. For example, the authentication method only includes FAS (Fedora Account System) and local (local database). Obviously we need to implement support for Debian SSO/LDAP and migrate alioth account system by ourselves. (GitLab supports LDAP & OAuth2 [3] but anyway we are not using it.) I'm wondering where should related development work happens. -- Boyuan Yang signature.asc Description: This is a digitally signed message part.
Work-needing packages report for May 19, 2017
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1069 (new: 13) Total number of packages offered up for adoption: 163 (new: 1) Total number of packages requested help for: 44 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: debget (#862640), orphaned 3 days ago Description: download/compile source and binary Debian packages Installations reported by Popcon: 60 Bug Report URL: http://bugs.debian.org/862640 ftp-upload (#862641), orphaned 3 days ago Description: put files with FTP from a script Installations reported by Popcon: 103 Bug Report URL: http://bugs.debian.org/862641 hearse (#862642), orphaned 3 days ago Description: exchange Nethack bones files with other players Installations reported by Popcon: 114 Bug Report URL: http://bugs.debian.org/862642 lcrt (#862464), orphaned 5 days ago Description: graphic Linux remote login tool Installations reported by Popcon: 28 Bug Report URL: http://bugs.debian.org/862464 libipc-signal-perl (#862643), orphaned 3 days ago Description: utility functions dealing with signals for Perl Reverse Depends: libipc-filter-perl libproc-waitstat-perl libsignal-mask-perl Installations reported by Popcon: 3575 Bug Report URL: http://bugs.debian.org/862643 libproc-syncexec-perl (#862644), orphaned 3 days ago Description: spawn processes but report exec() errors properly Installations reported by Popcon: 18 Bug Report URL: http://bugs.debian.org/862644 libproc-waitstat-perl (#862645), orphaned 3 days ago Description: interpret and act on wait() status values Reverse Depends: debget mime-construct Installations reported by Popcon: 3496 Bug Report URL: http://bugs.debian.org/862645 libstring-shellquote-perl (#862646), orphaned 3 days ago Description: quote strings for passing through the shell Reverse Depends: cpanminus libguestfs-tools libmysql-diff-perl libnet-scp-perl libobject-remote-perl libtime-olsontz-download-perl mp3burn notmuch-mutt prolix request-tracker4 (1 more omitted) Installations reported by Popcon: 4534 Bug Report URL: http://bugs.debian.org/862646 libtime-period-perl (#862647), orphaned 3 days ago Description: Perl library for testing if a time() is in a specific period Reverse Depends: dirvish mon Installations reported by Popcon: 745 Bug Report URL: http://bugs.debian.org/862647 makepatch (#862648), orphaned 3 days ago Description: generate/apply patch files with more functionality than plain diff Installations reported by Popcon: 106 Bug Report URL: http://bugs.debian.org/862648 mime-construct (#862649), orphaned 3 days ago Description: construct/send MIME messages from the command line Reverse Depends: logcheck Installations reported by Popcon: 3419 Bug Report URL: http://bugs.debian.org/862649 pygoocanvas (#862631), orphaned 3 days ago Description: GooCanvas Python bindings Reverse Depends: openshot python-goocalendar python-ns3 Installations reported by Popcon: 6413 Bug Report URL: http://bugs.debian.org/862631 xtail (#862650), orphaned 3 days ago Description: like "tail -f", but works on truncated files, directories, more Installations reported by Popcon: 285 Bug Report URL: http://bugs.debian.org/862650 1056 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: vblade-persist (#862873), offered yesterday Description: create/manage supervised AoE exports Installations reported by Popcon: 151 Bug Report URL: http://bugs.debian.org/862873 162 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: autopkgtest (#846328), requested 169 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker openstack-pkg-tools Installations reported by Popcon: 798 Bug Report URL: http://bugs.debian.org/846328 balsa (#642906), requested 2062 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 688 Bug Report URL: http://bugs.debian.org/642906 busybox (#854181), requested 103 days ago Description: Tiny utilities for small a
Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)
On Thu, May 18, 2017 at 10:37 PM, Matthias Klumpp wrote: > Unfortunately though, the D language ABI isn't stable, so any future > compiler update might break the software in weird ways unless all D > software is recompiled when a new compiler is released. > To make things worse, D also has three different compilers (which > share the same frontend), the GNU D Compiler (GDC), LLVM D Compiler > (LDC) and the reference compiler Digital Mars D compiler (DMD). > All compilers have different advantages, but they also have > incompatible ABI, especially because each comes with a separate > version of the D runtime and standard libraries. Is there any chance of the D community creating a standard ABI that will be stable and shared all of the compilers? -- bye, pabs https://wiki.debian.org/PaulWise
Bug#862933: ITP: gmailfeed -- A plasmoid for notification and listing unread emails from your Gmail inbox
Package: wnpp Severity: wishlist Owner: Nicholas D Steeves * Package name: gmailfeed Version : 1.1 Upstream Author : Anthony Vital * URL : https://github.com/anthon38/gmailfeed * License : GPL-3 Programming Lang: C++ Description : A plasmoid for the notification and listing of unread emails from your Gmail inbox Gmail Feed is a plasmoid for Plasma 5. It provides a list of unread emails from your Gmail inbox. You also get notified when you receive new messages. -- To the best of my knowledge there is not yet a plasmoid in the archive that provides equivalent functionality. While most KDE users probably use KMail or Thunderbird, and with KDE5/Plasma Desktop can receive new email notification from an Android Phone, or allow their browser to display desktop notifications, I believe that it is useful to provide an applet such as this--particularly for memory-constrained systems where productivity is negatively affected by keeping a desktop email client running. Things I haven't yet investigated about this package: 1. Does it support kwallet? 2. Does it use the IMAP interface and/or OAuth 2.0? 3. Does it support GMail labels. - eg: Are the nofications/lists for IMAP INBOX or for "Primary" 4. If it supports GMail labels, are they configurable? I believe that it would probably be best to maintain it as part of the pkg-KDE team; however, I am not yet part of this team. Please CC this bug when replying. Failing that, I would use a git project in collab-maint. In terms of priority/timeline it will be at least a month or two before I have the time to package this. Cheers, Nicholas
Re: Moving away from (unsupportable) FusionForge on Alioth?
Hi Mattia, On Wed, May 17, 2017 at 10:38:41PM +0200, Mattia Rizzolo wrote: > I wonder... > The problem here is about fusionforge only, in fact. > If we were to move git (i.e. the vast majority of its usage) to another > place, and took down fusionforge (i.e. no more guest user management), I > do not think there is a reason to shut down the rest. > SVN could stay there, with viewvc and everything, and let packages and > project migrate whenever they need something not provided by old-alioth > (f.e. direct contribution from a non-DD that won't be possible without > fusionforge running to create its user and dealing with groups). I like this suggestion. > @tille: please have a look at pkg-haskell and their DHG_packages > repository. I've never interacted with it, and I find it highly unusual > and non-standard that I doubt the usual tooling can deal with it, but it > might of ispiration about how to deal with R packages maybe? I confirm that I once had a short look into DHG_packages and I vaguely considered this as a potential solution for R packages. What keeps me away from implementing it is that it also includes a change of workflows (not only of users but also tools that are inspecting VCS need to be rewritten). So for the moment not to change a running system is my prefered way to go - but thanks for the hint anyway. Kind regards Andreas. -- http://fam-tille.de
Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)
Hello Matthias, On Thu, May 18, 2017 at 04:37:58PM +0200, Matthias Klumpp wrote: > Looking at what other languages with the same problem have done, there > are basically two ways to deal with the issue: > > 1) Rebuild every reverse-dependency of the languages' compiler every > time the compiler is updated. This is done by Haskell and OCaml and > resulted in permanent transition trackers for the libraries. > > 2) Ship source code instead of libraries in packages, and compile it > directly into the target binaries. That way, the maintenance overhead > of the languages' packages is greatly reduced, but code is statically > linked (boo!) and a lot of code needs to be rebuilt for every > dependency (meaning more work for the autobuilders). This is done by > Go, and apparently also the plan to do for Rust. Note that Haskell is statically linked, too. We rebuild every reverse-dependency of every library that changes, not just the compiler. Are you saying that with D, it's only changes to the compiler that are problematic? -- Sean Whitton signature.asc Description: PGP signature
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
One local team of BSP Debian paris ask me to propose a new webiste. i did :) If it fit to any use you need, i'm happy, if not, i'm happy to help in fit it better :) Elisa 2017-05-18 16:54 GMT+02:00 Sean Whitton : > Hello Elisa, > > On Thu, May 18, 2017 at 03:14:49PM +0200, Elisa Godoy de Castro Guerra > wrote: > > To finish this website we need : > > - the text to present stretch to news user to debian (who do ?) > > Are you suggesting this as a "Get Stretch" website, similar to > ? > > This thread has been about replacing the whole debian.org website. > > -- > Sean Whitton > -- -- Elisa de Castro Guerra
Bug#862912: ITP: iannix -- graphical OSC sequencer for digital arts
Package: wnpp Severity: wishlist Owner: IOhannes m zmoelnig * Package name: iannix Version : 0.9.17 Upstream Author : Iannix Association * URL : https://iannix.org * License : GPL-3 Programming Lang: C++ Description : graphical OSC sequencer for digital arts IanniX is a graphical sequencer for digital arts, based on Iannis Xenakis works on graphical scores. IanniX manages events described via graphical elements (like curves) and controls your real-time environment via Open Sound Control (OSC). It can also be fully controlled via OSC (or FUDI, if you prefer). I intend to package this under the pkg-multimedia-maintainers umbrella.
Bug#862911: ITP: python-decouple -- Helps you to organize your Django|Flask settings
Package: wnpp Severity: wishlist Owner: Herbert Parentes Fortes Neto * Package name: python-decouple Version : 3.0 Upstream Author : Henrique Bastos * URL : https://pypi.python.org/pypi/python-decouple/ * License : MIT Programming Lang: Python Description : Decouple helps you to organize your Django settings Decouple helps you to organize your settings so that you can change parameters without having to redeploy your app. Framework :: Django Framework :: Flask
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
Hello Elisa, On Thu, May 18, 2017 at 03:14:49PM +0200, Elisa Godoy de Castro Guerra wrote: > To finish this website we need : > - the text to present stretch to news user to debian (who do ?) Are you suggesting this as a "Get Stretch" website, similar to ? This thread has been about replacing the whole debian.org website. -- Sean Whitton signature.asc Description: PGP signature
Packaging of libraries with unstable ABI (D, Rust, Go, ...)
Hi! Recently, I have been packaging some libraries written in the D programming language[1]. Since the D team didn't have many libraries packaged, there was no policy on how to package libraries, so I packaged them like C/C++ libraries: Make a shared lib package and have the software requiring it depend on that. Unfortunately though, the D language ABI isn't stable, so any future compiler update might break the software in weird ways unless all D software is recompiled when a new compiler is released. To make things worse, D also has three different compilers (which share the same frontend), the GNU D Compiler (GDC), LLVM D Compiler (LDC) and the reference compiler Digital Mars D compiler (DMD). All compilers have different advantages, but they also have incompatible ABI, especially because each comes with a seperate version of the D runtime and standard libraries. So, if we ship a D package containing a shared library compiled with LDC, there is a high chance that you can't use that with DMD or GDC. Also, D makes excessive use of template programming, so quite a bit of code gets embedded into the target executable even if you have shared libraries. Looking at what other languages with the same problem have done, there are basically two ways to deal with the issue: 1) Rebuild every reverse-dependency of the languages' compiler every time the compiler is updated. This is done by Haskell and OCaml and resulted in permanent transition trackers for the libraries. 2) Ship source code instead of libraries in packages, and compile it directly into the target binaries. That way, the maintenance overhead of the languages' packages is greatly reduced, but code is statically linked (boo!) and a lot of code needs to be rebuilt for every dependency (meaning more work for the autobuilders). This is done by Go, and apparently also the plan to do for Rust. The workflows for packaging we have in Debian are very tailored to C/C++ packages. So I wonder, for new packages for a programming language with no ABI stability guarantees, what is the best way to package libraries? Also more specifically: If we ship source-code, should the packages shipping it also build the source code, or should we rely on the dependencies to build the code and catch issues? What about very large libraries, or ones which take long to compile? Should those be always recompiled too, for every dependency, or should there be exceptions for it? In general, I am interested in whether we have a "best practices" for this issue yet, and I would love to hear from people maintaining Go/Rust/etc. stuff on what works and how this issue should be handled. Cheers, Matthias P.S: The D language authors are aware of the ABI issue, and apparently there is even come level of compatibility between the GDC and LDC compilers at least. D also has some rules for how it's ABI should work, but apparently going the final steps is rather difficult and given the template-centric nature of D, stabilizing the ABI doesn't have the highest priority too (it apparently also is impractical in some cases). In ay case, ABI compatibility does sometimes work, but we can not rely on it at all, especially not with multiple compilers. [1]: https://dlang.org/ -- I welcome VSRE emails. See http://vsre.info/
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
Thanks, To finish this website we need : - the text to present stretch to news user to debian (who do ?) - more ilustration to be more firendly and attractive (i can do) - official publication after official approval from community :) - a available deadline to help in organization ^^' 2017-05-18 15:06 GMT+02:00 Sean Whitton : > On Thu, May 18, 2017 at 02:37:33PM +0200, Elisa Godoy de Castro Guerra > wrote: > > I participate to the BSP debian meeting in paris last week end. > > I propose a little webpage. > > https://gitlab.com/yemanjalisa/debianstretchwebsite > > > > I would love finish this work to fit for your need. > > I dit it very quickly on last sunday in collaboration with the all local > team. > > This is really nice. Thank you for contributing. > > It's a great idea to use the branding of the latest stable release for > the splash (though I guess the existing website does that too). > > -- > Sean Whitton > -- -- Elisa de Castro Guerra
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
On Thu, May 18, 2017 at 02:37:33PM +0200, Elisa Godoy de Castro Guerra wrote: > I participate to the BSP debian meeting in paris last week end. > I propose a little webpage. > https://gitlab.com/yemanjalisa/debianstretchwebsite > > I would love finish this work to fit for your need. > I dit it very quickly on last sunday in collaboration with the all local team. This is really nice. Thank you for contributing. It's a great idea to use the branding of the latest stable release for the splash (though I guess the existing website does that too). -- Sean Whitton signature.asc Description: PGP signature
When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
Hi, My name is elisa, Sorry for my english... I participate to the BSP debian meeting in paris last week end. I propose a little webpage. https://gitlab.com/yemanjalisa/debianstretchwebsite I would love finish this work to fit for your need. I dit it very quickly on last sunday in collaboration with the all local team. I would be happy to help anyone or take in charge this task. Elisa -- -- On Mon, 2017-05-15 at 11:19 +0200, Arturo Borrero Gonzalez wrote: > On 14 May 2017 at 11:58, lumin wrote: > > On the other hand, I fancy modern platforms such > > as Gitlab, as a user. And wondering when Debian > > will update its homepage (www.d.o) to a modern > > design[1]. > > > > [1] This is off-thread, but some of my young > > friends just gave up trying Debian at the > > first glance at our homepage. > > off-thread, yes. But please spawn another thread to talk about this > real issue. > Our users are really complaining about our look&feel in the web and > we > should address it. I'm looking forward to a new design of our homepage, but I'm not able to help since not familiar to this field. Take a look at the homepages of major distros: https://www.archlinux.org/https://www.centos.org/https://www.opensuse.org/https://manjaro.org/https://www.ubuntu.com/https://getfedora.org/https://linuxmint.com/https://gentoo.org/ Especially look at the homepage of Gentoo. Some of you must remember the old gentoo homepage, but now gentoo has a way much prettier face. Then look at ours https://www.debian.org/ We are the last major distro that move to systemd as the default init system. And now we are the last major distro that keeps an old design of homepage. Debian is a community that driven by volunteers. I believe volunteers are working hard for community at the points they are interested in. I guess, possibly there are too few volunteers able/intend to update the design, so the homepage is just kept as is. If none of the volunteers is willing to contribute a new design, what about spend some money to hire several worker working on this. neilm pointed out that we don't know how to spend our money at Debconf16, that we don't know how to spend our money. Making the community better is a good reason for doing so, since a modern design may attract more users/contributors, and is less likely to scare newbies away ... Even if Debian is ranked number 2 at distrowatch. Elisa de Castro Guerra
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Thu, May 18, 2017 at 10:43:44AM +0100, Jonathan Dowland wrote: > > developer time simply to switch lots of packages from an old VCS to a > > modern one has zero effect on users desktops and has no high priority. > > Absolutely; the impact is on potential packaging contributors. In last GSoC the student was not comfortable with SVN. I have converted lots of packages at request of the student. So I'm perfectly following your reasoning if (and only if) there are potential packaging contributors at horizon. Kind regards Andreas. -- http://fam-tille.de
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
Hello Zlatan, On Tue, May 16, 2017 at 02:58:14AM +0200, Zlatan Todoric wrote: > Improving things doesn't mean destroying identity. We add and remove > archs, we added graphical installer, we don't configure graphics > manually anymore - did we loose identity? Social Contract and DFSG > ensure our identity imho. There are aspects of our community's identity that go beyond the text of those documents, though those aspects could still be construed as interpretations of clauses in those documents. In this thread, we have seen views that are fiercely anti-promotion, and views that are in favour of very radical modernisations to our site. The community consensus seems to be that we want to promote ourselves, but we care more about providing quality information than do the people who designed sites like lxde.org (sorry to keep using that example). This consensus position is itself a value of our community, and an aspect of its identity. > >> Well Debian on its page doesn't mention it is Linux based or has > >> Linux kernel or at all word Linux. > > We have Linux, HURD and the FreeBSD kernel, though. I suspect the > > thought was Debian hopes its practices, values and community will > > outlive any specific kernel, just like they could outlive apt/dpkg. > > > You could add the quote on which I quoted (lxde page doesn't say it can > be installable on linux) so my comment makes more sense Sorry, I'm still not sure what you mean. -- Sean Whitton signature.asc Description: PGP signature
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
On Tue, May 16, 2017 at 11:13:38AM +0100, Wookey wrote: > I will observe that the debian wiki is a lot more up-to-date than the > website because it is much easier to update (much as I admire wml as > a tool/language). A relevant read is https://joeyh.name/blog/entry/ending_the_tyranny_of_unix_permissions/ However, I'm not sure that our public front pages should be editable by anyone, or even all DDs. -- Sean Whitton signature.asc Description: PGP signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Thu, May 18, 2017 at 09:07:53AM +0200, Andreas Tille wrote: > > 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. This is basically the problem. It's not that we have to use exactly the same workflow, but the differences between our workflows are large enough that we can't have something like Fedora's specs repo (e.g. repos with only the contents of debian/ -- inside or outside an enclosing debian/ dir). The best way to think about the current situation is to realise that the archive is a (bad) VCS: an upload is a commit, so NMUs are commits. Except for dgit, any repo is a secondary repo when compared to the archive. I have submitted a git packaging practices BoF for DebConf. -- Sean Whitton signature.asc Description: PGP signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Wed, May 17, 2017 at 10:38:41PM +0200, Mattia Rizzolo wrote: > I wonder... > The problem here is about fusionforge only, in fact. > If we were to move git (i.e. the vast majority of its usage) to another > place, and took down fusionforge (i.e. no more guest user management), I > do not think there is a reason to shut down the rest. > SVN could stay there, with viewvc and everything, and let packages and > project migrate whenever they need something not provided by old-alioth > (f.e. direct contribution from a non-DD that won't be possible without > fusionforge running to create its user and dealing with groups). I assume that you mean a read-only dump of all the old CVS repos, which could be hosted on a newer-than-wheezy machine? > @tille: please have a look at pkg-haskell and their DHG_packages > repository. I've never interacted with it, and I find it highly > unusual and non-standard that I doubt the usual tooling can deal with > it, but it might of ispiration about how to deal with R packages > maybe? I /believe/ that the reason we have the monolithic DHG_packages is because we frequently have to upload every or almost every Haskell package at once (e.g. bump all build-deps to use new ghc and upload to experimental). I don't think it's because the workflow for packaging any given Haskell package is very simple, which was what Andreas mentioned w.r.t. R. -- Sean Whitton signature.asc Description: PGP signature
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
On Wed, May 17, 2017 at 11:49:26AM +0200, Steffen Möller wrote:
> We should vividly demonstrate on our home page that we are just that -
> alive and developing. If we could have users contribute success stories
> like "I switched my Granny from Windows to Debian and she likes it" or
> "We autoconfigure our HPC cluster in the cloud with Debian and Ansible,
> saving us 30 grand this year" then we have enough to get people hooked
> and invest to dig deeper into the site, I tend to think.
The git-annex website does this quite well:
https://git-annex.branchable.com/ ("use cases" in the middle)
--
Sean Whitton
signature.asc
Description: PGP signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
Andreas Tille writes: > I do not see a good reason to spent time into a migration from SVN to > Git. Isn't EOL of the hosting platform FusionForge a good reason? Cheers Ole
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Wed, May 17, 2017 at 11:12:53PM +, Holger Levsen wrote:
> git clone https://src.fedoraproject.org/cgit/rpms/${srcpkg}.git is really
> awesome and works for every package in Fedora! (*)
I haven't looked at it much yet but I though Ian Jackson's dgit was a pretty
neat solution to this problem; or if not a solution, a decent puzzle piece.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote: > In short: There is no doubt that Git is the better VCS but spending > developer time simply to switch lots of packages from an old VCS to a > modern one has zero effect on users desktops and has no high priority. Absolutely; the impact is on potential packaging contributors. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Moving away from (unsupportable) FusionForge on Alioth?
Hi Holger, On Wed, May 17, 2017 at 11:12:53PM +, Holger Levsen wrote: > On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote: > > In short: There is no doubt that Git is the better VCS but spending > > developer time simply to switch lots of packages from an old VCS to a > > modern one has zero effect on users desktops and has no high priority. > > 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? As I tried to explain I'm perfectly convinced that Git is way better in most cases - but those superior features are not needed in all cases. The only thing that would save me some time in the cases I mentioned is that I from time to time type svn commit -a git commit -a if I actually mean svn commit :-) > And also you're imposing a stupid tool to anyone who wants to help out or > do security fixes. Hmmm, if those packages received any NMUs the NMUer never commited anything anyway - so this argument is void. > 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). > Debian aims to be the universal OS, but that doesn't mean we have to support > an universe of workflows and tools. Surely we doesn't have to support various workflows but these have developed over the time and I never had the impression that changes in Debian happened with dead beat arguments. > Everybody should be using version > control for their packages. Really. I fully agree and I'm known for team highjacking packages into Git repositories in several cases (and was also critizised about 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. 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. > And work together nicely. +1 Kind regards Andreas. -- http://fam-tille.de
