On Thu, 4 Apr 2013, Carlos R. Mafra wrote:
But that is not new behavior. I use ksnapshot and to have that app
I need to install the 'graphics' package and then I also have okular
etc (or something like that).
Maybe that's part of the reason I don't like big Desktop Environments like
KDE or Gnome and use Window Maker instead... But apart from that all your
examples where more stuff is packaged together were things that are
related by something (like using a common framework or library) and
updating that common part needs releasing all parts too. This kind of
relation warrants a common package but no such relation exists for
dockapps.
They're just put together in a repo trying to lower administrative
overhead but this does not make them related.
But this is precisely the point! They become related once you do that,
you can not have both at the same time. Either they have separate
repos with separate maintainers deciding when to release new versions,
or they are treated together like a whole.
I don't see it like that. The repo is a place to put code in and manage it
but the parts don't become related just by putting them in the same repo.
Also parts can be versioned and released separately even if they are in
the same repo. This requires a bit more thinking but not much more other
work.
I'm sorry, but I cannot imagine what "releasing them separately" would
even mean.
I meant that each dockapp in the common repo would retain it's own version
number which would only be increased if there were changes to this dockapp
and not just using a common version number for all of them. This would
allow distros to continue packaging them separately (or people only using
some of the apps to update if there were changes they care about).
There were patches to wmbiff recently. What should I do? Write a patch
changing the #define version x.y for wmbiff only and announcing that
I'm releasing a new wmbiff?
Or just tag the repository with a tag wmbiff-x.y when finished merging all
the patches and changed the #define in wmbiff to a new version. That's
what we can call a release: some marked point in the repo which can be
identified with a version number.
What about the others? Take a look at the history of the repo and
give me suggestions about which packages deserve a new version to
be released and which version numbers should they have? Now take
that list and let's write patches for their individual version numbers
and let's generate tarballs for them and upload them somewhere.
I don't think this is going to work, seriously. I cannot imagine
me doing that.
If something is unchanged and was just put in the repo it does not need a
new version and can be tagged with their current version. If something has
changed and there are no more pending patches they can be released with a
new version number. These are simple rules I think but I don't use your
dockapps repo so I cannot tell for dockapps in it but those who use it and
submitted patches before may be able to tell and contribute patches to
increase their version numbers.
But let's face reality. There's no one maintaining these dockapps
in the usual way (say like Alexey himself is maintaining wmvolman).
So there won't be anyone deciding when to release a new version of
wmbiff, or having plans for doing that.
Again, if there were no changes to a dockapp it needs no new release. When
someone submits patches to one dockapp you can decide to tag a new release
after merging their changes. It's always the repo maintainer who is in the
position to decide when to make a release otherwise there will only be
snapshots.
We are just trying to have them compiling and working, and when
something breaks we hopefully fix the ones we care most. The
purpose of the dockapps.git is to have a place to send these patches.
That's nice but not too friendly to distros. They need releases that can
be packaged and updated when there's a new release.
This does not work well, I think.
Let's say today I tag the dockapps.git repo as wmbiff-2.0, how would
that help someone?
I think it would help Alexey or Kix to know that they should update the
wmbiff package in their distros and (reproducibly) can get a revision from
the repository that contains exactly version 2.0 of wmbiff. If the next
day some patches to wmvolman are merged and tagged with wmvolman-1.15 they
know that they only have to update the wmvolman package and can again get
the corresponding revision from the repo. So even if the tarball from the
repo contains all the dockapps they are still versioned separately and one
can use them both together or separately as they wish. The administrative
overhead may be a bit higher but not much: instead of just using tags like
dockapps-3.0, dockapps-3.1, etc. you would use tags for independent apps
but the work involved is the same (merge patches, tag repo).
But as I said I don't use the dockapps repo, so it's only a proposal and
you are free to decide how you do your work and packagers can also say if
they like this proposal or not. I just though this might be an acceptable
compromise for both parties.
Regards,
BALATON Zoltan
--
To unsubscribe, send mail to [email protected].
