Hi, Sławomir Wójcik <vald...@gmail.com> writes:
> Thanks for the quick reply, > You're welcome :-) I'm happy I was able to--sometimes it may take a while to reply. > On 21.05.2020 01:30, Nicholas D Steeves wrote: >> Sławomir Wójcik <vald...@gmail.com> writes: [snip] >> The issue isn't the "repo" so much as continuity with the existing >> source package. Two people's occasional contributions over three years >> are valuable, and erasing them from Debian history would be unjust. > I have imported from dsc by gbp-import-dsc in a new fresh repo, so I > should be able to merge my changes(basically replacing all debian/* files) More or less, but it's a bit more involved than this, because a large part of the work of maintaining a package is documenting that work. At a minimum, this means one must document changes from the previous version in debian/changelog. If you're maintaining the package in git (highly recommended, and also generally expected for team packages), then "good git hygiene" means each step is contained within a single commit. For example, updating a new upstream version should be one commit. Adopting the package, or adopting it into the team, should be another. Adding yourself to Uploaders should be another, etc. As an example of when it's ok to combine micro operations, I think it's ok to combine changing debhelper to debhelper-compat and deleting debian/compat in a "Switch to debhelper-compat $version" step. Each of these actions must be documented in debian/changelog. Your changelog entry (everything from the "package-name (version-debian_revision)…" line at the top, to the " -- Your Name <email> `date -R`" line should be appended to the top of the existing changelog. Generally I will use 'dch -v$upstream_version-1' for this. " * Adopt package. (Closes: #ITA-bug-number)" should be the first line of the entry. Then "New upstream version." or "New upstream release.", as you prefer, and additionally closing a bug if there's a bug requesting a new version. Then other items. Finally, you're welcome to update the changelog all at once at the end, as a separate commit. Some people prefer to stage individual changelog lines with the commit associated with the work. You don't have to follow that practise if you don't want to, but if you do then "magit" can be used to do all your work at once, then stage and commit changes into discrete commits. All of this information should already be documented at: https://www.debian.org/doc/manuals/maint-guide https://www.debian.org/doc/manuals/debmake-doc Please study those guides. It's also recommended to look at other packages from our team for hints, and to get a sense of what the existing conventions are. Fair warning: I was taught that " * Bump foo" was an unacceptable practise. If someone has a link in-hand to one of the conversations about " * Bump foo" please share it! >>> -if we want to adhere to EmacsenTeam Addons packaging policy >>> (https://wiki.debian.org/EmacsenTeam) and I think we should for better >>> collaboration and consistency then the package name should be changed to >>> elpa-scala-mode and existing https://packages.debian.org/sid/scala-mode-el >>> should be marked as transitional dummy package installing new one, right? >>> >> The binary package name should be elpa-scala-mode, but the source >> package should remain scala-mode-el. > Actually upstream project name is > emacs-scala-mode(https://github.com/hvesalai/emacs-scala-mode > <https://github.com/hvesalai/emacs-scala-mode>) rather than > scala-mode-el, but I guess binary package name is more important for > debian users and if source package name will stay the same it won't be > such a big deal, right? Exactly :-) When I was a new member I also felt a strong inclination to rename source packages to sate my desire for correctness, but after a while I came to agree with more experienced developers; they expressed to me the perspective that it was a waste of time, and after seeing my packages wait for months in the "Debian NEW queue", waiting for an ftpmaster to review the package, I came to understand that source package renames burden the overworked/understaffed ftpmaster team with extra work, for little gain. For more info about why the binary package name is important, read the dh-elpa and dh-make-elpa documentation, and feel free to ask for clarification if anything there seems unclear. >>> -upstream version in existing package and most of debian files are very old >>> or outdated >>> >> Yup, that's part of the work of adopting a package that needs work ;-) >> >>> Please, let me know what should be done. As I pointed out here: >>> https://lists.debian.org/debian-emacsen/2020/05/msg00039.html >>> it would be the best if someone from Debian Emacsen Packaging Team will work >>> with me on this and other packages but maybe someone else will be >>> interested to >>> give his/her opinion. >>> >> If you proceed with this ITP I'd like to work with you and/or comaintain >> it, because it's a blocker for my smartparens ITP. > That would be great. Wonderful! I look forward our collaboration :-) > On 21.05.2020 01:49, Nicholas D Steeves wrote: >> P.S. Are you using the following as the new upstream source?: >> >> https://github.com/hvesalai/emacs-scala-mode >> >> I've received confirmation this is the one smartparens requires. > > Yes Brilliant, thank you for confirming. Regards, Nicholas
signature.asc
Description: PGP signature
