I can leave it as UNRELEASED.
As for my other nemo-extensions, I’ll come back to them once we have nemo 5.4 in the archives. No point in rushing an upload that will quickly require another one.
Il 10/06/2022 21:33, Joshua Peisach ha scritto:
> Hi list,
> I know. The muffin rebase is big and it's a huge work of standardizing
> code from years ago. I was honestly too afraid to contribute upstream
> as I did not want the muffin rebase to mess any of my work or ideas up.
> To make things easier for you, I'll update some of the extra packages
> (nemo-fileroller and other miscellaneous stuff not really impacted by
> the rebase) and mark them as 'experimental' in changelog. This will
> need a lot of QA, and soon I'll get the UCR 22.10 builds working. My
> school year ends on the 22nd.
Thanks for reply, as I saw other times you did "release" commit even
when not well tested and ready, is good to keep "UNRELEASED" until will
be ready and tested
if you don't have enugh time/experience I suggest to don't try start 5.4
package for now I'll start doing it checking better on all 5.4 packages
instead, I started to work cjs for now that also it was rebased on newer
gjs version and I not tested before (I did some test on the components
of muffin rebase and related things instead in these months)
I suggest you to do additional check on packages where I already need
major of work, I think is good a second check of another maintaner to
find possible my mistake or something I missed, for example for now I
start prepared fast (but not tested) xapp and python-xapp that are only
minor version for upload to unstable (when ready and tested) if you want
start check them
another thing I suggest you to continue your work on additional packages
(if you still want), for example nemo-audio-tab was sponsored and
uploaded but rejected by ftp master and need fix and nemo-compare need
small update if I remember good and after probably is ready (another
check can be good)
think is good you update other packages you maintain, from a fast look,
for example cppimport and pyupgrade have new upstream version
about cinnamon related package as wrote in past you have many ITP open
from long time, I think is good close the ones you will not complete and
the ones is good to not packaging like pix for example, mint did many
fork of software that maintain too low and is not very good (recently
instead they did a good thing removing one fork about bluetooth and
contributing to blueman instead), there is also cinnamon-dev-tools that
have broken link of source to one your repository
> As for upstream imports, I just do whatever gbp import-orig does. Most
> of the time (see https://salsa.debian.org/math-team/sc-im or my
> cppimport package) it will be one commit for all of upstream and not
> contain commit history upstream. That fine?
like other team and maintainers me, maxy and marga we used to add
upstream repository and merge upstream tag including the upstream git
history instead only import the source tar of the new version but as
wrote with debian/ history mixed is not good so I don't use it anymore
> I do not know much about DEP-14. I'd say keep the git branches as is
> for now.
> D/watch simplification should be good.
> My only other comment is nemo-search-helpers might want to be in a
> separate package - fedora has done this and I think it's a good idea
yes, there is also calendar server in cinnamon that should be splitted
like what did in fedora because low used (FWIK) and require many
additional deps but I think these are secondary things and is good do
better packages as possible for 5.4 and after probably will do these splits
> *From:* Fabio Fantoni
> *Sent:* Friday, June 10, 2022 6:12 AM
> *To:* email@example.com; Christoph Martin; ItzSwirlz
> Joshua Peisach
> *Subject:* New cinnamon version and possible improve to salsa gits
> Hi, today new upstream version was tagged.
> xapp and python-xapp are minor versions that can be uploaded to unstable
> when ready (I started prepare them but not tested for now).
> about cinnamon even if tagged 5.4.0 unfortunately like the other times
> several PR merge have been made just before the tag not to mention that
> this time a big muffin rebase has just been merged and other major
> changes on other components that unfortunately had remained until
> yesterday only in PR with too few testing so cinnamon 5.4 is to be
> considered in a "beta" (if not "alpha") state currently, I will start
> preparing the packages for experimental but they will need be checked
> well because several require significant changes, I helped a little to
> improve packaging upstream on some components (where in part can get
> from it) but may not be complete or good enough for the debian standards
> and latest version (upstream need support older versions of debian and
> about import of new upstream version as was decided by marga and maxy
> many years ago there was fetch of upstream git and merging also it for
> history but as saw in latest years is better don't keep upstream history
> which can make the debian/ history difficult to use soI would have
> thought of not using that thing anymore as norbert and joshua did of
> they upstream version imports
> about DEP14 (https://dep-team.pages.debian.net/deps/dep14/) even if
> still a "candidate" state many project use it, what do you think of
> change master branch to debian/latest (or debian/unstable if think is
> better) and experimental to debian/experimental? or you think is better
> keep master on existing gits for now?
> about d/watch I think is good simplify all like this:
> is ok or you think there is other needed improvements?
> you have suggestions on other possible changes/improvements?
> thanks for any reply and sorry for my bad english