git-annex-adapter
git-annex-adapter copied to clipboard
alpernebbi
Debian packaging
Hello,
I'd like to package git-annex-metadata-gui for Debian. Could you tag a stable release, please?
Thanks.
This would be nice, but there is a lot of work I need to do before I can confidently support git-annex-adapter as stable. This version's stuff would probably be broken and I wouldn't want to support it (the old version) after the changes. I'm currently busy with some personal stuff, so it might take some time.
Would it be fine if I tagged a version as stable, then asked people to upgrade if they have a problem later on (about a month or so)? If so, I can do it after some relatively minor modifications.
Thank you for your reply!
From my point of view, there is no rush to tag a stable release. I would prefer that it be genuinely stable.
-- Sean Whitton
until it gets into Debian stable at least 2 years would pass... and to make it stable, having it in debian unstable, would help . So I would recommend to not wait for ultimate stability to accomplish the mission! ;)
@spwhitton whenever you are done with the package(s), I would be happy to ship backports through NeuroDebian.
On Tue, Jun 06, 2017 at 06:39:12PM -0700, Yaroslav Halchenko wrote:
until it gets into Debian stable at least 2 years would pass... and to make it stable, having it in debian unstable, would help . So I would recommend to not wait for ultimate stability to accomplish the mission! ;)
I see what you are saying, but only things that would be acceptable in a release should be uploaded to Debian unstable. The 'unstable' name is misleading.
-- Sean Whitton
there is always a way to keep unstable away from testing, thus away from the Debian release. I did it to a number of packages, while allowing them to mature in unstable (name is given for a reason ;) )
On Wed, Jun 07, 2017 at 09:51:42AM -0700, Yaroslav Halchenko wrote:
there is always a way to keep unstable away from testing, thus away from the Debian release. I did it to a number of packages, while allowing them to mature in unstable (name is given for a reason ;) )
No. This is what experimental is for. Please use that in future!
-- Sean Whitton
I do use it ... some times. it is all a matter of preference (point me to the policy or at least debian devel which states otherwise) and only of importance during freeze (and only if that package is within testing/rc). experimental is used only by a fraction of people using testing/unstable, so packages in experimental get significantly less testing than the ones in unstable. I do upload to experimental package versions known to be buggy if there is a better/working version in testing/unstable (and again -- during freeze). Otherwise, to get a better "real life testing" I would recommend to upload all new packages to unstable for it (and thus "testing") to live up to its name ;-)
On Wed, Jun 07, 2017 at 11:04:47AM -0700, Yaroslav Halchenko wrote:
I do use it ... some times. it is all a matter of preference (point me to the policy or at least debian devel which states otherwise) and only of importance during freeze (and only if that package is within testing/rc). experimental is used only by a fraction of people using testing/unstable, so packages in experimental get significantly less testing than the ones in unstable. I do upload to experimental package versions known to be buggy if there is a better/working version in testing/ unstable (and again -- during freeze). Otherwise, to get a better "real life testing" I would recommend to upload all new packages to unstable for it (and thus "testing") to live up to its name ;-)
Experimental's codename is "rc-buggy", i.e., it's intended for packages that are not fit for a release.
This wouldn't go into Debian Policy because it's a social practice, not a requirement for the content of packages.
-- Sean Whitton
ok, you won @spwhitton -- you can upload it to experimental right away (and I will backport from there then since doesn't matter for me really) ;)