Re: [csw-maintainers] Integrating unstable→testing ― handover
Maciej (Matchek) Bliziński mac...@opencsw.org writes: 2013/9/7 Peter FELECAN pfele...@opencsw.org IMHO, we need to find somebody to implement the automatic transition from unstable to testing. Remember, we decided that the transition is made when there is no blocking issue reported in our BTS after 2 weeks from release time. Right. We might start moving in this direction. The database already stores the required information: when was each package inserted into which catalog. There is no REST API for it though. I'll see if I can add it. I'm also thinking that when we transition to the 2 week automatic package promotion, we'll come across a new failure scenario. For example, 2 co-dependent packages are uploaded, let's call them CSWfoo and CSWbar. A bug is discovered in CSWbar. A fixed version of CSWbar is uploaded a week later. But the timer on CSWfoo hasn't been reset, so CSWfoo gets promoted without the accompanying CSWbar. This causes CSWbar to be broken in the testing catalog. Of course, the promotion of a package can be done only if all its dependencies can be or are already promoted. This additional complexity is the probable cause of it not being yet implemented. So far, I've tried to make the package promotion as simple as possible. Ideally, it was an equivalent of taking a snapshot of unstable and making it the testing catalog. Oversimplification is its name. -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing ― handover
Maciej (Matchek) Bliziński mac...@opencsw.org writes: 2013/9/7 Laurent Blume laur...@opencsw.org On 2013-09-07 8:29 PM, Maciej (Matchek) Bliziński wrote: So far, I've tried to make the package promotion as simple as possible. Ideally, it was an equivalent of taking a snapshot of unstable and making it the testing catalog. Since that's basically what I'm doing in production, I'm all for it. In practice it wasn't that simple, there usually were packages I wanted to skip. Another thing is deletions: we need to propagate them as well, but the database currently doesn't hold the information about when a package was removed from a catalog. This might be an inconvenient feature to implement. We currently have a table which connects a svr4 file, catalog release, OS release and architecture. mysql describe srv4_file_in_catalog; +-+-+--+-+-++ | Field | Type| Null | Key | Default | Extra | +-+-+--+-+-++ | id | int(11) | NO | PRI | NULL| auto_increment | | arch_id | int(11) | NO | MUL | NULL|| | osrel_id| int(11) | NO | MUL | NULL|| | catrel_id | int(11) | NO | MUL | NULL|| | srv4file_id | int(11) | NO | MUL | NULL|| | created_on | datetime| NO | | NULL|| | created_by | varchar(50) | NO | | NULL|| +-+-+--+-+-++ 7 rows in set (0.37 sec) A row in this table means that such-and-such package is in a specific catalog. If we want to keep the information about deletions, we'll have to keep the row, but the row would need to contain a flag indicating that the package has been removed at certain time. Adding this information helps. The date of the deletion also to keep the certain time. Of course, the flag can be negated if the package is re-instantiated. BTW, what about increasing the size of created_by attribute to contain a group of maintainers? -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing — handover
2013/9/8 Peter FELECAN pfele...@opencsw.org: Adding this information helps. The date of the deletion also to keep the certain time. Of course, the flag can be negated if the package is re-instantiated. Yes. The problem is that this will require a database schema change and code changes in multiple places. BTW, what about increasing the size of created_by attribute to contain a group of maintainers? This field isn't the maintainer, it's the user who initiated the call to insert a package into a catalog. It also currently doesn't work because of the proxy issue we discussed earlier. http://lists.opencsw.org/pipermail/maintainers/2013-May/018107.html Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing — handover
I've pasted in the integration documentation into our wiki: http://wiki.opencsw.org/automated-release-process#toc4 The issue is still open, we're looking for someone to handle catalog integrations. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing ― handover
Maciej (Matchek) Bliziński mac...@opencsw.org writes: I've pasted in the integration documentation into our wiki: http://wiki.opencsw.org/automated-release-process#toc4 The issue is still open, we're looking for someone to handle catalog integrations. IMHO, we need to find somebody to implement the automatic transition from unstable to testing. Remember, we decided that the transition is made when there is no blocking issue reported in our BTS after 2 weeks from release time. -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing ― handover
2013/9/7 Peter FELECAN pfele...@opencsw.org IMHO, we need to find somebody to implement the automatic transition from unstable to testing. Remember, we decided that the transition is made when there is no blocking issue reported in our BTS after 2 weeks from release time. Right. We might start moving in this direction. The database already stores the required information: when was each package inserted into which catalog. There is no REST API for it though. I'll see if I can add it. I'm also thinking that when we transition to the 2 week automatic package promotion, we'll come across a new failure scenario. For example, 2 co-dependent packages are uploaded, let's call them CSWfoo and CSWbar. A bug is discovered in CSWbar. A fixed version of CSWbar is uploaded a week later. But the timer on CSWfoo hasn't been reset, so CSWfoo gets promoted without the accompanying CSWbar. This causes CSWbar to be broken in the testing catalog. So far, I've tried to make the package promotion as simple as possible. Ideally, it was an equivalent of taking a snapshot of unstable and making it the testing catalog. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing ― handover
On 2013-09-07 8:29 PM, Maciej (Matchek) Bliziński wrote: So far, I've tried to make the package promotion as simple as possible. Ideally, it was an equivalent of taking a snapshot of unstable and making it the testing catalog. Since that's basically what I'm doing in production, I'm all for it. Laurent ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing ― handover
2013/9/7 Laurent Blume laur...@opencsw.org On 2013-09-07 8:29 PM, Maciej (Matchek) Bliziński wrote: So far, I've tried to make the package promotion as simple as possible. Ideally, it was an equivalent of taking a snapshot of unstable and making it the testing catalog. Since that's basically what I'm doing in production, I'm all for it. In practice it wasn't that simple, there usually were packages I wanted to skip. Another thing is deletions: we need to propagate them as well, but the database currently doesn't hold the information about when a package was removed from a catalog. This might be an inconvenient feature to implement. We currently have a table which connects a svr4 file, catalog release, OS release and architecture. mysql describe srv4_file_in_catalog; +-+-+--+-+-++ | Field | Type| Null | Key | Default | Extra | +-+-+--+-+-++ | id | int(11) | NO | PRI | NULL| auto_increment | | arch_id | int(11) | NO | MUL | NULL|| | osrel_id| int(11) | NO | MUL | NULL|| | catrel_id | int(11) | NO | MUL | NULL|| | srv4file_id | int(11) | NO | MUL | NULL|| | created_on | datetime| NO | | NULL|| | created_by | varchar(50) | NO | | NULL|| +-+-+--+-+-++ 7 rows in set (0.37 sec) A row in this table means that such-and-such package is in a specific catalog. If we want to keep the information about deletions, we'll have to keep the row, but the row would need to contain a flag indicating that the package has been removed at certain time. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing — handover
2013/7/11 Oliver Kiddle o...@opencsw.org: I'm replying to two messages here. Maciej (Matchek) Bliziński wrote: We've kept the 'stable' dead for a while now. What do you think about pointing the 'stable' symlink at dublin and the 'testing' symlink at kiel? I'd definitely be in favour. The old stable release is way too ancient and it is a lot easier for users to understand if our naming is meaningful. Cool. To what extent have fixed packages been moved to dublin since it was frozen? In practice, close to zero updates in the last... I don't know, year? We did push PostgreSQL updates though, if I'm not mistaken. We have the capacity to submit with csw-upload-pkg to a named catalog, not only unstable. We can whitelist dublin and make submissions there a standard practice, with the regular checkpkg procedure. If anyone wants to submit packages to dublin, it's either possible already, or we can make it possible without too much effort. Has it relied on a single person or could any maintainer run integrate_catalogs.py if they had fixed a critical issue. Anyone can run integrate_catalogs.py, and the same goes with csw-upload-pkg. The former is far more dangerous though. Maciej (Matchek) Bliziński wrote: I'd like to hand over the unstable→testing integration to someone else. It's a periodic task, where you take an existing state of unstable, create a list of operations to bring testing to the same state, then you review the list and if it looks good, you execute it. If it doesn't look good (e.g. there's a broken package in unstable), you manually remove this package from the list. I'm tempted to take on this task though in a normal situation my use of unstable can be limited. For the systems at my work, I ended up creating my own stable release by taking a snapshot from unstable as it then was and grabbing newer packages in those cases where there were problems. I used to do the same. I guess it's a necessity if you run a fleet of machines. It's good that you have experience with managing catalogs. It was easier to use unstable as a starting point because I needed some extra things that were broken or missing at that time. This was before dublin and stable at that time was already old. We've got new hardware and I'm currently preparing a similar snapshot based on kiel. Perhaps I should use dublin but kiel seemed stable on the test machine. The result is that at the moment I'm testing and using unstable quite thoroughly. What is the intended schedule for kiel being frozen? There isn't a fully crystallized plan right now. There is a consensus that we will move towards timed releases, e.g. every 6 or every 12 months. With the limited workforce it has been very hard to hit our targets, but at least our efforts were coordinated. I'm thinking that what we want to finish for the kiel release is the OpenSSL migration. When we're done, we'll freeze kiel and continue with a new testing release. This topic will be definitely discussed in Berlin. We have the audacious goal of doing a full rebuild with GCC, but I still don't know if it's feasible. Maybe we should focus on IPS instead. To be discussed in Berlin. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
