Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/10/11 Peter FELECAN : >> I agree with this kludge only if its presence in the recipe is mandatory. > > Hm. We could make it mandatory, but then the default value should be > "nobody" or something of the same meaning. The reason is that only a > subset of packages have people who care about them. If we copy the > current state from the package catalog, we'll effectively freeze the > current package-maintainer relationship mapping. We will also not know > whether there is anyone that cares about certain package. Therefore, > there will be no gain. Really I do not understand. As shown in my previous messages, we know where to take the information, where to give it a good usage. Conceptually it's not difficult. Unfortunately I do not have the resources to implement this. >From my point of view, I consider this discussion closed as I don't like to run in circle chasing my tail. -- Peter
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
2013/10/11 Peter FELECAN : > I agree with this kludge only if its presence in the recipe is mandatory. Hm. We could make it mandatory, but then the default value should be "nobody" or something of the same meaning. The reason is that only a subset of packages have people who care about them. If we copy the current state from the package catalog, we'll effectively freeze the current package-maintainer relationship mapping. We will also not know whether there is anyone that cares about certain package. Therefore, there will be no gain. Maciej
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/10/11 Maciej (Matchek) Bliziński : >> Here's an idea: we >> could create an optional field in the recipe, which would be an >> explicit list of maintainers of that package. If it's not present, >> things work as previously. If it is there, it pins down the current >> maintainer, and the package does go to a new owner. > > Errata, a "not" is missing, I meant "the package does not go to a new owner." I agree with this kludge only if its presence in the recipe is mandatory. -- Peter
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
2013/10/11 Maciej (Matchek) Bliziński : > Here's an idea: we > could create an optional field in the recipe, which would be an > explicit list of maintainers of that package. If it's not present, > things work as previously. If it is there, it pins down the current > maintainer, and the package does go to a new owner. Errata, a "not" is missing, I meant "the package does not go to a new owner."
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
I didn't have the time to write a short email, so I wrote a long one instead. :) 2013/9/16 Maciej (Matchek) Bliziński : > Going back to the original subject, we know of the following facts / > relations of people to a given package: > > - people who made edits to the build recipe (can be taken from the > repository, it's not available for all packages) > - person who built the package / ran mgar (this information is > embedded in the package) > - person who inserted the package into a catalog (could be a different > person in each catalog) > > The above are the things we know. None of these things is the list of > the Maintainers Of The Package. I'd like to compare it with what Peter wrote earlier: http://lists.opencsw.org/pipermail/maintainers/2013-August/018444.html > 1. the user who modified the recipe > 2. the user who built the package > 3. the user who uploaded the package > 4. the user who owns the package, from Mantis stand point Here are the considerations: ad 1. we kind of have that information, but the users here are from a different user name space, e.g. I'm "maciej" on the buildfarm, but "wahwah" on SourceForge. We'd need a mapping to meaningfully match the two user names. ad 2. this information is stored in package's pkginfo file ad 3. there is no single upload operation we can refer to. The following operations exist: (1) a POST request which sends the .pkg.gz file to the web zone, causing the file to be saved in the allpkgs directory, (2) a PUT request to the releases_web.py app which creates a row in one of the tables. The row binds together the specific package file, and a specific catalog. This row later results in the presence of that package in the specific catalog on the mirror. Maintainers can insert packages into any catalogs: unstable as well as kiel and/or dublin. In most cases the inserts into the testing (currently: kiel) catalog are done by a different person than the maintainer. ad 4. this field is sourced directly from the user who built the package, but it doesn't have to be that way in principle Given how things currently work, I don't see an existing data that we can use for a more meaningful True Maintainer. Here's an idea: we could create an optional field in the recipe, which would be an explicit list of maintainers of that package. If it's not present, things work as previously. If it is there, it pins down the current maintainer, and the package does go to a new owner. But we would require a certain etiquette to use it. For example, I would put myself down as the Python package maintainer. There would be other packages that happened to rebuild, but I don't care as much as I do about the main Python package. If somebody else was rebuilding one of packages I also happened to rebuild earlier, I would not like them to put my name down as the maintainer. In other words: you would be supposed to only add your own name to that list. Would it make things better? I'm not sure. If I understand correctly, Peter's intention was to kind of hide the fact that you've rebuilt a package; so you rebuild the package, but you don't change the maintainer name associated with the package. But the problem is that the currently associated name is already as bogus as your name. Let me illustrate: Joe rebuilds the CSWfoo package from version 1.1 to version 1.2, but he doesn't want to take the ownership of that package. The current state is this: CSWfoo 1.1, maintainer: Jane But is Jane the true maintainer? No! She only did a rebuild of CSWfoo from 1.0 to 1.1, and the package was previously rebuilt by Bob. But was Bob the true maintainer? No, he only did a rebuild from 0.9 to 1.0. It can be turtles all the way. In other words, the package maintainer written on a package is not as meaningful as people often take it to be. Let's start by admitting it, then see if we can improve on that. I believe that True Package Ownership can be beneficial, but it should be an opt-in thing, and for all other packages we should continue the "who last touched it" tracking. Maciej
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
2013/8/11 Peter FELECAN : > "Maciej (Matchek) Bliziński" writes: > >> I tried and failed. I wanted to record who uploaded which package to >> which catalog. Unfortunately, our web proxy destroys this information. >> Maybe it can be fixed with some clever HTTP header rewriting, but I >> didn't manage to make it work. > > What's the proxy that we use? > > Can you show me where in the code this is done? It turned out that it wasn't the proxy at all. I've discovered the bug accidentally during the camp, while explaining the code to another person. This is the fix: http://sourceforge.net/apps/trac/gar/changeset/21921 From yesterday on, the buildfarm database has accurate information about who inserted which package to which catalog. There also is a new URL you can call to retrieve this information for a given catalog. For example: url=http://buildfarm.opencsw.org/pkgdb/rest/catalogs/unstable/sparc/SunOS5.10/timing/ curl -s $url | python -m json.tool | less The last 3 elements in each list are: - mtime of the svr4 file - time the package was inserted into the catalog - user name who did it, taken from HTTP auth Going back to the original subject, we know of the following facts / relations of people to a given package: - people who made edits to the build recipe (can be taken from the repository, it's not available for all packages) - person who built the package / ran mgar (this information is embedded in the package) - person who inserted the package into a catalog (could be a different person in each catalog) The above are the things we know. None of these things is the list of the Maintainers Of The Package. 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] Non-Maintainer Uploads (NMUs)
Funny we talked about the bus factor just now. I had a road accident two weeks ago and I'm now in a hospital due to some complications. I'm on a good way to recovery but I'm strongly computer-limited for a few days. I was expecting to be back by now and writing the docs but it'll take me a few additional days to be back in business^Wvolunteering. Maciej PS: top posting because phone No dia 15/08/2013 10:51, "Peter FELECAN" escreveu: > "Maciej (Matchek) Bliziński" writes: > > > 2013/8/15 Peter FELECAN : > 2. As for the persons implementing this, from an efficiency point of > view, who are the best suited candidates in your opinion? > >>> > >>> Anyone who cares and understands at least a little bit of Python. > >>> Whoever does it, will have to walk through multiple stages and levels > >>> of data processing. If someone new takes on this task, they will learn > >>> a lot about the infrastructure and improve our bus factor (yay!). > >> > >> My question wasn't innocent as I read some parts of the code and I must > >> confess that an architecture documentation, at least, is missing to > >> understand the thing. For example I'll had a great difficulty to set up > >> a test platform to explore the needed modifications. > > > > The problem with the buildfarm is that until other people tried, it > > has ever been installed once. Then it was modified several times. We > > didn't even know if it is still possible to install from scratch . > > > > In January this year, I've attempted to make an instructional video > > how to set up a private buildfarm. I've realized that using the > > resources I had at home, it was impossible. I've set out to adapt the > > code so that you can set up a build host on a small virtual machine. > > I'm working on the rewrite to this day; it is my priority. > > > > With regard to documentation, what level of detail do you think is > > optimal? I'm willing to write the documentation, but I'd prefer that > > someone reads it as I'm writing it so I have feedback if I'm on the > > right track at all. > > This is an endeavor that I like and think necessary. I'm a volunteer for > this: being a guinea pig for building a farm using your documentation > and I'll give plenty of feedback in the process. We can use a different > thread such as the process is public and well identified and others can > chime in or even follow the construction themselves. > > >> I think that the > >> effort needed to implement this by a novice is at least one order of > >> magnitude greater than that for one who already knows the code and > >> architecture. > > > > You're right, but there's no way around this; and me implementing it > > isn't a solution. It only delays the symptoms. It's better for another > > person to attempt now and have me to answer their questions. If a bus > > hit me, it'd be worse. > > Yeah, the bus metaphor... OK, lets take an insurance against that > undesirable event and proceed. The only thing which bothers me is that, > for the purpose of the initial subject, i.e. NMU, is quite a yak shaving > session. But I'm used to it, I do that more than what I really wish to > focus on. > > -- > Peter > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/15 Peter FELECAN : 2. As for the persons implementing this, from an efficiency point of view, who are the best suited candidates in your opinion? >>> >>> Anyone who cares and understands at least a little bit of Python. >>> Whoever does it, will have to walk through multiple stages and levels >>> of data processing. If someone new takes on this task, they will learn >>> a lot about the infrastructure and improve our bus factor (yay!). >> >> My question wasn't innocent as I read some parts of the code and I must >> confess that an architecture documentation, at least, is missing to >> understand the thing. For example I'll had a great difficulty to set up >> a test platform to explore the needed modifications. > > The problem with the buildfarm is that until other people tried, it > has ever been installed once. Then it was modified several times. We > didn't even know if it is still possible to install from scratch . > > In January this year, I've attempted to make an instructional video > how to set up a private buildfarm. I've realized that using the > resources I had at home, it was impossible. I've set out to adapt the > code so that you can set up a build host on a small virtual machine. > I'm working on the rewrite to this day; it is my priority. > > With regard to documentation, what level of detail do you think is > optimal? I'm willing to write the documentation, but I'd prefer that > someone reads it as I'm writing it so I have feedback if I'm on the > right track at all. This is an endeavor that I like and think necessary. I'm a volunteer for this: being a guinea pig for building a farm using your documentation and I'll give plenty of feedback in the process. We can use a different thread such as the process is public and well identified and others can chime in or even follow the construction themselves. >> I think that the >> effort needed to implement this by a novice is at least one order of >> magnitude greater than that for one who already knows the code and >> architecture. > > You're right, but there's no way around this; and me implementing it > isn't a solution. It only delays the symptoms. It's better for another > person to attempt now and have me to answer their questions. If a bus > hit me, it'd be worse. Yeah, the bus metaphor... OK, lets take an insurance against that undesirable event and proceed. The only thing which bothers me is that, for the purpose of the initial subject, i.e. NMU, is quite a yak shaving session. But I'm used to it, I do that more than what I really wish to focus on. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/15 Peter FELECAN : >>> 2. As for the persons implementing this, from an efficiency point of >>>view, who are the best suited candidates in your opinion? >> >> Anyone who cares and understands at least a little bit of Python. >> Whoever does it, will have to walk through multiple stages and levels >> of data processing. If someone new takes on this task, they will learn >> a lot about the infrastructure and improve our bus factor (yay!). > > My question wasn't innocent as I read some parts of the code and I must > confess that an architecture documentation, at least, is missing to > understand the thing. For example I'll had a great difficulty to set up > a test platform to explore the needed modifications. The problem with the buildfarm is that until other people tried, it has ever been installed once. Then it was modified several times. We didn't even know if it is still possible to install from scratch . In January this year, I've attempted to make an instructional video how to set up a private buildfarm. I've realized that using the resources I had at home, it was impossible. I've set out to adapt the code so that you can set up a build host on a small virtual machine. I'm working on the rewrite to this day; it is my priority. With regard to documentation, what level of detail do you think is optimal? I'm willing to write the documentation, but I'd prefer that someone reads it as I'm writing it so I have feedback if I'm on the right track at all. > I think that the > effort needed to implement this by a novice is at least one order of > magnitude greater than that for one who already knows the code and > architecture. You're right, but there's no way around this; and me implementing it isn't a solution. It only delays the symptoms. It's better for another person to attempt now and have me to answer their questions. If a bus hit me, it'd be worse. 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] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/14 Peter FELECAN : >>As we can see, there is no need of a new package field, nor to >>query the database during the build to obtain the set of >>maintainers. > > OK, so your idea is that the package will know who built the package, > but will not know the maintainer set. One problem with this design is > that if you tear down and rebuild the package database, you will lose > the information about the maintainer sets. The same would happen with > private buildfarms, they would not have this information. So far, I was > always trying to enclose all the relevant information inside the > packages. I understand that but don't think that is an obstacle. BTW, the mantis database contains the set of maintainers as all the managers of a project. Consequently, we have backup of the information which can help the reconstruction of the database. >> 2. As for the persons implementing this, from an efficiency point of >>view, who are the best suited candidates in your opinion? > > Anyone who cares and understands at least a little bit of Python. > Whoever does it, will have to walk through multiple stages and levels > of data processing. If someone new takes on this task, they will learn > a lot about the infrastructure and improve our bus factor (yay!). My question wasn't innocent as I read some parts of the code and I must confess that an architecture documentation, at least, is missing to understand the thing. For example I'll had a great difficulty to set up a test platform to explore the needed modifications. I think that the effort needed to implement this by a novice is at least one order of magnitude greater than that for one who already knows the code and architecture. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/14 Peter FELECAN : >As we can see, there is no need of a new package field, nor to >query the database during the build to obtain the set of >maintainers. OK, so your idea is that the package will know who built the package, but will not know the maintainer set. One problem with this design is that if you tear down and rebuild the package database, you will lose the information about the maintainer sets. The same would happen with private buildfarms, they would not have this information. So far, I was always trying to enclose all the relevant information inside the packages. > 2. As for the persons implementing this, from an efficiency point of >view, who are the best suited candidates in your opinion? Anyone who cares and understands at least a little bit of Python. Whoever does it, will have to walk through multiple stages and levels of data processing. If someone new takes on this task, they will learn a lot about the infrastructure and improve our bus factor (yay!). 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] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes:
> 2013/8/14 Peter FELECAN :
>> Laurent Blume writes:
>>
>>> On 14/08/13 16:12, Peter FELECAN wrote:
Each package has its set/group of maintainers. Is the simplest way.
>>>
>>> Is that easy to maintain, eg for recipe which create a bunch of packages?
>>
>> If we can do this for one, and we do, we certainly can do it for
>> many. Every operation that we have today for one maintainer can be reused
>> to manage another maintainer. Maybe Maciej can elaborate on this, he is
>> the guy who knows the code best.
>
> We still don't know how to implement it in details. The EMAIL field
> probably has to remain a single email address. We have to gradually
> develop an additional path of propagating maintainer information. For
> example:
>
> - a new pkginfo field MAINTAINERS
> - MAINTAINERS is a comma/space separated list of buildfarm user names
> - when a package is built, GAR makes a request to fetch the previous
> list from the buildfarm database, appends the currently building user
> to the list if not already there; put the list into the MAINTAINERS
> field
> - this list in the buildfarm database is mutable; you can
> send a request to the buildfarm to remove a maintainer (themselves or
> another maintainer). When a maintainer is removed, the name is no
> longer returned by the query and upon the next package rebuild, the
> name is no longer on the list.
> - the EMAIL field is the fallback for MAINTAINERS
> - GAR side handling of EMAIL remains as it was
> - we gradually change the code everywhere to look at MAINTAINERS and
> not at EMAIL
>
> By the way - I'm not volunteering for implementing this. I'm focusing
> on another part of the code.
1. Your example is interesting but, from my point of view it's a little
bit too complex and has the inconvenient of a query to the database
during the package construction wich hinders an isolated usage.
Let me simplify it by using a kind of poor man chronogram:
1. In the beginning, a new package is built by an initial
maintainer, lets name him m0.
The package has the usual EMAIL field which is used to create
the set of maintainers.
The set of maintainers is { m0 }.
2. Another maintainer, m1 does a NMU.
Again, the EMAIL filed in the package contains the new
maintainer's information. This is used to insert the new
maintainer in the maintainers set.
The set of maintainers is now { m0, m1 }.
3. The first maintainers doesn't wish anymore to be aware of bug
reports, retires or other whim.
He or another responsible maintainer removes him from
maintainers set using the safe_remove_package_maintainer tool.
The set of maintainers is now { m1 }.
4. Eventually the package is removed from the catalog.
Either safe_remove_package is used as today or
safe_remove_package_maintainer on a set having a sole
maintainer.
As we can see, there is no need of a new package field, nor to
query the database during the build to obtain the set of
maintainers.
2. As for the persons implementing this, from an efficiency point of
view, who are the best suited candidates in your opinion?
--
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] Non-Maintainer Uploads (NMUs)
2013/8/14 Peter FELECAN : > Laurent Blume writes: > >> On 14/08/13 16:12, Peter FELECAN wrote: >>> Each package has its set/group of maintainers. Is the simplest way. >> >> Is that easy to maintain, eg for recipe which create a bunch of packages? > > If we can do this for one, and we do, we certainly can do it for > many. Every operation that we have today for one maintainer can be reused > to manage another maintainer. Maybe Maciej can elaborate on this, he is > the guy who knows the code best. We still don't know how to implement it in details. The EMAIL field probably has to remain a single email address. We have to gradually develop an additional path of propagating maintainer information. For example: - a new pkginfo field MAINTAINERS - MAINTAINERS is a comma/space separated list of buildfarm user names - when a package is built, GAR makes a request to fetch the previous list from the buildfarm database, appends the currently building user to the list if not already there; put the list into the MAINTAINERS field - this list in the buildfarm database is mutable; you can send a request to the buildfarm to remove a maintainer (themselves or another maintainer). When a maintainer is removed, the name is no longer returned by the query and upon the next package rebuild, the name is no longer on the list. - the EMAIL field is the fallback for MAINTAINERS - GAR side handling of EMAIL remains as it was - we gradually change the code everywhere to look at MAINTAINERS and not at EMAIL By the way - I'm not volunteering for implementing this. I'm focusing on another part of the code. Thoughts? 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] Non-Maintainer Uploads (NMUs)
Laurent Blume writes: > On 14/08/13 16:12, Peter FELECAN wrote: >> Each package has its set/group of maintainers. Is the simplest way. > > Is that easy to maintain, eg for recipe which create a bunch of packages? If we can do this for one, and we do, we certainly can do it for many. Every operation that we have today for one maintainer can be reused to manage another maintainer. Maybe Maciej can elaborate on this, he is the guy who knows the code best. -- 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] Non-Maintainer Uploads (NMUs)
On 14/08/13 16:12, Peter FELECAN wrote: Each package has its set/group of maintainers. Is the simplest way. Is that easy to maintain, eg for recipe which create a bunch of packages? 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] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/14 Peter FELECAN : >>> 1. How do we remove a maintainer from a given group? >> >> This needs a specific command. > > Yes, it will be human initiated, the question is what command that is, > will it be a new too, or a new option to an existing tool? A new one as safe_remove_package has too explicitely other subject. safe_remove_package_maintainer ? >>> 2. What happens when the last maintainer is removed from a group? >>> (Should it be allowed? And why?) >> >> e.g. when a package is to be removed from the catalog; probably should >> imply the removal from the catalog, maybe transiting through a "orphaned" >> state. > > One more question about groups: Is it just that each package has > own group of maintainers, so it means there are (potentially) as many > groups as there are packages? Or do groups exist independently of > packages, and there are associations between groups and packages? Each package has its set/group of maintainers. Is the simplest way. Of course you can define sort of virtual users which correspond to a group to which real users are attached and this virtual user can be a manager, in mantis acception, of a package. How do you attach the real users to the virtual one is another discussion. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/14 Peter FELECAN : >> 1. How do we remove a maintainer from a given group? > > This needs a specific command. Yes, it will be human initiated, the question is what command that is, will it be a new too, or a new option to an existing tool? >> 2. What happens when the last maintainer is removed from a group? >> (Should it be allowed? And why?) > > e.g. when a package is to be removed from the catalog; probably should > imply the removal from the catalog, maybe transiting through a "orphaned" > state. One more question about groups: Is it just that each package has own group of maintainers, so it means there are (potentially) as many groups as there are packages? Or do groups exist independently of packages, and there are associations between groups and packages? ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/14 Peter FELECAN >> When a maintainer builds and uploads a package for which his status in >> Mantis is not "manager" he becomes part of the maintainers set for this >> package. > > Sounds good. > > Additional things to consider: > > 1. How do we remove a maintainer from a given group? This needs a specific command. > 2. What happens when the last maintainer is removed from a group? > (Should it be allowed? And why?) e.g. when a package is to be removed from the catalog; probably should imply the removal from the catalog, maybe transiting through a "orphaned" state. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/14 Peter FELECAN > When a maintainer builds and uploads a package for which his status in > Mantis is not "manager" he becomes part of the maintainers set for this > package. Sounds good. Additional things to consider: 1. How do we remove a maintainer from a given group? 2. What happens when the last maintainer is removed from a group? (Should it be allowed? And why?) ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
I have a new proposition which I hope will satisfy everybody involved in the discussion and probably beyond. When a maintainer builds and uploads a package for which his status in Mantis is not "manager" he becomes part of the maintainers set for this package. This satisfies at least the following requirements: 1. we have groups of maintainers 2. a previous maintainer is still informed on the issues related to the package 3. simple to implement on our infrastructure. Please air your opinions! TIA -- 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] Non-Maintainer Uploads (NMUs)
2013/8/12 Peter FELECAN : >> What I think we have, is this: >> HTTP client → squid → Apache → script > > That we can imagine. When I'm asking "where is the emitting end" I refer > to a place in the code. Sorry. I missed this, sorry. Here it is: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/python/rest.py#L142 ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
Yann Rouillard writes: > Well, I think I already expressed my opinion here: > http://lists.opencsw.org/pipermail/maintainers/2013-August/018413.html > But to recap: I am for promoting team for package maintenance, rather than > replacing the notion of maintainers with uploaders, and I am for allowing > uploads by non maintainers (or non member of a maintenance team) who don't > want to take over maintenance. You're right. > In our case, unfortunately I am not sure we can create a lot of teams but > we may create at least one core team to maintain some important base > packages and one for dealing with orphaned packages in best effort mode. > > But I would like to hear the opinion of other people as it is an important > change, maybe a subject for the summer camp. I would like too. -- 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] Non-Maintainer Uploads (NMUs)
Well, I think I already expressed my opinion here: http://lists.opencsw.org/pipermail/maintainers/2013-August/018413.html But to recap: I am for promoting team for package maintenance, rather than replacing the notion of maintainers with uploaders, and I am for allowing uploads by non maintainers (or non member of a maintenance team) who don't want to take over maintenance. In our case, unfortunately I am not sure we can create a lot of teams but we may create at least one core team to maintain some important base packages and one for dealing with orphaned packages in best effort mode. But I would like to hear the opinion of other people as it is an important change, maybe a subject for the summer camp. Yann 2013/8/12 Peter FELECAN > Yann Rouillard writes: > > > BTW, I also think we should debate on point #2 raised by Maciej before > > continuing: > > "2. A package owner/maintainer is responsible for everything that's > associated > > with the package, e.g. any current and future bugs." > > Because depending on the outcome, we may not need at all to implement > what > > you are trying to do. > > Of course. What's your opinion on it? > -- > Peter > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
Yann Rouillard writes: > BTW, I also think we should debate on point #2 raised by Maciej before > continuing: > "2. A package owner/maintainer is responsible for everything that's associated > with the package, e.g. any current and future bugs." > Because depending on the outcome, we may not need at all to implement what > you are trying to do. Of course. What's your opinion on it? -- 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] Non-Maintainer Uploads (NMUs)
Yes I agree, but if (2 != 3), I think 2 is more important than 3. So I am just saying that it's better to work on storing 2 rather than 3 and it's better to embed the information in the package itself. Currently, I think pretty much everything in the database can be retrieved from the content of a package (Maciej, do you confirm ?) and I think it's more reliable that way. Also if we set some rules one day related to NMU (like updating a changelog), it would be easier to check them if the information is stored in the package. BTW, I also think we should debate on point #2 raised by Maciej before continuing: "2. A package owner/maintainer is responsible for everything that's associated with the package, e.g. any current and future bugs." Because depending on the outcome, we may not need at all to implement what you are trying to do. Yann 2013/8/12 Peter FELECAN > Yann Rouillard writes: > > > I am not sure using the http protocol is the best way here. > > Yann, > > We are trying to solve the blocking issue which can make the proposed > modification easy. So, it's a way. Probably not unique or best. > > > I think we don't really care about the uploader, we rather care about who > > rebuilt the package. > > Because he's the one who knows what modification was made. > > > > So I think it makes more sense to put that information in the package (in > > pkginfo) at package build time, rather that trying to find it at upload > > time from the authorization layer (even if usually uploader = last > package > > builder). > > This is another solution if it doesn't change the ownership of the > package. > > From my point of view, there are 4 user related information: > > 1. the user who modified the recipe > 2. the user who built the package > 3. the user who uploaded the package > 4. the user who owns the package, from Mantis stand point > > Most of the time 1 == 2 == 3 == 4 (nice isn't it?) > > Sometimes 1 != 2 == 3 != 4 > > And other combinations... > > Now, I'm not saying the we must collect all this. What I'm saying is > that the values can be different and not always inferred from each other. > > With the exception of 3, all the values can be contained by the > package. And exactly 3 is the NMU finalization. > -- > Peter > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/12 Peter FELECAN >> >> > The place to retrieve the user is here: >> > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/releases_web.py#L207 >> >> Alright. This is the receiving end. Where is the emitting end? > > There's a few stages: the HTTP client uses HTTP basic auth. That is > handled by Apache; but squid is doing something to the headers. I'm > not sure if we only have a forward proxy or a reverse proxy? > > What I think we have, is this: > HTTP client → squid → Apache → script That we can imagine. When I'm asking "where is the emitting end" I refer to a place in the code. Sorry. -- 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] Non-Maintainer Uploads (NMUs)
Yann Rouillard writes: > I am not sure using the http protocol is the best way here. Yann, We are trying to solve the blocking issue which can make the proposed modification easy. So, it's a way. Probably not unique or best. > I think we don't really care about the uploader, we rather care about who > rebuilt the package. > Because he's the one who knows what modification was made. > > So I think it makes more sense to put that information in the package (in > pkginfo) at package build time, rather that trying to find it at upload > time from the authorization layer (even if usually uploader = last package > builder). This is another solution if it doesn't change the ownership of the package. >From my point of view, there are 4 user related information: 1. the user who modified the recipe 2. the user who built the package 3. the user who uploaded the package 4. the user who owns the package, from Mantis stand point Most of the time 1 == 2 == 3 == 4 (nice isn't it?) Sometimes 1 != 2 == 3 != 4 And other combinations... Now, I'm not saying the we must collect all this. What I'm saying is that the values can be different and not always inferred from each other. With the exception of 3, all the values can be contained by the package. And exactly 3 is the NMU finalization. -- 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] Non-Maintainer Uploads (NMUs)
I am not sure using the http protocol is the best way here. I think we don't really care about the uploader, we rather care about who rebuilt the package. Because he's the one who knows what modification was made. So I think it makes more sense to put that information in the package (in pkginfo) at package build time, rather that trying to find it at upload time from the authorization layer (even if usually uploader = last package builder). Yann 2013/8/12 Peter FELECAN > "Maciej (Matchek) Bliziński" writes: > > > 2013/8/12 Peter FELECAN : > >> Returning to the REMOTE_USER not being defined, after a cursory look at > >> other people having issues with that it seems that even if the > >> environment variable is not provided, there is a possibility to obtain > >> the remote user from the "authorization" header, see > >> > http://stackoverflow.com/questions/8495229/remote-user-not-being-set-by-apache2 > >> but maybe this is also modified by the proxy. > > > > Normally the authorization header is stripped, unless you configure > > Apache to specifically include it. The security concern is that you > > expose the auth password to the script while you don't need to. > > Indeed. How about a rewrite? What are the other environment variables > accessible to the script? > -- > Peter > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/12 Peter FELECAN : >> Returning to the REMOTE_USER not being defined, after a cursory look at >> other people having issues with that it seems that even if the >> environment variable is not provided, there is a possibility to obtain >> the remote user from the "authorization" header, see >> http://stackoverflow.com/questions/8495229/remote-user-not-being-set-by-apache2 >> but maybe this is also modified by the proxy. > > Normally the authorization header is stripped, unless you configure > Apache to specifically include it. The security concern is that you > expose the auth password to the script while you don't need to. Indeed. How about a rewrite? What are the other environment variables accessible to the script? -- 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] Non-Maintainer Uploads (NMUs)
Dagobert Michelsen writes: > Hi Peter, > > Am 12.08.2013 um 14:43 schrieb Peter FELECAN : >> "Maciej (Matchek) Bliziński" writes: >>> 2013/8/12 Peter FELECAN > The place to retrieve the user is here: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/releases_web.py#L207 Alright. This is the receiving end. Where is the emitting end? >>> >>> There's a few stages: the HTTP client uses HTTP basic auth. That is >>> handled by Apache; but squid is doing something to the headers. I'm >>> not sure if we only have a forward proxy or a reverse proxy? >>> >>> What I think we have, is this: >>> HTTP client → squid → Apache → script >> >> Maybe Dago could provide a description of the architecture. >> >> Returning to the REMOTE_USER not being defined, after a cursory look at >> other people having issues with that it seems that even if the >> environment variable is not provided, there is a possibility to obtain >> the remote user from the "authorization" header, see >> http://stackoverflow.com/questions/8495229/remote-user-not-being-set-by-apache2 >> but maybe this is also modified by the proxy. >> >> We need more information about the proxy's configuration. > > You should be able to > ssh web > with your pfelecan account which can also open /etc/opt/csw/squid/squid.conf Thank you. Can you confirm or correct the architecture hypothesis: HTTP client → squid → Apache → script More I read about this and more it seems that we must implement a rewrite on the proxy to pass the REMOTE_USER. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/12 Peter FELECAN : > Returning to the REMOTE_USER not being defined, after a cursory look at > other people having issues with that it seems that even if the > environment variable is not provided, there is a possibility to obtain > the remote user from the "authorization" header, see > http://stackoverflow.com/questions/8495229/remote-user-not-being-set-by-apache2 > but maybe this is also modified by the proxy. Normally the authorization header is stripped, unless you configure Apache to specifically include it. The security concern is that you expose the auth password to the script while you don't need to. 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] Non-Maintainer Uploads (NMUs)
Hi Peter, Am 12.08.2013 um 14:43 schrieb Peter FELECAN : > "Maciej (Matchek) Bliziński" writes: >> 2013/8/12 Peter FELECAN >>> The place to retrieve the user is here: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/releases_web.py#L207 >>> >>> Alright. This is the receiving end. Where is the emitting end? >> >> There's a few stages: the HTTP client uses HTTP basic auth. That is >> handled by Apache; but squid is doing something to the headers. I'm >> not sure if we only have a forward proxy or a reverse proxy? >> >> What I think we have, is this: >> HTTP client → squid → Apache → script > > Maybe Dago could provide a description of the architecture. > > Returning to the REMOTE_USER not being defined, after a cursory look at > other people having issues with that it seems that even if the > environment variable is not provided, there is a possibility to obtain > the remote user from the "authorization" header, see > http://stackoverflow.com/questions/8495229/remote-user-not-being-set-by-apache2 > but maybe this is also modified by the proxy. > > We need more information about the proxy's configuration. You should be able to ssh web with your pfelecan account which can also open /etc/opt/csw/squid/squid.conf Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/12 Peter FELECAN >> >> > The place to retrieve the user is here: >> > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/releases_web.py#L207 >> >> Alright. This is the receiving end. Where is the emitting end? > > There's a few stages: the HTTP client uses HTTP basic auth. That is > handled by Apache; but squid is doing something to the headers. I'm > not sure if we only have a forward proxy or a reverse proxy? > > What I think we have, is this: > HTTP client → squid → Apache → script Maybe Dago could provide a description of the architecture. Returning to the REMOTE_USER not being defined, after a cursory look at other people having issues with that it seems that even if the environment variable is not provided, there is a possibility to obtain the remote user from the "authorization" header, see http://stackoverflow.com/questions/8495229/remote-user-not-being-set-by-apache2 but maybe this is also modified by the proxy. We need more information about the proxy's configuration. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/12 Peter FELECAN > > > The place to retrieve the user is here: > > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/releases_web.py#L207 > > Alright. This is the receiving end. Where is the emitting end? There's a few stages: the HTTP client uses HTTP basic auth. That is handled by Apache; but squid is doing something to the headers. I'm not sure if we only have a forward proxy or a reverse proxy? What I think we have, is this: HTTP client → squid → Apache → script 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] Non-Maintainer Uploads (NMUs)
Dagobert Michelsen writes: > Am 12.08.2013 um 14:14 schrieb Peter FELECAN : >> "Maciej (Matchek) Bliziński" writes: >>> 2013/8/11 Peter FELECAN : "Maciej (Matchek) Bliziński" writes: > I tried and failed. I wanted to record who uploaded which package to > which catalog. Unfortunately, our web proxy destroys this information. > Maybe it can be fixed with some clever HTTP header rewriting, but I > didn't manage to make it work. What's the proxy that we use? Can you show me where in the code this is done? >>> >>> The proxy is just our proxy: echo $http_proxy >>> http://proxy:3128 >> >> Dago can maybe give us more information about which proxy is used. > > Sure, it runs in the "web" zone and is our CSWsquid 3.1,REV=2012.06.15_20 > > Do you have/want access to the webzone? The only reason for which I would wish access is to examine the logs and other similar stuff, maybe experiment a thing or another. -- 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] Non-Maintainer Uploads (NMUs)
Hi Peter, Am 12.08.2013 um 14:14 schrieb Peter FELECAN : > "Maciej (Matchek) Bliziński" writes: >> 2013/8/11 Peter FELECAN : >>> "Maciej (Matchek) Bliziński" writes: >>> I tried and failed. I wanted to record who uploaded which package to which catalog. Unfortunately, our web proxy destroys this information. Maybe it can be fixed with some clever HTTP header rewriting, but I didn't manage to make it work. >>> >>> What's the proxy that we use? >>> >>> Can you show me where in the code this is done? >> >> The proxy is just our proxy: echo $http_proxy >> http://proxy:3128 > > Dago can maybe give us more information about which proxy is used. Sure, it runs in the "web" zone and is our CSWsquid 3.1,REV=2012.06.15_20 Do you have/want access to the webzone? Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/11 Peter FELECAN : >> "Maciej (Matchek) Bliziński" writes: >> >>> I tried and failed. I wanted to record who uploaded which package to >>> which catalog. Unfortunately, our web proxy destroys this information. >>> Maybe it can be fixed with some clever HTTP header rewriting, but I >>> didn't manage to make it work. >> >> What's the proxy that we use? >> >> Can you show me where in the code this is done? > > The proxy is just our proxy: echo $http_proxy > http://proxy:3128 Dago can maybe give us more information about which proxy is used. > It's probably squid. > > The place to retrieve the user is here: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/releases_web.py#L207 Alright. This is the receiving end. Where is the emitting end? > Works in my testing env, and does not work on the buildfarm. > > Maciej > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/11 Peter FELECAN : > "Maciej (Matchek) Bliziński" writes: > >> I tried and failed. I wanted to record who uploaded which package to >> which catalog. Unfortunately, our web proxy destroys this information. >> Maybe it can be fixed with some clever HTTP header rewriting, but I >> didn't manage to make it work. > > What's the proxy that we use? > > Can you show me where in the code this is done? The proxy is just our proxy: echo $http_proxy http://proxy:3128 It's probably squid. The place to retrieve the user is here: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/lib/web/releases_web.py#L207 Works in my testing env, and does not work on the buildfarm. 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] Non-Maintainer Uploads (NMUs)
Laurent Blume writes: > Okay, I'm jumping on this thread as I'm a good example of this, I think: > I've taken over a good amount of packages recently, a lot of them I > don't care particularly for. > > At this point, I've seen rather good arguments exchanged, there's only > one thing I believe was not explained: why is the package owner a > *single* owner? Would it be possible to simply add a name to a list? Indeed. However, the same implementation difficulties occur for one or more users, i.e. adding the uploading user to the database takes the same route and as Maciej said, the proxy is tempering with the data... I'm waiting for an answer from Maciej about the proxy and the part of the code responsible for building the request. -- 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] Non-Maintainer Uploads (NMUs)
Okay, I'm jumping on this thread as I'm a good example of this, I think: I've taken over a good amount of packages recently, a lot of them I don't care particularly for. At this point, I've seen rather good arguments exchanged, there's only one thing I believe was not explained: why is the package owner a *single* owner? Would it be possible to simply add a name to a list? 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] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > I tried and failed. I wanted to record who uploaded which package to > which catalog. Unfortunately, our web proxy destroys this information. > Maybe it can be fixed with some clever HTTP header rewriting, but I > didn't manage to make it work. What's the proxy that we use? Can you show me where in the code this is done? -- 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] Non-Maintainer Uploads (NMUs)
2013/8/11 Peter FELECAN : 1. When you upload a package, you become the package owner/maintainer. >>> >>> The systematic of this association is what's annoying me. >> >> I think it should be named for what it is: who last uploaded the >> package. This is a useful piece of information and we should not >> inhibit it. > > So, we must have another information which is the uploader, displayed on > our web infrastructure. Cannot be taken from the user name of who's > running csw-upload-pkg? I tried and failed. I wanted to record who uploaded which package to which catalog. Unfortunately, our web proxy destroys this information. Maybe it can be fixed with some clever HTTP header rewriting, but I didn't manage to make it work. 2. A package owner/maintainer is responsible for everything that's associated with the package, e.g. any current and future bugs. >>> >>> This is not axiomatic and is what I wish to reasonably relax. >> >> Cool. We'll probably find a middle ground. A lot of that expectation >> revolves around wording used on our website. > > As said above, we should add the information of the user having done the > NMU but keep the mantis ownership of the project. The NMU setting could be a parameter for mgar invocation. Based on this, the appropriate details would be built into pkginfo, and then read by the infrastructure. I don't see any other sane way of implementing this. Instead of one EMAIL setting, we need two: package maintainer and package builder. (You cannot enclose the uploader information, because it's unknown until the upload.) You could invoke mgar with a flag indicating you don't want to be the owner. mgar can look into the buildfarm database to figure out who's the current maintainer of that package. Of course, we need to think what to do if there are discrepancies, e.g. different maintainers for 5.9, 5.10, 5.11, intel and sparc. Or maybe we could make that (no ownership change) the default and make the ownership change a special flag. 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] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/11 Peter FELECAN : >>> When you're running csw-upload-pkg, it's too late. All such >>> information must be inside the package, and that means it has to be >>> done in GAR. Probably as a field in pkginfo. >> >> How's that? The association is not done yet. That this association is >> based on what's in the package I understand. What I don't understand is >> how it's too late: the association is made after the invocation of >> csw-upload-pkg and this can be inhibited in any system that I can >> imagine, directly or by side effect. > > Yes, but inhibited based on what data? The only data the system has, > is the contents of the package. > >> Consequently, if you tell me where >> is the code responsible for the association I can review it and propose >> a concrete modification. > > Is this the line you have in mind? This is where the mantis database > update is done: > http://sourceforge.net/p/opencsw-ruby/code/ci/master/tree/lib/csw/db/mantis.rb#l112 Yes. So, when csw-upload-pkg was invoked with --nmo, it must not modify p.maintainer.username. But that is only the effect. We need to find a place where the cause became reality. >>> 1. When you upload a package, you become the package owner/maintainer. >> >> The systematic of this association is what's annoying me. > > I think it should be named for what it is: who last uploaded the > package. This is a useful piece of information and we should not > inhibit it. So, we must have another information which is the uploader, displayed on our web infrastructure. Cannot be taken from the user name of who's running csw-upload-pkg? >>> 2. A package owner/maintainer is responsible for everything that's >>> associated with the package, e.g. any current and future bugs. >> >> This is not axiomatic and is what I wish to reasonably relax. > > Cool. We'll probably find a middle ground. A lot of that expectation > revolves around wording used on our website. As said above, we should add the information of the user having done the NMU but keep the mantis ownership of the project. >>> 3. You have a small contribution to make. >> >> Quite often. If it's a maintained package I discuss it first with the >> relevant person. >> >>> 4. The benefit of the contribution does not outweigh the burden. >> >> Again, it's not a question of burden but responsible >> management. Dilution of responsibility is a very bad thing and is, >> unfortunately, encountered more and more often in enterprise >> environment. Lets not replicate that. > > We're very different from an enterprise environment. In enterprise, > the employer pays for the employee's time, and the employee's > obligation is to use the time in the way the employer wishes. In an > open source project, people offer contributions based on their innate > motivation. If someone doesn't want to perform a certain task, there > is no way you can make them do it. If you try, they will simply walk > away. Agree with you. However, this doesn't diminish the need for responsibility even though it's a voluntary responsibility: nobody force somebody to be responsible of something. In the case in discussion the current procedure induced by csw-upload-pkg &co force me to became the maintainer which I don't wish because, in some cases, I'm just an opportunistic actor. >>> 5. Therefore, you do not make the contribution. >> >> Even with the incurred burden I make it. The proof is in the logs. > > haha, I don't mean you personally. :) it's an expression as in > "brushing your teeth is healthy". I can rephrase it as "people are > less likely to contribute". If we solve the issue in discussion we will have more contribution at least from my part. >>> You think that #2 is fine and you want to fix #1. >> >> Not exactly. >> >>> I think that #1 is fine and I want to fix #2. >> >> We disagree on the "fineness" of #1 and this affirmation is in >> contradiction with the answer that you give to my question about the >> worthiness of my proposition. > > I understand that you didn't mean that the solution absolutely has to > be a flag for csw-upload-pkg. You probably mean some method of > indicating that you don't want your name to appear on the package's > page. There are many possible ways to achieve that. (Also, I do > believe that if you're building and pushing the package, it should be > somehow reflected on the website.) Is not that I don't want my name associated. On the contrary. If I've done a NMU it must appear in our web infrastructure, e.g. on the QA page, along the true owner of the package. By owner I mean the person which is most willing to work on the package, to correct possible bugs, bump version, &c. -- 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] Non-Maintainer Uploads (NMUs)
Ben Walton writes: > On Sat, Aug 10, 2013 at 4:58 PM, Peter FELECAN wrote: >> Ben Walton writes: >> >>> There would still be a discrepancy between pkginfo and pkgdb. >> >> Can you explain this in more depth please? > > Currently, csw-upload-pkg and pkgdb code backing that are using the > metadata stored directly in the package to determine the value of the > maintainer. pkdb can be made aware of the --nmu usage with csw-upload-pkg, isn't it? > We could override this with a flag as you're suggesting but if someone then > installs the package they'd have the pkginfo file containing information > that is a mismatch with the website view. > > This isn't a deal breaker by any means but I think we can do better. I'm > proposing that the override happens earlier (in GAR) so that pkgdb can be > ignorant of it entirely. But this modifies the recipe. BTW, what incantation would you use for this? > The down side of doing it with GAR is implementing a nice mechanism for the > user to specify the maintainer (different than the current packager). Can you give an example of the mechanism? -- 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] Non-Maintainer Uploads (NMUs)
2013/8/11 Peter FELECAN : >> When you're running csw-upload-pkg, it's too late. All such >> information must be inside the package, and that means it has to be >> done in GAR. Probably as a field in pkginfo. > > How's that? The association is not done yet. That this association is > based on what's in the package I understand. What I don't understand is > how it's too late: the association is made after the invocation of > csw-upload-pkg and this can be inhibited in any system that I can > imagine, directly or by side effect. Yes, but inhibited based on what data? The only data the system has, is the contents of the package. > Consequently, if you tell me where > is the code responsible for the association I can review it and propose > a concrete modification. Is this the line you have in mind? This is where the mantis database update is done: http://sourceforge.net/p/opencsw-ruby/code/ci/master/tree/lib/csw/db/mantis.rb#l112 >> 1. When you upload a package, you become the package owner/maintainer. > > The systematic of this association is what's annoying me. I think it should be named for what it is: who last uploaded the package. This is a useful piece of information and we should not inhibit it. >> 2. A package owner/maintainer is responsible for everything that's >> associated with the package, e.g. any current and future bugs. > > This is not axiomatic and is what I wish to reasonably relax. Cool. We'll probably find a middle ground. A lot of that expectation revolves around wording used on our website. >> 3. You have a small contribution to make. > > Quite often. If it's a maintained package I discuss it first with the > relevant person. > >> 4. The benefit of the contribution does not outweigh the burden. > > Again, it's not a question of burden but responsible > management. Dilution of responsibility is a very bad thing and is, > unfortunately, encountered more and more often in enterprise > environment. Lets not replicate that. We're very different from an enterprise environment. In enterprise, the employer pays for the employee's time, and the employee's obligation is to use the time in the way the employer wishes. In an open source project, people offer contributions based on their innate motivation. If someone doesn't want to perform a certain task, there is no way you can make them do it. If you try, they will simply walk away. >> 5. Therefore, you do not make the contribution. > > Even with the incurred burden I make it. The proof is in the logs. haha, I don't mean you personally. :) it's an expression as in "brushing your teeth is healthy". I can rephrase it as "people are less likely to contribute". >> You think that #2 is fine and you want to fix #1. > > Not exactly. > >> I think that #1 is fine and I want to fix #2. > > We disagree on the "fineness" of #1 and this affirmation is in > contradiction with the answer that you give to my question about the > worthiness of my proposition. I understand that you didn't mean that the solution absolutely has to be a flag for csw-upload-pkg. You probably mean some method of indicating that you don't want your name to appear on the package's page. There are many possible ways to achieve that. (Also, I do believe that if you're building and pushing the package, it should be somehow reflected on the website.) 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] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/11 Peter FELECAN : >> "Maciej (Matchek) Bliziński" writes: >> >>> 2013/8/11 Peter FELECAN : To come back to my proposition, in which part of the code is the association made, i.e. uploader becomes maintainer? Answering this question can simplify my life instead of wandering all the surface of the system. >>> >>> The starting point is here: >>> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L716 >>> >>> Every other bits of infrastructure read this pkginfo field. >> >> This I know. What I wish is to inhibit this, when supplying --nmu to >> csw-upload-pkg for an existing package. Where is this code situated? > > When you're running csw-upload-pkg, it's too late. All such > information must be inside the package, and that means it has to be > done in GAR. Probably as a field in pkginfo. How's that? The association is not done yet. That this association is based on what's in the package I understand. What I don't understand is how it's too late: the association is made after the invocation of csw-upload-pkg and this can be inhibited in any system that I can imagine, directly or by side effect. Consequently, if you tell me where is the code responsible for the association I can review it and propose a concrete modification. >>> I want to ask this question. It might sound like a rhetorical one, but >>> it's not: it's one of the central questions to the discussion: >>> >>> Do you become the owner of the package because you are willing to take >>> on the owner's duties, or do you take on the owner's duties because >>> you've become the package owner? >> >> Neither when I'm doing a NMU. >> >> Now, let me ask a pragmatical question: what is the reason for which my >> proposition is not worthy of implementation? > > But it is! We only need to talk about some details. Good. We agree on this. > I think I understand the idea: you want to be able to contribute > without taking on other associated burden, right? This is definitely > worth implementing. Noted. > IIUC, the problem you're addressing is this: > > 1. When you upload a package, you become the package owner/maintainer. The systematic of this association is what's annoying me. > 2. A package owner/maintainer is responsible for everything that's > associated with the package, e.g. any current and future bugs. This is not axiomatic and is what I wish to reasonably relax. > 3. You have a small contribution to make. Quite often. If it's a maintained package I discuss it first with the relevant person. > 4. The benefit of the contribution does not outweigh the burden. Again, it's not a question of burden but responsible management. Dilution of responsibility is a very bad thing and is, unfortunately, encountered more and more often in enterprise environment. Lets not replicate that. > 5. Therefore, you do not make the contribution. Even with the incurred burden I make it. The proof is in the logs. > You think that #2 is fine and you want to fix #1. Not exactly. > I think that #1 is fine and I want to fix #2. We disagree on the "fineness" of #1 and this affirmation is in contradiction with the answer that you give to my question about the worthiness of my proposition. -- 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] Non-Maintainer Uploads (NMUs)
2013/8/11 Peter FELECAN : > "Maciej (Matchek) Bliziński" writes: > >> 2013/8/11 Peter FELECAN : >>> To come back to my proposition, in which part of the code is the >>> association made, i.e. uploader becomes maintainer? Answering this >>> question can simplify my life instead of wandering all the surface of >>> the system. >> >> The starting point is here: >> http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L716 >> >> Every other bits of infrastructure read this pkginfo field. > > This I know. What I wish is to inhibit this, when supplying --nmu to > csw-upload-pkg for an existing package. Where is this code situated? When you're running csw-upload-pkg, it's too late. All such information must be inside the package, and that means it has to be done in GAR. Probably as a field in pkginfo. >> I want to ask this question. It might sound like a rhetorical one, but >> it's not: it's one of the central questions to the discussion: >> >> Do you become the owner of the package because you are willing to take >> on the owner's duties, or do you take on the owner's duties because >> you've become the package owner? > > Neither when I'm doing a NMU. > > Now, let me ask a pragmatical question: what is the reason for which my > proposition is not worthy of implementation? But it is! We only need to talk about some details. I think I understand the idea: you want to be able to contribute without taking on other associated burden, right? This is definitely worth implementing. IIUC, the problem you're addressing is this: 1. When you upload a package, you become the package owner/maintainer. 2. A package owner/maintainer is responsible for everything that's associated with the package, e.g. any current and future bugs. 3. You have a small contribution to make. 4. The benefit of the contribution does not outweigh the burden. 5. Therefore, you do not make the contribution. You think that #2 is fine and you want to fix #1. I think that #1 is fine and I want to fix #2. 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] Non-Maintainer Uploads (NMUs)
"Maciej (Matchek) Bliziński" writes: > 2013/8/11 Peter FELECAN : >> To come back to my proposition, in which part of the code is the >> association made, i.e. uploader becomes maintainer? Answering this >> question can simplify my life instead of wandering all the surface of >> the system. > > The starting point is here: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L716 > > Every other bits of infrastructure read this pkginfo field. This I know. What I wish is to inhibit this, when supplying --nmu to csw-upload-pkg for an existing package. Where is this code situated? > I want to ask this question. It might sound like a rhetorical one, but > it's not: it's one of the central questions to the discussion: > > Do you become the owner of the package because you are willing to take > on the owner's duties, or do you take on the owner's duties because > you've become the package owner? Neither when I'm doing a NMU. Now, let me ask a pragmatical question: what is the reason for which my proposition is not worthy of implementation? -- 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] Non-Maintainer Uploads (NMUs)
2013/8/11 Peter FELECAN : > To come back to my proposition, in which part of the code is the > association made, i.e. uploader becomes maintainer? Answering this > question can simplify my life instead of wandering all the surface of > the system. The starting point is here: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/gar/v2/gar.pkg.mk#L716 Every other bits of infrastructure read this pkginfo field. I want to ask this question. It might sound like a rhetorical one, but it's not: it's one of the central questions to the discussion: Do you become the owner of the package because you are willing to take on the owner's duties, or do you take on the owner's duties because you've become the package owner? 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] Non-Maintainer Uploads (NMUs)
Yann Rouillard writes: > I do not think the package ownership concept is obsolete. > We can't ask everybody to feel concerned and competent about every package > and some people might join the project just to maintain a few packages that > they really care about. > > Whatever we do, the question in the end is: who feels responsible for > dealing with bugs and updates for a package ? > I don't really believe in the mode "there are no package maintainer, > everybody can update every package", I think this lead to > http://en.wikipedia.org/wiki/Diffusion_of_responsibility > > Even if we don't have any contract, I think there is an implicit commitment > when you take ownership of a package. Debian even listed for instance what > are the responsabilites of a maintainer: > http://www.debian.org/doc/manuals/developers-reference/developer-duties. > > As a user of a package, it's also important to know wether the package you > want to use has some maintainers behind or if it's in best effort mode by > people who may even not use the package. > > > What is obsolete I think is the to have one maintainer package that is the > only one entitled to change the package (we already moved from that), we > should instead: > > - promote team maintenance rather than one maintainer per package, > - promote non-maintainer uploads with some rules, > - have a special team for orphaned packages. > > > Whatever the outcome, we will need anyway to change a bit the > infrastructure because it is not adapted to either team maintenance or > globally shared maintenance mode: > >- the bugtracker will always send the bugs to the last person that > uploaded the package and the the bug summary page does the same > http://www.opencsw.org/buglist/maintainer.cgi?maintainer=laurent > >- the qa page and maintainer page still list the packages last uploaded > by someone like it was maintained by the person (it's still written > "maintained by" by the way): http://www.opencsw.org/maintainers/maciej/ > > 2013/8/11 Maciej (Matchek) Bliziński > >> The current notion throughout our code base is that the user who runs >> mgar, and the user who owns the package is the same user. To separate >> these two concepts, the code needs modifications in many places. >> >> But I would also like to challenge Peter's not willing to inherit the >> packages. I was hoping that the notion of package ownership has >> already eroded. It was different in the times when package sources >> were private. Other people did not have access to the build recipes, >> so the only way to get the package modified, was to ask the sole >> person who had the sources. Fortunately, we're in a different world >> now, we share the code. Anybody can get the code and build it. >> >> We're a volunteer organization, we do not hold any binding contracts >> with regards to package maintenance. My name on a package means that I >> was the last person to modify the package, which means I might know >> something about the package and you have an idea of whom to talk to. >> It does not entitle you to any demands with relation to the package. I >> might have been the last person to upload the package, but I be no >> longer willing to work on the package. Therefore, I would suggest we >> do not embed in our infrastructure the outdated concept of package >> ownership. >> >> Let's take a step back: what's wrong with having your name show up >> next to a package to which you made a small change? >> I was on the point to answer when Yann's message come in. He answers very well my worries, especially the one about responsibility dilution. I have no issues with working on as many packages as it gets --- have done that a lot lately thus my set of "maintained" packages get bigger and bigger without intentionallity of my part of a real care. Until we have a way of collective maintainceship I think that my proposition is worthy of implementation. Even if we have a collective/group maintainceship the process of entering that collective/group must be more than a NMU action which can be motivated by other reasons than the intent of care for that package. To come back to my proposition, in which part of the code is the association made, i.e. uploader becomes maintainer? Answering this question can simplify my life instead of wandering all the surface of the system. -- 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] Non-Maintainer Uploads (NMUs)
I do not think the package ownership concept is obsolete. We can't ask everybody to feel concerned and competent about every package and some people might join the project just to maintain a few packages that they really care about. Whatever we do, the question in the end is: who feels responsible for dealing with bugs and updates for a package ? I don't really believe in the mode "there are no package maintainer, everybody can update every package", I think this lead to http://en.wikipedia.org/wiki/Diffusion_of_responsibility Even if we don't have any contract, I think there is an implicit commitment when you take ownership of a package. Debian even listed for instance what are the responsabilites of a maintainer: http://www.debian.org/doc/manuals/developers-reference/developer-duties. As a user of a package, it's also important to know wether the package you want to use has some maintainers behind or if it's in best effort mode by people who may even not use the package. What is obsolete I think is the to have one maintainer package that is the only one entitled to change the package (we already moved from that), we should instead: - promote team maintenance rather than one maintainer per package, - promote non-maintainer uploads with some rules, - have a special team for orphaned packages. Whatever the outcome, we will need anyway to change a bit the infrastructure because it is not adapted to either team maintenance or globally shared maintenance mode: - the bugtracker will always send the bugs to the last person that uploaded the package and the the bug summary page does the same http://www.opencsw.org/buglist/maintainer.cgi?maintainer=laurent - the qa page and maintainer page still list the packages last uploaded by someone like it was maintained by the person (it's still written "maintained by" by the way): http://www.opencsw.org/maintainers/maciej/ Yann 2013/8/11 Maciej (Matchek) Bliziński > The current notion throughout our code base is that the user who runs > mgar, and the user who owns the package is the same user. To separate > these two concepts, the code needs modifications in many places. > > But I would also like to challenge Peter's not willing to inherit the > packages. I was hoping that the notion of package ownership has > already eroded. It was different in the times when package sources > were private. Other people did not have access to the build recipes, > so the only way to get the package modified, was to ask the sole > person who had the sources. Fortunately, we're in a different world > now, we share the code. Anybody can get the code and build it. > > We're a volunteer organization, we do not hold any binding contracts > with regards to package maintenance. My name on a package means that I > was the last person to modify the package, which means I might know > something about the package and you have an idea of whom to talk to. > It does not entitle you to any demands with relation to the package. I > might have been the last person to upload the package, but I be no > longer willing to work on the package. Therefore, I would suggest we > do not embed in our infrastructure the outdated concept of package > ownership. > > Let's take a step back: what's wrong with having your name show up > next to a package to which you made a small change? > > Maciej > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
The current notion throughout our code base is that the user who runs mgar, and the user who owns the package is the same user. To separate these two concepts, the code needs modifications in many places. But I would also like to challenge Peter's not willing to inherit the packages. I was hoping that the notion of package ownership has already eroded. It was different in the times when package sources were private. Other people did not have access to the build recipes, so the only way to get the package modified, was to ask the sole person who had the sources. Fortunately, we're in a different world now, we share the code. Anybody can get the code and build it. We're a volunteer organization, we do not hold any binding contracts with regards to package maintenance. My name on a package means that I was the last person to modify the package, which means I might know something about the package and you have an idea of whom to talk to. It does not entitle you to any demands with relation to the package. I might have been the last person to upload the package, but I be no longer willing to work on the package. Therefore, I would suggest we do not embed in our infrastructure the outdated concept of package ownership. Let's take a step back: what's wrong with having your name show up next to a package to which you made a small change? 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] Non-Maintainer Uploads (NMUs)
On Sat, Aug 10, 2013 at 4:58 PM, Peter FELECAN wrote: > Ben Walton writes: > >> There would still be a discrepancy between pkginfo and pkgdb. > > Can you explain this in more depth please? Currently, csw-upload-pkg and pkgdb code backing that are using the metadata stored directly in the package to determine the value of the maintainer. We could override this with a flag as you're suggesting but if someone then installs the package they'd have the pkginfo file containing information that is a mismatch with the website view. This isn't a deal breaker by any means but I think we can do better. I'm proposing that the override happens earlier (in GAR) so that pkgdb can be ignorant of it entirely. The down side of doing it with GAR is implementing a nice mechanism for the user to specify the maintainer (different than the current packager). Thanks -Ben > -- > Peter > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. -- --- Take the risk of thinking for yourself. Much more happiness, truth, beauty and wisdom will come to you that way. -Christopher Hitchens --- ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Non-Maintainer Uploads (NMUs)
Ben Walton writes: > There would still be a discrepancy between pkginfo and pkgdb. Can you explain this in more depth please? -- 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] Non-Maintainer Uploads (NMUs)
There would still be a discrepancy between pkginfo and pkgdb. It would be better to handle this in GAR. An override of the maintainer field and the addition of a builder field or some such. This wouldn't require upload changes but should facilitate the required policy change. Hth. -Ben On Aug 10, 2013 4:42 PM, "Peter FELECAN" wrote: > We already had this discussion but we still didn't get a result. > > Now, that I need to re-spin a lot of python modules to get their > multi-versioned packages I really feel the need of this. > > In the work related to the availability of Python 2.7.x I inherited > without really willing the 2.x interpreters packages. I know that > the original maintainer can get them back by uploading a new > release, however it seems to me a little bit tedious and unduly > augment the already big cardinal of my maintained packages set. > > What I propose is to define a new option to csw-upload-pkg, let > name it '--nmu' which doesn't change the maintainer of an already > cataloged package when an upload is given. The default action, when > this option is not given, is to change the maintainer. > > I started to look at the code but I'm not really advancing as real > life activities are requesting my attention... > > Is somebody familiar with the code and can implement this? > > TIA > -- > Peter > ___ > maintainers mailing list > maintainers@lists.opencsw.org > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. > ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
[csw-maintainers] Non-Maintainer Uploads (NMUs)
We already had this discussion but we still didn't get a result. Now, that I need to re-spin a lot of python modules to get their multi-versioned packages I really feel the need of this. In the work related to the availability of Python 2.7.x I inherited without really willing the 2.x interpreters packages. I know that the original maintainer can get them back by uploading a new release, however it seems to me a little bit tedious and unduly augment the already big cardinal of my maintained packages set. What I propose is to define a new option to csw-upload-pkg, let name it '--nmu' which doesn't change the maintainer of an already cataloged package when an upload is given. The default action, when this option is not given, is to change the maintainer. I started to look at the code but I'm not really advancing as real life activities are requesting my attention... Is somebody familiar with the code and can implement this? TIA -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
