Why are 4.8.80 packages already out in the wild?

[Scott Kitterman]

On Monday, June 04, 2012 01:20:33 AM Albert Astals Cid wrote:
> El Dilluns, 4 de juny de 2012, a les 00:51:30, Kevin Kofler va escriure:
> > On Monday 04 June 2012, Albert Astals Cid wrote:
> > > I know building packages take time, that's why we give you early access,
> > > you should build the packages but you should not publish them before
> > > they are official.
> > > 
> > > If your packaging system does not support that maybe you need to refine
> > > your processes.
> > 
> > The most restrictive thing our build system (Koji) supports is to build
> > the
> > stuff in a side tag which does not hit the daily Rawhide. The packages
> > would still be in Koji and the corresponding specfiles in our public git
> > repositories ("dist-git"), but the packages would NOT show up on FTP/HTTP
> > (Rawhide and its mirrors). We cannot completely embargo Fedora packages.
> > (For embargoed security advisories, the Fedora builds are only started
> > once the embargo is lifted. But IMHO doing that for KDE SC packages would
> > not be practical because of the time it takes to prepare them. There is
> > also no strong need for an embargo, in particular, there are no security
> > reasons for it.)
> > 
> > > Sorry, but no, this is a release team matters, since it's a privilege
> > > we, the releas team, are giving you, the packagers.
> > > 
> > > We need to decide under which terms those privileges happen. Letting the
> > > packagers decide decide which rights they get, would be be like
> > > politicians
> > > deciding the salary policitians get, a mess.
> > 
> > Sorry, but you have to listen to the needs of the packagers, not just give
> > out a diktat. We are not out to arbitrarily grab power, we have genuine
> > needs that have to be addressed. Arbitrarily deciding what we should do
> > without listening to what we NEED to do is not going to work.
> 
> Yes, we have to listen your needs, that's exactly why i invited you to join
> the release team and discuss together with us and find a place where our
> needs meet yours.

OK.  I've subscribed to the release team list now based on your request.

For Kubuntu, our restrictions are similar to Fedora's.  The Ubuntu 
infrastructure does have the ability to do private builds, but for the official 
archive, that's only available for security uploads.  We are, however, 
fortunate that Canonical has made available to the Kubuntu team a private 
package archive where we can build packages using our standard build systems 
for testing.

Since we've had access to this private archive, we've been able to pretty 
strictly follow the no public release ahead of KDE's publishing the tarballs 
(once they are on the KDE FTP server, I think we are free to use them 
normally).  Before that, we did exactly like Fedora did in this case.  Once we 
got close to the release milestone we would upload some of the key packages 
that others depend on so that they were built and the balance of the packages 
could be publicly built ASAP after the release was announced.

There is a downside to our current approach for users.  When there is a KDE 
release, it is not immediately available for our users in the standard Kubuntu 
repositories.  They have to add an additional unofficial archive to download and 
install from.  We only start building the official packages on our production 
infrastructure after the public tarballs are available.

Bottom line is that early access is very, very useful to us and makes it 
possible to have packages ready at or near KDE's release date.  This is 
particularly true when we are packaging a major new release for the first time 
(as we're doing with 4.8.80 right now).

As someone who's involvement with KDE is primarily through packaging, I feel 
like I am part of the KDE community.  When you tell me I am being extended a 
'privilege' to get access to KDE tarballs to do my work, then I don't 
particularly.  If you want to work together, I think that is great, but I find 
your language divisive.  I think there is a real communication problem right 
now and I'm glad you are taking steps to try and improve it.

Scott K