On വ്യാഴം 01 മാർച്ച് 2018 05:45 വൈകു, Ian Jackson wrote:
> For the avoidance of doubt, I don't have a problem with the specific
> decision of ftpmaster here.
Coming back to this specific rejection (I have already started a
discussion on policy question in d-policy), do you agree node-backbone
(an
On Mon, Mar 05, 2018 at 02:43:34PM -0700, Sean Whitton wrote:
> If a package is maintained in git, then re-using a version number means
> force-pushing a git tag
Just don't tag uploads until they are accepted.
--
WBR, wRAR
signature.asc
Description: PGP signature
Package: wnpp
Followup-For: Bug #854895
Owner: Andre Bianchi
retitle 854895 ITP: social-auth-app-django -- Core component of the
python-social-auth ecosystem
thank you
I intend to package this. PyPI page is:
https://pypi.python.org/pypi/social-auth-app-django
On Monday, March 05, 2018 04:46:27 PM Sean Whitton wrote:
> Hello,
>
> On Mon, Mar 05 2018, Scott Kitterman wrote:
> > I'm not sure you actually read what I wrote since I wrote that I
> > thought REQUIRING the revision to be bumped was a bad idea and you
> > gave me a case where it made sense to d
Hello,
On Mon, Mar 05 2018, Scott Kitterman wrote:
> I'm not sure you actually read what I wrote since I wrote that I
> thought REQUIRING the revision to be bumped was a bad idea and you
> gave me a case where it made sense to do so. Nowhere in this thread
> have I ever said bumping the revision
Hi there,
My new book Configuration Management: Standard Requirements is out, get it here:
https://www.dropbox.com/s/86hqr1454ovgdqw/CM_Configuration_Management.pdf?dl=0
My goal is to get in front of anyone who will benefit from it. - perhaps you
will be able to help more people
On Sun 04 Mar 2018 at 19:10:02 +0100, Philip Hands wrote:
> Jude DaShiell writes:
>
> > The least debian-boot membership could do would be to have a note come
> > up for installers to execute a shell and do the file copy before
> > rebooting once hard drive got mounted. This is a problem for
On Monday, March 05, 2018 02:43:34 PM Sean Whitton wrote:
> Hello,
>
> On Mon, Mar 05 2018, Scott Kitterman wrote:
> > Taken to it's logical end, then every VCS commit should have it's own
> > revision.
>
> Could you explain how this follows? I don't see it.
If you consider it absurd to not inc
Hello,
On Mon, Mar 05 2018, Scott Kitterman wrote:
> Taken to it's logical end, then every VCS commit should have it's own
> revision.
Could you explain how this follows? I don't see it.
> I think requiring a maintainer to increment the Debian revision of a
> package based on things that happe
Hello,
On Mon, Mar 05 2018, Philipp Kern wrote:
> The most common counterpoint to bumping the version is that it's
> harder to get right because for some reason our tools rely on the
> whole delta to be present in the .changes file rather than inferring
> it from the in-package changelog. So bug
On 03/05/2018 08:08 PM, Scott Kitterman wrote:
> On March 5, 2018 7:01:14 PM UTC, Don Armstrong wrote:
>> On Mon, 05 Mar 2018, Scott Kitterman wrote:
>>> I think requiring a maintainer to increment the Debian revision of a
>>> package based on things that happen outside the Debian archive is
>>> "
On March 5, 2018 7:01:14 PM UTC, Don Armstrong wrote:
>On Mon, 05 Mar 2018, Scott Kitterman wrote:
>> I think requiring a maintainer to increment the Debian revision of a
>> package based on things that happen outside the Debian archive is
>"not
>> a good idea'[1].
>
>I don't want to make it a r
On Mon, 05 Mar 2018, Scott Kitterman wrote:
> I think requiring a maintainer to increment the Debian revision of a
> package based on things that happen outside the Debian archive is "not
> a good idea'[1].
I don't want to make it a requirement, just recommended good practice
when an upload has be
On Monday, March 05, 2018 05:54:59 PM Ian Jackson wrote:
> Gert Wollny writes ("Re: Updated proposal for improving the FTP NEW
process"):
> > The only option I see for doing this in the BTS would be to ask the ftp
> > team to file the reject messages as a new bug against the source
> > package. I
Steffen Nurpmeso writes ("Re: Rant about Debian reproducibility environment"):
> But despite that and the possibly correct observation that placing
> just about any environmental info in any non-system-dependent
> object you can close the issue that is my rant, but will not get
> away from the fact
Gert Wollny writes ("Re: Updated proposal for improving the FTP NEW process"):
> The only option I see for doing this in the BTS would be to ask the ftp
> team to file the reject messages as a new bug against the source
> package. I refrained from proposing this because this would mean filing
> a
On Mon, 05 Mar 2018, Gert Wollny wrote:
> Since the re-upload to NEW would have the same version like the
> version the bug is filed against
You don't have to upload with the same version (I usually don't, because
I've already tagged the previous upload in git).
> the BTS might get a hiccup. For
On Monday, March 05, 2018 04:00:06 PM W. Martin Borgert wrote:
> Quoting Chris Lamb :
> >> In many cases, there is an issue open about the new binary package
> >
> > (In my experience, there is not.)
> >
> >> When there is no bug report open at all, well, bad luck.
> >
> > Well, possbibly, but i
Simon McVittie wrote:
> Are binary-NEW packages more likely to violate the DFSG than randomly
> chosen packages?
I can't speak to a randomly-selected package, but IME entirely new source
packages are less likely have problems IME than older ones that Just
Visiting, thus ...
> If the goal is to
Am Montag, den 05.03.2018, 14:27 + schrieb Chris Lamb:
> Hi Gert,
>
> > (1) Given that all new source package come with an ITP bug, when a
> > package must be rejected, the FTP team could CC this bug in the
> > rejection message.
>
> Do you have any concrete suggestions for packages that are
On Mon, 05 Mar 2018 at 14:27:31 +, Chris Lamb wrote:
> > (1) Given that all new source package come with an ITP bug, when a
> > package must be rejected, the FTP team could CC this bug in the
> > rejection message.
>
> Do you have any concrete suggestions for packages that are "Just
> Visiting
On Mon, 2018-03-05 at 14:51 +, Chris Lamb wrote:
> Hi Martin,
>
> > In many cases, there is an issue open about the new binary package
>
> (In my experience, there is not.)
>
> > When there is no bug report open at all, well, bad luck.
>
> Well, possbibly, but if one is investing time and e
Quoting Chris Lamb :
In many cases, there is an issue open about the new binary package
(In my experience, there is not.)
When there is no bug report open at all, well, bad luck.
Well, possbibly, but if one is investing time and effort in changing a
process it seems a shame not to cover the
Hi Martin,
> In many cases, there is an issue open about the new binary package
(In my experience, there is not.)
> When there is no bug report open at all, well, bad luck.
Well, possbibly, but if one is investing time and effort in changing a
process it seems a shame not to cover these cases I
On 2018-03-05 12:18, Gert Wollny wrote:
> (1) Given that all new source package come with an ITP bug, when a
> package must be rejected, the FTP team could CC this bug in the
> rejection message.
i would really like to see this.
sometimes i miss rejection emails - or at least wonder whether i miss
Quoting Chris Lamb :
Do you have any concrete suggestions for packages that are "Just
Visiting" NEW, such as ones adding, say, a python3-foo, a -doc, a
SONAME bump, first upload to experimental, etc. etc.? They do not
have ITP bugs.
In many cases, there is an issue open about the new binary pac
Hi Gert,
> (1) Given that all new source package come with an ITP bug, when a
> package must be rejected, the FTP team could CC this bug in the
> rejection message.
Do you have any concrete suggestions for packages that are "Just
Visiting" NEW, such as ones adding, say, a python3-foo, a -doc, a
S
On Mon, Mar 5, 2018 at 7:18 PM, Gert Wollny wrote:
> (2) To improve the initial quality of uploads to NEW I also propose the
> introduction a (voluntary) review step:
These sort of things have been proposed multiple times before but
never materialised into policy, convention or common activity. H
Package: wnpp
Severity: wishlist
Owner: Andreas Tille
* Package name: r-cran-fauxpas
Version : 0.2.0
Upstream Author : Scott Chamberlain
* URL : https://cran.r-project.org/package=fauxpas
* License : MIT
Programming Lang: GNU R
Description : GNU R HTTP
Dear all,
thanks for all the feedback, based on this I'd like to modify the
proposal like follows:
(1) Given that all new source package come with an ITP bug, when a
package must be rejected, the FTP team could CC this bug in the
rejection message. This would have the advantage that for everyon
30 matches
Mail list logo
