Collaboration in Kubuntu
Martin Böhm
martin.bohm at kubuntu.org
Tue Jun 19 14:52:20 BST 2007
Hello list,
If we're planning to have bzr repositories for the most important KDE
packages, it might be a good idea to solve the notifications that way.
Allow me to clarify: In bzr/Launchpad, there is the "Subscribe"
feature which sends an email to every subscriber to it, once there's a
new commit in the branch. If the core-dev uploaders were subscribed to
the relevant bzr branch of their package ,they would get notifications
if another core-dev decided to newly upload this particular source
package.
Let's say there's a new version of the KFoo application in KDE. By
commiting the newly released source code into the bzr branch, the
core-dev would tell the others that he/she is going to package KFoo
and upload it (to the archive).
Advantages:
* in the end we have an up-to-date bzr branch with the KDE package,
which other members can commit to
* relevant core-devs would now know where to check; we avoid
duplicate work (which actually started this discussion)
* the uploader doesn't have to spend time writing an extra email to
the ML, all the subscribed people are alerted once he commits the code
to the bzr branch
Disadvantages:
* upstream maintainers may disagree about keeping the "pre-release"
source code in a bzr branch, even for the sake of packaging it and
uploading it.
* The amount of source code changes (and the size of "bzr up"s) would
grow very fast if we're going to keep a single branch of an app (and
the subscribed people get notifications only for the branch they're
subscribed to)
* the whole "let's keep the current code of the important apps in
bzr" concept is not yet acknowledged by the majority of the Kubuntu
Council and core-devs, people might disagree with the solution
suggested by Hobbsee. My proposal builds upon bzr, so managing the
package source code in a different way would undermine it.
Only my 2 cents. Of course, my suggestion might be flawed even more,
considering I don't have much experience with uploading/maintaining
Debian packages in Debian or Ubuntu.
Martin "mhb" Böhm
2007/6/19, Sarah Hobbs <hobbsee at kubuntu.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Sarah Hobbs wrote:
> > Currently, I'm putting the main KDE packages into bzr.
> >
> > Please see https://code.launchpad.net/~kubuntu-members and use this to
> > edit all KDE packages now.
> >
> > It only contains the debian/ dir for each - hopefully someone will come
> > in and write the "get-orig-source" stuff.
> >
> > This should make it easier for anyone in kubuntu-members to fix
> > (sometimes little) bugs, and not have to get the source package uploaded
> > every time.
> >
> > This doesn't solve the issue for who is going to do package upgrades,
> > and such - but it's a start.
>
> Notes for bzr are at:
> https://wiki.ubuntu.com/Bzr
> https://wiki.ubuntu.com/BzrMaintainerHowto
>
> Apologies for not adding them in the first time.
> >
> > Hobbsee
> >
> > Sarah Hobbs wrote:
> >> Zhengpeng Hou wrote:
> >>> Why don't we maintain all packages relate to KDE using bzr or svn, you
> >>> know Debian guys has worked in this way well.
> >>> Zhengpeng Hou
> >
> >> So far we havent due to lack of interest, and then my lack of knowledge
> >> on how bzr works. We have only had a few contributors previously.
> >
> >> Clarification:
> >> a) If it's allowed to be committed now, upload it
> >
> >> means "if you're allowed to upload it, because you have rights, and the
> >> software authors havent asked you to wait until the official release
> >> day, then upload it to ubuntu"
> >
> >> Hobbsee
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGd89+7/o1b30rzoURAtDUAJwIoYv8JHKKpJLZE/qbc3G7yr8BfgCeO7j7
> DejjNJAN8uv/BFzAnjtT2tk=
> =oWeR
> -----END PGP SIGNATURE-----
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>
More information about the kubuntu-devel
mailing list