Drop Alphas and Betas (was Re: Releasing Alphas and Betas without "freezing")
(I changed the subject to better represent this branch of the conversation) This discussion suggests that we don't need to release special alpha and beta ISOs, but we do need: 1. A cadence of testing 2. A trial run (or 2) of spinning ISOs 3. Development targets Therefore, I propose we: 1. Stop with the alphas and betas and win back all of the development effort 2. *Increase* the cadence of ISO testing to whatever we want or whatever the community team can manage 3. Spin a trial ISO near what is not beta time (maybe around current kernel freeze?) 4. Spin ISOs for release candidates 5. Maintain the current Alpha and Beta designations as development targets only (i.e. don't spin a special image for them). Cheers, Rick On Sun, Jun 17, 2012 at 11:25 PM, Robert Ancell wrote: > On 16/06/12 02:12, Rick Spencer wrote: >> In short, freezing the archive before an alpha or beta should not >> actually be contributing to either ensuring the installability of >> Ubuntu images or ensuring the quality of these images. This implies, >> therefore, that all the work around freezing, and all the productivity >> lost during a freeze, actually subtracts from the quality of Ubuntu by >> reducing our overall velocity for both features and bug fixes, since >> every day the image is good quality, and Alpha or Beta should be just >> that day's image tagged appropriately. > In particular I find the alpha freeze kills our velocity and I wonder > how more useful than a daily build the alpha release is (given it's so > early in the cycle anyway). I'd support dropping the alpha and pointing > at the dailies. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Does anyone knows about utmp and wtmp handling?
On Mon, 11 Jun 2012 19:37:26 +0200 Sebastien Bacher wrote: > Hey, > > That's a call for help,feedback,comment on lightdm bug #870297 [1]: > "Lightdm logins not being logged in wtmp" > > From the comments and feedback that seems like an issue that should > be fixed in the lts, there is a merge request proposed to fix it on: > https://code.launchpad.net/~lotheac/lightdm/utmpx/+merge/107739 > > The lightdm project has been trying to avoid adding code "just > because it's this way for 25 years" but trying to understand if > things still make sense on a modern linux distribution rather and > that's where we need your help. > > Does anyone knows if: > - utmp and wtmp support is still important? > - if those are "speced" or described in a reference document > somewhere? > - if the login manager is the right place to record those entries? > > Review of the previous listed merge request from people who know > about the topic would be welcome as well > > Thanks, > Sebastien Bacher > A bit late, but anyway. Yes, I think it should be there. Unfortunately. The most important issue, I think, is to find out/code/propose a replacement for utmp. utmp is old, and is one of the old *IX utilities that did not age well. When *IX moved from being a pure/mostly command line system, there was nothing to replace utmp to find out who is logged in -- or, better saying, nothing that really won the battle. We now need a similar thing that will work on graphical environments. We need to be able to know who is logged in, if a movie is being played, etc. utmp does not cut it, but there is nothing I know of (a bit dated as well, last time I looked for it was a few years ago) that cut the mustard. The issue we have is less and less programs bother about utmp; some that do bother to write a login record in utmp do not bother to write a "logoff" (usually not really a logoff, but an exit from the application). FWIW, utmp is in Posix. Cheers, ..C.. signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Monday, June 18, 2012 06:59:17 AM Martin Pitt wrote: > Scott Kitterman [2012-06-15 10:46 -0400]: > > In Debian terms I'm seeing release-proposed as like unstable and release > > as > > testing. Is there a mechanism for direct uploads to testing (e.g. t-p-u)? > > I don't think we want that. Our system will move it over as soon as > it's built, verified to not cause uninstallability, and pass the > automatic tests, but it will not wait any extra time (unlike Debian's > testing migration). > > When preparing a milestone release, it is rather more important to > ensure to not let in a package that only built on half of the > architectures and causes uninstallability. This thought was in the context of dealing with uploads that were too invasive to hit a milestone, but we needed a smaller fix to get into the milestone? It seems wasteful to remove from -proposed and reupload, but I guess that would work. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
Sebastien Bacher [2012-06-15 17:26 +0200]: > Can we just drop the image rolling part of milestones? We still > probably want fixed checkpoints in the cycle to review the features, > etc but they don't especially need to be linked with a special > image... Our automated tests are still wy to incomplete for this step. In manual testing we have found quite a number of real deal-breaker bugs which the automatic tests didn't pick up. We also need to test the current images on a wider range of real iron; which is something our automated QA could do one day, but doesn't right now. So regular manual testing rounds are still required, and the points when we do them might just as well be called "milestones". Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
Scott Kitterman [2012-06-15 10:46 -0400]: > In Debian terms I'm seeing release-proposed as like unstable and release as > testing. Is there a mechanism for direct uploads to testing (e.g. t-p-u)? I don't think we want that. Our system will move it over as soon as it's built, verified to not cause uninstallability, and pass the automatic tests, but it will not wait any extra time (unlike Debian's testing migration). When preparing a milestone release, it is rather more important to ensure to not let in a package that only built on half of the architectures and causes uninstallability. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On Sat, Jun 16, 2012 at 2:12 AM, Rick Spencer wrote: > Hello all, > > At UDS I had some "hallway discussions" about why we freeze for Alphas > and Betas, and the fact that I think it is time to drop this practice > and rather focus on making Ubuntu good quality each day. Sadly, there > was no session on this, thus this email to this list for discussion. +1 in general. One thing that occurs to me, is that I don't know what the Alpha and Betas are *for* for us I mean: in a traditional software product alpha releases would be used to guage customer reaction to new features and changes, betas are used to assess real-world defect rates (and once they drop low enough, general release can happen). We have landed substantial changes post-alpha-milestone in the past, and we probably will continue to do so (e.g. Gnome releases, Unity etc): so I'm not sure, *other* than defect rates, what Alpha does for us. I'm a huge fan of keeping trunk stable and release-quality always, which makes the beta process still useful, but one that doesn't need fixed beta releases, just get folk tracking trunk and reporting back. -Rob -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Releasing Alphas and Betas without "freezing"
On 16/06/12 02:12, Rick Spencer wrote: > In short, freezing the archive before an alpha or beta should not > actually be contributing to either ensuring the installability of > Ubuntu images or ensuring the quality of these images. This implies, > therefore, that all the work around freezing, and all the productivity > lost during a freeze, actually subtracts from the quality of Ubuntu by > reducing our overall velocity for both features and bug fixes, since > every day the image is good quality, and Alpha or Beta should be just > that day's image tagged appropriately. In particular I find the alpha freeze kills our velocity and I wonder how more useful than a daily build the alpha release is (given it's so early in the cycle anyway). I'd support dropping the alpha and pointing at the dailies. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
