Bug#835658: RFS: backbone/1.3.3+ds-1
Hi Jonas!
>Do you intend to help maintain the package collaboratively, or take over
>maintenance?
I see a team upload, so I guess the former of course
>If the former, then you should coordinate your work with current
>maintainers (fine that you seek help and guidance from others too, but
>don't go ahead with only input from external parties).
this is something that a good sponsor has to check, and the reason for
me putting *you* in cc :)
I hope the workflow was good enough for you, we didn't upload anything
and we are here to reach a common view, that might be beneficial
from people needing the new release
(I personally sponsored ~10 packages for the new ipython, and this one
seems needing an update too)
>If the latter, then be cautious that you either have consent from
>current maintainers to do so, or ensure that you are following the
>procedures in Debian for takeover (search list archives for "hijacking"
>for more info).
never been the case here, but nice to put it clear, hijacking
is *never* something good, except for MIA maintainers.
Since you put the package under team maintenance, I guess a Team
Upload is something we can handle, right?
(of course, I wanted you to be eplicitly aware of this RFS, in my cc
and the main goal is to agree on something all together)
>Bugs requesting new upstream releases are wishlist bugs, and they are
>targeted the maintainer of the package.
>
>Wishlist bugs being old is not a good reason to bypass the maintainer.
not this case, of course :)
He did the work, but "bypassing" the maintainer needs somebody to upload it :)
in case you want to upload by yourself, you might find some work already done,
and cherry-pick it ;)
>Each team collaborate differntly - don't assume it is ok to change a
>package without coordinating with current maintainers (i.e. those listed
>as "Uploaders" for team-maintained packages).
not sure if you mean the archive or the packaging repo...
but yeah, probably I would have done a git push on an external branch/repo
and pushed only after the current upload.
You are right, every team has a different workflow, and remembering all of them
and all of the different maintainers is something difficult...
But with git it is trivial to revert/cherry-pick/branch/delete stuff :)
>> That was the first time I met a cdbs package... isn't it deprecated?
>
>No. Never was.
>
>Some people disliking CDBS wants everyone to believe that's the case.
I personally don't like CDBS, but I never had a war against it. I don't like
because probably I had a first approach without it, but I have NMUed packages
with it, and as I said, I preferred to be explicit about that point.
CDBS is used, probably not the first one by popcon, but it has reasons
to be there, and a Team Upload should probably respect that.
(BTW, it seems true that for a package that needs a bunch of files copied
over two directories, a ~100 lines rules file seems a little bit complicated
to read, do we really need all of this file?
(I'm interested in this part, I might find that CDBS has some nice features
and make me switch or partially switch to it)
>Please consult current maintainers of a package before making large
>changes, like restructuring to a different core packaging helper tool.
this is true, but we cal always revert if it isn't ok for you I hope
>Please consult current maintainers of a package before making large
>changes, like "starting from scratch".
true,
but at the end, would you consider sponsoring an updated package or not?
ok the change back to cdbs, ok the testing, but what are the points you
would like to see addressed (if eventually you want somebody else sponsoring
this one)
thanks for the quick reply, I know you are busy, and this is appreciated
(actually I remember me taking over of a package or two, some years ago,
they were RC-buggy and you gave them to me so nicely, I hope we will "fix" the
current situation in the same way, to help reverse-dependencies move
forward)
thanks,
G.
Reply to: