RFC: Conditions of early access to unreleased

[Albert Astals Cid]

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 :-)

Cheers,
  Albert

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