FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu Development

 
 
LinkBack Thread Tools
 
Old 01-10-2009, 07:03 PM
Harald Sitter
 
Default Improve Ninja's release packaging (once more)

[caution: this mail grew incredibly long :P]
Hola!

I'd like to discuss a new workflow for KDE release packaging. Latest changes
to the infrastructure (namely the use of bzr and the availablility of a
private PPA) allow us to improve the package update process a lot.

I propose the following changes:

Dettaching from the packaging coordinator dude. Ultimately the Ninjas would
get a server where everyone gets access (at least sftp), so they can upload
the content rather than sending it to a single person. Also it would allow
us to run batch QA tools on the package tree and for example detect moved
files and introduce proper replaces. But since we don't have a server offer,
bzr will have to do :P
The main idea is that, unlike I intent before, maximize commit rate to the
branches. In the best case a ninja would do a commit indicating the changes
(debcommit -R) and a reviewer would commit the relase tag (debcommit -r) ...
considering everything is ok. Worst case would be: ninja fixes more stuff
(committed with debcommit -R in one or more commits) and the reviewer needs
to fix something as well (debcommit -R -r). So, I guess we will use bzr
pretty much like a remote server, just that bzr got tagging support and can
revert stuff :P
* batget sets the push target for the batbranch to avoid the use of gypsy to
do an initial push from the batbranch
* batsend doesn't create a bzr bundle (bzr commit in a file) but pushes the
commit to launchpad

Centering around the branch, not the source tree. Until now we focused our
efforts on the source tree (copied debian/ to the tree and only left it
once everything was fine).
That concept however is flawed considering we loose the advantages of bzr
by doing so. Reason enough to change that completely.
* batbuild will be invoked in batbranch/ or the top source directory and
copy batbranch/debian/ to $package/debian/, then continue as usual (in
a way this is like bzr-buildpackage, just more powerful ;-)

Stackbuilds for everyone. Primary target ought to be to update the main
dependency chain (libs - pimlibs - bindings - workspace) and deploying it
to the PPA. At least the upload will be done by $reviwer(s) to ensure
everything is fine and prevent a chain reaction of issues (like someone
changes kdelibs5-dev to kdelibs6-dev and everyone changes the build-depends
even though kdelibs5-dev should have never been renamed). Obviously
before uploading the reviewer should review ;-)
I'll add a script that uses the same mehtod as batbuild to export the debian
directory to the source tree, automagically adds ~ppaTIMEDATE to the
version and then uploads to the PPA. Using the batbranch/debian dir as
center of development this approach also prevents that one accidently pulls
these ~ppa changes in (batbuild would overwrite $package/debian/ with un-
ppa'ed changelog from batbranch/).

Reduce testbuilds. No doubt, testbuilds are an essential part of QA, but
they are also the most time consuming one. To improve this situation the
requirements for a good package will change a bit.
Everyone then must pbuild against the PPA main stack with the D10aptupdate
hook to ensure buildability against the main stack as well as most recent
jaunty packages. Before batsending one should have a complete build/BUILDLOG
file including the output of B10list-missing. Then it is up to $reviewer if
they want to testbuild again them selfs or trust the packager or upload to
the PPA (which should be easy enough using the new script but will lack
the list-missing output, which isn't necessary if a BUILDLOG was batsent
though).

Send more information. The new batreports (a collection of the parsed output
of dpkg-source, lintian src, lintian deb, cmake and list-missing hook) allow
a much more precise review and QA. Executing batbuild -b (no build) will
however eliminate the output of 3 sources and thus dumps information.
* batbuild probably should
a) name REPORTS coming from a batbuild run with build REPORT.build
b) scan the previous build/ dirs for REPORT.builds and copy them
to the current build/ directory to preserve information
I am not so sure about this, but it is probably the best option to
preserve build information and at the same time do a batbuild -b.

Opinions? Further suggestions?

regards,
Harald


--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-10-2009, 07:09 PM
Jonathan
 
Default Improve Ninja's release packaging (once more)

On Saturday 10 January 2009 3:03:17 pm Harald Sitter wrote:
> [caution: this mail grew incredibly long :P]
>[...snip]
> Opinions? Further suggestions?
Sounds great!
>
> regards,
> Harald


--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-10-2009, 09:24 PM
Scott Kitterman
 
Default Improve Ninja's release packaging (once more)

On Sat, 10 Jan 2009 21:03:17 +0100 Harald Sitter <apachelogger@ubuntu.com>
wrote:
>Opinions? Further suggestions?

It seems complicated for the casual ninja.

Can haz wikipage plz?

Scott K

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-12-2009, 04:51 PM
"Harald Sitter"
 
Default Improve Ninja's release packaging (once more)

On Sat, Jan 10, 2009 at 11:24 PM, Scott Kitterman <ubuntu@kitterman.com> wrote:
> On Sat, 10 Jan 2009 21:03:17 +0100 Harald Sitter <apachelogger@ubuntu.com>
> wrote:
>>Opinions? Further suggestions?
>
> It seems complicated for the casual ninja.
>
> Can haz wikipage plz?

https://wiki.kubuntu.org/Kubuntu/Ninjas/ReleasePackaging

back feeding please.

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-13-2009, 02:57 PM
Scott Kitterman
 
Default Improve Ninja's release packaging (once more)

On Monday 12 January 2009 12:51, Harald Sitter wrote:
> On Sat, Jan 10, 2009 at 11:24 PM, Scott Kitterman <ubuntu@kitterman.com>
wrote:
> > On Sat, 10 Jan 2009 21:03:17 +0100 Harald Sitter
> > <apachelogger@ubuntu.com>
> >
> > wrote:
> >>Opinions? Further suggestions?
> >
> > It seems complicated for the casual ninja.
> >
> > Can haz wikipage plz?
>
> https://wiki.kubuntu.org/Kubuntu/Ninjas/ReleasePackaging
>
> back feeding please.

When LaserJock was trying to understand what all the batscripts were doing, I
pointed him at the page and he said something like, "Oh. It's much clearer
now." I think that counts as mission accomplished.

Scott K

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-13-2009, 06:38 PM
"Nathan Handler"
 
Default Improve Ninja's release packaging (once more)

On Sat, Jan 10, 2009 at 2:03 PM, Harald Sitter <apachelogger@ubuntu.com> wrote:
> Opinions? Further suggestions?

The page looks like a great resource. My one suggestion would be to
actually give an example of how to go from start to finish with an
actual package. This package's files should be made available
somewhere so that they do not disappear. By doing this, people will be
able to follow the wiki page, and compare their results to those in
the guide. I personally find guides that I am able to follow much more
beneficial than guides that just outline the steps. Either way, the
wiki page is a great resource, and we should definitely refer people
to it.

Nathan

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-13-2009, 07:01 PM
Richard Birnie
 
Default Improve Ninja's release packaging (once more)

> Date: Mon, 12 Jan 2009 18:51:26 +0100
> From: "Harald Sitter" <apachelogger@ubuntu.com>
> Subject: Re: Improve Ninja's release packaging (once more)
> To: "Kubuntu Developer Discussion" <kubuntu-devel@lists.ubuntu.com>
> Message-ID:
> <1cc7d65c0901120951m7ae9b3b3i346662544c00a3d7@mail .gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Sat, Jan 10, 2009 at 11:24 PM, Scott Kitterman <ubuntu@kitterman.com>
wrote:
> > On Sat, 10 Jan 2009 21:03:17 +0100 Harald Sitter
> > <apachelogger@ubuntu.com>
> >
> > wrote:
> >>Opinions? Further suggestions?
> >
> > It seems complicated for the casual ninja.
> >
> > Can haz wikipage plz?
>
> https://wiki.kubuntu.org/Kubuntu/Ninjas/ReleasePackaging
>
> back feeding please.

Some instructions on setting up and maintaining multiple pbuilders for
different releases would be nice. As would similar info on how to use pbuilder-
hooks and how to edit pbuilderrc accordingly

Maybe it's just me (entirely likely) but this was and is a pretty big barrier
to contribution. Personally I think this is a pretty complicated thing to do.
The time I can spend on Kubuntu is fairly limited at the moment so I'd rather
spend it on something useful instead of spending an entire evening trying to
make the build environment behave properly as I did for the last two KDE
releases. I'm all in favour of automating this process as much as possible but
I'd second Scott's point that this is pretty complicated.

Another thought that crossed my mind is that we are now another step further
removed from anything that is in the packaging documentation for either
(k)ubuntu or debian. From the point of view of anybody new to packaging that
wants to get involved in KDE releases (and I'd include me in that group) it's
pretty hard to relate what the ninjas do to any other form of packaging in
ubuntu. If that isn't considered important the fair enough. I don't claim to
be any expert in the field but I thought I'd throw it out there as an idea.

Anyway, that's my two cents (or tuppence worth as they say round here)
Rich


--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-13-2009, 10:11 PM
Alessandro Ghersi
 
Default Improve Ninja's release packaging (once more)

Nathan Handler ha scritto:
> On Sat, Jan 10, 2009 at 2:03 PM, Harald Sitter <apachelogger@ubuntu.com> wrote:
>
>> Opinions? Further suggestions?
>>
>
> The page looks like a great resource. My one suggestion would be to
> actually give an example of how to go from start to finish with an
> actual package. This package's files should be made available
> somewhere so that they do not disappear. By doing this, people will be
> able to follow the wiki page, and compare their results to those in
> the guide.
> Nathan
>
>

For me it is a good idea to have an example in the wiki page.
Alessandro

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-14-2009, 05:09 PM
Harald Sitter
 
Default Improve Ninja's release packaging (once more)

On Dienstag 13 Januar 2009 16:57:12 Scott Kitterman wrote:
> When LaserJock was trying to understand what all the batscripts were doing,
> I pointed him at the page and he said something like, "Oh. It's much
> clearer now." I think that counts as mission accomplished.

They mostly also have manpages ;-)

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 01-14-2009, 05:19 PM
Harald Sitter
 
Default Improve Ninja's release packaging (once more)

On Dienstag 13 Januar 2009 20:38:43 Nathan Handler wrote:
> On Sat, Jan 10, 2009 at 2:03 PM, Harald Sitter <apachelogger@ubuntu.com>
wrote:
> > Opinions? Further suggestions?
>
> The page looks like a great resource. My one suggestion would be to
> actually give an example of how to go from start to finish with an
> actual package. This package's files should be made available
> somewhere so that they do not disappear. By doing this, people will be
> able to follow the wiki page, and compare their results to those in
> the guide. I personally find guides that I am able to follow much more
> beneficial than guides that just outline the steps. Either way, the
> wiki page is a great resource, and we should definitely refer people
> to it.

That would involve deploying a customized .batrc(_path), which would mean I
need to keep 3 of them up-to-date :P

I am not sure where to store it, since people.ubuntu is still not useable for
mere mortals.. Maybe master Riddell could throw it up there?

Generally I agree though.


--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 

Thread Tools




All times are GMT. The time now is 09:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org