Why are 4.8.80 packages already out in the wild?

[Albert Astals Cid]

El Diumenge, 3 de juny de 2012, a les 23:54:30, Scott Kitterman va escriure:
> 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.

Sorry if my language felt divisive, it did not meant to be, let's not call it 
privilege, let's call it "thing", you have a "thing" other people don't, and 
yes it's so you can do your contribution, that's why we have it, because we 
are glad you are doing this contributiong.

But i still think it makes sense to define what you have to do to get that 
"thing" you do and others don't otherwise it feels a bit arbitrary to grant or 
not people access to the tarballs in advance.

Cheers,
  Albert

> 
> Scott K
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team