RFC: Conditions of early access to unreleased

[Scott Kitterman]

On Tuesday, June 05, 2012 12:56:36 AM Albert Astals Cid wrote:
> El Dilluns, 4 de juny de 2012, a les 00:11:32, Scott Kitterman va escriure:
> > Sorry for breaking threading.  I wasn't subscribed when this was sent, so
> > I
> > had to copy/paste from the web archive.
> > 
> > > On Monday, June 04, 2012 00:52:47 Albert Astals Cid wrote:
> > > > My proposal:
> > > > 
> > > > ******************************
> > > > 
> > > > The KDE Release Team recognizes the importance of making a source
> > > > release
> > > > together with binary packages of various distributions since this
> > > > greatly
> > > > increases the impact of a given release.
> > > > 
> > > > To this effect we give the privilege of early access to unreleased
> > > > tarballs
> > > > to select packagers of distributions
> > > 
> > > I like to view it as we have specific points-of-contact within the
> > > various
> > > distributions who have agreed to interact directly with us, the KDE
> > > developers and community in order to deliver the best possible KDE for
> > > their
> > > distribution. As such they have early access to unreleased tarballs to
> > > give
> > > early feedback of issues that would impair their ability to package the
> > > software so that when Release Day rolls around, there are already KDE
> > > packages available, yaaay!
> > > 
> > > Really though, that's where I try to stop thinking of it being a
> > > privilege
> > > for the packagers. You've certainly seen how hard it is to tag together
> > > dozens and dozens of disparate modules into a working release, I can't
> > > imagine it is much easier for the packagers to stitch it together on
> > > their
> > > end.
> > > 
> > > I agree candidate tarball releases shouldn't be deliberately announced
> > > to
> > > users or pushed directly to distribution channels, but I would not see
> > > major issue if enterprising users happened to end up with binary
> > > packages. After all, they can already run "the upcoming release" using
> > > build-tool or kdesrc- build so they really have no more advantage or
> > > claim to running it than many other users.
> > > 
> > > If it is required for a distribution's packaging build system to push
> > > packages out, I would still rather have that than for them to hold up
> > > making packages until *we* are ready.
> > > 
> > > >  * Report any compilation error you might find as soon as possible to
> > > >  the
> > > > 
> > > > release team mailing list
> > > > 
> > > >  * Report any missing package or unpackaged dependency as soon as
> > > >  possible
> > > > 
> > > > to the release team mailing list
> > 
> > I agree packagers should do this, but it's been done on the packagers
> > list.
> > I think that should be sufficient.  It shouldn't need to go to two lists.
> 
> The problem is kde-packagers is a *private* list, so posting there doesn't
> really help much, in the other had all/most module coordinators should be
> subscribed to the release team list and they can act on mails only if they
> see them.
> 
> That's why I think mails should go to release-team.
> 
> Actually if you browse the archives of release-team, it was suggested that
> kde-packager was disbanded as there is lots of overlap between both lists,
> and actually packagers are part of the release team by doing binary
> releases for their distros.
> 
> We only kept kde-packagers as a private list where we could propagate
> eventual security advisories, but otherwise i think it was agreed
> release-team is quite a good place for us to discuss release things, like
> needed patches, etc.
> > > I agree with this, and AFAIK the packagers have been doing well with
> > > this.
> > > But it's good to have it in writing.
> > > 
> > > > Reiterated failure to comply with this guidelines might end up in
> > > > revocation of your special access to unreleased tarballs.
> > > 
> > > I would agree with this, with the proviso that we're talking about a
> > > guideline more along the lines of "do your best to avoid publicizing the
> > > new KDE packages" as opposed to "don't let any packages get out at all".
> > > I'm assuming the packagers generally want this as well instead of having
> > > to
> > > worry about other distros "breaking the street date".
> > 
> > I think putting the focus on don't publicize is the correct one.  Keeping
> > things private prior to the final release is important for a number of
> > reasons:
> > 
> > 1.  Until release time, the tarballs may change and users shouldn't get
> > the
> > incorrect one.
> > 2.  Having everyone publicize availability of source and packages together
> > maximizes the impact of the release.
> > 3.  A competition among distributors to be 'first' would invariably lead
> > to
> > more freeze breaks and undermine the process.
> > 4.  Having more time to get ready results in higher quality packages. 
> > This
> > is good for both KDE and various distributions.
> > 
> > Note that I don't list 'KDE developer doesn't get bugs before the
> > release',
> > because they will.  When distributions are testing their packages, they
> > will find bugs and report them.  This should be treated as a good thing.
> > 
> > I'm not aware of any distributions doing anything with leaking early
> > packages that affects any of the above points, so I think we are in pretty
> > good shape as it is.
> > 
> > > > So it turns I'm undecided and don't know if we should un-tighthen the
> > > > first
> > > > point to something like
> > > > 
> > > >  * Do not make the packages available to your users (in stable or
> > > > 
> > > > automatically suggested updates to stable versions) before the
> > > > official
> > > > tarballs are announced
> > > 
> > > I like this much better.
> > 
> > If this were the rule, we (in Kubuntu) could have official packages for
> > our
> > development release out significantly closer to release than we do as we
> > currently have to recompile everything after the packages are public to
> > get
> > into the official archive.
> 
> You mean you upload packages to stable users or automatically suggested
> updates to stable users before we release?
> 
> From my previous experience as a Ubuntu user I don't see this being true,
> but you surely know more than me :-)

No.  

The only place we would ever push any update before it had all been tested 
would be into the development release and the development release is exactly 
that (this is not a release that's supposed to be run by end users).  Being 
able to start that process a bit earlier there and build KDE SC packages that 
other KDE SC packages need to build (which must be done in a public 
repository) would help us get done with official packages closer to the release 
time.

Before a point release gets to a repository that will cause it to be 
automatically suggested to normal users it will have been through at least two 
rounds of building and testing in unofficial and official test repositories to 
make sure it works and to try and identify any regressions.

Scott K