Discussion:
bcache-tools ITP
Robie Basak
2014-09-17 11:55:38 UTC
Permalink
I have some progress to report. I also think that this is ready to
upload, though we should sort out a couple of things first.

I've added the bcache list (this is the Debian packaging bug) since
there is a question about some of these commits that seem to be relevant
to upstream but aren't in the upstream branch.

I've done some (functional only) testing of bcache itself with a
colleague, and we haven't seen any major issues.

I think the packaging is good to go, though I've added a removal of one
extraneous file and updated debian/copyright. This is in
github.com/basak/bcache-tools. I haven't submitted any pull requests to
avoid confusion (see below).

A colleague (James Page) is a DD and is prepared to upload, provided
that we all agree on who will maintain the package first. I'm happy to
step up. Who else does?

I found following all the various git trees confusing, and think we
should resolve this soon after upload. There are three git trees I'm
aware of, and I've added a fourth:

1) http://evilpiepirate.org/git/bcache-tools.git
2) git://github.com/g2p/bcache-tools.git
3) git://github.com/squisher/bcache-tools.git
4) git://github.com/basak/bcache-tools.git

Vcs-Git points to 2 (g2p). I also noted that the github branches seem to
contain commits to the upstream source, too, that aren't present in the
"upstream" repository (1).

Can we define which the canonical upstream source tree is, please, and
where the canonical Debian packaging branch should be? Then we can work
on pushing the changes back to the right places, rather than having
scattered branches all over the place. I noticed some changes to the
upstream source that don't appear to be in branch 1, for example.

I think it would be easiest to upload, since I think it's good to go and
this will at least result in a definitive packaging state that we can
work from.

In the meantime, I think branch 3 contained everything, so I cloned that
one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.

So in summary:

1) Define and agree maintainers.
2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.
3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there are
any objections to James uploading.
4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.

In the meantime, I'll upload to Ubuntu as I can do that straight away
and we're quite close to release now. I hope that we can get Debian
straightened out soon.

Robie
Robie Basak
2014-09-17 13:08:05 UTC
Permalink
Post by Robie Basak
Can we define which the canonical upstream source tree is, please, and
where the canonical Debian packaging branch should be? Then we can work
on pushing the changes back to the right places, rather than having
scattered branches all over the place. I noticed some changes to the
upstream source that don't appear to be in branch 1, for example.
I've looked again and I see that 1.0.7 is tagged in the Github repos,
but not in evilpiepirate.org/git/bcache-tools.git.

Does this mean that the Github repos are now the canonical upstream?
Should the page at http://bcache.evilpiepirate.org/ be changed?
David Mohr
2014-09-17 22:35:59 UTC
Permalink
About the licensing & copyright: I emailed Gabriel and Kent Overstreet
on 2014-06-02 but did not get a reply. I admit though that I didn't
follow up afterwards.
Post by Robie Basak
1) http://evilpiepirate.org/git/bcache-tools.git
Original sources, no changes in a while.
Post by Robie Basak
2) git://github.com/g2p/bcache-tools.git
First clone by Gabriel, contains work and bugfixes to the bcache-tools
userland and some initial Debian packaging.
Post by Robie Basak
3) git://github.com/squisher/bcache-tools.git
My work on Debian packaging. I set Vcs-Git to g2p's version instead of
mine because that seems to be the most active upstream repository. I
thought this was relevant for uscan, but obviously I was wrong (as was
pointed out on mentors.debian.net).
Post by Robie Basak
4) git://github.com/basak/bcache-tools.git
Vcs-Git points to 2 (g2p). I also noted that the github branches seem to
contain commits to the upstream source, too, that aren't present in the
"upstream" repository (1).
I thought that (1) is historic at this point and considered (2) the
upstream. I did not verify that though.

I would suggest to co-maintain the package on
https://alioth.debian.org/projects/collab-maint
Post by Robie Basak
I think it would be easiest to upload, since I think it's good to go and
this will at least result in a definitive packaging state that we can
work from.
Fine by me.
Post by Robie Basak
In the meantime, I think branch 3 contained everything, so I cloned that
one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.
Right, see above.
Post by Robie Basak
1) Define and agree maintainers.
I'd like to get my feet wet and co-maintain, if you're interested.
Post by Robie Basak
2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.
I'd say point it at 3) or at collab-maint, if that's where the packaging
ends up being.
Post by Robie Basak
3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there are
any objections to James uploading.
Bernd Zeimetz, I added him to the CC, was willing to sponsor the package
once it was ready. But since he has been pretty busy recently, I don't
think he'll object to James uploading. I definitely don't; it'd be
awesome to get this finally into the official repository!
Post by Robie Basak
4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.
I very much agree.

~David
Rolf Fokkens
2014-09-18 17:26:10 UTC
Permalink
Hi,

For the Fedora package I solely aimed at the (Kent's) evilpiepirate bcache-tools repo. Most development was done in Gabriel's (g2p) repo in preperation of the Fedora package, but that was merged by Kent prior to the Fedora package release.

After that not much has happened in Kent's repo, and te status of that repo is unclear to me.

Rolf
About the licensing & copyright: I emailed Gabriel and Kent Overstreet on 2014-06-02 but did not get a reply. I admit though that I didn't follow up afterwards.
Post by Robie Basak
1) http://evilpiepirate.org/git/bcache-tools.git
Original sources, no changes in a while.
Post by Robie Basak
2) git://github.com/g2p/bcache-tools.git
First clone by Gabriel, contains work and bugfixes to the bcache-tools userland and some initial Debian packaging.
Post by Robie Basak
3) git://github.com/squisher/bcache-tools.git
My work on Debian packaging. I set Vcs-Git to g2p's version instead of mine because that seems to be the most active upstream repository. I thought this was relevant for uscan, but obviously I was wrong (as was pointed out on mentors.debian.net).
Post by Robie Basak
4) git://github.com/basak/bcache-tools.git
Vcs-Git points to 2 (g2p). I also noted that the github branches seem to
contain commits to the upstream source, too, that aren't present in the
"upstream" repository (1).
I thought that (1) is historic at this point and considered (2) the upstream. I did not verify that though.
I would suggest to co-maintain the package on https://alioth.debian.org/projects/collab-maint
Post by Robie Basak
I think it would be easiest to upload, since I think it's good to go and
this will at least result in a definitive packaging state that we can
work from.
Fine by me.
Post by Robie Basak
In the meantime, I think branch 3 contained everything, so I cloned that
one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.
Right, see above.
Post by Robie Basak
1) Define and agree maintainers.
I'd like to get my feet wet and co-maintain, if you're interested.
Post by Robie Basak
2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.
I'd say point it at 3) or at collab-maint, if that's where the packaging ends up being.
Post by Robie Basak
3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there are
any objections to James uploading.
Bernd Zeimetz, I added him to the CC, was willing to sponsor the package once it was ready. But since he has been pretty busy recently, I don't think he'll object to James uploading. I definitely don't; it'd be awesome to get this finally into the official repository!
Post by Robie Basak
4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.
I very much agree.
~David
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Darrick J. Wong
2014-09-17 23:21:14 UTC
Permalink
Hi,

If you're interested in the bcache-status[1] tool, I'd be happy to work with
you to get (and keep) it in Debian. I /think/ it's in the Fedora package.

(afaict the script is not in any of those git trees...)
Post by Robie Basak
I have some progress to report. I also think that this is ready to
upload, though we should sort out a couple of things first.
I've added the bcache list (this is the Debian packaging bug) since
there is a question about some of these commits that seem to be relevant
to upstream but aren't in the upstream branch.
I've done some (functional only) testing of bcache itself with a
colleague, and we haven't seen any major issues.
I think the packaging is good to go, though I've added a removal of one
extraneous file and updated debian/copyright. This is in
github.com/basak/bcache-tools. I haven't submitted any pull requests to
avoid confusion (see below).
A colleague (James Page) is a DD and is prepared to upload, provided
that we all agree on who will maintain the package first. I'm happy to
step up. Who else does?
I found following all the various git trees confusing, and think we
should resolve this soon after upload. There are three git trees I'm
1) http://evilpiepirate.org/git/bcache-tools.git
2) git://github.com/g2p/bcache-tools.git
3) git://github.com/squisher/bcache-tools.git
4) git://github.com/basak/bcache-tools.git
I had thought that #2 was the new upstream, but then I haven't paid attention
in a while either.

--D

[1] https://gist.github.com/djwong/6343451
Post by Robie Basak
Vcs-Git points to 2 (g2p). I also noted that the github branches seem to
contain commits to the upstream source, too, that aren't present in the
"upstream" repository (1).
Can we define which the canonical upstream source tree is, please, and
where the canonical Debian packaging branch should be? Then we can work
on pushing the changes back to the right places, rather than having
scattered branches all over the place. I noticed some changes to the
upstream source that don't appear to be in branch 1, for example.
I think it would be easiest to upload, since I think it's good to go and
this will at least result in a definitive packaging state that we can
work from.
In the meantime, I think branch 3 contained everything, so I cloned that
one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.
1) Define and agree maintainers.
2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.
3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there are
any objections to James uploading.
4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.
In the meantime, I'll upload to Ubuntu as I can do that straight away
and we're quite close to release now. I hope that we can get Debian
straightened out soon.
Robie
Robie Basak
2014-09-18 07:59:58 UTC
Permalink
(cutting out everything but the list, since this isn't directly related
to the Debian ITP)
Post by Darrick J. Wong
If you're interested in the bcache-status[1] tool, I'd be happy to work with
you to get (and keep) it in Debian. I /think/ it's in the Fedora package.
(afaict the script is not in any of those git trees...)
Can we get your script upstream (wherever it is that we decide it is) so
that it just ships and distributions don't individually have to carry
it?

For a start, maybe send g2p a pull request?

Robie
Darrick J. Wong
2014-09-18 18:19:57 UTC
Permalink
Post by Robie Basak
(cutting out everything but the list, since this isn't directly related
to the Debian ITP)
Post by Darrick J. Wong
If you're interested in the bcache-status[1] tool, I'd be happy to work with
you to get (and keep) it in Debian. I /think/ it's in the Fedora package.
(afaict the script is not in any of those git trees...)
Can we get your script upstream (wherever it is that we decide it is) so
that it just ships and distributions don't individually have to carry
it?
For a start, maybe send g2p a pull request?
I sent one to Gabriel, we'll see what he says.

--D
Post by Robie Basak
Robie
Rolf Fokkens
2014-09-18 17:18:37 UTC
Permalink
Indeed it's included in the Fedora package!

Rolf
Post by Darrick J. Wong
Hi,
If you're interested in the bcache-status[1] tool, I'd be happy to work with
you to get (and keep) it in Debian. I /think/ it's in the Fedora package.
(afaict the script is not in any of those git trees...)
Post by Robie Basak
I have some progress to report. I also think that this is ready to
upload, though we should sort out a couple of things first.
I've added the bcache list (this is the Debian packaging bug) since
there is a question about some of these commits that seem to be relevant
to upstream but aren't in the upstream branch.
I've done some (functional only) testing of bcache itself with a
colleague, and we haven't seen any major issues.
I think the packaging is good to go, though I've added a removal of one
extraneous file and updated debian/copyright. This is in
github.com/basak/bcache-tools. I haven't submitted any pull requests to
avoid confusion (see below).
A colleague (James Page) is a DD and is prepared to upload, provided
that we all agree on who will maintain the package first. I'm happy to
step up. Who else does?
I found following all the various git trees confusing, and think we
should resolve this soon after upload. There are three git trees I'm
1) http://evilpiepirate.org/git/bcache-tools.git
2) git://github.com/g2p/bcache-tools.git
3) git://github.com/squisher/bcache-tools.git
4) git://github.com/basak/bcache-tools.git
I had thought that #2 was the new upstream, but then I haven't paid attention
in a while either.
--D
[1] https://gist.github.com/djwong/6343451
Post by Robie Basak
Vcs-Git points to 2 (g2p). I also noted that the github branches seem to
contain commits to the upstream source, too, that aren't present in the
"upstream" repository (1).
Can we define which the canonical upstream source tree is, please, and
where the canonical Debian packaging branch should be? Then we can work
on pushing the changes back to the right places, rather than having
scattered branches all over the place. I noticed some changes to the
upstream source that don't appear to be in branch 1, for example.
I think it would be easiest to upload, since I think it's good to go and
this will at least result in a definitive packaging state that we can
work from.
In the meantime, I think branch 3 contained everything, so I cloned that
one to add my two commits. To keep Vcs-Git correct g2p should pull my
commits, or else we can change Vcs-Git.
1) Define and agree maintainers.
2) g2p to pull my commits, or we agree to change Vcs-Git, or we drop
Vcs-Git for now.
3) Upload. Either my colleague (James Page) can do it as he's already
reviewed the packaging itself, or someone else. Let me know if there are
any objections to James uploading.
4) Sort out which trees are canonical upstream and packaging branches,
and push all commits to those places.
In the meantime, I'll upload to Ubuntu as I can do that straight away
and we're quite close to release now. I hope that we can get Debian
straightened out soon.
Robie
--
To unsubscribe from this list: send the line "unsubscribe linux-bcache" in
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...