Bug#887454: Debian Science Policy has moved [was Re: Bug#887454: Re-uploaded console-bridge]

[Sébastien Villemot]

On Sun, Feb 18, 2018 at 08:18:30AM +0100, Andreas Tille wrote:

> > If your way of doing it is really common practice, I would be glad to get
> > some references for it.
> 
> Very simple:
> 
>
> https://debian-science.alioth.debian.org/debian-science-policy.html#idm45916846202048

Note that following the move to salsa, the homepage of the Debian Science
Policy has changed, and is now:

 https://science-team.pages.debian.net/policy/

Unfortunately there seems to be an SSL certificate issue with this URL.

I have setup a redirection so that the old address of the policy redirects to
the new.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887454: Re-uploaded console-bridge

[Andreas Tille]

Hi Jochen,

I'm putting Debian Science list in CC.  More information about this
discussion is in bug #887454.

On Sun, Feb 18, 2018 at 01:41:10AM +0100, Jochen Sprickerhof wrote:
> * Andreas Tille  [2018-02-17 22:30]:
> > A not uploaded state has the target distribution "UNRELEASED".  Once it
> > is uploaded this is set to "unstable" and the commit log says something
> > like:
> > 
> >"Uploaded to unstable (or new)"
> > 
> > I think that's pretty obvious vor everybody even without a tag.
> 
> We had the UNRELEASED discussion before, so there are obviously different
> ways to do it. But I would call an upload a release, as in you should not
> modify that version anymore and also don't use the same version number again
> for something different. So you might as well tag it. I don't see a benefit
> of putting the tag afterwards, rather it would make it harder for tools like
> git-buildpackage to find a reference point for a new version. Also note that
> packages might get uploaded and used on other sites, so it's useful to have
> the tag as a reference point.
> If your way of doing it is really common practice, I would be glad to get
> some references for it.

Very simple:

   
https://debian-science.alioth.debian.org/debian-science-policy.html#idm45916846202048

The Debian Science team where this package is maintained has agreed upon
this policy.

> But otherwise we could just agree to have different
> views and stop this :).

I admit I have no big interest in keeping on this discussion, but it
makes things easier if members of a team follow the policy.

> > Its not about holding back version numbers.  As far as I know ftpmaster
> > is not really happy about Debian revisions different from "-1".
> 
> Do you have a reference for this? Because I see some packages with higher
> numbers in there and one I uploaded recently with a -2 got accepted pretty
> quick without a complaint.

I admit I'm to lazy to seek for references.  There are cases when
revisions with higher numbers accepted but what I said is that ftpmaster
"is not happy" - I did not say that it is a reason for rejection.

Kind regards

   Andreas.

-- 
http://fam-tille.de

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887454: Re-uploaded console-bridge

[Jochen Sprickerhof]

* Andreas Tille  [2018-02-17 22:30]:

A not uploaded state has the target distribution "UNRELEASED".  Once it
is uploaded this is set to "unstable" and the commit log says something
like:

   "Uploaded to unstable (or new)"

I think that's pretty obvious vor everybody even without a tag.


We had the UNRELEASED discussion before, so there are obviously 
different ways to do it. But I would call an upload a release, as in you 
should not modify that version anymore and also don't use the same 
version number again for something different. So you might as well tag 
it. I don't see a benefit of putting the tag afterwards, rather it would 
make it harder for tools like git-buildpackage to find a reference point 
for a new version. Also note that packages might get uploaded and used 
on other sites, so it's useful to have the tag as a reference point.
If your way of doing it is really common practice, I would be glad to 
get some references for it. But otherwise we could just agree to have 
different views and stop this :).



Its not about holding back version numbers.  As far as I know ftpmaster
is not really happy about Debian revisions different from "-1".


Do you have a reference for this? Because I see some packages with 
higher numbers in there and one I uploaded recently with a -2 got 
accepted pretty quick without a complaint.


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887454: Re-uploaded console-bridge

[Andreas Tille]

On Sat, Feb 17, 2018 at 07:18:11PM +0100, Jochen Sprickerhof wrote:
> * Andreas Tille  [2018-02-17 19:13]:
> > I tend to disagree.  A package that's rejected by ftpmaster will not
> > reach the archive.  I'm tagging only those commits that have an
> > equivalent package inside the package pool.
> 
> But how would you know which state you uploaded to ftp-master?

A not uploaded state has the target distribution "UNRELEASED".  Once it
is uploaded this is set to "unstable" and the commit log says something
like:

"Uploaded to unstable (or new)"

I think that's pretty obvious vor everybody even without a tag.

> Also, version
> numbers are cheap, no need to hold them back ;).

Its not about holding back version numbers.  As far as I know ftpmaster
is not really happy about Debian revisions different from "-1".  Besides
this extra options are needed when building to add upstream tarball.

As far as I know this is good packaging practice - at least all team
members I know are doing it this way.

Kind regards

   Andreas.

-- 
http://fam-tille.de

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887454: Re-uploaded console-bridge

[Andreas Tille]

Hi Jochen,

On Sat, Feb 17, 2018 at 06:12:09PM +0100, Jochen Sprickerhof wrote:
> 
> * Andreas Tille  [2018-02-17 13:48]:
> > I've re-uploaded console-bridge_0.4.0+dfsg-1 to new.
> 
> I did so as well yesterday, that's why your upload was rejected.

That's fine.

> > Please note: I have removed the changelog entry
> > 
> [..]
> > since this release never has hit the Debian mirrors.  Please note that
> > due to this change I've deleted the tag debian/0.4.0+dfsg-1.  I have not
> > set a new tag since this should be done after the package was accepted
> > by ftpmaster.
> 
> I added the tag and for me it makes sense to have it on the uploaded
> package. This makes it easier to track which version you uploaded to
> ftp-masters and in case you want to update the package in the new queue, you
> have to increase the number anyhow.

I tend to disagree.  A package that's rejected by ftpmaster will not
reach the archive.  I'm tagging only those commits that have an
equivalent package inside the package pool.

Kind regards

   Andreas.

-- 
http://fam-tille.de

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887454: Re-uploaded console-bridge

[Jochen Sprickerhof]

* Andreas Tille  [2018-02-17 19:13]:

I tend to disagree.  A package that's rejected by ftpmaster will not
reach the archive.  I'm tagging only those commits that have an
equivalent package inside the package pool.


But how would you know which state you uploaded to ftp-master? Also, 
version numbers are cheap, no need to hold them back ;).


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887454: Re-uploaded console-bridge

[Jochen Sprickerhof]

Hi Andreas,

* Andreas Tille  [2018-02-17 13:48]:

I've re-uploaded console-bridge_0.4.0+dfsg-1 to new.


I did so as well yesterday, that's why your upload was rejected. (I 
wasn't aware of the bug, so sorry for not commenting about it.)



Please note: I have removed the changelog entry


[..]

since this release never has hit the Debian mirrors.  Please note that
due to this change I've deleted the tag debian/0.4.0+dfsg-1.  I have not
set a new tag since this should be done after the package was accepted
by ftpmaster.


I added the tag and for me it makes sense to have it on the uploaded 
package. This makes it easier to track which version you uploaded to 
ftp-masters and in case you want to update the package in the new queue, 
you have to increase the number anyhow.


Cheers Jochen


signature.asc
Description: PGP signature
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#887454: Re-uploaded console-bridge

[Andreas Tille]

Hi Jose,

I've re-uploaded console-bridge_0.4.0+dfsg-1 to new.

Please note: I have removed the changelog entry


console-bridge (0.4.0-1) unstable; urgency=medium

  * New upstream version 0.4.0

 -- Jose Luis Rivero   Mon, 15 Jan 2018 18:21:19 
+


since this release never has hit the Debian mirrors.  Please note that
due to this change I've deleted the tag debian/0.4.0+dfsg-1.  I have not
set a new tag since this should be done after the package was accepted
by ftpmaster.

Further comment:  Next time please check lintian warnings.  Since it is
a pretty harmless one I simply left

W: console-bridge source: debian-rules-uses-unnecessary-dh-argument dh ... 
--parallel (line 12)

but it should be handled in next upload.

Thanks for your work on this package

  Andreas.

-- 
http://fam-tille.de

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers